Re: [csswg-drafts] [css-animations-2] Move scroll and event animation triggers to independent namespace (#12336)

> > 1. Currently triggers, mostly relevant to timeline triggers, contain the state of the effect they apply on the animation's playback. With separate triggers used for start/end, where does that state lives? Or perhaps this design makes them stateless?
> 
> Yes, this makes them stateless. An animation that was started by a timeline trigger can be ended by an event trigger; etc. Each trigger's start and end criteria are defined independently of each other: a timeline trigger starts when you switch from being outside the start range to inside, and ends when you switch from being inside the continue range to outside; similar for event triggers.
> 
> If we need to pair them up, e.g. so that certain end triggers can only end animations started by certain start triggers, we'd need to do something a little different. For example, we could make space-separated list of events and actions be paired between as corresponding start and end triggers, and use brackets to batch multiple actions as an interchangeable set. We'd need to make this decision now, though, because the default behavior we're currently proposing for when the author provides multiple triggers (all are interchangeable) would have to be explicitly written as a batched set (wrapped in brackets).
> 

Could you give a brief example of this? It would help me better understand, thanks.

> > 2. We probably want animation-start-trigger-action to just be once | always, since the alternating behavior is part of the exit/end triggering. Then you have the following mapping: once -> once, repeat -> always / reset, alternate -> always / direction, state -> always / pause.
> 
> Ah, ok, so we'd have animation-start-trigger-action: once | always animation-end-trigger-action: reset | pause | alternate ?
> 
> I guess it depends, do you want to alternate the direction only if there's an end trigger flipping the direction, or every time the start trigger is initiated (regardless of whether there was an end)? Do we need both options?

I can imagine an author wanting a start trigger that alternates without an end trigger. Would this modification to your suggestion be enough to support both:

animation-start-trigger-action: once | always | **alternate**
animation-end-trigger-action: reset | pause | alternate

(maybe we would consider an **always** action for the end trigger too?)

I think this gives an author a clear way to indicate what they intend. However, with this interpretation of "alternate" (which matches the current spec's `animation.reverse()`), I think we need a separate "reverse" action. Roughly speaking, the current spec maps the "always" behavior/action to `animation.play()` and the "alternate" behavior to "animation.reverse()", but I think this doesn't work so well in the simple case of `start-action: always; end-action: alternate` where the author's intent is probably "play the animation forwards on start; backwards on end." - a start event that follows as end event will also play the animation in reverse (due to the updated playback rate).

So, my suggestion for how to specify the actions maps to the current Animation interface like this:

"always": `animation.updatePlaybackRate(Math.abs(animation.playbackRate)); animation.play()`
"reverse": `animation.updatePlaybackRate(-1 * Math.abs(animation.playbackRate)); animation.play()`
"alternate": `animation.reverse()`

I think this will make the options for -actions predictable and allows both cases @fantasai pointed out.

> 
> Which I guess raises the question of, do we want a start trigger to be able to restart a playing animation, or only trigger if the animation is stopped/paused, and do we need control over that?
> 

I think restarting a playing animation would be an option authors would like to have. Building on my suggestion to have a "reset" action, perhaps we can have a "restart" action as well. I wonder if the set of actions for both start and end triggers should just be the same? Might not be able to think of particular use cases for all combinations at the moment but I think if we allow all then maybe we're definitely allowing all valid use cases (and some invalid ones) but if we restrict them then maybe we are disallow invalid use cases possibly along with some valid ones?




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


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

Received on Wednesday, 23 July 2025 12:57:10 UTC