Scroll-driven animations are set to land in all major browsers by the end of the year, but I haven’t seen many people using them in production yet. Maybe because it still feels like an all-or-nothing feature, or maybe I’m just buried too deep in my little JS/creative dev corner again.

Regardless the reason why, one of my recently graduated students, Anne van Dijk, (she’s looking for a job, by the way; hit me up if you have a position available and I’ll connect you!) asked me how I built the selected work slider on my portfolio. She wanted to make something similar and had been using GSAP ScrollTrigger, but was curious about switching to CSS scroll-driven animations since GSAP was running a bit rough on mobile.

Unless she’ll be looking at scroll driven animations on an android phone, using scroll driven animations won’t help, because, at the time of writing this, it’s not supported on Safari, which means it’s not supported on iOS. But let’s not let that stop us from coding for the future in stead of coding for the past.

Ever had the debate with a colleague which is better; progressive enhancement or graceful degradation? I have, my colleague Krijn Hoetmer at the Amsterdam University of Applied Sciences for example is firmly in the progressive enhancement camp. And I get it: PE encourages solid defaults and clean, efficient code, whereas GD often means piling on complexity just to force things to work where they maybe shouldn’t.

I agree with Krijn, in a perfect world PE would win. But in practice, there’s one thing that tips the scales about 8 times out of 10: clients. Clients rarely want to hear that a scroll-driven animation won’t work on certain browsers or will just look different. And that’s usually when graceful degradation ends up being the solution.

For Anne, I decided to show both approaches: one version that gracefully degrades to GSAP ScrollTrigger (with a few optimisations to reduce the mobile lag), and another that’s progressively enhanced, using CSS scroll-driven animations where supported, and falling back to a different, simpler interaction where it’s not.

The Progressively Enhanced version doesn’t need any JavaScript; I’m simply overwriting or adding certain styles based on the @supports tag.

For example; if scroll driven animations are not supported I want to make the individual cards sticky in stead of the .cards__inner container that’s around it.

The animation is completely different when scroll driven animations are supported (left screen) and when they’re not (right screen), but the usability is the same.

If position: sticky is not supported the cards will be just underneath each other, if display: flex is not supported the items will still just be underneath one another anyway, as that’s default behaviour for divs.

Using this approach we need to check with JavaScript if view timelines are supported; I’m saving the value inside of a variable named needsGSAP. If needsGSAP is true, we can write a fallback with JavaScript.

Using the graceful degradation approach we can get much closer to the wanted animation, but you could ask yourself if this is maintainable in the long run.

I’m using graceful degradation on this portfolio too; turns out I’m one of those clients who can’t quite accept animations looking different across browsers (at least not yet). I’ll probably be fine with it once scroll-driven animations only fail in genuinely old browsers, rather than on most of my clients’ mobile devices.