- From: David A via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Apr 2025 19:22:21 +0000
- To: public-css-archive@w3.org
Thanks for filing this! > ### Proposal > * `animation-trigger` does not override the behavior of `animation-play-state`. > * If `animation-play-state` is set to `running` then the associated trigger's effects continue as specified. > * If the `animation-play-state` is set to `paused` then the associated trigger's effects are overridden and the animation remains paused. > I think I agree with the proposal overall with one (perhaps significant) difference: I wouldn't say that a trigger's effects are overridden by `animation-play-state`. I think of it more as the condition for advancing an animation (forwards or backwards, so that it reflects its timeline time) now requires, in addition to `animation-play-state`, whether its trigger condition has been met. I think where this really makes a difference is when we consider what happens when we have a scroll-based trigger (no time-based triggers for now) and the exit condition is met. With `animation-play-state: paused` should a repeat trigger still reset the animation? should an alternate trigger still reverse the animation? I think these answers should be yes - which means the trigger isn't really overridden, but in all cases (assuming a waapi call hasn't stopped us from listening to `animation-play-state`) we would still need `animation-play-state` to be `running` to make progress on the animation with time. A related question I was thinking about was: when an animation with a `state` trigger is paused by its trigger upon exiting the exit range, if its `animation-play-state` is then toggled from `running` to `paused` and then back to `running` should it continue to make progress? I think so. -- GitHub Notification of comment by DavMila Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12064#issuecomment-2790772597 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 April 2025 19:22:22 UTC