Intent to Ship: Timeline Named Range "scroll"

[David Awogbemila]

Contact emails

awogb...@google.com

Explainer

No information provided

Specification

https://drafts.csswg.org/scroll-animations-1/#valdef-animation-timeline-range-scroll

Summary

This feature expands the set of named ranges of view timelines, adding a "scroll" range. The Scroll-Driven Animations API introduced ViewTimelines along with named ranges which refer to portions of a ViewTimeline that define an animation's range[1]. However, all the named ranges provided were restricted to the portion of the ViewTimeline where its subject is visible. It is useful for authors to be able to refer to the full extent of the scroll container underlying the timeline. This feature facilitates this by adding a named range of "scroll" to the existing set ("entry", "exit", "cover", "contain").

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/animation-range

Blink component

Blink>Animation

Web Feature ID

Missing feature

Motivation

A scroll-driven animation's range[1] can be described in terms of the (named) ranges of a ViewTimeline, i.e. "cover", "contain", "entry", "exit." This allows authors to tie the progress of the animation directly to the the position of the ViewTimeline's subject within the scroll container underlying the ViewTimeline.

However, ViewTimelines are, by default, constrained to the portion of the underlying scroll container within which the subject is (wholly or partially) visible, i.e. the "cover" range, i.e. { rangeStart: cover 0%, rangeEnd: cover 100%}. This means that an author has no way, for example, to refer to a range that starts when the subject is visible but ends at the end of the scrolling container (rather than when then subject stops being visible). They could opt for a hack like { rangeStart: cover 0%, rangeEnd: cover 10000%}, having attempted to manually calculate rangeEnd. Similarly, to set rangeStart, to the start of the scroll container they'd need to compute some negative percentage or px offset.

With a named range of "scroll", the author would write "scroll 0%" or "scroll 100%" instead of manually-calculated values.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/animation-range

Initial public proposal

https://github.com/w3c/csswg-drafts/issues/9367#issuecomment-1854280461

TAG review

We think this should be covered by the TAG review[1] for scroll-driven animations as it extended the API introduced in that feature by one keyword. 

[1] https://github.com/w3ctag/design-reviews/issues/828

TAG review status

Pending

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/scroll-animations/view-timelines?label=master&label=experimental&aligned&q=view-timeline-get-current-time-range-name.tentative.html https://wpt.fyi/results/scroll-animations/css/view-timeline-range-animation.html?label=master&label=experimental&aligned&q=view-timeline-range-animation.html https://wpt.fyi/results/scroll-animations/view-timelines/view-timeline-get-set-range.html?label=master&label=experimental&aligned&q=view-timeline-get-set-range.html

Flag name on about://flags

No information provided

Finch feature name

No information provided

Non-finch justification

No information provided

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/41483848

Estimated milestones

Shipping on desktop	146
Shipping on Android	146
Shipping on WebView	146

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6522328437620736?gate=6481153257242624

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

Can you ask for signals?

 

Web developers: No signals

Presumably, we're shipping this because this is something developers want to use..

[Bramus Van Damme]

Yes, authors need this. Not only for Scroll-Driven Animations, but also for Scroll-Triggered Animations when you want to implement a trigger that fires only once. The end of the activation range for such a trigger is then typically set to “scroll 100%”.

[David Awogbemila]

I think this CSSWG issue comment might be the only external one I have; I've added it to the chromestatus page.

Bramus's comment also highlights that the "scroll" keyword will be particularly useful for Scroll-Triggered Animations:

it allows authors to effectively create timeline ranges with a single trigger point (since the boundaries of the "scroll" range cannot be crossed).

[Alex Russell]

So there's no explainer, no developer feedback, and no examples...are we being asked to ship this first? Feels higher risk than it should be. Can a developer combine `scroll` and `exit`, e.g.?

[David Awogbemila]

Apologies, perhaps I assumed too strongly that it would be considered a minor extension to the scroll-driven animations API.

I've written an explainer and updated the chromestatus page with it.

Happy to provide further info.

[Dan Clark]

Thanks for providing the explainer, I found the examples helpful in understanding the need for the feature.

I'll +1 the request for browser signals; I'd like to understand if other browsers plan to ship this addition.

The first linked WPT https://wpt.fyi/results/scroll-animations/view-timelines?label=master&label=experimental&aligned&q=view-timeline-get-current-time-range-name.tentative.html looks like it's mainly testing for getCurrentTime which was removed from the spec per https://github.com/w3c/csswg-drafts/issues/8765. Can you confirm that's not part of what's being shipped here?

[David Awogbemila]

On Tue, Jan 20, 2026 at 3:35 PM 'Dan Clark' via blink-dev <blin...@chromium.org> wrote:

Thanks for providing the explainer, I found the examples helpful in understanding the need for the feature.

I'll +1 the request for browser signals; I'd like to understand if other browsers plan to ship this addition.

Thanks for the feedback. I've now filed requests for WebKit & Mozilla positions.

The first linked WPT https://wpt.fyi/results/scroll-animations/view-timelines?label=master&label=experimental&aligned&q=view-timeline-get-current-time-range-name.tentative.html looks like it's mainly testing for getCurrentTime which was removed from the spec per https://github.com/w3c/csswg-drafts/issues/8765. Can you confirm that's not part of what's being shipped here?

Yes I can confirm that getCurrentTime is not part of what we're shipping. The only thing we are shipping is support for the keyword "scroll." 

 

[Rick Byers]

Thanks David. LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA6pwF7SKXY%3DfOH6gKTxurh-UU_tS6honKtFgLSmK%2B3V-nxwTw%40mail.gmail.com.

[Dan Clark]

LGTM2