- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Mar 2026 16:34:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[animation-triggers-1] Multiple named triggers`, and agreed to the following: * `RESOLVED: Allow event triggers with the same name to combine into a single named trigger.` <details><summary>The full IRC log of that discussion</summary> <fantasai> ydaniv: Currently, the way we define event-trigger and timeline-trigger, when you provide a custom-ident as the name for the trigger, multiple declarations of the same name overwrite each other<br> <fantasai> ydaniv: but if you want multiple triggers, managing this state becomes impossible<br> <fantasai> ydaniv: So what we propose here is to take a different approach<br> <fantasai> ydaniv: Instead of clashing, they merge<br> <fantasai> ydaniv: When you set an event trigger with a custom-ident, and another trigger with the same name<br> <fantasai> ydaniv: Instead of creating trigger instances, they create attachment points to triggers<br> <fantasai> ydaniv: and when you specify the usage on an animation-trigger, that's where the trigger instance is created<br> <fantasai> ydaniv: and it attaches to all of those place<br> <fantasai> ydaniv: So this is the proposed behavior<br> <fantasai> flackr: The trigger isn't created at the point where you use it. It's just a conceptual thing that exists. All the named events are contributing towards it.<br> <DavidA> q+<br> <fantasai> ydaniv: This is different from how custom-idents are used with other features<br> <fantasai> flackr: In other usages, we required a unique target for the custom ident. E.g. a scroll timeline produces a time from a single scroller, no way to combine<br> <fantasai> flackr: but with trigger events, no reason we can't collect trigger events from different sources<br> <TabAtkins> q+<br> <Rossen> ack DavidA<br> <fantasai> DavidA: Adopting this would mean that we have to attach multiple triggers to an animation<br> <DavidA> https://github.com/w3c/csswg-drafts/issues/12399#issuecomment-3109330018<br> <fantasai> DavidA: If that's true, I think we had a previous resolution to only support a single trigger per animation, would we need an update to that resolution?<br> <fantasai> flackr: No, doesn't require that.<br> <fantasai> flackr: This means that a single named trigger can have many sources that contribute events to it<br> <fantasai> flackr: For timeline triggers, it would mean that your trigger has many contributing timelines that each have their own thresholds of when they contribute their activation events etc.<br> <Rossen> fantasai: overall makes sense, esp for event triggers. For timeline triggers, one is start anim, the other<br> <ydaniv> qq+<br> <TabAtkins> fantasai: so how does that work? when you exit one of the timelines but not the other... do you want the intersection? or what?<br> <fantasai> flackr: When I created this issue, I had event triggers in mind.<br> <TabAtkins> flackr: I agree. when i created the issue i had event triggers in mind, where it's straightforward.<br> <fantasai> flackr: For timeline triggers, we very much depended on trigger state to do something meaningful<br> <fantasai> flackr: So would be supportive to say this is only for event triggers.<br> <Rossen> ack ydaniv<br> <Zakim> ydaniv, you wanted to react to DavidA<br> <Rossen> ack fantasai<br> <fantasai> ydaniv: [missed]<br> <TabAtkins> q-<br> <fantasai> ydaniv: If everything converges all things that use same ident for this trigger<br> <fantasai> ydaniv: and also the multiple triggers defined for that animation<br> <fantasai> ydaniv: if we merge all this comes to a single point, then it doesn't matter<br> <fantasai> flackr: For timeline triggers, only way this makes sense is if they each keep internal state of whether it's active or inactive<br> <fantasai> flackr: You don't want a situation where one timeline wants to activate but other wants to deactivate and you flip between them rapidly<br> <fantasai> ydaniv: So we also need a resolution to say that this only works for event triggers ...<br> <DavidA> q+<br> <fantasai> flackr: I don't know that we've thought about it enough.<br> <fantasai> flackr: but easy to do for event triggers<br> <fantasai> DavidA: With timeline triggers, where each timeline maintains its own state... that would basically be functionally equivalent to each instance of the event instatiates a trigger<br> <Rossen> ack DavidA<br> <fantasai> flackr: I don't know. Haven't thought through that question.<br> <TabAtkins> fantasai: I think doing this for events make sense, would support resolution<br> <Rossen> ack fantasai<br> <flackr> q+<br> <TabAtkins> fantasai: for timeline, needs more thought. might be ar easonable model for combining, not sure what it woudl be. would hold off until robert and yehonatan have time to think on it<br> <fantasai> flackr: There is one tricky bit, triggers exist in the same namespacing.<br> <fantasai> flackr: You could have a combination of timeline triggers and event triggers contributing activations and de-activations to the same named trigger. Should that work or not, idk<br> <fantasai> flackr: So to take the resolution, can't combine different types of triggers.<br> <fantasai> fantasai: Yeah, I think we start there. If we find a reasonable way to combine, we can change.<br> <fantasai> PROPOSED: Allow event triggers to combine.<br> <Rossen> ack flackr<br> <fantasai> PROPOSED: Allow event triggers with the same name to combine into a single named trigger.<br> <fantasai> RESOLVED: Allow event triggers with the same name to combine into a single named trigger.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13710#issuecomment-4128044742 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 March 2026 16:34:25 UTC