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

In the issues section of that very comment, it is noted that event triggers don't naturally follow the "start"/"end" paradigm. "Behavior" is just another way of saying "start"/"end" which, again, doesn't naturally fit event triggers. This was the whole point of flackr's last comment. If we must have explicit "start"/"end" declarations, it should probably be restricted to timeline triggers, which certainly means we can't move it into event-trigger.
  
> 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.

I see no problem at all here. The goal is to map an `event` to an `action` and sure, we can do that with separate properties, but it is not clear to me at all what is problematic about explicitly grouping them as in `click(play)` because, in the context of an event trigger, what relevance/meaning does an action have without an event? similar question about an action without an event.

On the "modifiers of the trigger" point,  this seems to be an inconsistent play on words. Why is passing params to `click()` modifying the event and not the trigger, yet passing params to `viewenter()` modifying the trigger and not the event? They seem to be doing the exact same thing to me: declaring the conditions under which the trigger performs the specified action.

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

So this would seem to be introducing some multi-axis timeline representation, something that doesn't currently exist and  is not the goal of this effort. I certainly would not push back against pursuing that - we can define any number of "custom"/new events to pass to event-trigger - but this makes me feel even more strongly about keeping timeline-trigger which is intended to work based on the established definition of a timeline and whose removal I don't see any rationale for.

> > 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()`.
> 

I don't see why pursuing new viewenter/viewleave events warrants eliminating timeline-trigger, especially since your idea seems to be expressing something different than the current/established definition of a timeline as you indicate above.

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

This also seems like an inconsistent comparison between the two. We would need to track exactly the same information whether we write the syntax as:

`event-trigger: --trigger viewenter(0.5) play`

or

`timeline-trigger: --trigger view() contain 0% enter(play)`

It's literally just syntax and name changes.

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

I didn't think this has been brought up. Can you point to where? I'm planning on filing a separate issue for name clashes.



-- 
GitHub Notification of comment by DavMila
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3165365835 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 18:52:33 UTC