In CSS scroll-driven animations, what is the difference between the scroll() and view() values of animation-timeline, and when would you pick each?

## The question each one answers The two anonymous timeline functions differ in what they are measuring, not in how they are wired up. - `scroll()` answers **"how far has this container been scrolled?"** - `view()` answers **"where is this element in its trip through the scrollport?"** Everything else follows from that. ## scroll(): one timeline for the whole container A scroll progress timeline maps the scroll container's position across its scrollable range onto 0%–100%. It knows nothing about the animated element — the element could be off-screen the whole time and the timeline would still advance. Because the measurement belongs to the container, every element that attaches to the same scroller shares identical progress. That makes it the right tool whenever the animation is *about the page*: a progress indicator, a sticky header that compacts, a background hue that shifts as you descend, a table-of-contents marker. ```css #progress { animation: grow-bar linear; animation-timeline: scroll(root block); } ``` ## view(): one timeline per element A view progress timeline is defined by the relationship between a **subject** box and the **scrollport** of its scroll container. Progress runs from the moment the subject's box first begins to intersect the scrollport to the moment it has completely passed out of it. With anonymous `view()`, the subject *is* the element carrying the declaration — which is exactly why a single class can drive per-element behaviour: ```css .card { animation: fade-up linear both; animation-timeline: view(); } ``` Every `.card` gets its own timeline. The first card is already halfway through its range when the tenth has not started. No JavaScript, no per-element bookkeeping, no observer callbacks. `view()` takes optional arguments too: `view(<axis> <inset>)`, where the axis is `block` (default), `inline`, `x`, or `y`, and the inset shrinks or grows the region of the scrollport that counts as "in view" — `view(block 20%)` treats the middle band of the viewport as the visible region, so a reveal fires before the element touches the true edge. ## The subject can be a different element Anonymous `view()` always makes the declaring element the subject. When you want element A's animation driven by element B's visibility, you name the timeline instead: put `view-timeline: --hero block` on B and `animation-timeline: --hero` on A. The named form also has `view-timeline-name`, `view-timeline-axis`, and `view-timeline-inset` longhands. ## Choosing between them Ask whether the animation should be identical for every element using it. | Intent | Timeline | |---|---| | Reading progress bar | `scroll(root block)` | | Header shrinks as the page scrolls | `scroll(root block)` | | Each card fades in as it arrives | `view()` | | Image parallaxes within its own frame | `view()` | | Indicator tracks a horizontal carousel | `scroll(self inline)` on the scroller, or a named scroll timeline | A useful cross-check: if the effect would look wrong when two instances animate at different moments, you want `scroll()`. If it would look wrong when they animate *together*, you want `view()`. ## Shared gotchas Both need a real scroll container. `view()` measures against the scrollport of the nearest ancestor scroll container on the chosen axis, so an element inside an `overflow: auto` panel is measured against that panel, not the viewport — surprising when the panel is small and the effect never seems to complete. With `view()` you almost always want `animation-fill-mode: both` (the `both` keyword in the `animation` shorthand). Without it, the element snaps back to its unanimated styles once it has passed out of the range, which for a fade-in reveal means the element disappearing again after it has scrolled by. Finally, `view()`'s default range covers the subject's entire passage — from first entering to fully leaving. A reveal that should finish once the element is comfortably on screen needs `animation-range` to narrow that, otherwise the fade only reaches full opacity as the element exits the far edge, which reads as an effect that never quite lands.