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.

They Keep Stealing My Thunder ...

Apparently, things sound a lot more impressive when Steve Jobs or Eric Schmidt say things than when I do. For good reason I guess ... . Either way, I'm riding a prediction hot streak stretching back a  few years - hopefully they'll start paying off in a big way soon. For posterity's sake I'd like to make a few on virtual paper so that I can someday show my kids that ,in fact, I am right about somethings!

So, here goes - my predictions sure to go wrong:

PREDICTION: HP's acquisition of WebOS will be a winner. The importance of good UI is starting to be understood by the world (thanks Steve). WebOS is by far the best of the rest when it comes to UI on mobile devices and HP has the power to make something of it. Microsoft needs to prove that they've got a phone/tablet OS with legs, Android needs to get a better UI (they're working on it) ... so if HP puts the whole package in the market this year they'll have a seat at the table. They also are showing signs of getting their sexy back and polishing their PR image. That creaking you hear is the turning of the QE2, Google and Apple beware - it's headed your way!

PREDICTION: Google's acquisition of On2 won't work out. Their attempt to create an open video standard on top of On2's VP8 is going to turn into a morass. They chose an inferior codec to H.264 and one that is also open to all kinds of patent claims from 3rd parties. They must have known that both problems are there  - or they do their due diligence a lot worse than I believe they do. It must be that they don't believe there is another viable codec that could work as well as H.264 or that there is no video codec free of patent issues. They're wrong on both counts (more on that in a different posting). More importantly, even if they are right, they've underestimated people's appetites for legal risk. Under patent law if you (e.g. Comcast) sell a product (e.g. video) that infringes someone's patents (e.g. Phillips) you can't be shielded by a 3rd party (Google) for infringing. Sure Google can stand next to you at trial and even pay the damages, but you are still a defendant at the trial - and that really sucks.

HTML5 IS Mobile

Let me start by saying I'm not a hater. I really like much of Adobe's offerings - but I've hated Flash for a long time. I've hated it all the more because, for a long time, it was an absolute necessity. After slaving for several months in 1999/2000 writing one of the first cross-browser "DHTML" libraries, I really had to admit that Flash was a better solution - in fact it may still be in the desktop world.

So, I just gave up on the desktop world a few years ago. Don't ask me about it, in my eyes it barely exists anymore. If you don't know that Mobile is where the action is at, then you've apparently been on walk-about for the last few years. I'd lay odds that within 3 years tablets will have replaced 75%+ of laptop and desktop sales.

So, let's take a quick look at the mobile world's browsers - iPhone = webkit, Android = webkit, Nokia = webkit, HP/Palm = webkit, Blackberry 6.0 = webkit ... see where I'm going here? Did you notice any major mobile smart device platform that isn't on the list? Of course you didn't - because the one you're thinking of is as irrelevant right now as the desktop.

I know, you'll try and tell me that webkit doesn't equal HTML5 ... I'm not one to get stuck on semantics. Webkit is the closest thing to that mythical HTML5 beast as you'll find in the wild. And I'll tell you what, it's better than Flash! If you don't believe me, check out http://www.appmobi.com/gallery.aspx to see samples of what you can do in native apps using only HTML5 and Javascript.

Why is this so much better than Flash? Because it's not one vendors imposed death grip on all things cool in apps - whether those apps are web based or not. And when I say one vendor I don't just mean Adobe/Flash, I mean: Microsoft/C#, Apple/Objective-C, Oracle/Java, etc.. Adobe did a great job with Flash and it filled a need - but we'd all be doing ourselves a collective disservice if we adopted it on mobile. How many people reading this are expert in any of those technologies - let alone all of them? HTML5 is the savior from that tyranny - not Flash! We've been promised newer/better versions of Flash on mobile devices for many years - was FlashLite 3.1 so great that it was worth waiting 2 years to have it show-up on all of 3 devices no-one cares about?

Adobe's role is to scream out that Flash shouldn't be pulled off of life-support on mobile. We know better and should respectfully allow that once great product to go gently into the good night.