CSS Scroll-Driven Progress Bar — Native scroll() Timeline, No JS

A scroll progress bar is one of the most common pieces of DOM math on the web — read scrollY, divide by document height, write a style, every frame. This snippet replaces all of that with a single native CSS feature: scroll-driven animations. The bar's fill is a CSS keyframe animation whose timeline is the document's own scroll position, not the clock — so it plays exactly as far as you've scrolled, with no JavaScript computing it at all.

The core mechanism

The bar has animation: sdp-grow auto linear and animation-timeline: scroll(root). Normally an animation's timeline is time — sdp-grow would just play once over a fixed duration. Setting animation-timeline to scroll(root) swaps that clock for the scroll position of the document's root scroller: 0% scrolled maps to the animation's 0% keyframe, 100% scrolled maps to 100%. The keyframes themselves just scale the bar from scaleX(0) to scaleX(1) — the browser handles mapping scroll offset to animation progress natively, off the main thread, in the compositor.

Why this beats a scroll listener

A hand-rolled version needs a scroll event handler firing potentially hundreds of times per second, each computing scrollY / (scrollHeight - innerHeight) and writing a style — main-thread work competing with everything else on the page. This snippet's CSS keyframe runs on the compositor thread and updates every rendered frame regardless of main-thread load, so the bar never stutters even during heavy JS work elsewhere on the page. It pairs naturally with other scroll techniques like Reveal on Scroll or a Scroll Reveal Grid — both could migrate part of their logic to scroll timelines as browser support matures.

Graceful degradation

Scroll-driven animations currently ship in Chromium browsers (Chrome, Edge, Opera 115+) behind full support, with Firefox and Safari still rolling it out. The CSS includes an @supports not (animation-timeline: scroll()) block that swaps the bar for a striped placeholder rather than leaving it invisible or frozen. The JS layer is deliberately thin: it only checks CSS.supports('animation-timeline: scroll()') to flip a status badge, and — only when unsupported — attaches a minimal scroll listener as a safety-net fallback. The native CSS path is always what actually drives the bar when it's available.

When to reach for this vs. GSAP ScrollTrigger

If your scroll effect needs sequencing across multiple elements, scrubbing timelines with pins, or complex easing curves, a library like GSAP's ScrollTrigger (used in Scroll Reveal Grid) is still the more capable and cross-browser tool today. But for a single, simple linear or eased progress indicator — a reading bar, a scroll-to-top ring, a section indicator — native scroll timelines remove a dependency entirely and hand the work to the browser's own rendering pipeline.

Customizing it

Swap scroll(root) for scroll(nearest) to track a scrollable container instead of the whole page, change the gradient or thickness, or add a second bar bound to a view() timeline (see View Timeline Image Reveal) that only tracks a specific section rather than the whole document.