Introducing Web Animations

Today we finally shipped the First Public Working Draft of Web Animations!

Working Draft: https://www.w3.org/TR/web-animations/
Editor’s Draft: https://drafts.csswg.org/web-animations-1/

Over the coming weeks I’d like to introduce some of the key concepts as well as some of the issues that need your input.

First, I’d like to give an overview of where the spec comes from and what it covers.

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.

Implementations?

Work has started on implementation in Blink and is on the radar for Gecko. Until then a polyfill is coming along in leaps and bounds and covers nearly all of the FPWD.

That’s it for now. I’ll follow up with posts explaining specific features and issues needing input but if you have any feedback on the spec, don’t hesitate to send it along to public-fx@w3.org with subject [web-animations]. Thanks!

Hi Denny, thank you very much! Yes, I think custom effects open up a lot of possibilities. In the demo we presented last year we used it to generate audio and then applied an easing function to the audio and reversed it–whilst maintaining synchronisation with the animation. You can see it in the video if you haven’t already. I’m pretty excited about what people will do with canvas. I’d love some input though about WebGL. I don’t know if this approach works for WebGL as well.

Hi David, thank you! I can’t comment on Blink development since I’m only involved in Gecko.
That’s an excellent suggestion about making animations then-able. Would you mind sending that comment to public-fx?

In terms of the API I think Animations won’t be then-able because they can run many times if they are in a group. Instead, we have timing events for that so you can hook into ‘onstart’ and ‘onend’. However, we could make Players then-able. That would mean introducing the concept that Players stop when their source content has finished but we’ve toyed with that idea before for a number of other reasons. Also, I guess it might mean that Element.animate would need to return a Player instead of an Animation. In any case, it’s definitely worth investigating!