Re: [csswg-drafts] [css-animations-2][web-animations-2] How should AnimationTrigger work? (#12119)

Replying to @DavMila's [comment](https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2912543529):
  
> > * 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).

Awesome. Yes, that's a good detail to be aware of.

> > * 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?

Yes, I think those approaches would work too.

> > * 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?

From what I understand that seems fine. I think it would be mostly unobservable too unless we expose `Animation.triggers` or `AnimationTrigger.getAnimations()` etc.

> > * `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.

I was thinking about this and I actually wonder if it's even necessary. For example, would it be so bad if `cancel()` just made the animation become idle and didn't tell the trigger?

> > 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.

Thank you so much for your understanding!

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


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

Received on Friday, 30 May 2025 01:13:12 UTC