Why it matters
Scroll-driven animations tie a CSS animation's progress to scrolling instead of time. A scroll() timeline follows a scroll container from top to bottom, good for reading progress bars. A view() timeline follows one element as it crosses the viewport, good for reveal effects. Named ranges pick the part of that journey that counts: entry is the element coming into view, exit is it leaving, cover is the whole crossing, contain is while it's fully visible.
The ranges are where people get stuck, because "entry 0% to cover 50%" is hard to picture. This builder writes the CSS and runs it in a sandboxed preview you can scroll, then works out where the animation starts and ends in pixels for that box. It wraps the result in @supports (animation-timeline: view()) so older browsers just show the end state, and adds a prefers-reduced-motion block that turns the animation off for people who ask for less motion.
How to use it
- Pick a timeline (view or scroll) and a preset.
- Choose the range start and end, with offsets.
- Scroll the preview to check the timing.
- Copy the CSS; the @supports and reduced-motion guards are included.
FAQ
Which browsers support scroll-driven animations?
Chrome and Edge from 115 and Safari from 26. Firefox has them behind a flag. The generated CSS is wrapped in @supports, so other browsers show the final state with no animation.
What does 'entry 0% cover 50%' mean?
The animation starts as the element's leading edge enters the scrollport and finishes when the element is halfway through its full crossing. The builder shows both points in pixels.
Should scroll animations respect reduced motion?
Yes. Movement tied to scrolling can make people with vestibular disorders feel ill. The output turns animations off under prefers-reduced-motion: reduce.
Does it need JavaScript?
No. The output is pure CSS. The page uses script only to build the code and run the preview.
