[csswg-drafts] [web-animations-1][scroll-animations-1] Animations on inactive timelines should still become ready (#9256)

flackr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [web-animations-1][scroll-animations-1] Animations on inactive timelines should still become ready ==
[web-animations-1 section 4.5.6](https://drafts.csswg.org/web-animations-1/#waiting-for-the-associated-effect) says

> An animation is ready at the first moment where both of the following conditions are true:
>
> * the user agent has completed any setup required to begin the playback of the animation’s [associated effect](https://drafts.csswg.org/web-animations-1/#animation-associated-effect), including rendering the first frame of any [keyframe effect](https://drafts.csswg.org/web-animations-1/#keyframe-effect).
>
> * the animation is associated with a [timeline](https://drafts.csswg.org/web-animations-1/#timeline) that is not [inactive](https://drafts.csswg.org/web-animations-1/#inactive-timeline).

Per [scroll-animations-1 section 2.1](https://drafts.csswg.org/scroll-animations-1/#scroll-timeline-progress), there are conditions during which a scroll or view timeline can be inactive (e.g. the scroller is not currently scrollable) but may become active as a result of a user action, e.g. resizing the browser window such that the scroller is visible.

As a result of the second condition above, an animation using an inactive timeline is not considered to be "ready" until the scroll range is available. E.g. if you load the following demo the animation becomes ready once the viewport is smaller than the black box: https://jsbin.com/xezuluc/edit?js,output

This seems counter-intuitive to me. As a developer I would expect animations to become ready once the setup was complete, but not to be indefinitely delayed. E.g. a start delay on a time-based animation does not delay the ready promise. 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 think a developer would expect the animation ready promise to resolve once the animation has entered its current stable state.

@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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9256 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 28 August 2023 19:55:11 UTC