Until recently it did not have a choice. The browser had no way to tie an animation to scroll position, so every fade-in, progress bar, and parallax effect ran through JavaScript that listened to scroll events and recalculated on every frame. That work happens on the main thread, which is the same thread that handles clicks and typing.
CSS scroll-driven animations change that. They let you drive an animation from scroll progress using nothing but CSS. No listener, no library, no per-frame math in your own code.
The obvious question is whether you can actually ship them. The honest answer in 2026 is yes, but only as an enhancement layered on top of a page that works without them. That distinction matters, and it is where most of the advice online gets sloppy.
They are regular CSS animations whose timeline comes from scroll position instead of the clock. MDN describes them as animating "along a scroll-based timeline rather than the default time-based document timeline". You still write keyframes exactly as you always have. You just change what advances them.
The property that does the work is animation-timeline. Instead of the animation running for two seconds, it runs from the start of a scroll range to the end of it. Scroll down and the animation advances. Scroll back up and it reverses. There is no state to manage because the scroll position is the state.
A handful of related properties fill in the details. MDN lists scroll-timeline and view-timeline as the shorthands for naming timelines, animation-range for controlling which slice of the scroll drives the animation, and timeline-scope for making a named timeline visible to elements outside its subtree. That is essentially the whole feature.
Not as a baseline, but yes as an enhancement. MDN currently marks animation-timeline as having limited availability, explicitly noting it is not Baseline "because it does not work in some of the most widely-used browsers". That is the fact to design around.
Support has genuinely moved, though. Chrome documentation states that "from Chrome version 115 there is a new set of APIs and concepts that you can use to enable declarative scroll-driven animations", so Chrome and Edge have had it since 2023. On the Safari side, WebKit published a guide in June 2025 confirming scroll-driven animations "are available in Safari 26 beta".
Firefox is the remaining gap, which is why the feature has not reached Baseline status. We are not going to quote a Firefox version here, because the public reporting on exactly where it stands disagrees with itself and we have not been able to confirm a single figure from Mozilla directly. Check MDN before you rely on it.
None of that blocks you. It just tells you the shape of the implementation. Build the page so it is complete without the animation, then add the animation for browsers that support it. This is ordinary progressive enhancement, and we go through the general approach in our piece on how you know a web feature is safe to use.
A scroll timeline tracks how far a scroll container has been scrolled. A view timeline tracks how far a specific element has travelled through the viewport. Scroll timelines suit page-level effects like reading progress bars. View timelines suit per-element effects like a card fading in as it appears.
You create them with two CSS functions. Chrome documentation describes scroll() as creating anonymous scroll progress timelines, accepting "a scroller argument (nearest, root, or self) and axis argument (block, inline, y, or x)". So scroll(root block) means the page vertical scroll, which is what a progress bar wants.
The view() function creates view progress timelines and takes an axis plus a view-timeline-inset. The inset is the useful part. It lets you say the animation should start when the element is 20% up from the bottom of the viewport rather than the instant it touches the edge, which is how you get an entrance that feels deliberate instead of twitchy.
In practice we reach for view() far more often. Almost every scroll effect a marketing site actually needs is per-element, and view timelines mean you never write a single line of JavaScript to know where an element sits on screen.
Because the browser can run them off the main thread. Chrome documentation is direct about this, saying scroll-driven animations "integrate with the existing Web Animations API and CSS Animations API" and that this "includes the ability to have scroll-driven animations run off the main thread".
That is the whole argument in one sentence. A JavaScript scroll handler has to run on the main thread by definition, competing with everything else the page is doing. If a third-party script is busy, your parallax stutters. With a CSS scroll timeline, the compositor can keep the animation smooth even while the main thread is under load.
The difference shows up worst on the devices that matter most. On a fast laptop a JavaScript scroll effect looks fine, which is why so many of them ship. On a mid range phone with a heavy analytics stack already running, the same effect judders. We have replaced a lot of scroll handlers for exactly this reason and the improvement is visible without a profiler.
Chrome frames the payoff as "silky smooth animations, driven by scroll, running off the main thread" with just a few lines of extra code. That is marketing language for a real architectural difference.
Wrap it in a feature query so unsupported browsers get the static layout instead of a broken one. MDN documents the detection pattern using a supports query on scroll-timeline. Put the final visible state in your base CSS, then use the query to add the animated version on top.
The order of that logic is the part people get backwards. If you write the animation first and treat the static state as the fallback, a browser without support gets an element stuck at opacity zero and the content simply never appears. We have seen this ship. Always make the visible, finished state the default, and treat motion as the addition.
There is one syntax trap worth memorising. Chrome documentation warns that "animation-timeline must be declared after the animation shorthand as the shorthand will reset non-included longhands to their initial value". If you set animation-timeline first and then use the animation shorthand below it, your timeline is silently wiped and the animation runs on the clock instead. It looks like the feature is broken. It is just declaration order.
Finally, respect the reduced motion preference. A scroll-driven animation is still motion, and a visitor who has asked their operating system for less of it should get the static version regardless of browser support.
For simple effects, yes. For complex sequenced work, no. If you need an element to fade, move, or scale as it enters the viewport, CSS now does that natively and better. If you need timelines that branch, pin elements, snap between sections, or coordinate a dozen elements in sequence, GSAP and its ScrollTrigger plugin remain the practical tool.
Our rule of thumb is the number of moving parts. One element responding to its own position is a CSS job. Five elements choreographed against a pinned section is a library job. Trying to force the second case into pure CSS produces code nobody on the team can maintain six months later.
There is also a weight argument. Loading an animation library for three fade-ins is a bad trade, and it is the single most common reason we find a JavaScript animation dependency on a client site. If CSS covers the whole requirement, dropping the library removes real bytes and a real dependency. We compared the tradeoffs in more depth in our article on whether to use Webflow Interactions or write GSAP by hand.
Yes, through custom code. Webflow Interactions is a JavaScript-based system, so scroll-driven CSS is not something you build by clicking around the Designer. You add the keyframes and the animation-timeline declarations in a custom code block or an embed and target your existing Webflow classes.
That works better than it sounds. Because the animation attaches to a class, you can style it in the Designer as usual and let the CSS handle only the motion. Your content editors never see the difference, and the Designer preview shows the finished state, which is exactly what you want them reviewing anyway.
The main caution is discipline about class names. If someone renames a class in the Designer, your custom CSS silently stops matching and the animation disappears with no error anywhere. We prefix animation-only classes so it is obvious they are load-bearing for something outside the Designer.
Only where they help someone understand the page. A progress indicator on a long article is useful. A card that fades in as it arrives can guide attention. A hero that hijacks the scroll wheel to play a five second sequence is a cost the visitor pays for a decision they did not make.
The cheapness of the new syntax makes this question more urgent, not less. When an effect costs one JavaScript library and an afternoon, teams think about whether it is worth it. When it costs four lines of CSS, effects multiply, and a page ends up with fourteen things animating on the way down.
We hold the same line we always have. Motion should reduce confusion or reinforce hierarchy. If it does neither, it is decoration competing with the content, and the fact that it is now free to implement does not make it free to experience. Our view on where the line sits is in our piece on whether website animations help or hurt conversions.
Yes, for progressive enhancements on non-critical motion, and no for anything a visitor must see. Use them to replace JavaScript scroll handlers you already have, wrapped in a feature query with the finished state as your default. Do not use them for content reveals that would hide information in an unsupported browser.
The practical move this quarter is an audit rather than a rebuild. Find the scroll listeners already on your site, work out which ones are doing simple per-element effects, and convert those. You will usually remove more code than you add, and the pages get smoother on exactly the devices where they were worst.
If you want a second opinion on which of your animations are earning their keep and which are just costing you main thread time, we are happy to look. Get in touch at phoenix.studio and we will go through the page with you.
Tell us where you want to go. We'll tell you how we'd get you there.