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)

> 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](https://drafts.csswg.org/web-animations-1/#concept-animation) is relevant if:
> 
> - Its [associated effect](https://drafts.csswg.org/web-animations-1/#animation-associated-effect) is [current](https://drafts.csswg.org/web-animations-1/#current) or [in effect](https://drafts.csswg.org/web-animations-1/#in-effect), and
> 
> - Its [replace state](https://drafts.csswg.org/web-animations-1/#replace-state) is not [removed](https://drafts.csswg.org/web-animations-1/#removed-replace-state).

And "current" effect is defined as:

> An [animation effect](https://drafts.csswg.org/web-animations-1/#animation-effect) is current if any of the following conditions are true:
> 
> - the [animation effect](https://drafts.csswg.org/web-animations-1/#animation-effect) is [in play](https://drafts.csswg.org/web-animations-1/#in-play), or
> 
> - the [animation effect](https://drafts.csswg.org/web-animations-1/#animation-effect) is in the [before phase](https://drafts.csswg.org/web-animations-1/#animation-effect-before-phase) and is [associated with an animation](https://drafts.csswg.org/web-animations-1/#animation-effect-associated-animation) with a [playback rate](https://drafts.csswg.org/web-animations-1/#playback-rate) > 0, or
> 
> - the [animation effect](https://drafts.csswg.org/web-animations-1/#animation-effect) is in the [after phase](https://drafts.csswg.org/web-animations-1/#animation-effect-after-phase) and is [associated with an animation](https://drafts.csswg.org/web-animations-1/#animation-effect-associated-animation) with a [playback rate](https://drafts.csswg.org/web-animations-1/#playback-rate) < 0, or
> 
> - the [animation effect](https://drafts.csswg.org/web-animations-1/#animation-effect) is [associated with an animation](https://drafts.csswg.org/web-animations-1/#animation-effect-associated-animation) not in the [idle](https://drafts.csswg.org/web-animations-1/#play-state-idle) [play state](https://drafts.csswg.org/web-animations-1/#animation-play-state) with a non-null associated [timeline](https://drafts.csswg.org/web-animations-1/#timeline) that is not [monotonically increasing](https://drafts.csswg.org/web-animations-1/#monotonically-increasing-timeline).

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!

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


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

Received on Saturday, 22 March 2025 21:06:30 UTC