Question 1

What are CSS scroll-driven animations?

Accepted Answer

Scroll-driven animations are CSS animations whose progress is tied to scrolling instead of time. You write a normal @keyframes rule, then set animation-timeline to scroll() or view() instead of letting it run on the default time-based DocumentTimeline. scroll() links the animation to the overall scroll progress of a scroll container — useful for reading-progress bars or parallax backgrounds. view() links it to a specific element's visibility as it enters, sits inside, and exits the viewport — useful for fade-ins, slide-ins, reveal effects, and any per-element scroll animation. Everything else (easing, fill modes, keyframes) works exactly as before.

Question 2

What browsers support scroll-driven animations in 2026?

Accepted Answer

Chromium-based browsers (Chrome, Edge, Opera, Brave) have supported them since version 115 in mid-2023. Safari added full support in version 18. Firefox has partial support behind a flag as of April 2026 — it is not on by default, which means a meaningful slice of Firefox users will not see the animation. This is why the exported CSS wraps every scroll-driven rule in an @supports (animation-timeline: view()) feature query: browsers that do not recognize the property simply show the final state of the element without animating, which is a clean no-motion fallback. For complete cross-browser coverage today, the Intersection Observer JavaScript alternative or the scroll-timeline polyfill are still options, but for most greenfield projects the CSS @supports fallback is the pragmatic choice.

Question 3

What's the difference between scroll() and view()?

Accepted Answer

scroll() tracks the scroll position of a scroll container (the viewport by default, or a nearest scrollable ancestor). The animation progresses from 0% to 100% as the user scrolls from the top of the page to the bottom. Good for global effects: reading-progress indicators, sticky header shrinking, full-page parallax. view() tracks a specific element's visibility — the animation progresses as the element enters the viewport, passes through, and exits. Good for per-element effects: fade-ins, slide-ins, scale-ups, image zoom-on-scroll. The builder lets you pick either, because most real designs use both types for different elements on the same page.

Question 4

What are entry, exit, contain, and cover ranges?

Accepted Answer

These are the named ranges you use with the animation-range property to control when inside the view timeline an animation plays. entry runs while the element is entering the viewport (from the moment the first pixel appears until the element is fully visible). exit runs while it is leaving (from fully-visible until the last pixel disappears). contain runs only while the element is fully inside the viewport. cover runs the entire time any part of the element is visible (entry + contain + exit combined) — this is the most common default. You can also mix ranges like animation-range: entry 25% exit 75% for precise control. The builder includes a visual range slider so you can see which part of the element's scroll life the animation covers without memorizing the spec.

Question 5

Do scroll-driven animations run on the GPU?

Accepted Answer

Yes — and that is the main performance argument for using them over the classic scroll-event-listener approach. Because they are declarative CSS, the browser can run them on the compositor thread (off the main thread entirely) the same way it runs transform and opacity animations. This means no jank even during heavy JavaScript work on the main thread, and no scroll events firing at 60 times per second that your code has to throttle. For animations limited to transform, opacity, filter, and clip-path, the result is buttery smooth on mobile — genuinely hard to achieve with JavaScript scroll listeners. Avoid animating properties that trigger layout (width, height, top, left, padding) — those will still run on the main thread even with a scroll timeline.

Question 6

How do I add a reduced-motion fallback?

Accepted Answer

Wrap the scroll-driven portion in @media (prefers-reduced-motion: no-preference) so it only applies when the user has not asked for reduced motion. Users who enable reduced motion in their OS (macOS, Windows, iOS, Android all have it) will see the static final state instead of the animation, which is the accessible default. The builder exports this guard automatically around every animation. This is important for users with vestibular disorders who experience dizziness or nausea from parallax and scroll-linked motion. Respecting the preference is not optional for modern sites — and it is a one-line cost to include.

📖 Learn More