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.

Yes, it would be nice to have a way to have a way to revert that state back to the initial paused state.

> I think that's a bit unfortunate since it introduces hidden coupling between animations and triggers

I agree it's not optimal, but I think otherwise we'll need something like `animation.reset()` or `trigger.enable(animation)`.

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

That sounds fine. What if both triggers are of type `once`? I suppose each trigger would call `play()` once if that's what the author chose. We could also argue the expected behavior would be to have the animation be triggered *at most* once. It's fine to say such behavior is only possible with some additional scripting, but still it's an edge case to be aware of.

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

Currently `alternate` behavior is defined to call `play()` only on first tripping and then it only calls `reverse()` on every enter/exit. In this way 2 overlapping triggers may cause the state of the playback direction and the trigger to be flipped, again, unless that was the intent. 
Or, we could change the definition of `alternate` to be specifically to play forwards on entry, and backwards on exit, and then we'd have the re-`play()` behavior again.
Well, can't say I can think of a good use-case of either :P

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

So exactly the options I explained above. For example, if you want 2 `once` triggers to play at most once.

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

No worries, by "worked well" I meant matching the value of `auto`, which is a valid value for a timeline, explain the default behavior of autoplaying an animation, and also be the default value for the trigger's timeline.
So if we scrap the notion of "default trigger" we say CSS animations and `Element.animate()` animations simply automatically call the `play animation` procedure. But we still need an `initial` value for `animation-trigger`, and to define what `animation-trigger-timeline: auto` means. That is what the default trigger managed to tie together in a coherent way.

-- 
GitHub Notification of comment by ydaniv
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2930775831 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 13:37:35 UTC