You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Scroll-driven Animations specification discusses this only within the context of CSS-declared @keyframes rules, but the Web Animations specification does not discuss how such values can be used through the Web Animations API and the various methods it defines to consume keyframes: animate(), setKeyframes() and the KeyframeEffect constructor. It doesn't discuss either how such keyframe offsets would be dealt with in a call to getKeyframes().
There are a fair few WPT tests related to this, too many to list here, so the Chrome team has given this some thinking and WebKit will be getting support for this in short order, but this entire area needs to be specified and the merits and the approach taken by the Chrome team need to be discussed.
The text was updated successfully, but these errors were encountered:
In the Web Animations spec, ranges can be used by rangeStart and rangeEnd properties on the animation options (discussed in #7589), and #10000 is proposing supporting them for keyframe offsets as well. These are represented as a TimelineRangeOffset when returned and we would presumably do the same for offsets.
Yes, that is what Chrome implements and it sounds reasonable. We need updates to the spec to specify expanded variants in the IDL for the various dictionaries and the minutiae of how to represent unresolved computed offsets (Chrome uses NaN) and the relative sorting of keyframes with null, double and TimelineRangeOffset specified offsets.
The Scroll-driven Animations specification defines Named Timeline Range Keyframe Selectors allowing specific portions of a scrollable area to be targeted while rendering animations. Specifically, the combination of a
<timeline-range-name>
and a<length-percentage>
such ascover 10%
.The Scroll-driven Animations specification discusses this only within the context of CSS-declared
@keyframes
rules, but the Web Animations specification does not discuss how such values can be used through the Web Animations API and the various methods it defines to consume keyframes:animate()
,setKeyframes()
and theKeyframeEffect
constructor. It doesn't discuss either how such keyframe offsets would be dealt with in a call togetKeyframes()
.There are a fair few WPT tests related to this, too many to list here, so the Chrome team has given this some thinking and WebKit will be getting support for this in short order, but this entire area needs to be specified and the merits and the approach taken by the Chrome team need to be discussed.
The text was updated successfully, but these errors were encountered: