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

> However, perhaps we treat event trigger as a source that conceptually provides all events with their corresponding names:
> 
> .target {
>   animation: anim 5s;
>   /* Event trigger is no longer for a specific event or pair of events, but merely identifies the event target */
>   event-trigger-name: --source;
>   animation-trigger-event: --source click;
>   animation-trigger-action: play;
> }
> And with timeline triggers the events could be enter and exit to correspond conceptually to their ranges:
> 
> .target {
>   animation: anim 5s;
>   /* Event trigger is no longer for a specific event or pair of events, but merely identifies the event target */
>   timeline-trigger-name: --source;
>   timeline-trigger-source: view();
>   animation-trigger-event: --source enter;
>   animation-trigger-action: play;
> }

W.r.t. the timeline-trigger example, how do you specify a corresponding exit action? I think you're suggesting animation-trigger-* specify the name of the source and the events to be listened to on the source so maybe:

```CSS
timeline-trigger-name: --source;
timeline-trigger-source: view();
animation-trigger-event: --source enter --source exit;
animation-trigger-action: play pause;
``` 
?

> Or, perhaps the individual trigger description decides what events should be taken, e.g. for event triggers:
> 
> .target {
>   animation: anim 5s;
>   /* Event trigger is no longer for a specific event or pair of events, but merely identifies the event target */
>   event-trigger-name: --source;
>   event-trigger-actions: click play;
>   animation-trigger: --source;
> }
> and for timeline triggers:
> 
> .target {
>   animation: anim 5s;
>   /* Event trigger is no longer for a specific event or pair of events, but merely identifies the event target */
>   timeline-trigger-name: --source;
>   timeline-trigger-source: view();
>   timeline-trigger-action-enter: play;
>   timeline-trigger-action-exit: pause;
>   animation-trigger: --source;
> }

This makes sense to me and would enable the use case of "start by click, stop by scroll (or vice versa)" mentioned in Tab & fantasai's proposal _using multiple triggers per animation_. Though we are not spec'ing multiple triggers right away, this format would allow declaring multiple triggers  by a simple space separated list, e.g:

```CSS
.target {
  event-trigger: --play-on-click click play;
  timeline-trigger: --pause-on-view-exit view();
  timeline-trigger-action-exit: pause;
  animation-trigger: --play-on-click --pause-on-view-exit;
}
```

> > Here's some suggestions for the matrix, based on David's ideas and expanded a little
> > Keyword Initial Playing Paused Finished
> > `play-alternate` play() Negates playback rate play() Negates playback rate, play()
> > `play-pause` play() pause() play() play()
> > `restart` play() set progress to 0 set progress to 0, play() set progress to 0, play()
> 
> I'm not sure keywords like these should be allowed, because they roughly imply statefulness. The risk is that the "state" gets out of sync.
> 
> As an example, let's say you have `animation-trigger-action: play-pause;`, and you have that triggered by both `mousedown` and `mouseup`. The expectation is that this will play the animation when you mousedown, and stop playing when you mouseup. But you run into issues if the animation state can change via other means. If, for example, you mousedown and the animation starts playing. Then, before you mouseup, the animation hits the end and stops playing on its own. In this case, very unintuitive things happen. Releasing the mouse in this case restarts the animation. And now it's playing, so mousedown will stop it again. But then you're stuck. The only way to release the mouse and have a non-playing animation is to wait, with the mouse down, until the animation hits the end again.

I think the new direction, where we declaring "actions" rather than "behaviors", gives us stateless triggers, and I think this agrees with @fantasai's earlier [comment](https://github.com/w3c/csswg-drafts/issues/12336#:~:text=this%20makes%20them%20stateless). Tab's table seems to me to be a more elaborate specification of the trigger behavior Stefan was describing in his [PR](https://github.com/w3c/csswg-drafts/pull/12314/files#r2145827252), except now this statelessness applies not only to event triggers but also to timeline triggers (ignoring timeline state which is quite a separate thing). To use Mason's example, if the expectation is "play on mousedown, pause on mouseup", the CSS would be:

```CSS
event-trigger: --mousedown-trigger event(mousedown), --mouseup-trigger event(mouseup);
animation-trigger: --mousedown-trigger play / --mouseup-trigger pause;
```
(can probably also be easily achieved with Rob's proposal too)

and you'll see that in Tab's table the pause action only does something (pause) when the animation is playing, otherwise it does nothing. So overall, we're not really relying on any trigger state.

I think `play-pause` would be for a different use case, perhaps where you want the same click trigger pausing and playing the animation - and that wouldn't be based on statefulness of the trigger but only the animation's current playState.



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


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

Received on Wednesday, 30 July 2025 14:06:17 UTC