Frustrating CSS Animations

I want to like CSS3 animations: they seem cleaner than relying on setTimeout() or setInterval()-based Javascript animations, generally run faster and are optimized by the browser, sometimes even hardware accelerated. If I want smooth animations in a mobile browser, CSS3 is pretty much the only way to go.

But it always feels like I’m “hacking” CSS; that is, I punch in a series of properties, and through some set of obscure CSS syntactic and resolution rules, I’m able to get something that approximates what I really want. It’s one of the reasons why backend engineers hate trying to understand the black box that is the CSS rule engine.

CSS animations don’t make this better.

A little background – CSS3 provides two main ways to animate your DOM elements:

For simple animations (e.g., sliding a box, rotating an image, etc.), they work pretty well with their limited syntax and options. There have been plenty of interesting CSS3 animation demos, but most of them concentrate on showcasing one special effect or some small piece of desktop UI. The CSS rules are pretty straight-forward, and most just play around with rotations and 3D transforms anyway.

But for webapps, with dynamically-created DOM elements and various animations for a variety of actions, CSS is a complete pain to deal with:

Maybe I’m stepping beyond what CSS animations were designed for, and expecting a more scriptable syntax and malleability with the feature; I can understand limiting the number of properties for common cases and for browser makers to optimize for them. The lack of integration with the DOM interface, though – when a lot of application state, models, and interactions are coded and stored in Javascript – make them much more limited than they really should be.