- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 May 2025 05:54:02 +0000
- To: public-css-archive@w3.org
> [@birtles](https://github.com/birtles) [@graouts](https://github.com/graouts) FYI want to call your attention to this meta issue in case you have further thoughts about the animation trigger model Thanks @flackr. The expectations sound mostly reasonable to me. I definitely agree with trying to make Web Animations and CSS animations behave consistently at a basic level. Since we're talking about the high-level architecture, I think it makes sense that triggers operate at the playback level and should ideally not need to touch the animation effect timing. However, taking this a step further, I wonder if it is possible to have triggers be entirely independent of animations such that they exist as external mechanisms that simply call `play()`, `pause()`, `cancel()` etc. on their target animations. I think that would produce behavior that is easy to reason about for all cases. If we want to distinguish between certain cases where the to-be-triggered animation fills backwards or not (e.g. distinguishing between `Element.animate()` and CSS animations vs `new Animation()`) then we could introduce some concept to the trigger like "arming" or whatever which effectively just calls `pause()` on the associated animation. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2844158638 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 1 May 2025 05:54:03 UTC