[web-animations-2]Should animation triggers have equal control over their animations’ playback?

[DavMila]

AnimationTriggers control the playback of Animations, i.e. they can play, pause or reverse 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(),
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. 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.

[ydaniv]

In css-aniamtions-2 there is a section on how overriding properties using WAAPI takes precedence over related properties in CSS. This issue is somewhat similar.
I suppose if an author chose to both set a trigger and control the playback manually then the UA should try to respect that, unless this causes one of the two:

1. Unpredictable behaviors for authors
2. Problems for implementors in implementing a predictable/consistent behavior

I assume, also from your proposal of option 1, that none of the two options above is the case.
So I also suggest going with option 1, also given they can nullify the trigger as you mentioned.

[ydaniv]

@DavMila the spec's text already says use existing algorithms for triggering and pausing when a range is crossed, so I guess if a playback method was explicitly invoked the state should be already well defined, so going with your proposal - option 1 - should be good.
Shall we close as no change?

[ydaniv]

Copying here the discussion from #12064:

I have a proposal for handling calls to cancel() and play() again:

• Change the name of Trigger's state idle to something else, like pending. I think I chose a bad name here which doesn't correctly reflects the behavior of the state.
• Add a new Trigger state named idle, which behaves as the name suggests, makes the Trigger effectless.
• When running Cancelling an animation procedure we add an extra step that sets associated trigger's state to idle.
• Add a step in Updating Animation Trigger State that checks if state is idle, and if so it aborts the procedure.
• Add a step in Playing an animation that checks if the associated trigger's state is idle, and if so resets it to pending.

I think this solves the cancel()/play() issue and avoids adding any additional complications to the existing model.

---

Regarding calls to play()/pause()/reverse(), I keep supporting the proposal of allowing triggers to keep function normally after these methods are invoked, assuming play/pause/reverse tasks are queued in the same manner by both.

/cc @birtles @flackr

[birtles]

Sounds reasonable to me. In particular, from what I understand, this involves modifying the timing procedures affecting animations (cancelling, playing, etc.) but not animation effects (active interval etc.). That seems like a better fit from a layering point of view—triggers should be things that control animation playback and not something that effects need to know about.

However, I think we are trying to decide the high-level expectations over in #12119 before we commit to anything here. (And I'd like to at least entertain the idea of triggers being entirely independent of animations over in that issue.)