[csswg-drafts] [web-animations-2][css-animations-2]Should an animation-trigger prevent its animation from taking effect until the trigger says so? (#11971)

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

== [web-animations-2][css-animations-2]Should an animation-trigger prevent its animation from taking effect until the trigger says so? ==
In the web animations [spec](https://drafts.csswg.org/web-animations-2/#the-animationtrigger-interface), we say that `animation-triggers` should `play`, `pause`, `cancel`, or `reverse` their associated animations when their triggering conditions are met. Animations with triggers will remain idle until their trigger takes action on them, meaning these animations will have no visual effect, even e.g. with `animation-fill-mode: both`.

NOTE: This only applies to animations with scroll-based triggers, i.e. animations whose trigger has a progress-based timeline (`ScrollTimelines` or `ViewTimelines`). Since, at the moment, we are only specifying scroll-triggered animations, for a trigger to have any effect, it must have a progress-based timeline. If the trigger’s timeline is not scroll-based it is not affected at all by `animation-trigger`.

One of the implications of an animation remaining idle until its trigger says otherwise is that `getAnimations` will not include this animation until its trigger plays it.
This means that the trigger has both the jobs of creating and of advancing the animation, which isn’t unlike what `Animation.play` already does.  In this [demo](https://codepen.io/awogbemila/pen/LEYyPPM), when the animation is canceled (it becomes idle), it is no longer included in `getAnimations`, but when play is called, it is again included in `getAnimations` and begins to make progress.

So I think there are 2 related questions:

1. Should (scroll-based) animation-triggers prevent their animations from taking effect until the trigger’s condition is met?
2. If we answer ‘yes’ to 1., should these animations be included in `getAnimations`?

My proposal for 1. is: Yes. I think the animation should remain idle until its trigger plays it. This is similar to an animation created via the WAAPI. A WAAPI animation remains idle until the author invokes `animation.play` so I think this makes `animation-triggers` function in a manner that is familiar to developers, i.e. the developers can think about `animation-triggers` as an automated/CSS means of invoking the playback control APIs. (though maybe this is just one aspect of the broader issue in [11914](https://github.com/w3c/csswg-drafts/issues/11914).

My proposal for 2 is: No, it shouldn't be included in `getAnimations`.

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


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

Received on Thursday, 20 March 2025 22:05:36 UTC