Re: [csswg-drafts] [web-animations-2] Add `Animation.started` and `Animation.playing` promises (#5871)

> ## Related Proposals
> 
> 1. [[web-animations-2] animation (or effect) start and iteration events #4461](https://github.com/w3c/csswg-drafts/issues/4461)
> 
> 2. [[scroll-animations] Should animation events fire every time active range is left / reentered? #4324](https://github.com/w3c/csswg-drafts/issues/4324)

Thank you! That looks right.

> ## Motivation & Use Cases
> 
> Often, an author needs to synchronize arbitrary code with a web animation. For example, during a few key points in an animation lifecycle, one may need to manipulate the DOM, or initiate network requests, or conditionally trigger other animations, among other things.

Thank you. I was hoping there might be more specific use cases but the precedent of CSS animation events is compelling enough that I think this makes sense.

> _"2. When the animation is played"_ could be handled in one of two ways:
> 
> * `Animation.played` Promise
>       --or--
> * `animationplay` event
> 
> 
> I think there is an argument to be made that `Animation.played` is analogous to `Animation.ready` and, as such, it makes sense to use a Promise. I suppose this would fall under `2.3. More general state transitions` in the [Writing Promise-Using Specifications](https://www.w3.org/2001/tag/doc/promises-guide#when-to-use) document.
> 
> Side note: even after reading the spec a few times and experimenting with the `Animation.ready` promise, I'm still unclear on it's use-case or why a Promise was used versus and event. Perhaps an exploration of that reasoning could help guide a decision for an `Animation.played` Promise.

The `Animation.ready` promise fits into the "One-and-done operations" category, i.e. asynchronous operations. Calling `play()` and `pause()` triggers an asynchronous operation to setup the playback / pausing by synchronizing with the state of animations running on other processes/threads. The `ready` Promise resolves when that async operation has completed.

Initially the expectation was that user agents might take different amounts of time to setup animations but in practice all user agents resolve the promise on the next animation frame unless the animation is already playing or unless it is associated with an inactive timeline.

As for use cases, it lets you know when it is safe to read the `startTime` (in the casing of playing) or `currentTime` (in the case of pausing), so that, for example, you can synchronize other animations with the newly played/paused animation.

I'm still not clear on the use cases for the `played` promise, however. When do you ever have an animation that you don't initially `play()` on, where the caller of `play()` is sufficiently distant from the observer of played state that you can't call it directly, and where events would not be ergonomical?

As I understand it, the examples for "More general state transitions" in that document refer to async operations that differ from this case. Also it seems like the warnings about over-using Promises apply to this case, at least as I understand it.

> ### `AnimationEffect`
> 
> In issue #4461, You wrote:
> 
> > If we were to add iteration events they would most naturally become a property of the effects...Initially these events were not added because of performance concerns...since then we've taken a different approach to the requirements for dispatching events for CSS animations that limits events to 1~2 per animation frame. I think that would address some of the performance concerns we previously had

Thanks, that's great. (I've moved this discussion to web-animations-2 in keeping with the discussion there.)

Yes, it does sound like we could resolve the performance issues I had in mind.

> An uneducated guess of what AnimationEffectEvent could look like: [...]

That all seems reasonable.

> This would require adding a new `name` attribute to `AnimationEffect`:

I wonder if that would be necessary if we make the target of the event the `AnimationEffect` itself? (Since only `KeyframeEffect`'s have a (pseudo-)element target and even that is optional.)

> ## Next Steps
> 
> Would it be helpful if I created separate proposals for `AnimationEffectEvent` and/or `Animation.played` ?

I'm personally still unclear about `Animation.played` but I can see `AnimationEffectEvent` as being worth specifying if you have time to work on it!

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5871#issuecomment-760587697 using your GitHub account


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

Received on Friday, 15 January 2021 01:40:04 UTC