- From: Olga Gerchikov via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 May 2020 23:51:54 +0000
- To: public-css-archive@w3.org
> In any case, I still want to refactor this to make step 5 simply set a local seek time variable, and then, as a separate step, update either the hold time or start time based on the value of finite timeline. Once we do that, it would be easier to clear the pending playback rate there too if we decide to do that. Second commit has the refactoring per your suggestion, both play and pause procedures. It's much cleaner now. > Ok, please help me try to understand. I believe Kevin is suggesting that simply resetting the hold time when setting the start time is enough to fix both problems? Is that correct? Olga, does that work? I spoke to Kevin offline and his point was that clearing hold time is required but not sufficient for the reverse() case. > I was thinking more about diverging play procedure for scroll animations to call set start time. I feel like this inconsistency is "more inconsistent" than applying pending playback rate. > > > I'm not quite sure I follow. Does this mean that you prefer we don't call the "set start time" procedure but just directly apply the pending playback rate? Is there anything in particular that you feel is better about that? Yes, I prefer we don't call "set start time" from play. I also spoke to Kevin about it and his preference is alike. He is concerned that differences in timing of ready promise resolution might complicate user scrips. In the example below, pause() resolves new promise for scroll animations, versus the one from play() procedure for the time based animations (see [Pausing an animation](https://drafts.csswg.org/web-animations/#pausing-an-animation-section) step 7). ``` anim.play(); anim.pause(); ``` > How about we generalize updating playback rate asynchronously only when it's needed? In this case the condition will be: > > - If performed seek is true or hold time is resolved, > - Apply any pending playback rate on animation. > > That's interesting. What would that help with? This is my attempt to generalize when playback rate doesn't need to be updated asynchronously so animation type is not a factor in the logic. In general, it feels like differences in timing of updating playback rate is a "lesser evil" than having pretty much different play procedure for scroll animations. However I'll trust your judgement since you are the expert and my opinion is more based on intuition rather than real data. -- GitHub Notification of comment by ogerchikov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5059#issuecomment-635004489 using your GitHub account
Received on Wednesday, 27 May 2020 23:51:55 UTC