Re: [csswg-drafts] [web-animations-1] Fixed play animation procedure for scroll animations (#2075) (#5059)

> > But thinking about this further, currently the whole point of the pending task is typically to resolve a suitable start time. That's why setting the start time cancels any pending tasks.
> 
> I was also thinking that perhaps initializing start time in play() should work the same as [setting the start time](https://drafts.csswg.org/web-animations-1/#setting-the-start-time-of-an-animation) regardless of timeline activeness. However I convinced myself otherwise to keep scroll and time linked animations behave similarly in terms of timing of resolving Ready promise and the value of pending flag.
> 
> In addition, calling play() on pause pending animation has the same effect - hold time unresolved, start time is resolved and Ready promise is resolved asynchronously.

There's a parallel though because both `play()` and `pause()` update the start time after the animation is ready (although in the latter case, it is updated to an unresolved time). With finite timelines, however, we're updating it synchronously.

My concern is that it feels odd that we are sometimes running the procedure to apply the pending playback rate synchronously and sometimes asynchronously. Don't you think that feels a bit odd? A bit unpredictable?

If we could do the whole thing synchronously by invoking the _set the start time_ procedure, that would at least be more consistent.

But I'm actually starting to wonder if the issue needs to be fixed in the first place. Could we just say that the _current time_ is out of date until the animation is ready? (As opposed to the _start time_ being out of date.)

For the second test, clearing the hold time probably makes sense (I need to double-check). Sorry, it takes me a long time each time to try and remember how this all fits together.

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

Received on Wednesday, 13 May 2020 09:38:48 UTC