[csswg-drafts] [web-animations-2] Progress APIs (#8799)

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

== [web-animations-2] Progress APIs ==
In #8669, #8765 and #8201 there seems to be a common desire to have more convenient APIs for getting some representation of progress. Currently you can get the progress of the current iteration of an effect using the [getComputedTiming()](https://www.w3.org/TR/web-animations-1/#dom-animationeffect-getcomputedtiming) API as follows:

```js
let progress = animation.effect.getComputedTiming().progress;
```

You can also get the overall effect progress by doing a calculation such as:
```js
let progress = animation.currentTime / animation.effect.getComputedTiming().endTime;
```

However, with several of the other linked issues it seems that it would be convenient for developers to have some form of access to the progress through the attached animation range, or to get that progress directly from the timeline.

We could add a convenience currentProgress helper alongside the currentTime API on [Animation](https://www.w3.org/TR/web-animations-1/#the-animation-interface):
```
attribute double? currentProgress;
```
This could return the progress of currentTime through the entire range before which it is considered complete, e.g. calculated as follows:

currentProgress = [currentTime](https://www.w3.org/TR/web-animations-1/#animation-current-time) / [effect endTime](https://www.w3.org/TR/web-animations-1/#end-time)

Note that endTime is infinite when either iterations or duration is infinite. In these cases currentProgress should probably be null or undefined?

Open question - should it be read only or should we allow setting the progress which would be equivalent to setting currentTime to currentProgress * endTime?

As per discussion on #8669 a progress reported on animation should be mostly independent of the effect timing, so we calculate it as the progress from [startTime](https://www.w3.org/TR/web-animations-1/#dom-animation-starttime) to the time when the animation would resolve its finished promise. This would intentionally not match the progress through the developer specified keyframes.

@birtles @bramus @fantasai 

I also propose that given the uncertainty around what's expected from the `getCurrentTime` API on timeline, that we remove it until we have a better understanding of the specific use cases that developers need it for. Perhaps the animation progress API above will address some of them where it seems developers were trying to work this out through the timeline.

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


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

Received on Friday, 5 May 2023 15:32:31 UTC