Open DavMila opened 1 month ago
Hi @DavMila - just a quick question: you've indicated "CSS working group" as where this work is being done. However it doesn't seem to be in the CSS repo... is this an official CSS working draft or is it that the intention is to submit it to the CSS working group? Thanks! ✨
Hi @DavMila - just a quick question: you've indicated "CSS working group" as where this work is being done. However it doesn't seem to be in the CSS repo... is this an official CSS working draft or is it that the intention is to submit it to the CSS working group? Thanks! ✨
Thanks for the question. It's in the web-animations-2 spec in the official CSSWG repository for editor's drafts of CSS specifications . I don't think the web-animations-2 spec has been published as a working draft so it's still an editor's draft. So it has been submitted to the CSS working group as part of an editor's draft but not yet a working draft.
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:
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
and the named timeline 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.
I've updated the explainer to address some of the concerns raised by @jyasskin .
- It doesn't say why the developer is writing code like this in the first place.
- 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 interest in a progress accessor was mainly driven by scroll-driven animations but it does seem to be a concept that would be valid for time-driven animations as well so I've set up a demo showing a more useful scenario: where a dev might want to synchronize audio based on the progress of an animation .
I've also:
scrollTop
could instead be used to make the before/after contrast clearer.About the name of the property, I agree that it could be confusing, maybe a name like totalProgress
would work better - I'll file an issue with the CSS working group for this.
Further feedback appreciated :)
こんにちは TAG-さん!
I'm requesting a TAG review of Animation.progress.
This feature adds a "progress" property to the JavaScript class Animation. The goal of this property is provide authors a convenient and consistent representation of how far along an animation has advanced across its iterations and regardless of the nature of its timeline.
Further details: