- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Aug 2023 01:42:19 +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? > @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. (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.) [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. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9256#issuecomment-1696646960 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 29 August 2023 01:42:21 UTC