Re: [csswg-drafts] [css-animations-2][web-animations-2] How should AnimationTrigger work? (#12119)

> However, taking this a step further, I wonder if it is possible to have triggers be entirely independent of animations such that they exist as external mechanisms that simply call play(), pause(), cancel() etc. on their target animations. I think that would produce behavior that is easy to reason about for all cases.

This matches how I had been thinking about it and I think it might be possible with a [proposal](https://github.com/explainers-by-googlers/scroll-triggered-animations/blob/main/PROPOSAL.md
) I've just uploaded.

Regarding some of the expectations put forward by @flackr

Certainly, existing animations should work as before and I think gating AnimationTrigger behind `enableTrigger` and `disableTrigger` is a very clean way to do that. Existing CSSAnimations always “call enableTrigger” which immediately calls play() as they have document.timeline as their trigger’s timeline. Existing WAAPI animations never call `enableTrigger` and just rely on `play()` being directly called.

> Setting up an animation with a trigger that is not yet active (either via CSS* or element.animate* or the animation constructor and calling play) should result in:
>
> - an animation in its before phase (or after if reversed, as if the animation has a future start time that we just don't precisely know yet)
>  - that will not advance until the trigger is active
> - and is listed in getAnimations
> 
> CSS animations and Element.animate implicitly "play" their animations

It seems to me that the expectation that `element.animate` will not advance until the trigger is active and that element.animate implicitly calls play is kind of already assuming that play functions by arming a trigger and does not advance an animation. I guess in my [proposal](https://github.com/explainers-by-googlers/scroll-triggered-animations/blob/main/PROPOSAL.md) we can say that `element.animate` calls enableTrigger rather than play, which satisfies the idea that it doesn’t advance until its trigger’s condition is met. (Though in my mind still, element.animate is synonymous will animation.play)


> If you create an animation with a trigger but don't play it (e.g. Animation constructor), just like with regular animations, it will:
>
> - not be actively producing an effect
> - not listed in getAnimations
> - not start if/when the trigger condition is active

On creating but not playing an animation, I think if you don’t play but you call `enableTrigger` we should play the animation when the trigger's condition is met.
On getAnimations, we can specify that an inactive trigger does not make an animation relevant but any other state will.



-- 
GitHub Notification of comment by DavMila
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2845262646 using your GitHub account


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

Received on Thursday, 1 May 2025 17:04:54 UTC