Web Animations API Tutorial Conclusion

This is the conclusion to an introductory/tutorial series on the Web Animations API coming to browsers. I've updated the series content in June 2016, as Chrome and Firefox have both rolled out major updates (and some small spec changes). If you have thoughts/questions or see that I’ve misinterpreted the spec, please reach out to me on Twitter, @dancwilson.

We've covered a fair amount of ground and hopefully cleared up questions about what the Web Animations API is (and is not). To conclude this series, we'll recap what we've discussed and take a look at what has yet to be implemented.

Why Bother with the API? 

In the introduction we discussed how the API came into being as a way to unite the various methods to animate in CSS, JS, and SVG... with the intent to take the best of them all. This means, for example, JavaScript can latch on to the hardware acceleration that CSS has had for years, and you are not limited to the declarative nature of CSS. The API is not meant to replace libraries like GSAP, but simply to provide more options at the browser level.

Firefox and Chrome have both started implementations, and Edge has it on its backlog. The polyfill allows us to start playing with it today as the team finalizes the specification.

Animation Basics 

To create a basic animation, we follow a structure similar to CSS by providing keyframes and timing properties.

var player = document.getElementById('toAnimate').animate([
{ transform: 'scale(1)', opacity: 1, offset: 0 },
{ transform: 'scale(.6)', opacity: .6, offset: 1 }
], {
duration: 700,

Timeline controls are the obvious pieces not currently present in CSS. Reading the state of an animation happens via the playState property, and changing the state is via methods such as play(), pause(), and finish(). We can also change the playback rate to be slower or faster with the read/write playbackRate property. The currentTime can be checked (or changed), and we can set a callback for when the animation finishes with onfinish.

Multiple Animations and Grouping 

The Web Animations API allows for multiple animations on an element, creating separate animation objects. The default timeline on the document gives us access to all animations created with the getAnimations() method. Animations can be grouped to play together or one after the other by using GroupEffects and SequenceEffects (available in the polyfill but not in the first spec).

Motion Path and the Future 

Animating along a path sneakily saw its first implementation in CSS during this series, but there are many other pieces yet to come.


The current implementations use a default spacing if no offsets are set in the keyframes, meaning they are evenly distributed (e.g. three frames will have offsets of 0, .5, and 1). The specification also defines a way to pace the animation based on a property, so that it has a constant rate of change. The spec describes this well when discussing Spacing Keyframes.


The spec has evolved to include a ready Promise that will be replaced with a new Promise every time the animation is cancelled or enters a pending state (which will typically happen before changing to "running" or "paused"). In addition to using the onfinish callback as we have discussed in this series, we will be able to use the finished Promise to run a function after an animation finishes.

Let's Keep Talking about the Web Animations API 

People are starting to talk more about this API, and I hope this conversation continues. The spec, browser implementations, and polyfill have been going on for a while, and they are ready to examine closely.

Sometimes CSS will make the most sense, sometimes requestAnimationFrame will, and sometimes using a library will be the best solution. It's good to know when to use what, and this API provides quite a few things that were not previously available to us by default... so have fun.

Check out the rest of this series: