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.?
On Wednesday, January 14, 2026 at 7:34:26 AM UTC-8 David Awogbemila wrote: > I think this CSSWG issue comment > <https://github.com/w3c/csswg-drafts/issues/9367#issuecomment-1730320477> > 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). > > On Wed, Jan 14, 2026 at 9:48 AM Bramus Van Damme <[email protected]> > wrote: > >> >> >> On Wednesday, January 14, 2026 at 2:57:24 PM UTC+1 Yoav Weiss (@Shopify) >> wrote: >> >> On Tuesday, January 13, 2026 at 5:19:24 PM UTC+1 David Awogbemila wrote: >> >> *Contact emails* >> [email protected] >> >> *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 >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAnimation%22> >> >> *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 >> >> >> Can you ask for signals? >> >> >> >> *Web developers*: No signals >> >> >> Presumably, we're shipping this because this is something developers want >> to use.. >> >> >> 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%”. >> >> >> >> >> >> *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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> https://wpt.fyi/results/scroll-animations/view- >> timelines?label=master&label=experimental&aligned&q=view- >> timeline-get-current-time-range-name.tentative.html http >> s://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 desktop146Shipping on Android146Shipping on WebView146 >> >> *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 >> <https://chromestatus.com/>. >> >> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3437d66a-8a6c-45ae-a33d-801dfaa31660n%40chromium.org.
