Animation: CSS3 or HTML5?

There's a lot of confusion about what HTML5 and CSS3 actually are, where to get the "real" facts, what techniques actually work, and what techniques work well. I'm going to be a bit blasé here and slightly redefine the meanings of HTML5 and CSS3 for the purposes of this discussion. I'll catch a lot of heat from the purists who will say HTML5 and CSS3 have nothing to do with my definitions - complain if you must, I've moved on already. Then I'll skip to the last question - "what techniques work well" on iOS and Android.

For purposes of animation, HTML5 is herein defined as dynamic HTML manipulated through javascript of individual components of the style attribute of an HTML element.

For purposes of animation, CSS3 is herein define as definition of a style in a style block or style sheet and application of that animation style to an elements style class.

Ok, let's get on with it ...

For Fast Animation, use HTML5 

Slow animations without interactivity (e.g. repetitive snow flakes falling) are best done in CSS3. You'll find plenty of examples of that on the web. But what about high-speed animations? If you look at the source code downloadable in the appMobi Gallery for the Soda Can demo, what you see on your device is a multi-part animation that happens 100 times a second on iPhone/iPad (less frequently on Android where the accelerometer give readings less frequently). The effect of rolling the soda can around the table is accomplished by manipulating a soda can outline and the soda can label. Leaving aside all the calculations of the physics - the div containing the the can components (outline and label) needs to be moved ("translated" in javascript HTML5 parlance) and rotated, and the label has to be translated relative to the div as well. This happens pretty smoothly - even on the Gen 1 iTouch we have laying around the office. Here's a sample of the source (full source downloadable from the appMobi Gallery)


container.style.webkitTransform = 'translate(' + current_left + 'px, ' + current_top + 'px) rotate(' + canangle + 'deg) scale(.85, .85)';
label.style.webkitTransform = 'translate(' + labelleft + 'px, 0px)';


If you're paying close attention you'll notice the scale operation thrown in there for good measure - it's only there because I was lazy and didn't feel like breaking out PhotoShop to scale the image. Erm ... I mean I wanted to show how inefficient you could be as a coder and still get great results ;)

By contrast, the first time we wrote the Coin Flip demo (source also available), we used CSS3 animations (changing the style class to a pre-defined animation). The results were less than dazzling. I can't really tell you why ... so we re-wrote Coin Flip to work similarly to  Soda Can and it you can see it works very nicely now.

setTimeout/setInterval is much more accurate and lightweight than I thought


This surprised me a little. Actually, this surprised me a lot! I thought setTimeout would be a dog. A little timing code similar to the following showed me I was wrong ...
/*------------SAMPLE CODE----------------------------*/

var mspercall = 0;
var totaltime = 0;
var numberofsamples = 0;
var lasttime = 0;

function timeme() {

    if (lasttime == 0) {
        lasttime = new Date().getTime();
    }
    else {
        numberofsamples++;
        var newtime = new Date().getTime();
        totaltime += (newtime - lasttime);
        lasttime = newtime;
        mspercall = totaltime / numberofsamples;
      
    }
    //add code here to write results to a debug div
 
}

setInterval ('timeme()', 50);

/*----------------------------------------*/

Use CSS3/webkit-marquee for tickers
In contrast to the last item, timeout based animations that need to go more slowly (like a news ticker) require a lot of javascript code to get the correct visual effect. There's really no need for it, just used the marquee webkit style:
.marquee
{
white-space: nowrap; overflow: hidden;
overflow-x:-webkit-marquee;
-webkit-marquee-direction: backwards;
-webkit-marquee-style: alternate;
-webkit-marquee-speed: normal;
-webkit-marquee-increment: small;
-webkit-marquee-repetition: 4;
}


For the love of God - don't use opacity frequently
It's just slow. If you are doing a lot of animation, using opacity will bring things to a grinding halt. If you are trying to write a game where, e.g., ghosts blink with different opacity as they move around the screen, I'd strongly suggest swapping images with different alpha levels as opposed to set the opacity of a single image. I'd love to give more details on the why opacity is the equivalent of animation tar - but I just know it ain't your friend.