CSS Scroll-Driven Animations: animation-timeline Explained

Scroll-linked effects — a progress bar that fills as you scroll, an image that fades in when it enters the viewport, a parallax card that scales as it passes through view — have almost always been built the same way: attach a scroll event listener, read window.scrollY or element.getBoundingClientRect() on every fired event, compute a percentage, and write the result into an inline style or CSS custom property, typically wrapped in requestAnimationFrame to avoid layout thrashing. The CSS Scroll-Driven Animations spec replaces that entire pipeline with two new native timeline types, scroll() and view(), that plug directly into the standard CSS animation property — no JavaScript execution on scroll at all.

`animation-timeline: scroll()` — progress through a scroller

By default, a CSS animation's progress is driven by time — 0% at animation-duration: 0s, 100% at the end. Setting animation-timeline: scroll() instead ties that same 0%-to-100% progress to how far a scrollable ancestor has been scrolled. The progress bar in this demo uses animation-timeline: scroll(nearest), which tells the browser "find the nearest scrollable ancestor and use its scroll position as the timeline" — in this case, the dashed-border .scroller box. The @keyframes grow-progress rule animates transform: scaleX(0) to scaleX(1), and instead of running over a fixed duration, the browser now maps that keyframe range directly onto 0%-100% of the scroller's scroll distance. Note animation-duration becomes irrelevant for a scroll-timeline-driven animation; only the keyframe percentages matter.

`animation-timeline: view()` — progress through the viewport

The reveal, scale, and rotate cards use the second timeline type, view(), which is subtly different: instead of tracking scroll distance through a container, it tracks how far the *animating element itself* has travelled through its nearest scrollable ancestor's visible area — effectively "is this element entering, centered in, or leaving the visible viewport of its scroller." This is the exact mechanism most scroll-reveal libraries (AOS, ScrollReveal, GSAP ScrollTrigger) reimplement in JavaScript, now available natively.

`animation-range` — controlling exactly when the animation plays

Pairing a view() timeline with animation-range lets you scope the 0%-100% animation progress to a specific portion of the element's transit through the viewport. This demo's reveal card uses animation-range: entry 0% cover 40%, meaning the keyframes play out entirely during the element's "entry" phase (from first becoming visible to being 40% scrolled past) — so it finishes revealing well before it reaches the vertical center, rather than animating the whole time it's on screen. The named range keywords are entry, contain, exit, cover, and entry-crossing/exit-crossing, each describing a different phase of the element's relationship to the scrollport.

Named scroll-timelines vs the anonymous shorthand

This demo uses the anonymous scroll()/view() function form for simplicity, but the spec also supports explicitly named timelines: declaring scroll-timeline-name: --my-timeline on the scroller and referencing animation-timeline: --my-timeline on a *different* element anywhere in the DOM (not just a descendant), which is useful when the element you want to animate isn't nested inside the scroller itself.

Browser support and the `@supports` fallback

animation-timeline shipped in Chromium-based browsers (Chrome/Edge 115+) first, with Safari and Firefox support arriving later — as of early 2026 it's usable in production behind a feature-detection fallback. This demo wraps a fallback in @supports not (animation-timeline: scroll()), which sets all animated elements to their final, fully-visible resting state (opacity: 1, transform: none, animation: none) so unsupported browsers see a clean static layout instead of permanently-hidden or half-animated content — this is the single most important detail to get right when shipping scroll-driven CSS today, since without it, elements would stay at their from keyframe state (often invisible) forever in a non-supporting browser.

Why this matters for 2025/2026 UI work

Because the browser owns the timeline calculation, scroll-driven CSS animations run off the main thread and stay perfectly smooth even during heavy JavaScript execution elsewhere on the page — a category of jank that plagued nearly every JS-based scroll-reveal implementation. It also means one less runtime dependency, one less bundle-size cost, and no risk of a scroll listener firing after its element has already been removed from the DOM.