Status updates, Web Animations

Introducing Web Animations

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

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:

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.


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.


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 with subject [web-animations]. Thanks!

13 thoughts on “Introducing Web Animations

  1. Thanks for all the hard work in pushing this through! The ability to use the Web Animations timing model to drive animations of HTML canvas really opens up some interesting possibilities, practically bringing canvas into the circle with CSS and SVG.


  2. 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!


  3. Great to know, I can see the reasoning why so see how this progresses as quite a few working drafts and api specs have been pushed to working draft and scrapt recently.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s