[csswg-drafts] Should animation triggers have equal control over their animations’ playback? (#11914)

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

== Should animation triggers have equal control over their animations’ playback? ==
[AnimationTriggers](https://drafts.csswg.org/web-animations-2/#triggers) control the playback of Animations, i.e. they [can](https://drafts.csswg.org/web-animations-2/#:~:text=triggering%20the%20associated%20animation,pausing%20the%20associated%20animation) [play](https://drafts.csswg.org/web-animations-2/#play-an-animation), [pause](https://drafts.csswg.org/web-animations-1/#pause-an-animation) or [reverse](https://drafts.csswg.org/web-animations-1/#reverse-an-animation) an animation. Authors can also explicitly invoke these operations via JavaScript. Should animation triggers continue to control animations after JavaScript has invoked these methods?

Option 1: Yes.
Allowing animation triggers to continue to function after JavaScript playback methods have been invoked means that:

`once` triggers could restart an already-played animation,
`repeat` triggers could reset an already-played animation, and could play an animation that has previously been [canceled](https://developer.mozilla.org/en-US/docs/Web/API/Animation/cancel)(),
`state` triggers could pause an animation that has been played or vice versa,

For an `alternate` trigger, invoking play() outside the exit range would play it in the reverse direction. Invoking reverse() outside the exit range will change the animation’s state so that the trigger now plays the animation forward outside the exit range and backward inside the trigger range.

Option 2: No.
This would disable an animation’s trigger if one of the playback methods is called by JavaScript. If doing this, I think we’d want a way for an author to re-enable the trigger so perhaps we can specify that setting an animation’s trigger enables the trigger so an author could do this:
```
const old_trigger = animation.tigger;
…
animation.play(); // disables trigger
…
animation.trigger = old_trigger; //  re-enables trigger
```
Also, a style change of one of the animation-trigger-* properties would re-enable the trigger on the animation, but that seems like a less clean way to enable the trigger.

I propose going with option 1. I think the behaviors I listed above make sense and align with what an author would expect to see today given the behaviors of `play()`, `pause()`, `cancel()` and `reverse()` which can be seen in this [demo](https://codepen.io/awogbemila/pen/LEYyPPM). For example, if you just click “play”, the animation plays forward. If you click “reverse” and then click “play”, play() continues to play it in reverse. The trigger is only setting up an automated scroll-based way of invoking these methods.

If an author wishes to disable a trigger they can just set `animation.trigger = null` and then reset the animation’s trigger whenever they wish.

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


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

Received on Tuesday, 11 March 2025 18:09:48 UTC