2 views
Skip to first unread message

David Awogbemila

unread,
5:41 PM (4 hours ago) 5:41 PM
to blink-dev
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 by 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

No milestones specified



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.
Reply all
Reply to author
Forward
0 new messages