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

A few of issues I'm seeing:

1. The starting actions is _always_ `play`. It's always play/resume forwards. Either `once` or `always. So I think it's kind of redundant to follow that path in general. I think either we go back to the single `behavior` form, or we adopt something like the `start`/`end` `action` pair that was suggested [here](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3091201201).
2. The suggested syntax: `event-trigger-actions: click(play) keypress(pause)`, is a bit problematic since it mixes different concerns together, the event and the action, which should probably be split into different sub-properties. Moreover, I think if we add this format of `<event>()` functions, IMO it makes sense that the arguments they take are modifiers of the events, and not of the trigger.
3. Again, in `viewenter(..., block, ...)` the `block`, which I guess is for the axis, is not necessary since we're defining a rect for both axes.

> However I feel like timeline-trigger, with its longhands, is a simpler and more familiar (similar to animation-timeline and animation-range-* longhands) way of expressing the same thing, so I think we should keep it.

Well, that is what I'm trying to figure out, if we can fit all of those into event triggers.
We already have `-behavior` in both, `-timelline` becomes `-event` and `-range`'s should fit into arguments of `viewenter()`/`viewexit()`.

> Whether we express timeline-based triggering in event-trigger or timeline-trigger, we'll still have to track the exact same "in-range" state you mention above, so I'm not at all seeing how this affects statelessness. The definitions of the actions, i.e. play, pause, etc, are the same regardless of the trigger type. Can you elaborate?

The implementation probably needs to use a timeline under the hood which tracks the state, but the trigger itself only observes changes to that state, so the trigger itself is stateless. Whereas a timeline trigger holds that state inside it.

> One issue that does occur to me with having event-trigger and timeline-trigger is name clashing between these two properties

We need to clarify exactly what happens when similar names are used. So far there were different opinions on the expected behavior.

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


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

Received on Thursday, 7 August 2025 17:21:15 UTC