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

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

Yes, I agree that it's inconsistent and odd. But perhaps it can be explained that while scroll animation is pending, calculating current time requires up to date playback_rate.

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

I prototyped this in Chromium and ran all the timing tests. I didn't find any failures with the exception of pending flag being false after play() and timing of ready promise. Note that  [update an animations finished state](https://drafts.csswg.org/web-animations/#update-an-animations-finished-state) invoked from [setting the start time](https://drafts.csswg.org/web-animations-1/#setting-the-start-time-of-an-animation) (see the last bullet) should be called with _did seek_ flag set to false. Alternatively play task can be called synchronously from play().

This is probably the right way to go since there is no really pending actions that can not be accomplished synchronously. I am just worried that it can complicate user scripts when both scroll and time linked animations are involved.

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

What does it mean the current time is out of date? Unresolved and no effect? If so it will be inconsistent with time linked animations in pending state. 



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

Received on Wednesday, 13 May 2020 21:26:46 UTC