Re: [csswg-drafts] [web-animations-2][css-animations-2]Should an animation-trigger prevent its animation from taking effect until the trigger says so? (#11971)

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](https://drafts.csswg.org/web-animations-2/#animation-trigger-state-idle) as:

> The [animation effect](https://drafts.csswg.org/web-animations-1/#animation-effect) associated animation remains in its [before phase](https://drafts.csswg.org/web-animations-1/#animation-effect-before-phase) and stays at zero [start time](https://drafts.csswg.org/web-animations-1/#animation-start-time).

My intent by that was that according to the animation's [active time calculation](https://drafts.csswg.org/web-animations-1/#calculating-the-active-time)

> If the animation effect is in the [before phase](https://drafts.csswg.org/web-animations-1/#animation-effect-before-phase),
The result depends on the first matching condition from the following:
> 
> * If the [fill mode](https://drafts.csswg.org/web-animations-1/#fill-mode) is [backwards](https://drafts.csswg.org/web-animations-1/#fill-mode-backwards) or [both](https://drafts.csswg.org/web-animations-1/#fill-mode-both),
Return the result of evaluating max([local time](https://drafts.csswg.org/web-animations-1/#local-time) − [start delay](https://drafts.csswg.org/web-animations-1/#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 my 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.

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


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

Received on Friday, 21 March 2025 14:50:07 UTC