W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

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

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Fri, 15 May 2020 07:19:22 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-629074135-1589527160-sysbot+gh@w3.org>
> > 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.

Yes, that's a very valid concern.

However, I _think_ by calling the procedure to _set the start time_ the Promise resolution procedure will mean those callbacks get called at the next microtask checkpoint so those code will still act more-or-less the same in both cases.

The only difference is that the `pending` state is false immediately after calling `play()` for the scroll-timeline case. However, that is already true if, for example, you call `play()` on an already running animation attached to a document timeline--so in that sense we're being consistent with the idea that we only go pending if there is pending work to do.

(And the more I think about it, the more I wonder if the pending playback rate actually needs to be applied asychronously for `play()` anyway? I'm having trouble thinking of a scenario where it would make a difference?)

While we're touching this procedure, I wonder if it would be more neat to drop the _performed seek_ flag and set a local _seek time_ variable. Then, if that value was set, before step 6 we'd either update the _hold time_ or call the _set the start time_ procedure? (And possibly clear the _hold time_ value there too as per this PR?)

Thanks for all your work on this. Unfortunately I think at this time it's only you and I who are really familiar with these procedures and they're very complicated. I wish we could make them all simpler somehow!

GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5059#issuecomment-629074135 using your GitHub account
Received on Friday, 15 May 2020 07:19:26 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:06 UTC