- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Aug 2020 07:08:31 +0000
- To: public-css-archive@w3.org
> We have precedence for the play state being restricted to the idle or paused when the timeline is explicitly null. This was captured in the following WPT test: > > * wpt/web-animations/timing-model/animations/setting-the-timeline-of-an-animation.html > * After clearing timeline on finished animation it is idle > * After clearing timeline on running animation it is idle > > The expectations were updated in https://chromium-review.googlesource.com/c/chromium/src/+/2150687; however, the expectations no longer align with the test description. The text associated with these tests could be updated if the new behavior is in fact what we want. I think the tests and descriptions are somewhat irrelevant to determining the specified behavior. They should simply be capturing what the spec text says so what I'm curious about is if the spec ever differentiates between the lack of an associated timeline and an associated but inactive timeline for the purposes of timing calculations. If it doesn't (and as best I recall it doesn't), it seems like we probably shouldn't introduce that distinction here. > Though one can think of an animation with a null timeline as one that is always inactive, the distinction is that the animation will never tick until the timeline is changed. In the case of scroll timelines, the inactive state is transient. Yes, but I wonder if that should matter? With regards to the determining the play state, it seems like it shouldn't depend on whether the timeline could become active or not? > Having said that, I'm OK with going either way on this, but would like to see consistency with the test expectations and descriptions. Yes, agreed! I find these changes very difficult to reason about (which is really my fault for failing to get spec in a better shape before it was shipped) and was very concerned about the original change to the play state algorithm (which added the condition for an unresolved start time). Assuming we stick with that, however, I think we should _not_ add the condition regarding an unresolved timeline because: * We typically treat the lack of an associated timeline and an inactive timeline as the same for the purpose of timing calculations * It would be odd to further extend this condition to include inactive timelines because then the play state would suddenly change when the timeline became active and it probably shouldn't do that (except with regards to the finished state) -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5400#issuecomment-672665371 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 August 2020 07:08:33 UTC