Spec review for Animation.progress

[DavMila]

こんにちは 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.

• Explainer¹: https://github.com/DavMila/explainer-animation.progress
• Specification: https://drafts.csswg.org/web-animations-2/#the-progress-of-an-animation
• WPT Tests:
  • https://wpt.fyi/results/web-animations/interfaces/Animation/progress.tentative.html?label=master&label=experimental&aligned&q=web-animations%2Finterfaces%2Fanimation%2Fprogress.tentative.html
  • https://wpt.fyi/results/web-animations/interfaces/Animation/scroll-timeline-progress.tentative.html?label=master&label=experimental&aligned&q=web-animations%2Finterfaces%2Fanimation%2Fscroll-timeline-progress.tentative.html
• User research: N/A
• Security and Privacy self-review²: This feature has no known privacy/security concerns.
• GitHub repo: None
• Primary contacts:
  • David Awogbemila (@DavMila), Google, Developer
  • Robert Flack (@flackr), Google, Developer
• Organization/project driving the specification: CSS Working Group
• Multi-stakeholder support³:
  • Chromium comments: Implemented as an experimental feature, crbug.com/40914396
  • Mozilla comments: Animation.progress mozilla/standards-positions#1073
  • WebKit comments: Animation.progress WebKit/standards-positions#398
• Status/issue trackers for implementations⁴: Chromestatus

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Chrome would like to ship whenever possible.
• The group where the work on this specification is currently being done: CSS Working Group
• Major unresolved issues with or opposition to this specification:
  • [web-animations-2] Progress APIs w3c/csswg-drafts#8799 (comment) (whether to clamp to [0,1])
• This work is being funded by: Google

[torgo]

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! ✨

[DavMila]

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.

[jyasskin]

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 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.

[DavMila]

I've updated the explainer to address some of the concerns raised by @jyasskin .

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 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:

• included a scroll-driven demo where the currentTime of a video is set based on the progress of a scroll-driven animation.
• included a code example of how 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 :)

[jyasskin]

@tabatkins, does w3c/csswg-drafts#6245 (comment) affect this review?

[tabatkins]

No, completely unrelated name clash.

[jyasskin]

Thank you for the fleshed out use cases in the explainer. We agree that it makes sense to be able to pass this value through Javascript to feed it into any parts of the platform that can't be directly animated by CSS.

Thank you also for driving the CSSWG to pick a clearer name. With that done, we don't see any other issues with this proposal, so we'll close this review. Thanks!