[css-animations-2][web-animations-2] How should `animation-play-state` interact with `animation-trigger`?

[ydaniv]

Before the addition of animation-trigger it was possible to control the playback state of an animation using the animation-play-state property or using the Web Animations API via the .play()/.pause()/.reverse() methods or setting the animation's playbackRate.

A Trigger applies an effect on its associated animation based on its type and state, and these effects are currently defined by the playing, pausing, and reversing an animation procedures. That is now yet another method to control playback state.

To resolve conflicts between properties specified in CSS and state changes by usage of the WAAPI, it is specified how the latter takes precedence over changes to corresponding properties in CSS.

But now we have a new CSS property, animation-trigger, that may conflict with another property, animation-play-state, and it may not be trivial to determine how these two properties interact with each other and what should be the playback state when their both specified to non default values.

With the default values for animation-trigger being once auto we may already have an existing definition of this interaction:

• If the animation-play-state is set to running then the trigger behaves normally as specified.
• If the animation-play-state is set to paused then the trigger's behavior is overridden and the animation's playback remains paused.
• Notice that animation events must still trigger, if the trigger's timeline has active and inside the attachment range, just as a newly created animation with a play-state set to paused still triggers the animationstart event. However, we may say that animations with a trigger with a view timeilne must only trigger animation events according to their progress inside their attachment range. So for example, animation with animation-trigger: view() repeat will only trigger its animationstart event once it enters its 0-100% range.

Additionally, changes to playback state via WAAPI continue overriding animation-play-state as specified, but don't override changes to animation-trigger.

Proposal

• animation-trigger does not override the behavior of animation-play-state.
• If animation-play-state is set to running then the associated trigger's effects continue as specified.
• If the animation-play-state is set to paused then the associated trigger's effects are overridden and the animation remains paused.
• Animation events still trigger normally when paused but only when entering/exiting the trigger's attachment range.

/cc @flackr @DavMila @birtles

[DavMila]

Thanks for filing this!

Proposal

• animation-trigger does not override the behavior of animation-play-state.
• If animation-play-state is set to running then the associated trigger's effects continue as specified.
• If the animation-play-state is set to paused then the associated trigger's effects are overridden and the animation remains paused.

I think I agree with the proposal overall with one (perhaps significant) difference: I wouldn't say that a trigger's effects are overridden by animation-play-state. I think of it more as the condition for advancing an animation (forwards or backwards, so that it reflects its timeline time) now requires, in addition to animation-play-state, whether its trigger condition has been met.

I think where this really makes a difference is when we consider what happens when we have a scroll-based trigger (no time-based triggers for now) and the exit condition is met. With animation-play-state: paused should a repeat trigger still reset the animation? should an alternate trigger still reverse the animation? I think these answers should be yes - which means the trigger isn't really overridden, but in all cases (assuming a waapi call hasn't stopped us from listening to animation-play-state) we would still need animation-play-state to be running to make progress on the animation with time.

A related question I was thinking about was: when an animation with a state trigger is paused by its trigger upon exiting the exit range, if its animation-play-state is then toggled from running to paused and then back to running should it continue to make progress? I think so.

[birtles]

I haven't thought about the detail here but broadly speaking the layering makes sense to me. At very least, WAAPI needs to be able to override the trigger mechanism so that DevTools etc. can inspect triggered animations.

[ydaniv]

I think I agree with the proposal overall with one (perhaps significant) difference: I wouldn't say that a trigger's effects are overridden by animation-play-state. I think of it more as the condition for advancing an animation (forwards or backwards, so that it reflects its timeline time) now requires, in addition to animation-play-state, whether its trigger condition has been met.

Yes, that's gist of it. I guess "overridden" is less accurate here.

I think where this really makes a difference is when we consider what happens when we have a scroll-based trigger (no time-based triggers for now) and the exit condition is met. With animation-play-state: paused should a repeat trigger still reset the animation? should an alternate trigger still reverse the animation? I think these answers should be yes - which means the trigger isn't really overridden, but in all cases (assuming a waapi call hasn't stopped us from listening to animation-play-state) we would still need animation-play-state to be running to make progress on the animation with time.

Yes, agreed. With alternate the direction is still flipped, but playback still remains paused and current time remains fixed on the same hold time.

A related question I was thinking about was: when an animation with a state trigger is paused by its trigger upon exiting the exit range, if its animation-play-state is then toggled from running to paused and then back to running should it continue to make progress? I think so.

Here I think is where the animation-play-state is more sort of overriding the behavior of the trigger. I think the playback state should remain paused if it's set that way in CSS, regardless of the trigger's effect. If it's set to running then the trigger's effect starts affecting the playback state.

[ydaniv]

@birtles:

I haven't thought about the detail here but broadly speaking the layering makes sense to me. At very least, WAAPI needs to be able to override the trigger mechanism so that DevTools etc. can inspect triggered animations.

Do you mean overriding animation-trigger with animation.trigger = ...? Or overriding by calling play()/pause()/reverse()/etc?
Note that we agreed on the interaction of the latter in this issue.

[birtles]

Do you mean overriding animation-trigger with animation.trigger = ...? Or overriding by calling play()/pause()/reverse()/etc? Note that we agreed on the interaction of the latter in this issue.

Yes, the latter.

[ydaniv]

@birtles so the question is what do you mean by "override"?
In the above mentioned issue we proposed that if a user invoked some method of the WAAPI it still applies its effect, but does not prevent the trigger from continuing to function afterwards.

[birtles]

so the question is what do you mean by "override"?
In the above mentioned issue we proposed that if a user invoked some method of the WAAPI it still applies its effect, but does not prevent the trigger from continuing to function afterwards.

@ydaniv That sounds fine but it makes me wonder, does cancel() still cause the animation to have no effect (including the "put it in the before phase with a zero time" behavior)?

That is, can a user still do element.getAnimations().forEach(anim => anim.cancel() and be sure that the element is no longer affected by animations on it? (With the exception of animations on ancestors/descendants)

[ydaniv]

@ydaniv That sounds fine but it makes me wonder, does cancel() still cause the animation to have no effect (including the "put it in the before phase with a zero time" behavior)?

That is, can a user still do element.getAnimations().forEach(anim => anim.cancel() and be sure that the element is no longer affected by animations on it? (With the exception of animations on ancestors/descendants)

Sure, any method should apply its effect, so calling cancel() should terminate that animation and any effect it applies.

[birtles]

Sure, any method should apply its effect, so calling cancel() should terminate that animation and any effect it applies.

But haven't we defined that if a trigger is attached to an animation then it ends up being put in the before phase with a zero time? Meaning that if it has a backwards fill, that will take effect? So in order to remove that does cancel() need to disassociate from the trigger?

[ydaniv]

But haven't we defined that if a trigger is attached to an animation then it ends up being put in the before phase with a zero time? Meaning that if it has a backwards fill, that will take effect? So in order to remove that does cancel() need to disassociate from the trigger?

Currently, any animation has an initial value of animation-trigger: once auto, so it has a trigger, and calling cancel() on that animation should still set its currentTime to unresolved, so that animation's effect will be removed.
I think that, by itself, should render the associated trigger effectless.
Do you think we need to also explicitly disassociate the trigger?

[DavMila]

Sure, any method should apply its effect, so calling cancel() should terminate that animation and any effect it applies.

But haven't we defined that if a trigger is attached to an animation then it ends up being put in the before phase with a zero time? Meaning that if it has a backwards fill, that will take effect? So in order to remove that does cancel() need to disassociate from the trigger?

This seems related to the issue @ydaniv linked earlier. There, our current proposal is that animation-trigger can still play, pause, etc an animation after it has been played, paused, etc by a WAAPI. It sounds like you think cancel should be different in that the trigger should no longer be able to do those things?

Currently, any animation has an initial value of animation-trigger: once auto, so it has a trigger, and calling cancel() on that animation should still set its currentTime to unresolved, so that animation's effect will be removed. I think that, by itself, should render the associated trigger effectless. Do you think we need to also explicitly disassociate the trigger?

If we don't want the trigger to be able to perform those actions on the animation after cancel() I think we would need to explicitly disassociate it since, for example, a repeat trigger can set the currentTime of the animation? (that link says "start time" currently but we intend to modify it to currentTime)
Otherwise, in the following instance the trigger could still cause the animation to have visual effect:

• user scrolls into default range, causing animation (which has fill-mode: both) to play,
• page calls cancel() on the animation, stopping the animation from taking visual effect,
• user scrolls outside the exit range, causing the animation to be reset to its first keyframe / 0% progress.

[birtles]

Currently, any animation has an initial value of animation-trigger: once auto, so it has a trigger, and calling cancel() on that animation should still set its currentTime to unresolved, so that animation's effect will be removed.
I think that, by itself, should render the associated trigger effectless.
Do you think we need to also explicitly disassociate the trigger?

@ydaniv Maybe the problem is I don't understand how the following behavior is intended to be realised:

The animation effect associated animation remains in its before phase and stays at zero current time.

What part of the timing model is actually updated here?

cancel() doesn't set the currentTime to unresolved. currentTime is a calculated property, you can only affect it by updated the start time and hold time.

Depending on how an idle trigger interacts with the timing model, cancel() may no longer produce the result that the animation no longer affects its target(s).

[birtles]

This seems related to the issue @ydaniv linked earlier. There, our current proposal is that animation-trigger can still play, pause, etc an animation after it has been played, paused, etc by a WAAPI. It sounds like you think cancel should be different in that the trigger should no longer be able to do those things?

@DavMila Not really, I'm just trying to understand if cancel() can still clear animation effects.