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:
> 

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](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.
> 

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.


-- 
GitHub Notification of comment by DavMila
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11971#issuecomment-2744275106 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 19:31:20 UTC