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?
To create a basic animation, we follow a structure similar to CSS by providing keyframes and timing properties.
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
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
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: