- From: Robert Flack via GitHub <noreply@w3.org>
- Date: Thu, 28 Aug 2025 18:08:59 +0000
- To: public-css-archive@w3.org
> However, one thing I want to regress to is the higher-level behaviors we started with, as in `once`, `repeat`, `alternate`, and `state`. I really don't think we have any valid use-cases for splitting those, or mix and matching stuff like `reset` and `pause`. > I strongly believe not starting with triggers simply playing an animation by default, and have a matching invert action, could be a bad design, even a footgun, especially when we're just starting with level 1 of this feature. We decided to split these into animation-specific actions specifically because event triggers are not paired, and so breaking the inverting part of the behaviors into actions allows for doing the same things with either event triggers or timeline triggers. I think we've covered this previously, and as discussed at tpac, these behaviors can be achieved by having animation [play state](https://www.w3.org/TR/web-animations-1/#play-states) dependent actions: 1. `once` can be implemented with a `play-once` action that will only play the animation if it is paused. 2. `repeat` is a `play` action that plays the animation if it is paused or finished, and a corresponding `reset` or `finish` action on exit to immediately finish the animation. 3. `alternate` is a `play-reversed` action that will play the animation if it is in the paused state, and reverse it if it is finished. 4. `state` is a `play` action on entry, and a `pause` action on exit. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3234466432 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 August 2025 18:09:00 UTC