- From: Yehonatan Daniv via GitHub <noreply@w3.org>
- Date: Sun, 05 Oct 2025 12:58:55 +0000
- To: public-css-archive@w3.org
> Yes, I'm arguing with that.
That was a typo, meant "I'm NOT arguing with that", anyway...
> @flackr already https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3234466432 that we split the higher level behaviors into animation-specific actions. I 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 https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3091201201."
Yes, this is understood, but then we have the paired behaviors, like `play-pause` and `play-alternate`. Those are either tied to a pair of events, or alternate on a single event. Now, while this makes sense for alternating on `click`, I'm not sure how useful it is to alternate those on "view-enter" or "view-leave".
> Yes, it's useful and expected under the model that the keyword describes only the enter behavior, or only the exit behavior, aka the granular model - if you refer to the 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/)
Yes, again, while it's useful to only `pause` on "leave", I'm not sure about alternating between `play`/`pause` on "leave".
> play-alternate in this example specifies only the enter behavior, no exit behavior is specified.
OK, so in the above example we have both enter and exit events, but only an enter behavior. So this behavior means "alternate direction only on `pointerenter`", right?
> 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.
Right, so this also implies the question: what is the initial value of the exit action? Is it `auto` or `none`?
Using `none` would make it more explicit, and might be safer.
> 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>].
So now specifying `play-alternate` can only be applied to a single event, which means that `animation-trigger: --view-trigger play-alternate` will alternate only on enter, which again, is very weird, but if we agree that that's the explicit syntax we choose, that's fine. Just maybe unfortunate that the syntax for the most important and simple use-case became a bit cumbersome:
```css
.target {
timeline-trigger: --trigger view();
animation-trigger: --trigger play-forwards play-backwards;
}
```
Though we could still add a function to simplify trigger declarations, the behavior is now split into 2 longer keywords, which is a bit unfortunate.
But honestly, these "Entrance" animations are the most basic and common of animations on the web.
> 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.
Yes, simple, but cumbersome and unfortunate.
> 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.
Well, first of all I have raised many concerns on the issues, and suggested alternatives.
Besides some answers from you, most were ignored and then quickly discussed on call, at which, TBH, I was a bit overwhelmed to respond thoroughly 🙂
For instance, I keep getting back to issues with multiple timeline triggers and/or mixed timeline triggers and event triggers, and issues with state in the design, and got no response there.
We also agreed on deferring multiple triggers, which has now crept back in without any response to my questions on state.
I think I can resolve this in the spec, but this is not being addressed in the issues or on call 🙁
I guess I was also confused by the fact that we kept the paired behaviors along with the granular ones, and I assumed these would work the same as the current behaviors, while implicitly these actually work now a bit differently.
> 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.
Well that's the heart of the issue, I guess. Now that misunderstood parts are more clear, I think the only option is to try and see if perhaps instead of the "initial `none`" behavior we can somehow fit an alternate solution that simplifies the syntax, like maybe doing sort of "initial `auto`" behavior. I need to think this over again.
> You seem to be subscribing to the granular behavior model already in which one keyword, none, specifies the <enter behavior> and another, pause, specifies the <exit behavior>. So I'm a bit confused at what you're arguing with.
Yeah, I just started understanding that part of the model.
I'm also fine with the granular model, but it seems to be we had rushed to resolve on it, before checking all the edge cases, and before realizing how this affects the simple and common use-cases.
--
GitHub Notification of comment by ydaniv
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3369041525 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 5 October 2025 12:58:56 UTC