- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 Sep 2023 19:28:10 +0000
- To: public-css-archive@w3.org
> > As it is currently implemented, it's not safe to wait on animation ready promises even though the effect is as ready as it can be on the next rendered frame. > > I didn't understand this part. What's not safe about waiting on the ready promise? What I mean by "not safe" is that the code which is waiting for the animation to be "ready" may not run at all (if the observed scroller isn't scrollable) or not for quite some time, even though everything needed to run the animation has happened. > > @birtles, do you know why we have this condition? Would it be reasonable to remove it? I'm not sure which particular cases it is trying to cover. > > You mean the second condition? > > I don't recall (it would take a bit of digging to find out since the spec has moved repositories so many times) but I _think_ it comes down to the fact that calling `play()` is all about resolving the start time. Without an active timeline, you can't resolve the start time. I guess I would expect the animation to become ready once any necessary setup was complete but not to require waiting for some user triggered state change. E.g. it doesn't seem mandatory to me that we know what the start time will be as long as it has been set up and can be expected to take effect in the frame at which it should be active. > (Similarly, if we ever rebase SVG/SMIL animations on Web Animations, the SVG timeline does not become active until the `load` event fires for the nearest document fragment so the `ready` promise shouldn't resolve before that point because we don't know when the start time will be.) So at a high level this seems fine and safe in the meaning I meant above - as the document fragment will eventually load it's a reasonable thing to put some code behind that you expect to run once everything finishes loading, unlike how a scroll timeline may never become active until the user resizes the window. > [4.5.8 Playing an animation](https://drafts.csswg.org/web-animations-1/#playing-an-animation-section) has: > > > 12. Schedule a task to run as soon as animation is [ready](https://drafts.csswg.org/web-animations-1/#ready). The task shall perform the following steps: > > > > 1. Assert that at least one of animation’s [start time](https://drafts.csswg.org/web-animations-1/#animation-start-time) or [hold time](https://drafts.csswg.org/web-animations-1/#animation-hold-time) is [resolved](https://drafts.csswg.org/web-animations-1/#unresolved). > > 2. Let ready time be the [time value](https://drafts.csswg.org/web-animations-1/#time-value) of the [timeline](https://drafts.csswg.org/web-animations-1/#timeline) associated with animation at the moment when animation became [ready](https://drafts.csswg.org/web-animations-1/#ready). > > So if were to drop that condition, this procedure would no longer work since it assumes that when the animation is ready it has a timeline with a resolved time value (e.g. it attempts to calculate `ready time` − [`hold time`](https://drafts.csswg.org/web-animations-1/#animation-hold-time) / [`playback rate`](https://drafts.csswg.org/web-animations-1/#playback-rate)). > > If we update that procedure to allow an inactive timeline, we'd break the invariant that the `start time` is set when we're running and not pending. I worry that this invariant may no longer be as strong as it should be. Scroll driven animations don't have a correct start time when the timeline becomes inactive. E.g. try out https://jsbin.com/fuzomoq/edit?css,js,console,output . The start time can't compute correctly until the view is scrollable but the animation state is running and not pending. @kevers-google -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9256#issuecomment-1712129580 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 8 September 2023 19:28:12 UTC