Re: [csswg-drafts] [animation-triggers-1] Should play-forwards and play-backwards have no effect if the animation has already reached its end? (#13643)

The problem is that we moved the state to the trigger, when before it was possible to keep it synchronized to the animation's state. And having multiple triggers on a single animation becomes problematic.
Even if we create another state on the animation and manage it, we still need to sync it with the rest of the triggers. If we use the example above it means that click on `button-1` will also flip state of the trigger on `button-2`, and I'm not sure we want to go that way.

-----

Another option I can think of is changing the whole model of "name-clashing" for triggers.
We could say trigger names "add" and don't "clash", they add more event registrations to the same trigger instance. And then if you want multiple triggers it simply means reusing the same name, plus we go back to single trigger per animation, and that would look like:

```css
.button-1 {
  event-trigger: --c click / click;
}

.button-2 {
  event-trigger: --c click / click;
}

.target {
  animation: slide 1s both;
  animation-trigger: --c play-forwards play-backwards;
}
```

This has its pros and cons for sure, but it's also exposing all the control to authors, and it's very explicit about what's happening and where the state is.
One possible down-side could be that it may accidentally "merge" triggers, but that can also be mitigated with `trigger-scope`.
There's also the issue of mixing stateful triggers with stateless triggers. I suppose stateless triggers will simply trigger regardless of state, and also won't affect the state.

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


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

Received on Tuesday, 17 March 2026 11:28:22 UTC