Re: [csswg-drafts] [web-animations-2][css-animations-2] Should an animation be allowed to have multiple triggers associated? (#12399)

Summary: I don't see the benefit in not allowing multiple triggers per animation at the moment. If authors want  coordinated trigger behavior, it should not be implicit - they should specify it. I don't see a nice way of specifying it with the current set of properties we have so I think such specification will have to be an additive feature.

> Let's start with considering examples with multiple timeline-based triggers:
> 
> * 2 `view()` triggers on same animation, one on the `x` axis and the second on the `y` axis. Should each apply its effect separately? What if the author wants a behavior where only if scrolled into a specific rect, the intersect of these two triggers' ranges, then they apply their effect?
> * The above example becomes more concrete when used with 2 `pointer()` timelines, if an author would attempt to apply the triggers' effect only when the pointer is over the intersection of x and y.
> * 2 overlapping `view()` or `pointer()` triggers on same animation with `once`, `state`, or `alternate` types.  Does entering one range apply the effect? And when entering the overlap area, do we re-apply the effect?
> 

It seems the main question here is: Should each apply its effect independently or in coordination with other triggers? Without any additional information from the author, I think the answer is *yes, triggers should operate independently*. Right now, all you can specify is within what scroll range a trigger is "tripped." If an author's intention was for a trigger not to play its animation despite its trigger condition being met, I think we'd need a way for them to express this.  If an author wants some sort of coordination between triggers, I think it would be better for them to specify it. Otherwise, I think we'd be introducing a bit too much magic into how triggers function. I think by default triggers should just function independently and authors should be able to opt into more complex coordination. E.g. perhaps we can think about an `animation-trigger-coordination` or an `animation-trigger-group` property which has a `name` and a `type`. The `type`s could have meanings  corresponding to:
- if ANY triggers in this group tripped, play the animation, or
- iff ALL triggers in this group are currently tripped, play the animation,
- other interesting ideas.

(I guess by "tripped" I mean "have matching state").

Of course, it will still be possible for authors to construct instances where triggers wish to perform different actions on a given animation. I'm not sure this is entirely avoidable under any scheme.

> If we consider event-based triggers, though they aren't fully specified yet we can think of use-cases like:
> 
> * 2 `click` triggers of type `once` on different elements working on same animation. If the trigger contains the state, does each apply a `once` effect? Otherwise, if we expect for this animation to play once, this state should be part of the animation. Since the notion of "once" is part of the trigger, not the animation, this starts complicating the model.
> * Same example above with `state` or `alternate`.
> 

Hm, I don't think it's complicated: the once notion is part of the trigger, not the animation.  Two clicks (on the separate trigger click targets) will play the animation twice, so long as the second click happens after the animation finishes from the first click. If the second occurs while the animation is playing from the first, it's essentially a noop, just like invoking `play()` is. Right @szager-chromium ?

> I think if we just think in simple terms of "click" then this seems trivial. But honestly I think this just becomes a mess. On top of that, we also don't have a way of specifying multiple triggers per animation in CSS. So I also don't think we should allow such a radically different API in Web Animations from CSS.
> 

If we adopt the `timeline-trigger`, `event-trigger`, `animation-trigger` namespaces, we can specify multiple triggers per animation in CSS. E.g.:

```
#view-target-1 {  timeline-trigger: --my-trigger view(); }
#view-target-2 {  timeline-trigger: --my-trigger view(); }
#animatable {  animation-trigger: --my-trigger alternate; }
```

The animation on #animatable can be triggered by scrolling either `view-target-1` or `view-target-2` into view.  





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


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

Received on Monday, 30 June 2025 14:03:24 UTC