WAAPI Animation controls
The WAAPI let’s you reverse, pause, speed up your animations and gives you callbacks for when an animation has finished. These things are fairly hard to do in CSS , especially chaining multiple animations requires a lot of variables or specifying exactly when what it is going to happen.
Styling vs. Behaviour
The more interactive and complicated an animation gets in CSS, the more CSS tricks & hacks you are going to need, which might make your CSS harder to read for other people. So for example of you have a
div, that you want to fade out when you click on it, there would be three forward ways to do it.
In order to do it in pure CSS you would need a checkbox to register the click. Once the checkbox is
:checked you could play the according CSS animation. This does however require another element on top of our original element.
CSS Animation with class changes via JS
Nevertheless this doesn’t mean you have to abandon CSS animations. You still have the option to combine the two, when it makes more sense to do an animation in CSS, because of the simplicity.
In the past you would often prefer CSS Animation, because it gave you hardware acceleration and it could render properties like
transform very performant over the GPU. But now you will also get this acceleration in the WAAPI, if the browsers already supports the Web Animation API.
Tell the Browser what is animated
When you use the Web Animations Api, all your animations will be described in the
document.timeline and you (and the browser) have access to all the animations.
What’s a problem with external animation libraries is that the Browser sometimes doesn’t recognise elements that the library animates as elements that are animated and therefore they aren’t promoted to their own layer or rendered over the GPU. With the WAAPI we’re telling the Browser: “Hey Browser, I’m animating this element with the API you’re providing, can you please optimise it for me with what’s available to you?”
The browser are already working hard on implementing the API and Firefox has large parts of it implemented already. This means you maybe won’t need to add an large external library to do some chained custom animations in the future.
Of course there will always be a need for libraries like Greensock, because they are aimed to do a lot more than the API (SVG morphing for example) and are easily understandable for developers and designers, but with the API you have a simpel native option to do more advanced animations without needing to add or learn a new library.
Animations in the document
If you have all animations described in your
document.timeline, you have easy access to all the animations that are happening on your site.
It’s a big problem that animations can be mentally taxing for people if they’re overdone or if they suffer from an illness like vestibular disorder (more in this article) . So providing an option to disable the animations is important. Since they are all in the document you can call
getAnimations() on the
cancel() them if needed.
CSS can do this too
There is also a great way to take care of this in CSS with CSS Custom Properties:
Last week I created a pen animating tiles to reveal underlying text. It creates
Tile function class, that creates an animation for each element in the grid
gridItems.forEach((item) => new Tile(item)); .
Once the animation for this tile is created
this.opacity = this.element.animate(..), it is immediately paused with
this.opacity.pause(); and only played once the
mouseover event is fired.
When we click the
Reset Tiles button, I change the
playbackRate of all the animations to
-1 , which plays all the animations in reverse and animates them back in. I could have also called
this.opacity.reverse() , which would have done the same thing.
This interaction was quite simple to create with the WAAPI, but would have required a lot of class changes on the DOM if I’d done it with CSS Animation. In this case working with the animation object turned out to be really useful and straight forward.