Dispelling the Android CSS animation myths

Posted on

We live in good times as web developer/designers. There are more fantastic resources available today than there ever have been — we have websites like QuirksMode, Can I Use?, and the recent Mobile HTML5 to tell us what features we can expect to use on a myriad of operating systems, browsers and mobile devices. Super! But there’s a recurring theme across all of these websites. They all tell us that Android fully supports CSS animations.

Android flaunting it’s CSS animation support. But not so fast — there’s more to it than this.

That’s crazy talk, Dan! I hear you say. Open up any Android 2.0+ device and check out this feature detection page. Sitting, quite proudly, will be the words “css animation” — Modernizr says it’s fully supported. So over you go to your CSS file and pump in a bunch of amazing CSS animations to make your website fly. Back to the Droid we go, and what do we find?

These aren’t the Androids we’re looking for.

We find absolutely nothing.

Here’s the thing: CSS animations are supported by Android devices — but only if a single property is changed. As soon as you try to animate more than one property at once, the entire element disappears. In non-native Android browsers, the element will be visible for the duration of the animation, but will hide immediately after it’s finished. This is true for (as far as I know) all Android devices below 4.0. Testing for 4.0 is yet to be done.

So what can we do? Well, if you’re only animating a single property, such as opacity or transform, that’s fine. Nothing to worry about. However, for more than one property, you’ll need to put each of the properties into their own keyframe declaration. Here’s a handy example:

@-webkit-keyframes myAnimation {
    from {
        opacity: 0;
        -webkit-transform: translateY(-20px);
    }

    to {
        opacity: 1;
        -webkit-transform: translateY(0);
    }
}

/* That animation won't work. But, if we put each property into it's own keyframe declaration, it will work. */

@-webkit-keyframes a-opacity {
    from { opacity: 0; }
      to { opacity: 1; }
}

@-webkit-keyframes a-transform {
    from { -webkit-transform: translateY(-20px); }
      to { -webkit-transform: translateY(  0  ); }
}

This, my friends, is a very real and serious issue. The Android browser will always claim to support CSS animation. The compatibility charts will also praise Android for it’s support. Web authors will write WebKit specific CSS animations which will work great on WebKit browsers — except on Android, where any content within the animated element will never see the light of day. There’s no way around it, other than UA sniffing, which is undesirable to say the least.

What needs to happen, more than anything at this stage, is for people to raise awareness of this issue. I hope this gets as far as the authors of sites such as Can I Use?, Modernizr et al so that we can make sure people are aware of the issue. Tread with caution, animation authors — and help spread the word!

Update: it turns out Android 4.0 actually addresses this issue. Still, we need to urge the authors of these resources to explicitly mention that full support isn’t available in previous versions of Android.

  • http://paulirish.com Paul Irish
  • http://twitter.com/Fyrd Alexis Deveria

    Interesting, I hadn’t seen this bug before, but I have seen others, including a sudden white page flash when starting an animation in JS and the inability to animate transform matrices in Android 2.x.

    Thanks for posting this, I’ve changed the caniuse.com support to “partial”.

  • http://blog.oxiane.com Alain Boudard

    very Interesting ! Thanks for the review !!

  • Christoph Martens

    Well, the same bug exists for transitions. As far as I know it seems to be the same revision / WebKit port where you will need additional containing elements for each additional “transitioning” property.

    As there is also the bug with declaring multiple transitions properties via shorthand notation (-webkit-transition: ‘opacity, transform’ …) that might be a similar problem.

  • Richard Scarrott

    This is a shame however surely your .touch.no-webgl fix is worse than UA sniffing as it defeats the point of feature detection when you’re sniffing out unrelated features that just happen to be a combo that target the browser your after…

    • http://daneden.me Dan Eden

      I agree it’s not ideal, but short of serving no animations at all it’s the closest we’ll get. If you’re using Modernizr then it requires no extra JS, which is great — and Modernizr has a pretty damn small footprint anyway.

      There *is* a PHP UA checker which is faster and more reliable than the JavaScript alternatives, I’ve mentioned it briefly in this article.

  • Pingback: Weekly #27 | fitml.com Blog

  • Pingback: Bruce Lawson’s personal site  : Reading List

  • Pingback: Revision 52: Android 4.0, Webvideo & CoffeeScript | Working Draft

  • Pingback: Optimising animations and transitions / Daniel Eden

  • Pingback: Css rotation not applied in android (phonegap) : Android Community - For Application Development

  • Pingback: [译]Modernizr官方文档 | Mr.X