An AI agent reviewing a design pull request may be able to read the DOM, inspect CSS, follow named timelines, and identify a reduced-motion branch. It may still be unable to answer the question a human designer asks immediately: does the motion feel right while scrolling?
That distinction is the central problem. An agent can verify much of the declared machinery of scroll-driven CSS animation, but it cannot verify the rendered experience without a browser render or an equivalent observation system. This review is based on MDN, the W3C draft, and Chrome for Developers documentation; we did not run these demos in a browser.
The practical verdict is conditional trust. Static analysis can establish whether the animation has a coherent timeline binding, whether its names resolve, whether its ranges make sense, and whether reduced motion is addressed. It cannot establish smoothness, visual timing as experienced by a person, or actual cross-browser fallback behavior.
What Scroll-Driven Animations Actually Are
The first task for an agent is to identify what kind of animation it is reviewing. CSS keyframe animations normally use the time-based DocumentTimeline. The animation-timeline property replaces that default only when it is set, binding the animation to a scroll or view timeline instead. Its documented values include none, auto, scroll(), view(), and a named dashed identifier. See MDN’s animation-timeline reference and the DocumentTimeline documentation.
That binding changes what advances the keyframes. The animation is no longer necessarily progressing because elapsed time is passing. It may progress because a scroll position changes or because an element moves through a scrollport.
The W3C Scroll-driven Animations specification distinguishes scroll-driven animation from scroll-triggered animation. Scroll-driven animation has progress tied to scroll position. Scroll-triggered animation is triggered by scrolling but then progresses over time. Those are different contracts, and an agent should not treat the presence of a scroll-related trigger as proof that the animation is continuously mapped to scroll progress.
Scroll and View Progress Timelines
A scroll progress timeline maps a scroll container’s position to animation progress. At the startmost scroll position, progress is 0%. At the endmost scroll position, progress is 100%. The W3C describes the progress as:
scroll offset / (scrollable overflow size − scroll container size)
That formula is useful to a static reviewer because it describes the intended relationship between geometry and progress. An agent can sanity-check the declared structure and, in principle, reason about whether the relevant scroll container has the dimensions needed for that relationship. The W3C scroll-driven animation model is the authority for this definition.
A view progress timeline describes an element’s visibility inside a scrollport. Progress begins when the element is first visible at one edge and reaches 100% when its end edge exits the opposite edge. MDN describes this model on its animation-timeline page.
The distinction matters for review. A scroll timeline commonly describes the movement of a container through its scrollable range. A view timeline describes an element’s passage through visibility boundaries. An agent can identify which function is declared, but that declaration alone does not show how the resulting motion will look in a particular composition.
The Progress Formula an Agent Can Check
The formula gives an agent a concrete static question: what is the intended scrollable overflow, what is the scroll container size, and what does the animation use as its scroll source?
If the denominator is conceptually the difference between scrollable overflow and the scroll container, the agent can look for a mismatch between the named scroller and the element being animated. It can also distinguish a declared scroll progress timeline from a view progress timeline rather than assuming that every scroll-linked animation uses the same geometry.
This remains a reasoning check, not a rendered observation. No browser was run for this review, so no claim is made about the behavior of a live page. The agent can inspect the contract expressed in CSS and markup; it cannot confirm the actual relationship between scrolling input and painted output from source text alone.
What an Agent Can Perceive: The Static Evidence Trail
A non-rendering agent has a meaningful evidence trail. It can inspect whether animation-timeline is declared and whether its value belongs to the documented set of timeline forms. It can trace a named timeline through declarations, keyframes, and the element receiving the animation. The MDN scroll-driven timelines guide provides a useful vocabulary for that inspection.
Named timeline wiring deserves special attention. timeline-scope allows a non-ancestor to attach to a named scroll timeline by declaring that name on a shared parent. In other words, the agent should not reject a timeline merely because its source is not an ancestor of the animated element. It should look for the shared-parent wiring described by Chrome for Developers’ scroll-driven animation documentation and the MDN timeline-scope reference.
The agent can also inspect keyframes and range declarations. With view(), keyframes can contain the range information, so animation-range is not needed for the list-view pattern described by Chrome for Developers. That means the absence of animation-range is not automatically an error. The relevant question is whether the chosen view() pattern places the range information in the keyframes as documented.
There is an important boundary around computed style. Whether getComputedStyle exposes animation timing specifics is NOT verified. That uncertainty should be reported qualitatively rather than filled with an invented API guarantee. A reliable agent can say that source-level declarations are inspectable; it should not claim that computed style provides every timing detail needed to prove runtime behavior.
What an Agent Cannot Perceive: The Rendered Experience
Static evidence cannot establish whether motion feels smooth, whether its easing communicates the intended hierarchy, or whether the transition feels abrupt during actual scrolling. These are experiential judgments. They depend on the relationship between input, layout, painting, and perception—not just on the text of a stylesheet.
The agent also cannot determine from this review whether a motion pattern is comfortable for a particular person in practice. It can check for a reduced-motion branch, but it cannot experience the alternative or establish how a user will respond to it.
Cross-browser behavior is another hard boundary. MDN marks animation-timeline as “Limited availability” and not Baseline because it does not work in some of the most widely used browsers. That statement is the supported compatibility claim here; current Firefox and Safari status for animation-timeline is NOT verified. An agent must not turn that gap into a more specific browser matrix.
The CSSWG scroll-animations editor’s draft can help an agent distinguish an evolving draft model from a universal production guarantee. It does not remove the need for rendered validation.
Static Checks Versus Unrenderable Experience
| Aspect | Agent can verify statically? | Evidence source | Limit |
|---|---|---|---|
| Timeline declaration | Yes, as declared | MDN animation-timeline | Does not prove the rendered animation runs as intended |
Named timeline wiring via timeline-scope |
Yes, if the declarations are traceable | MDN timeline-scope | Does not prove runtime resolution in every environment |
| Keyframe and range coherence | Yes, as a source-level relationship | Chrome for Developers | The visual result remains unobserved |
| Scroll progress math | Partially | W3C Scroll-driven Animations | No browser was run; geometry is not rendered here |
| View-progress semantics | Yes, as declared | MDN animation-timeline | Does not show how the element looks while entering or leaving |
| Reduced-motion fallback declared | Yes | MDN prefers-reduced-motion | The alternative experience is not observed |
| Reduced-motion experience | No | MDN’s media-feature guidance | No browser was run |
| Cross-browser fallback behavior | No | MDN marks the feature Limited availability | Current Firefox and Safari status is unverified |
| Smoothness and feel | No | No rendered evidence | Requires a renderer, observation system, or human review |
The table captures the key design-agent boundary: the agent can audit a declared contract, but not certify the experience produced by that contract.
Reduced Motion: The Fallback an Agent Must Always Check
prefers-reduced-motion is Baseline “Widely available” since January 2020. Its reduce value represents an OS-level setting. For an agent reviewing scroll-driven motion, this makes reduced-motion handling one of the highest-value static checks.
The agent should search for a @media (prefers-reduced-motion: reduce) block that addresses any scroll-driven animation. The goal is not merely to find the string reduce; it is to determine whether the branch changes or removes the motion that could otherwise be problematic.
MDN gives a concrete muted-alternative pattern: replace a scale pulse with an opacity dissolve. That example is useful because it demonstrates a design decision rather than a browser claim. The fallback does not need to preserve the same visual movement. It needs to provide a less motion-intensive alternative, and the agent can verify whether the stylesheet declares such an alternative. See the MDN reduce guidance.
The agent still cannot verify the felt result of the alternative. It can establish that the author accounted for the preference and that the relevant declarations are guarded. It cannot decide whether the replacement is visually clear or comfortable without observing it.
The Browser-Support Blind Spot
The support story must be stated narrowly. MDN marks animation-timeline as Limited availability and not Baseline. Chrome for Developers lists Chrome 115 as the first version with scroll-driven animation support. Those are the supported facts an agent can cite when flagging compatibility risk.
The current status of Firefox and Safari is NOT verified here. The Chrome page’s support badges list Firefox Technology Preview and Safari 26, but this review did not confirm either against a live browser. The agent must not infer it from the absence or presence of a source citation, and it must not produce a current browser-support table from unverified assumptions.
This is where a static review can still help. It can flag the use of a feature whose availability is limited, identify whether a fallback is declared, and request a browser-based compatibility pass. It cannot declare the fallback successful simply because the CSS is syntactically coherent.
For contextual examples and terminology, an agent may also consult scroll-driven-animations.style, but examples do not substitute for the support statement above or for a render-based test.
An Agent Verification Checklist
A practical review can follow this sequence:
- Find the timeline declaration. Confirm that
animation-timelineis present where the animation is defined and that its value is one of the documented forms:none,auto,scroll(),view(), or a named dashed identifier. Use MDN’s reference as the vocabulary check. - Identify the timeline type. Determine whether the animation is scroll-progress-based or view-progress-based. Do not confuse scroll-driven progress with scroll-triggered, time-progressed animation.
- Resolve named timelines. Follow the name through the scroll source and animated element. If the scroller is not an ancestor of the animated element, inspect the shared-parent
timeline-scopedeclaration. - Check progress assumptions. For
scroll(), compare the intended scroll source with the scroll progress model: 0% at the startmost position and 100% at the endmost position. - Check view ranges. For
view(), inspect whether the keyframes carry the range information. Do not requireanimation-rangewhen the documented pattern places that information in the keyframes. - Check reduced motion. Look for
@media (prefers-reduced-motion: reduce)and verify that the scroll-driven motion has a declared alternative or is disabled. - Flag support carefully. Report MDN’s Limited availability status and the Chrome 115 support milestone without asserting unverified current Firefox or Safari status.
- Escalate the experience. Mark smoothness, feel, visual hierarchy, and actual fallback behavior as requiring a renderer or human review. No browser was run here.
FAQ
Is scroll-driven animation the same as scroll-triggered animation?
No. Scroll-driven animation has progress tied to scroll position. Scroll-triggered animation is triggered by scrolling but progresses over time. The distinction is defined in the W3C specification.
Can an agent verify that the animation will run at all?
It can verify the declared machinery: the timeline value, the relationship to the animation, named-timeline wiring, and relevant fallback declarations. It cannot prove the rendered result without a browser observation. The default is a time-based DocumentTimeline, and animation-timeline replaces it only when set, as described by MDN.
What does view() measure?
A view progress timeline measures an element’s visibility inside a scrollport. Its progress runs from first visibility at one edge to the element’s end edge exiting the opposite edge. See MDN’s view() reference.
How can a non-ancestor use a named timeline?
A named timeline can be exposed through timeline-scope on a shared parent. That allows a non-ancestor to attach to the named scroll timeline. The pattern is documented by MDN’s timeline-scope reference.
Do I always need animation-range with view()?
No. With view(), the keyframes can contain the range information, so animation-range is not needed for the documented list-view pattern. This is the pattern described by Chrome for Developers.
What about Firefox and Safari?
Their current status for animation-timeline is NOT verified in this review. The supported statement is that MDN marks the feature Limited availability and not Baseline because it does not work in some widely used browsers.
The Bottom Line
Verdict: conditional trust.
An AI agent can verify the declared contract of scroll-driven CSS animation with meaningful confidence. It can inspect timeline bindings, distinguish scroll and view progress, follow timeline-scope wiring, check keyframe range choices, and require a prefers-reduced-motion branch.
It cannot verify the experience it cannot watch. Smoothness, feel, visual timing, practical comfort, and actual cross-browser fallback behavior remain outside a purely static review. The right workflow is therefore two-tiered: use the agent for a precise static pass, then escalate experiential and compatibility questions to a rendering harness or human reviewer.
The agent should not pretend to see motion. It should make the boundary explicit, preserve every uncertainty, and turn unrenderable questions into clear follow-up work.
How This Guide Was Built
This guide uses MDN’s animation-timeline page, MDN’s scroll-driven animations page, and MDN’s prefers-reduced-motion page; the W3C Scroll Animations Working Draft and its editor’s draft; and Chrome for Developers’ scroll-driven animation documentation. The MDN pages were last modified September 16, 2026; October 5, 2026; and June 10, 2026, respectively. It identifies the W3C Working Draft as latest published in 2023 with an editor’s draft open, and the Chrome for Developers page as published May 5, 2023 and last updated 2023-05-05.
The facts were fetched in-session on 2026-10-25. This review makes no hands-on browser-testing claim. No browser was run. Current Firefox and Safari status is NOT verified, and whether getComputedStyle exposes animation timing specifics is NOT verified. The analysis deliberately separates source-level checks from claims about rendered motion.