Introducing Web Animations

Why Web Animations? A summary of happenings until now

On the Web today we have CSS Animation (including Transitions) and SVG Animation and they both have their problems. For example, CSS is so simple it doesn’t even support synchronization and SVG is pretty hairy when it comes to interval negotiation and syncbase timing—and it’s SVG-only. Most of all though, they’re completely separate.

Also, Microsoft don’t support SVG Animation. They have consistently maintained that they want to see a single model for animation on the Web (e.g. minutes) and that that model should have an API. That’s a very reasonable position in my mind, albeit frustrating for authors who want to use SVG Animation now.

The story since then is as follows:

• On several occasions throughout 2011 and 2012 I proposed various alternatives (#1 – presentation, #2, #3) for harmonizing the two such as importing SVG features into CSS and vice versa. People mostly just nodded in agreement and nothing happened.
• In January 2012, Adobe wisely suggested I go away and prepare a concrete proposal so people can get a feel for what is might look like. Adobe also offered to assist where they could.
• At the end of January 2012 I invited a contact from Google to join in since he had some great ideas about state machines.
• In March 2012 folks from Adobe, Google and I (Mozilla) got together in Tokyo and hacked out a first version of the spec.
• In May 2012 we got approval from the CSS and SVG working groups to continue this work as an official work item.
• In September 2012 we presented a demo of the work at the Graphical Web conference in Zurich (video recording).
• In June 2013 we got approval from the CSS and SVG working groups to publish a FPWD.
• Today (25 June 2013) we finally published something!

What’s in the box?

Basically, this:

Web Animations is essentially a common model for animation that underlies CSS and SVG. It covers the common features of both plus a few only found in one or the other.

It also has a few extra features not currently found in either:

Timing groups

This is the primary means of synchronization.

It’s quite powerful but I’ll leave the details and justification for this to a separate post.

Speed control (#1 and #2)

This is a requested feature for SVG2 and may be useful for achieving reversing effects such as exposed in CSS.

Custom effects (API)

This allows the Web Animations timing model to be used to drive animations of HTML canvas etc. by registering a script callback.

Iteration start

This is a minor but much requested feature that allows you to start an animation part-way through its interval.

What’s not included?

Bear in mind that Web Animations is essentially a model. It’s not a declarative syntax. That’s something left to other specs. The API happens to be bundled with the model simply because that makes it easy to keep the two in sync.

The arrangement is as follows:

The CSS-specific features required for CSS animations and transitions will be covered in a separate specification, possibly called “CSS Animations/Transitions level 4” which expresses its features in terms of the Web Animations model.

Likewise, current SVG features such as syncbase timing, or targetting attributes (not just CSS properties) will be covered by a separate specification (my next task) expressed in terms of that model. That specification may be called something like “SVG Animation” but I suspect not since quite a few people have expressed interest in allowing it to apply to HTML content too.

Other features that are not included:

• Bounce/spring timing functions – we really wanted to make this possible and have a couple of simple extensions to timing functions to allow this but we haven’t yet reached agreement about which one is best so we’re leaving them both out for now.
  The plan is to follow up with a separate specification which provides additional timing functions anyway.
• (In fact, with the current working draft, you can’t even do more than one timing function over an animation currently but that will be fixed in the next draft when we introduce chained timing functions).
• Media integration – this is something a lot of people have been asking for but we decided to postpone it in the interests of progressing the spec along.
  The good news is this used to be part of the spec so we know it integrates very cleanly.
  For now we’ll work on it in a separate spec and if that comes along quickly enough we might merge it back in.
• State machines – this is something that is very useful when you start programming UI interactions but something we decided is not critical for the first version of the spec.
  Again, we’ll probably work on this as a separate spec.

API?

Originally I opposed the idea of adding an API because I think declarative solutions are generally preferable. However, the API is useful in a few cases:

• It lets you inspect the state of all animations in the document. Anyone can build developer tools that present you with a timeline of all the running CSS animations/transitions/SVG animations in the document for debugging.
• It lets you make runtime changes to declarative animations—for many apps a combination of declarative and procedural approaches is the best fit and lets you achieve effects that might not be possible using purely declarative features.
• For some problems a procedural approach is suitable and in those cases using the API is both simpler than writing the animation loop yourself and also means the browser can optimise the animation for smoother performance and less battery consumption.