Re: [w3ctag/design-reviews] Spec review for Animation.progress (Issue #994)

After a discussion in a breakout:

The explainer doesn't justify this feature well enough. It presents two use cases: one for showing a percentage through a time-based animation, and another for showing a scroll percentage.
  
The time-based animation has two issues:
1. It doesn't say why the developer is writing code like this in the first place.
2. It doesn't show how `updateInfo` would get called.  A big reason to do animations with CSS is to get them off the main thread, but this seems to require interrupting the main thread periodically to change the text.

The scroll percentage code doesn't show the "before" state. What would the code look like if you only used `scrollTop` and friends to measure progress and draw the meter? Is using animations simpler or more performant here, given the common use cases' needs for [`animation-range`](https://drafts.csswg.org/scroll-animations-1/#propdef-animation-range) and the [named timeline ranges](https://drafts.csswg.org/scroll-animations-1/#view-timelines-ranges)? 

It's possible but complicated to render text directly from an animated property: https://dev.to/madsstoumann/clocks-countdowns-timing-in-css-and-javascript-554n. Maybe the use cases for `Animation.progress` would be better served by making that easier to use?

Finally, if you do need a property for this, it seems confusing to have two `.progress` properties with different meanings (within-iteration for `myAnimation.effect.getComputedTiming().progress` vs overall for `myAnimation.progress`). Please find a different name for the new meaning.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/994#issuecomment-2427287323
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/994/2427287323@github.com>