[scroll-animations-1] currentTime for animations attached to a timeline attachment range · Issue #8669 · w3c/csswg-drafts (original) (raw)

While playing with ViewTimelines and trying to derive how much of an animation-range had already progressed, it surprised me that reading currentTime always returned the progress relative to the entire ViewTimeline range.

To demonstrate, I have a demo up on CodePen which you can check using the latest Chrome Canary. The demo tries to resprent the progression within the currently set animation-range for the ViewTimeline and has these controls:

• Using the radio buttons it’s possible to change the animation-range
• Using the “set range-start to 20% and range-end to 80%“ checkbox it’s possible to set the range-start and range-end percentages to 20% and 80% respectively. When not checked, the default values of 0% and 100% are used.
• The “force main thread animation“ checkbox is added to work around https://crbug.com/1421690

On load, the animation-range is set to entry 20% entry 80%.

The demo outputs the currentTime in three possible ways:

1. Directly read it from the animation.
   let progress = animation.currentTime;
   This doesn’t work when set to a value other than cover. This because italways returns the progress measured against the entire range of the ViewTimeline (which coincides with cover)
2. Read it from the range
   let progress = animation.timeline.getCurrentTime(animation.rangeStart.rangeName).value;
   Using getCurrentTime[ForRange] doesn’t cut it here things here, as it only covers animations that have the same rangeName in animation-range-start and animation-range-end. Above that, it also only works for when the entire range is covered (from 0% to 100%).
3. Read from the animation’s effect
   As a workaround, I turned to reading the animation’s effect, which did the trick:
   // This works
   let progress = animation.effect.getComputedTiming().progress * 100;
   if (animation.playState === 'finished') progress = 100;
   This, however, felt a lot like jumping through hoops to be honest.

To simplify things for authors, I would like to propose that currentTime (the method used in the first approach) returns the progress relative to the timeline attachment range.

• If one explicitly sets the animation-range to, for example, entry 50% cover 100% the currentTime should be relative to that set (custom) range.
• If one sets no animation-range, the progress should be relative to the entire range, which for View Timelines equals to cover

I think this change also lines up with what @fantasai described here (and which was adopted by the WG):

The animation is attached to a timeline. But more specifically, it is attached to a timeline attachment range. By default this is the entire timeline, which in the case of a scroll-driven timeline is finite, and in the case of a time-driven timeline is infinite. The attachment range is the portion of the timeline that the animation is laid out in (somewhat analogous to a containing block).

Note that in this case getCurrentTime[ForRange] would still be relevant to keep, as it allows you to get the currentTime as if the range was spanning from 0% to 100%.

WDYT @fantasai @flackr @kevers-google @birtles?