[web-animations-2][css-animations-2]Should an animation-trigger prevent its animation from taking effect until the trigger says so?

[DavMila]

In the web animations spec, 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, 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.

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

[ydaniv]

Thanks filing this! There are several issues here, so let's break this down.

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 that while the trigger has an idle state, the animation isn't idle. I tried to put this precise behavior in the spec, though I might have used wrong terms/wording?
The spec defines the trigger idle state as:

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

My intent by that was that according to the animation's active time calculation

If the animation effect is in the before phase,
The result depends on the first matching condition from the following:

• If the fill mode is backwards or both,
  Return the result of evaluating max(local time − start delay, 0).

So by that I assumed the animation's effect should be "in effect" and produce an output.

---

If the trigger’s timeline is not scroll-based it is not affected at all by animation-trigger.

Note that trigger can have a time-based timeline, when the animation-trigger-timeline is set to auto. In that case the trigger does have an effect on the animation, but because this timeline is monotonic - as in always increasing - and currently can't have ranges applied to it, all the trigger effect types effectively become the once type, since they can only switch between idle to primary once, and never return.

---

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 is an important observation! I think if what I explained above is in fact correct, then depending on the fill mode, calling getAnimations should return the animation while the trigger is in idle state. But perhaps we should specify a mechanism for making animations still relevant, depending on the trigger's type, and not only on their fill mode. Perhaps we should say the in some cases they become persisted while the trigger has non-monotonic timeline and a trigger type of either repeat or alternate?

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.

Yes. In with the repeat and alternate types it can also re-play or re-reverse the animation. So I think we should propose that such animations become persisted.

---

Should (scroll-based) animation-triggers prevent their animations from taking effect until the trigger’s condition is met?

The whole purpose of this feature is to allow authors to specify an active animation on a target in CSS, and have that animation's effect produce initial output depending on the animation's fill mode. In that way authors can declaratively create entrance animations whose initial state is "in effect", without resorting to extra attributes that need to be toggled by JS once the animation plays. E.g: an element can have fade-in animation with fill: backwards that is initially invisible and then removes itself once it's done, without any residual state on the DOM, plus, if JS fails the animation still plays and the element won't stay invisible.

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.

So my proposal is the opposite (:
Currently, in order to create a simple entrance animations via CSS authors must resort to JS for triggering, and then either persist the last frame to keep the element visible, or with JS toggle an attribute to keep it visible, which sometimes also breaks when combined with JS frameworks' rendering.

I also think we should include these animations in getAnimations in some cases, as I explained above, since they're still relevant.

[DavMila]

Thanks filing this! There are several issues here, so let's break this down.

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 that while the trigger has an idle state, the animation isn't idle. I tried to put this precise behavior in the spec, though I might have used wrong terms/wording? The spec defines the trigger idle state as:

No, I believe your wording is correct :) I recognized that I had been thinking about certain details a bit differently than is currently spec’d so I needed to file the issue so we (including the WG) can come to a consensus.

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

My intent by that was that according to the animation's active time calculation

If the animation effect is in the before phase,
The result depends on the first matching condition from the following:

• If the fill mode is backwards or both,
  Return the result of evaluating max(local time − start delay, 0).

So by that I assumed the animation's effect should be "in effect" and produce an output.

Yes I believe that’s right. If it’s in the before phase and at time zero, it would be “in effect.”
(PS Should it be current time rather than start time? We can sort that out later)

If the trigger’s timeline is not scroll-based it is not affected at all by animation-trigger.

Note that trigger can have a time-based timeline, when the animation-trigger-timeline is set to auto. In that case the trigger does have an effect on the animation, but because this timeline is monotonic - as in always increasing - and currently can't have ranges applied to it, all the trigger effect types effectively become the once type, since they can only switch between idle to primary once, and never return.

Yeah I think this is in line with what I meant to say. Since, atm, it “can't have ranges applied to it”, when it plays is not dependent on the trigger. And it’ll be this way until we specify time-based range, if we ever do.

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 is an important observation! I think if what I explained above is in fact correct, then depending on the fill mode, calling getAnimations should return the animation while the trigger is in idle state. But perhaps we should specify a mechanism for making animations still relevant, depending on the trigger's type, and not only on their fill mode. Perhaps we should say the in some cases they become persisted while the trigger has non-monotonic timeline and a trigger type of either repeat or alternate?

Yes I agreed above that it would be “in effect” and included in getAnimations. However I currently feel that getAnimations doesn’t need to change. If the trigger affects the animation in such a way that the animation is not in effect then the animation shouldn’t be included in getAnimations. I think we're still trying to align on whether the trigger should be able to do that independent of animation-fill-mode.

Should (scroll-based) animation-triggers prevent their animations from taking effect until the trigger’s condition is met?

The whole purpose of this feature is to allow authors to specify an active animation on a target in CSS, and have that animation's effect produce initial output depending on the animation's fill mode. In that way authors can declaratively create entrance animations whose initial state is "in effect", without resorting to extra attributes that need to be toggled by JS once the animation plays. E.g: an element can have fade-in animation with fill: backwards that is initially invisible and then removes itself once it's done, without any residual state on the DOM, plus, if JS fails the animation still plays and the element won't stay invisible.

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.

So my proposal is the opposite (: Currently, in order to create a simple entrance animations via CSS authors must resort to JS for triggering, and then either persist the last frame to keep the element visible, or with JS toggle an attribute to keep it visible, which sometimes also breaks when combined with JS frameworks' rendering.

I guess your proposal is to delay the point of playing rather than the point of creation.
That makes sense but would we consider it to be overriding animation-play-state?
Say we have animation with animation-play-state: paused, a once trigger and animation-fill-mode:both. When the trigger’s condition is met, does the animation make progress to the end or does it remain paused? I had thought that the trigger would create the animation in this case and then either leave it paused or advance it depending on animation-play-state. But I guess with your proposal we can spec it so that even if the animation was already in effect while the trigger was idle it still stays paused if animation-play-state is paused.

[ydaniv]

PS Should it be current time rather than start time?

Oh, that might be right.

---

However I currently feel that getAnimations doesn’t need to change. If the trigger affects the animation in such a way that the animation is not in effect then the animation shouldn’t be included in getAnimations.

Currently the spec says getAnimations returns all "relevant" animations which is defined as:

An animation is relevant if:

• Its associated effect is current or in effect, and

• Its replace state is not removed.

And "current" effect is defined as:

An animation effect is current if any of the following conditions are true:

• the animation effect is in play, or

• the animation effect is in the before phase and is associated with an animation with a playback rate > 0, or

• the animation effect is in the after phase and is associated with an animation with a playback rate < 0, or

• the animation effect is associated with an animation not in the idle play state with a non-null associated timeline that is not monotonically increasing.

So by that this means that while a trigger is in idle state it will return its associated animation, right?
Perhaps we should amend this list and include more cases for animations that may be relevant due to re-triggering? Perhaps something that's independent on the fill-mode, as you said?

---

I guess your proposal is to delay the point of playing rather than the point of creation.

Yes, exactly.

That makes sense but would we consider it to be overriding animation-play-state?
Say we have animation with animation-play-state: paused, a once trigger and animation-fill-mode:both. When the trigger’s condition is met, does the animation make progress to the end or does it remain paused? I had thought that the trigger would create the animation in this case and then either leave it paused or advance it depending on animation-play-state. But I guess with your proposal we can spec it so that even if the animation was already in effect while the trigger was idle it still stays paused if animation-play-state is paused.

That's a very good question. I think this well requires additional issues to open!

[bramus]

I would like it if we could closely match the behavior of Scroll-Driven Animations here.

For example, when opening https://scroll-driven-animations.style/demos/image-reveal/css/ for example (and while making sure both images are not in the viewport – you might have to resize your window) and then calling document.getAnimations() it returns the two scroll-driven animations even though they are not “in-scrollport”. Those animations are active but in the before phase. animation-fill-mode: both is making sure the element is rendered with the from keyframe values.

To answer the questions asked at the start of the thread, I would assume that:

1. When not triggered yet, the effects of STAs are in their before phase. This to prevent sudden jumps.
2. When calling getAnimations STAs are returned because they are impacting rendering of the element.

I think this boils down to saying that an animation is also relevant when the animation-trigger-timeline is determining things. For scroll() or view() specifically, that results in a “non-null associated timeline that is not monotonically increasing” used as the animation trigger.

[ydaniv]

Yes, I think I agree to everything.

Just to be clear, we're saying that STA's with a view/scroll trigger-timeline are also relevant, regardless of their fill mode, if either of the following is true:

• They're trigger is in idle state.
• Their type is either repeat or alternate.

This means their associated effect may not have an actual output in before/after phases of their triggers.

[DavMila]

Just to be clear, we're saying that STA's with a view/scroll trigger-timeline are also relevant, regardless of their fill mode, if either of the following is true:

• They're trigger is in idle state.
• Their type is either repeat or alternate.

This means their associated effect may not have an actual output in before/after phases of their triggers.

This sounds good to me! So contrary to my initial position I think triggers should not prevent their animations from having an effect and should be included in getAnimations. One more thing that might be worth calling out is the timing of the animationstart event.

The way I'm thinking about it is: say we have an animation-fill-mode: both/backwards animation which is yet to trigger. Although the animation's effect is in effect before the animation is triggered, animationstart doesn't fire until the animation is triggered and is advancing. The "and is advancing" part means that if the the element has animation-play-state: paused it still doesn't fire, until/unless perhaps animation-play-state changes to running?

[ydaniv]

The way I'm thinking about it is: say we have an animation-fill-mode: both/backwards animation which is yet to trigger. Although the animation's effect is in effect before the animation is triggered, animationstart doesn't fire until the animation is triggered and is advancing. The "and is advancing" part means that if the the element has animation-play-state: paused it still doesn't fire, until/unless perhaps animation-play-state changes to running?

Yes, I agree with that. If that needs to be explicit in the spec then we should probably add an issue for that.

[ydaniv]

The way I'm thinking about it is: say we have an animation-fill-mode: both/backwards animation which is yet to trigger. Although the animation's effect is in effect before the animation is triggered, animationstart doesn't fire until the animation is triggered and is advancing. The "and is advancing" part means that if the the element has animation-play-state: paused it still doesn't fire, until/unless perhaps animation-play-state changes to running?

Yes, I agree with that. If that needs to be explicit in the spec then we should probably add an issue for that.

I opened another issue specifically regarding interaction of animation-trigger with animation-play-state, and how/when events should trigger here #12064.

---

Regarding making an animation relevant, currently the spec says:

An animation is relevant if:

Its associated effect is current or in effect, and

Its replace state is not removed.

So the associated effect may not be in effect but it may be current according to this:

An animation effect is current if any of the following conditions are true:

• the animation effect is in play, or

• the animation effect is in the before phase and is associated with an animation with a playback rate > 0, or

• the animation effect is in the after phase and is associated with an animation with a playback rate < 0, or

• the animation effect is associated with an animation not in the idle play state with a non-null associated timeline that is not monotonically increasing.

So proposing:

1. Animation Triggers do not prevent their animation from taking effect before entering active range.
2. Add another condition to the definition of current animation effect:

• the animation effect is associated with an animation, that is associated with a trigger with a non-monotonically increasing timeline and a type of either repeat or alternate.

[birtles]

Sorry, just catching up on this thread because I was pinged on #12064 (otherwise I've been trying to keep out of the scroll-driven animations and animation triggers discussions so I don't hold things up).

The original proposal made sense to me so I'm trying to get on board with the reasoning for the updated proposal (which I think it starting to make sense).

Just to check, if I create an Animation with a backwards fill mode, the moment I attach a trigger to it, it takes effect?

If so, I think it will be treated as being "in effect".

And why do we need to tweak the definition of "current animation effect" if an idle trigger already ensures that we're in the before phase?

Do you mind if we continue this discussion async? I won't be able to join the telcon (timezone).

[ydaniv]

Just to check, if I create an Animation with a backwards fill mode, the moment I attach a trigger to it, it takes effect?

If so, I think it will be treated as being "in effect".

In this case, once you attach a trigger it takes care playback for you, so in that case it is "in effect".

And why do we need to tweak the definition of "current animation effect" if an idle trigger already ensures that we're in the before phase?

You're right, I took that into consideration, that the animation is initially "in effect", but I figured the tweak is necessary for the case where playbackRate > 0 and we may be in the "after" phase, and cases like this. So basically to make sure that if the animation may resume/rewind/reverse the algorithm says it's relevant.

Do you mind if we continue this discussion async? I won't be able to join the telcon (timezone).

Sure thing, we have a bunch of open issues in css-animations-2 and web-animations-2, most with agenda+. I'd appreciate if you could review those this week and at least mark those we can raise in the weekly meeting, and we can defer/keep async discussion on the rest.

[birtles]

Just to check, if I create an Animation with a backwards fill mode, the moment I attach a trigger to it, it takes effect?
If so, I think it will be treated as being "in effect".

In this case, once you attach a trigger it takes care playback for you, so in that case it is "in effect".

Sorry, by "in effect", I mean the Web Animations term, in effect.

So, to the extent that such an animation has an effect that is in effect, it should already be relevant, regardless of whether or not it's current.

And why do we need to tweak the definition of "current animation effect" if an idle trigger already ensures that we're in the before phase?

You're right, I took that into consideration, that the animation is initially "in effect", but I figured the tweak is necessary for the case where playbackRate > 0 and we may be in the "after" phase, and cases like this. So basically to make sure that if the animation may resume/rewind/reverse the algorithm says it's relevant.

Oh, I see. I guess that makes sense. Might be worth a note in the spec to remind ourselves in future why we went that route.

Do you mind if we continue this discussion async? I won't be able to join the telcon (timezone).

Sure thing, we have a bunch of open issues in css-animations-2 and web-animations-2, most with agenda+. I'd appreciate if you could review those this week and at least mark those we can raise in the weekly meeting, and we can defer/keep async discussion on the rest.

Oh, I'm trying to keep off the critical path for all the scroll-driven and triggers work since I have very little time available for spec work. I'm mostly just interested in anything where we're touching the core Web Animations definitions.

That said, I think I'm OK with the proposal here so feel free to resolve on it in telcon.