In exploring the currently numerous different options for creating an interactive experience with animation on the web I’ve been gravitating toward SVG as a promising candidate to offer a rich experience.

I thought I’d try a few experiments to see what exactly is possible and was quite pleased with the ability access and manipulate the various elements within an SVG using javascript.

Using an SVG that I designed and exported from Adobe Illustrator, this mandatory carousel example demonstrates the ability to assign mouse events and other event listeners to different objects and even reposition, scale and change the opacity of different objects. Not shown in this example is the ability to rotate or modify the appearance of objects within the SVG using CSS, though, this is entirely possible.

Give it a try on your PC or iPad or whatever!

See the Example

Feel free to view the source and see how it’s all done.

Links / Thanks

• jQuery SVG Plugin
• Floorplanner Tech Blog – Previous iPad/SVG Experiments
• Lee Brimelow / Gotoandlearn – Great resource for learning interactive development
• newblack on Flashkit forums – Trig method for circular positioning

There are about a hundred ways to add animation and interactivity to a webpage nowadays, including, but probably not limited to the following list of options that I’ve explored:

• CSS Transitions
• CSS Transforms (2D and 3D) + Javascript
• Flash
• JQuery/Javascript/JS Library Animation
• Webkit Keyframe Animations
• SVG Animation with Javascript
• SVG Animation with SMIL
• Canvas animation with javascript (2d context)
• WebGL in Canvas (3d context) animated with Javascript

Some of these are new, others have been around for a while. But with all these options, web developers should have no problem getting in bed with whichever technology is easiest for them to work with, and it’s off to the races, right? If it were only that simple. In fact, every option above has at least a few ‘gotchas’ that will keep you on your toes.

Let’s take a closer look at a few of these and look at some of the advantages, as well as their inevitable pitfalls.

Let’s start with Flash

I love flash. Why? Flash is an excellent platform for advanced animation and interactivity that runs very consistently on everything that supports it. If you develop something in Flash, you can generally expect it to look and operate the same on a PC as it will on a tablet or any other device, give or take performance ability based on processor power and a few other factors. Interfaces in Flash are highly customizable and there are numerous IDE’s out there for building and developing them. This all, incidentally, also means faster development time. And, Flash has been around a long time, and as such, it has been refined to the point where it is one of your most efficient options, performance-wise.

Flash player, being a plugin, can also theoretically be installed on just about any modern device (and for the most part, it can be), it would be natural to assume that it is your most compatible option.

In walks iOS. Alas, we all know that, being 2011, this is about a big a pitfall as a technology could face. We all want wickedly cool websites, but if it cannot work on a mobile device, what good is it? I realize iOS isn’t the only mobile OS out there, but it’s safe to say that a huge number of people love Apple shit. And that’s enough to turn one away, in some aspects.

Today,  web/interactive developers have to decide, based on target audience, whether it’s worth it to build a potentially more advanced interactive website in a shorter timeframe, or instead adopt newer un-finalized technologies in an effort to achieve the same effect. This, of course, is if we want our product to be the same across different platforms and devices. In many cases, it may actually be easier to build different experiences for the various different devices which we’re targeting.

Summary: Flash is the winning interactive web and animation technology for PC’s, but not the right choice for a mobile audience- a growing market.

WebGL

WebGL is an open-source technology supported by a few newer browsers. It allows developers to make use of 3D Graphics API’s to build and incorporate some pretty impressive interactions into a webpage through the HTML5 canvas tag, without the need for any plugins. Some of the early experiments with WebGL are pretty impressive, and there are even some Javascript libraries like J3D popping up that will start to put some real power in the hands of developers looking to develop with it.

Unfortunately WebGL is still in it’s infancy, and is currently not even supported by iOS either. Because of the current lack of support, WebGL is probably still not ready for the masses, but will be interesting to keep an eye on this one as it develops.

Summary: Promising 3D graphics rendering technology that could be great for producing games on the web in the future, as well as numerous other potential applications.

SVG Animation

Surprisingly, there has not been as much hype about SVG animation as their has been about some of the other “HTML5″ technologies. SVG is another open source web technology, but for handling mainly vector graphics. I previously thought that you needed the <canvas> tag to work with SVG and vectors on the web, however this is not the case at all. I got particularly excited when I realized you can animate, manipulate and add interactivity directly to SVG graphics on a web page with some simple Javascript. This is all great news, since it is extremely easy to export graphics from a program like Adobe Illustrator.

Another way of animating SVG graphics is using SMIL. Which is basically another type of XML markup that can be used to configure some very simple animations within an SVG file. I haven’t experimented with SMIL extensively but looks like it could be useful in some cases for simple animations.

SVG animation is progressing quickly and is consistently getting growing browser support. There is even a library, SVGWeb, for adding backwards-compatibility for SVG to older browsers than did not support it. Unfortunately, SVG is currently not a robust enough specification to allow for animation and interactivity as advanced as something like Flash (which, as far as I’m concernced, is still the benchmark). And backwards-compatibility is spotty (even with a library like SVGWeb). It should also be noted that SVG is not primarily designed as an interactive vector format.

Summary: SVG is another promising technology. The concept of being about export vector graphics from Illustrator and simply assign animation and interactivity using Javascript is exciting. But there is still work to be done before it’s  ready for prime-time.

CSS Transitions

CSS transitions recently captured my heart a little bit, at least as far as simple animations that do not require any kind of timeline are concerned. They are exactly that. They are useful for animating in between properties/style changes that occur on an HTML element. The nice thing about CSS transitions is that they are hardware accelerated, making them crazy smooth and sexy looking. Sorry, I got a little excited there.

Many people argue that CSS is not the place to be handling animations. And it’s a valid argument. But the deed has been done, and there are some obvious advantages – so it would be good now to at least see some improvements. For example, there is currently no way of tracking, or synchronizing, or modifying/stopping transitions as they run. The other issue of course is that CSS transitions are not supported by older browsers – namely the Windows OS default Internet Explorer versions <10.

Summary: CSS Transitions are very useful for enhancing the experience in newer browsers with some simple, easy-to-implement animations. However cannot be fully relied upon for a complete, consistent interactive experience for all users.

Webkit Keyframe Animations

Another option to throw on the pile is webkit keyframe animations. This is another method of configuring animation through CSS. As such, it uses a different syntax and approach than transitions. The advantage here though is that you can perform a more complex timeline of animations with the ability to track them a little better. And like CSS transitions, they are hardware accelerated too.

It seems to me that the people at webkit just weren’t getting what they wanted out of CSS transitions, so they just went ahead and built their own specification to do what they wanted. Which is fine. But at this point there are so many ways to animate things, that having yet another specification just adds to the confusion. It should also be mentioned that webkit browsers are currently the ONLY browsers to support this functionality.

Summary: Webkit keyframe animations are an interesting proposal to offer some necessary functionality for animation, but lack of support makes it difficult to get behind in the greater picture. They may, however, be quite useful in building mobile websites/applications since they would run fine in iOS or Android browsers.

Animation & Interactivity in HTML5 Canvas

There is a surprising amount of hype/fan following behind the HTML5 canvas. Granted, there are a number of pretty cool and even useful things that can be done with this technology. However, I think there is an even greater confusion as to what canvas actually is and does. Canvas is particularly great at drawing and manipulating graphics and rendering them – even in real time. Canvas supports drawing with either vector or raster graphics, though, the actual output is only raster.

Where canvas lacks, and what I think a lot of people don’t realize, is that canvas is really not a suitable medium for animation or interactivity as it stands. In fact, it is quite the opposite. Because there is no API for animation, developers wanting to simulate animation on the canvas need to clear and redraw the entire canvas at every frame. This can be extremely taxing and processor intensive. Furthermore, there are no actual nodes, or ways of accessing objects drawn onto the canvas using javascript. This means that in order to add interactivity to the actual canvas, a developer needs to specify, in a seperate manner, coordinates of the canvas that are to be interactive. Another inefficient method, both in terms of computing power and development time.

What I think canvas is most useful for is in it’s name – a canvas. There are a number of useful things it can do with graphics, and it certainly has its place in the HTML specification. Animation and interactivity, however, is not it.

Summary: Probably not actually a very practical choice for animation unless you’re making some sort of computer generated visualization. There are a number of other ways to animate, as noted above in this post, including SVG, that will in most cases have better performance and require less development time.

Over the past year or so I’ve been slowly adding  more and more “CSS3″ techniques to my web dev tool belt as I experiment with them. They aren’t all necessarily practical for all occasions, but since Mozilla and IE9 IE10 added support for CSS transitions, they have nicely been finding their place in my arsenal.

What are CSS transitions?

CSS transitions are browser-native animations that can be configured through CSS and do not require Javascript to run. When properly configured, you can effectively transition styles between CSS properties. The concept is simple, but there is, understandably, a lot of confusion surrounding their use and usage.

Go to Example & Code

Why do they rock?

For certain animations that require a great deal of control, Javascript or jQuery is still a great tool for the job. CSS transitions, however, are great for performing simple, smooth animations. They can make your life a bit easier by reducing the amount of Javascript and event listeners you need, and best of all, they are hardware accelerated – meaning they will be much smoother and sexier than your standard JS animation. They also nicely degrade for older browsers – meaning they will still get the effect of a distinct change, just without the animation.

How to use CSS Transitions

Consider a style you’ve maybe already written for a link on your page:

a.myLink {
    display:block;
    width:75px;
    height:75px;
    background-color:#9C0;
    color:#fff;
    padding:20px;
}

And some different additional styles you may have for it’s :hover state:

a.myLink:hover {
    margin-left:40px;
    width:150px;
    padding:40px;
    height:15px;
}

Simple stuff. Currently, there would be no animation. It would be an abrupt jump in between the styles in each state. OK in 2008, but today, we can do better! To enable a CSS transition, all you have to do is add a few extra lines into the main style block (that is, it’s default -or original- state). So the first style block from our example would now look like this:

a.myLink {
    display:block;
    width:75px;
    height:75px;
    background-color:#9C0;
    color:#fff;
    padding:20px;
    -webkit-transition: all 200ms ease-in-out 0s;
    -moz-transition: all 200ms ease-in-out 0s;
    -o-transition: all 200ms ease-in-out 0s;
    transition: all 200ms ease-in-out 0s;
}

Make note of the last four CSS declarations in our rule now. You may notice, and indeed they are, a bit repetitive. But although they all do the same thing, all four are necessary for maximum web browser compatibility. The key thing to understand here though, is that the transitions themselves are actually configurable here. In the example above we’ve told it to animate all properties (you could instead specify a single property if all properties are not necessary), it will animate for 200 milliseconds, using the ease-in-out easing method, with a zero second delay before it runs.

Though these new animations aren’t yet fully implemented, and lack support from older browsers, they still offer web developers a simple new way to add unobtrusive hardware accelerated, maintenance-free, javascript-free animations to web pages for their users who have up-to-date browsers.

Links

• CSS Transitions on the Mozilla Developer Network
• John Resig Comparing CSS Animations and Javascript Animations
• More Examples and Explanation on CSS3 Transitions by Richard Bradshaw