[csswg-drafts] [scroll-animations-1] currentTime for animations attached to a timeline attachment range (#8669)

bramus has just created a new issue for https://github.com/w3c/csswg-drafts:

== [scroll-animations-1] currentTime for animations attached to a timeline attachment range ==
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](https://codepen.io/bramus/full/RwYOYeO/b972db85414fe9f8ef17e6c1b304c1e8) 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.

    ```js
    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

    ```js
    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:
    
    ```js
    // 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](https://github.com/w3c/csswg-drafts/issues/8405#issuecomment-1464810166) _(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?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8669 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 2 April 2023 18:13:22 UTC