How does this compare to the classic css-native parallax effect? Before the scroll timeline APIs you'd use the "perspective" css property to create a container where the z plane is n pixels away from the screen, and then position each layer within it at a different z distance using transform: translateZ
That method is GPU accelerated too, so it is performant compared to some js solutions, and has worked well in every browser for around a decade
I like the idea of the scroll-timeline though, just keen to understand what the advantage is for this
OP here, thanks for asking. While the `perspective` technique works too, it has the downside of needing a careful combination of scroller elements and properties.
This approach adds a single class to the image container and that's it. Plus you can control many aspects of the animation such as entry/exit ranges, and make it control other properties like opacity or color, for example.
I know browser support is still lacking, but it will get there eventually. I'm not using this in production code yet, but I think it's useful to experiment with these new CSS APIs.
This method should still support GPU acceleration, as `transform` (or rotate/scale/etc.) is the only property being animated. The benefit of animation-timeline seems to be that it's much easier to set up than a CSS perspective context.
No doubt quite a few folk with the same question. Keen to understand performance tradeoffs.
Obvious comparison note would be that the "new" method currently enjoys somewhat limited browser support (no Firefox without a flag, and only since Safari 26)
I was wondering the same thing. That translateZ is a bit fiddly to get right, so I could believe this is a bit easier to use, maybe? And presumably this could be used for other properties besides position, like colors, opacity or blurs.
For people saying it's not working in any browser - do you have some kind of reduced motion preference setting turned on? I can imagine that would have an effect on something like this and it's definitely working in Chrome for me.
Enabling (layout.css.scroll-driven-animations.enabled) and refreshing the codepen gives a "we crashed this to prevent a crash from an infinite loop" clicking to allow the infinite loops allowed me to see the animation.
Fedora 44 Kernel: x86_64 Linux 7.0.10-201.fc44.x86_64 Firefox 151.0.2
The JS and bot check are for making additional functionality, beyond just showing the example, work easily. I.e. editing and sharing edits from a browser. If all you want is a static example, feel free to make it without these things.
A parallax effect has also long been possible with CSS 3D transforms. Here's a demo,[0][1] from the same person who made that CSS 3D FPS a while ago.[2]
You can make some really cool stuff with css scroll animations. I used SVG paths with a scroll animated dash offset to draw an image while scrolling. Zero javascript, it feels so smooth. https://thomaswelter.nl (the background)
Can only see it on chrome though =/. I switched to Safari as the lesser of two data-harvesting evils. Or rather, with an iPhone I've already chosen my overlord. I also switched to Kagi. Trying to deGoogle myself.
firefox android does not support CSS animation-timeline, and firefox desktop needs layout.css.scroll-driven-animations.enabled. This probably should not be used for any critical features.
This [0] seems to be the main meta bug, with [1] being for CSS and [2] for JS, for FF to ship it without the flag. There seems to be slow work towards it, kinda funny that FF was the first browser to have it (flag-gated, according to CIU) and now is the only one without it in stable ;)
I played around with this API some time ago. It’s simple and high-performance, but one feature I wish existed is damping. Scroll-driven animations are tied directly to the scroll timeline, so there’s no concept of the parallax object “catching up” to the scroll progress over, say, one second. From what I remember, `animation-timing-function` feels weird when you scroll, so it’s not the right solution. GSAP offers this, but it’s JS-only.
In a world where it's increasingly overlooked, I'm glad the author mentions disabling it respecting user settings. I do think it should be reversed and only enabled with the `@media (prefers-reduced-motion: no-preference)`, but that is the opinion of someone who gets negative value from animations and is bemused by how much dev and compute time is spent on them.
Great. I tried the Google examples a while ago and got nowhere with it, time for another go, within the netherworld of SVG, to map to several different layers.
Edit: if the body has class="no-sda", it uses a js fallback.
That method is GPU accelerated too, so it is performant compared to some js solutions, and has worked well in every browser for around a decade
I like the idea of the scroll-timeline though, just keen to understand what the advantage is for this
This approach adds a single class to the image container and that's it. Plus you can control many aspects of the animation such as entry/exit ranges, and make it control other properties like opacity or color, for example.
I know browser support is still lacking, but it will get there eventually. I'm not using this in production code yet, but I think it's useful to experiment with these new CSS APIs.
Obvious comparison note would be that the "new" method currently enjoys somewhat limited browser support (no Firefox without a flag, and only since Safari 26)
Fedora 44 Kernel: x86_64 Linux 7.0.10-201.fc44.x86_64 Firefox 151.0.2
https://developer.chrome.com/docs/css-ui/scroll-driven-anima...
Edit: Their reference works and has some really nice demos. Must be an iframe problem. https://scroll-driven-animations.style/#demos
[0]: https://www.keithclark.co.uk/articles/pure-css-parallax-webs...
[1]: blog: https://www.keithclark.co.uk/articles/pure-css-parallax-webs...
[2]: https://www.keithclark.co.uk/labs/css-fps/
Can only see it on chrome though =/. I switched to Safari as the lesser of two data-harvesting evils. Or rather, with an iPhone I've already chosen my overlord. I also switched to Kagi. Trying to deGoogle myself.
[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1676779
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1676780
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1676781