I’m pretty hot on Scroll-Driven Animations! What a wonderful idea that we can tie @keyframe animations timelines to scroll positions. And I’m sure the creators of it thought long and hard, because the API makes a ton of things possible. It’s not just “how far the entire page has scrolled”, although that’s possible. The progress through the animation can be tethered either to the scroll position of any element or to the position of an element within a scrollable container. Those are referred to as the Scroll Progress timeline or the View Progress timeline respectively. Slow clap, people.
Bramus Van Damme makes that nicely clear in this overview article. Bramus has been following, working on, creating demos, and writing about this stuff for a long time, and it was a smart move to wrap all that stuff up in a dedicated website for it.
I’m also a big fan of his co-worker Adam’s approach to an intro article here. Adam makes demos that are a smidge more designery and those tend to land with me. And speaking of designery demos, Ryan Mulligan’s beginning explorations are wonderful. He’s got some Polaroid photo style images that “blur in” when they scroll into view and a pair of photos that shuffle themselves as you scroll. I share Ryan’s sentiment that the tools Bramus has built are nearly crucial in understanding this stuff, since all the different keywords and values have such big effects.
These scroll-driven animations tend to be things that are just fun and could easily be thought of as progressive enhancement. So the fact that this is Chrome-only for now isn’t terribly bothersome to me, although it is polyfillable. We also didn’t get scroll-driven animations on the Interop 2024 list, but that doesn’t mean we won’t get Safari or Firefox support this year. Still could happen, just not really a guarantee.
Why do I think this is so cool? It’s not like we absolutely couldn’t do this before. Greensock has a ScrollTrigger plugin that is widely loved and has a pretty sweet API. (Here’s a great Collection.) I don’t think it’s terribly egregious to use JavaScript for these kind of effects, particularly if it makes them more maintainable, performant, or do things impossible any other way. But that’s the thing — when these abilities come back to native web technology like CSS, chances are the performance is going to be great and arguably more maintainable thinking long term as the people familiar with the technology will grow.
Yuriko Hirota did a great job of proving how much more performant using CSS for these types of animations are. The single-threaded nature of DOM interactive JavaScript means that if JavaScript is busy doing anything else, a JavaScript-powered animation is going to suffer from jankiness, that is, jerky and non-smooth animation. Even when JavaScript is quite busy, a CSS powered animation is fine. Those “scroll progress animations” are the classic demo of this web tech. Michelle Barker went deep on those this past year, starting with the basics and getting lovably weird as the article goes on.
Let’s end with a little tip! Bramus mentioned that if you’re setting up a scroll-driven animation that involves a target element and different scrolling element, if it’s not working, there is a good chance…
The culprit: an
overflow: hiddensitting somewhere in between the target and the scroller.
It’s always the overflow, isn’t it? I find overflow is usually the culprit in figuring out why a sticky positioned item isn’t working as well. The solution, if you do actually need to deal with hiding overflow, is to use overflow: clip; instead, a relatively new ability. Kevin Powell covered a couple other scenarios where overflow: clip; saves the day, so it’s definitely worth knowing about!
I’ve been playing with Scroll-Driven Animations myself a bit. I wrote one bit about highlighting a bit of text as you scroll down a blog post, something I was inspired by from Lene Saile’s blog. As a response to a reader question, I also figured out how to zoom in images when they come into the viewport as well. Both of those ultimately use the scroll position to control the point in the animation to be at, which I think is usually nice, but I also enjoyed the idea that you can un-tether those things (say, run a 3s animation once an element becomes fully visible) by flipping a --custom-property in a keyframe which triggers a different keyframe, like Ryan Mulligan digs into.
It’s still early days for Scroll-Driven Animations and there are sure to be extremely clever ideas people will find for years. My jaw was already dropped by using them to fit text exactly to a container and to write conditional logic detecting if an element can scroll or not.
