- From: David A via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 May 2025 13:35:05 +0000
- To: public-css-archive@w3.org
> I've gone through the AnimationTrigger doc and with the help of some explanations from [@DavMila](https://github.com/DavMila) I think it makes sense. However, I'm pretty sure I'm still missing some important understanding of how triggers work. I think all your suggestions are good and I'd be happy with moving forward this way. I'll add a few details. > * We introduce means of temporarily overriding the interval endpoint behavior to Web Animations. We already need this in [[web-animations-1] Make commitStyles use an endpoint-inclusive active interval #11881](https://github.com/w3c/csswg-drafts/pull/11881) so perhaps in a similar vein we allow a flag to be passed in to the pause procedure (at a spec level, not the API level) that allows overriding the endpoint behavior whilst paused. (Could scroll animations use something like this too?) Yes. I believe this works just fine conceptually for AnimationTriggers. The slight difference with the way that PR is currently written is that AnimationTrigger will want to be in the before phase for a forward-playing animation when the local time is at the before-active boundary time. But I guess those are just details and using a/this flag is conceptually fine... just thought I'd mention the detail in case there is anything about that that is unexpected (which I doubt). > * `AnimationTrigger`s keep track of which animations they are controlling and call `play` / `pause` etc. on them. This seems good to me. We can track any relevant state within the AnimationTrigger rather than the Animation. In line with your suggestions in the doc, we can scrap Animation.trigger and just have AnimationTrigger.arm(Animation) and the AnimationTrigger will be aware of which animations its associated with. > * An animation can be controlled by multiple triggers and, provided they have a well-defined evaluation order, the result is just whatever you'd get from calling play / pause / etc. on them in that order. This seems good to me. > * Animation's have no notion of whether they are being controlled by a trigger or not but they retain a list of triggers associated with them purely for convenience so that you can navigate from a `CSSAnimation` to any trigger targeting it. (Although even that might not be necessary? If the only use case is disassociating triggers then we could just let `cancel()` do that?) Agreed. I've realized we can move all state tracking to the trigger. I'm okay with not even having that convenience. At the very least, if it's something that authors think they'd find useful and want, we can always add it. Maybe we can also think about an AnimationTrigger.getAnimations() API?.. and perhaps a document.getAnimationTriggers() API? > * Triggers are armed when they are constructed and there is no default trigger. Sounds good to me. With option 1 we really don't need a default trigger for explicitly constructed Animations. However I think CSS animations should still get triggers by default. Like we're currently trying to specify, animation-trigger defaults to a trigger that would play the animation immediately - so no change to existing animations - and custom `animation-trigger`s also just work, neither being treated as a special case? > * `cancel()` disassociates any triggers from the animation. Yes. Further, explicit calls to `play()`, `pause()`, `finish()`, `reverse()`, setting currentTime/startTime also disassociate any triggers from the animation. > > Sorry for the delay and for where I've surely overlooked important behaviors. I'm just trying to wrap my head around this and see if there's a simpler, less-coupled approach that lets us avoid adding more boolean state parameters to the already-complicated Web Animations model. No worries, your input has been very helpful! I think we're converging on what the API should look like. -- GitHub Notification of comment by DavMila Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2912543529 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 May 2025 13:35:06 UTC