Re: [csswg-drafts] [web-animations-2][css-animations-2] Set of actions for animation triggers (#12611)

> [@DavMila](https://github.com/DavMila)
> 
> > the [repeat](https://drafts.csswg.org/css-animations-2/#valdef-animation-trigger-behavior-repeat) behavior that currently exists in the spec means "play on enter, reset on exit." In other words, it ties `play()` to the "enter" event and `reset` to "exit" event. This is captured by the `play` and `reset` keywords in the above table, e.g. `animation-trigger: --view-trigger play reset` or even `animation-trigger: --view-trigger replay reset`.
> 
> Yes, I'm arguing with that. So how do we expect `--view-trigger play-pause` and `--view-trigger play-alternate` to behave? Currently they assume `play`/`forwards` on entry and `pause`/`backwards` on exit. Do we change this behavior to do `play`/`pause` and `forwards`/`backwards` on entry alone? I'm not sure that's a useful/expected behavior for authors.
> 

@flackr already [explained](https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3234466432) that we split the higher level behaviors into animation-specific actions. I [explained](https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3325345645) that this supports "the mixing and matching of event-trigger and timeline-trigger as mentioned in Tab & Elika's [proposal](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3091201201)." Yes, it's useful and expected under the model that the keyword describes *only* the `enter` behavior, or *only* the `exit` behavior - if you refer to the [meeting notes](https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3357304276), I believe fantasai referred to this as "making a lot of sense." I've demonstrated the use of most of the keywords in my [demo](https://davmila.github.io/sta-demos/explore/) (only works with chrome canary, experimental web  platform enabled). Some other keywords may be better demonstrated by EventTriggers, but I don't have a demo for that atm.


> Moreover, what happens if you specify both an enter _and_ exit events with a `play-alternate-behavior, like:
> 
> .trigger {
>   event-trigger: --event-trigger pointerenter / pointerleave;
> }
> 
> .target {
>   animation-trigger: --event-trigger play-alternate;
> }
> This is the same issue again. So what does it mean? Do we duplicate the behavior for `pointerenter`? Or magically map it to both?

`play-alternate` in this example specifies only the enter behavior, no exit behavior is specified.
We can decide whether when the exit behavior is not specified, it should be `none` or the same as the enter behavior, I think it should be `none`. You seem to be mixing the granular behavior keyword with the higher-level behavior model - we should stick with the appropriate model for the keywords we are using. With the granular keywords/model, the syntax is `animation-trigger: <dashed ident> <enter behavior> [<exit behavior>]`.
I think the intent in your example is to play the animation forwards on `pointerenter` and backwards on `pointerleave`. Using the granular keywords with the granular model, the author would write the following: `animation-trigger: --event-trigger play-forwards play-backwards`. It's really quite simple.  

> 
> So I think we have 2 options here, and the second with 2 sub-options:
> 
> 1. Remove the `play-*` behaviors altogether, and only allow the alternating behavior explicitly using 2 specified behaviors. So for timeline triggers they map to entry/exit, and for event trigger they alternate based on animation's state.
> 2. Keep the `play-*` behaviors, add `play-reset` for consistency and also because it's different from `replay`, and decide how they behave with timeline triggers and event trigger pairs:
>    i. They map to entry alone, or
>    ii. They magically adapt to entry/exit?
> 
> Since this is relevant both for timeline triggers and event trigger pairs, I'm kind of between 1 and 2.ii.
> 

This is a point I brought up while introducing the issue on Wednesday: with the granular behaviors, we don't have to define a keyword one way for one type of trigger and another way for another type.

> Aside from that, I think we have another issue with syntax that we overlooked. Since behaviors are space separated, we don't have a way to map a behavior to the exit action alone, e.g. only `pause` on exit. I also see a couple of options here:
 
Again, with the granular keywords/model, the syntax is `animation-trigger: <dashed ident> <enter behavior> [<exit behavior>]` . So this is a non-issue.

I have to say, I've mentioned multiple times (as has @flackr) that we split the behaviors up to facilitate the mixing and matching of event-trigger and timeline-trigger as was raised by Tab and fantasai. You seem to be opposing this split but haven't yet either rejected that use case or given a way to handle it with the higher level behaviors so we are in a somewhat circular pattern. Do you have a way to address this use case  with the higher level behaviors? (preferably in a way that doesn't require defining they keywords separately per trigger type?). If so, tbh I'm okay with the higher-level behaviors - they're what we started with after all.



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


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

Received on Friday, 3 October 2025 15:17:15 UTC