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

@DavMila:

> 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 an 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.

Yeah sure, we could define those behaviors to be something like "always play forward on entry, and vice versa", etc.

------

I completely agree with @szager-chromium's [comment](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3129952281). It's probably a bad idea to magically map an event and an action to a pair of two other events etc. I've seen it done in user-land implementations, at the end that abstraction only complicates things.

I also agree with the statelessness nature of event triggers, but that should be pretty straightforward.

------

@tabatkins:

> It looks like this was a miscommunication. We (Elika and I) thought that y'all were saying there was a necessary statefulness in the API, such that every start trigger had to be accompanied with its paired end trigger for the actions to make sense, and vice versa.
>
> It seems like this wasn't the case, it was just both of us talking past each other. @szager-chromium's comment seems to support this as well; the only "statefulness" is that the Animation object tracks some state and the trigger actions interact with that, but the triggers don't care about that and are stateless. (Especially if we do end up requiring/enforcing that the "continue range" is a superset of the "start range" for a timeline/view trigger.)

Yes, I think that's correct. There is the state of `did trigger` that a trigger needs to maintain in order to get the initial behavior of "just start playing", and only after that follow the specified behavior.

Beyond that, event triggers can be stateless. Timeline triggers need to only maintain the "in-range" state.


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


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

Received on Monday, 4 August 2025 16:23:49 UTC