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

> > My original concern about `cancel()` not cancelling things would still be addressed in this model since `cancel()` would work as usual. The only caveat is that if the user later scrolled etc. the animation might start whereas if `cancel()` disassociated triggers, that would no longer happen.
> 
> I still think cancel should result in an animation no longer being triggered. When we add an animation to a trigger it sits in a paused state waiting for the trigger, and that explains why it is "relevant" and returned by getAnimations. When you cancel, the animation would no longer be paused right? It would be strange to have two states that a triggered animation could be in.

Right, it would be in the idle state. As a result, there would be two different states: "paused by trigger" and "idle with a trigger". From an author's point of view, the only way to get back from "idle with a trigger" to "paused by a trigger" would be to re-associate with the trigger. So I think that's a pretty good argument for having `cancel()` disassociate from any triggers.

I think that's a bit unfortunate since it introduces hidden coupling between animations and triggers but perhaps in future it could be explained by having animations emit events and letting triggers listen to them (we've discussed animation mutation observers in other issues before).

> Regarding [@birtles](https://github.com/birtles)' suggestion:
> 
> > 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.
> 
> How should that actually work in the following scenarios:
> 
> * One trigger is tripped to `primary` and then a second trigger trips to `primary`. Should that re-play the animation? Or should the second trip be ignored?

It would do whatever primary triggering is defined to do. If triggering calls `play()`, it calls `play()` twice.

> * One alternating trigger is set to `inverse` and then another alternating trigger is set to `inverse`. Should the animation be reversed twice so it now plays forward? Or should we change the definition of `alternate`?

Again, it simply does whatever an inverse trigger is defined to do. So if that calls `reverse()` then it will be called twice and presumably will end up playing forward.

> It seems to me like both cases above force us to make this behavior stateful again. I could see having both a click and view triggers be a possible use-case, but not sure about multiple view triggers. I think this behavior needs more work.

I'm afraid I'm not following why we'd need to make the behavior stateful. Could you elaborate?

> > > I like the idea of constructed Animation's simply not having a trigger and just keep work as is, while CSS and .animate() ones get a new instance of the default trigger. Does that summarize this point correctly?
> > 
> > I'm not sure that animate() needs a default trigger. I'm not sure CSS does either unless that makes the mapping to CSS default property values simpler.
> 
> So far defaulting to a trigger with the `DocumentTimeline` worked well as the default behavior. We also need to keep in mind that `timeline` values also include `none` and `auto`, and that is how we modeled that part to be consistent.

Sorry for being dense here, but I'm not quite following this part. Could you elaborate on what "worked well" means here? And how the "none" and "auto" values play into this? Thank you!

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


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

Received on Monday, 2 June 2025 03:00:23 UTC