Re: [csswg-drafts] [animation-triggers-1] Add custom triggers (#13625)

> In particular, you could do the following:
> 
> ```js
> // Create a trigger.
> const myTrigger = new CustomTrigger();
> // Create as many associated animations as you like.
> myTrigger.addAnimation(element.animate({ ... }, { ... }, 'play');
> myTrigger.addAnimation(element.animate({ ... }, { ... }, 'play');
>
> // Sometime later, the associated animations can be triggered:
> myTrigger.activate();
> ```

So the difference is that you don't attach it to an event, and you have an imperative API for activation/deactivation, right?

Just for argument's sake, is this significantly better than using imperative `EvenTrigger` with triggering a `CustomEvent`?

> Should it be stateful, i.e. enter an activated and deactivated state like timeline triggers, or like event triggers where it does not stay in an activated state and merely triggers the activation behavior. I'm leaning towards non-stateful.

Again, I'm a bit confused, since we also specced [stateful event triggers](https://drafts.csswg.org/animation-triggers-1/#event-triggers), but to the question at hand, I think we should ask what are authors expecting to get OOTB from this API?
I believe not having to worry about state management yourself is a big deal. Otherwise this could have been a simple object with a reference to animations.
So IMO we should allow both options, either as a config to to the constructor, or via API, as in both endpoints for state transition, and for forcing re-trigger of same/specific state.

> The developer can pre-arm important animations ahead of time without knowing exactly when they need to play.

Does this basically mean exposing a way to make an animation active and in its `before` phase? Perhaps we should simply allow that ability on animations in general?

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


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

Received on Friday, 13 March 2026 11:21:18 UTC