20 CSS Scroll Animations

The distinction matters because almost every library conflates them. A scroll-driven animation has its progress bound to a scroll offset: scroll halfway through the range and the animation is exactly halfway, scroll back and it plays backward. It is a timeline, declared with animation-timeline, scroll-timeline-name, view-timeline-name and animation-range, and it has no clock of its own. A scroll-triggered animation fires once when an element crosses a threshold and then runs on its own duration regardless of what the scroll does next — that is an entrance animation that happens to be started by scroll. Both are useful and they solve different problems: use a timeline when the motion should track the user's scroll position, and a trigger when you want a one-shot reveal. This collection covers the timeline mechanism; one-shot entrance effects live in the fade-in and slide-in collections.

Not yet — Safari has not shipped animation-timeline, and Firefox required the layout.css.scroll-driven-animations flag until version 136. That is the single most important fact about this feature and it shapes how every demo here is written. The rule is that the base layout must declare the FINISHED state, with the scroll binding layered on top inside an @supports (animation-timeline: scroll()) block. Get that ordering backwards — base style sets opacity: 0 and the @supports block animates it in — and browsers without support show content that never arrives, which is a blank page rather than a missing flourish. Every demo in this collection was verified by stripping its timeline-gated @supports blocks and confirming the demo still renders complete and readable. Demo 07 teaches the gating pattern directly, and demo 01 covers the IntersectionObserver fallback for when you need the motion in Safari too.

Scroll timelines fail silently — no console error, no warning, nothing moves — so the debugging is all checklist work. Five causes account for nearly every case. The element you bound to is not actually a scroll container: it only becomes one with overflow: scroll or auto plus content taller than its box, and binding to a div that never scrolls produces no error at all. An ancestor has overflow: hidden, which kills the scroll container you were counting on. The animated element is not a descendant of the element that defines the named timeline, so the name simply does not resolve — that is what timeline-scope exists to fix. The range resolves to zero length, so there is no progress to interpolate across. Or the property you are animating is not animatable in the first place. Demo 08 walks all five as toggleable broken states with the symptom labelled beside each.

They are the four named ranges of a view timeline, and they are the most confusing part of the specification because the names sound similar and the differences only show up at the edges. cover spans the entire time the subject overlaps the scrollport at all — from the moment its leading edge appears to the moment its trailing edge leaves. contain spans only the period when the subject is fully inside the scrollport, which means it is empty for a subject taller than the viewport. entry covers just the arrival, from first appearance to fully visible. exit covers just the departure. The practical rule: reach for entry when you want something to animate as it arrives, cover when you want motion across the whole visible pass, and be careful with contain on tall elements. Demo 14 puts four identical cards side by side, one per range, each labelled with when it starts and ends.

Because the scroll position IS the progress. On a normal time-based animation the duration says how long to take; on a scroll timeline there is no clock to take time from, so the declaration is ignored entirely — which sends people in circles when the motion feels wrong and adjusting duration changes nothing. What controls the extent of the motion is animation-range-start and animation-range-end, which decide which slice of the timeline the animation spans. What still matters is animation-fill-mode: it controls how the element renders outside the active range, and both is usually what you want so the element holds its start state before the range and its end state after. Demo 18 shows all four fill modes on identical elements sitting outside their range, which is the only place the difference is visible.

That is exactly what view() is for, and the distinction from scroll() is worth getting right because mixing them up causes most of the "it animates at the wrong time" confusion. scroll() binds progress to the scroller's total offset, so an element animates according to how far the page has scrolled overall. view() binds progress to the subject's own passage through the scrollport, so the animation tracks that specific element regardless of where it sits in the document. Two roles are in play and they are easy to conflate: the subject is the element being tracked, and the scroller is the thing it moves through. Demo 11 shows one element bound each way, side by side and labelled, which makes the difference obvious in a way prose does not.

CSS scroll timelines are considerably better than the scroll-event listener they replace, and that is the strongest practical argument for using them. A scroll listener runs on the main thread, so it competes with rendering, hydration and any other JavaScript — under load the motion visibly stutters. A CSS scroll timeline animating transform or opacity runs on the compositor and stays smooth while the main thread is busy. Demo 06 makes this visible by putting both approaches side by side with a deliberate main-thread block, so the difference is demonstrated rather than asserted. The caveat is the same as for any animation: stay on transform and opacity. Binding width, height or top to scroll re-runs layout on every frame and gives back everything you gained.

Scroll-bound motion is among the strongest vestibular triggers, because the movement tracks the user's own scrolling and is not something they chose to start. But the blanket fix everyone reaches for — a universal selector setting animation: none under the reduced-motion query — is wrong here for a specific reason: it can leave elements stranded at their range-start state, which for a typical reveal means invisible or offset, so the user gets a broken page rather than a calm one. The strategy that holds up is to make the finished state the default and layer the scroll binding on only when motion is allowed, so removing the animation removes movement without removing content. Demo 05 puts a component under all three treatments — blanket kill, no handling, and the layered approach — so the failure mode of the common advice is visible.

Several collections sit adjacent here and each owns a distinct thing. This one covers the scroll timeline mechanism itself: how progress is bound, which subject and which scroller, what range it covers, and what to do where the feature has not shipped. css-parallax-designs (22 demos) owns parallax as a visual genre — depth layers, landscapes, mouse tracking, pinned scenes — where the look is the subject and the binding is plumbing. css-image-reveal-scroll (12 demos) owns image reveals, wipes and masks. css-scroll-progress-bar (18 demos) owns the progress bar as a component: styling, placement and variants. css-slide-in-animation and css-fade-in-animation own one-shot scroll-triggered entrances. If you are asking which range to use or why your timeline will not resolve, you are in the right place; if you want a finished parallax scene, the parallax collection is the better starting point.