- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 18:09:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[animation-triggers-1] Proposal: toggle Custom States using Animation Triggers (`state-trigger`)``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> ydaniv: we've started work on animation-triggers. have timeline-trigger in chrome, working on event-trigger<br> <TabAtkins> ydaniv: these only allow us to change animation playback<br> <TabAtkins> ydaniv: there was previously work on state management with triggers, using CSS toggles. this didn't mature into an accepted proposal<br> <TabAtkins> ydaniv: this is trying to revive a similar concept, but building on things we already have accepted, like animation-triggers<br> <TabAtkins> ydaniv: idea is simple. we already have element stages, select via :state(), for custom elements<br> <TabAtkins> ydaniv: using JS you can add/remove strings from the state set, changes how :state() matches<br> <TabAtkins> ydaniv: proposal from Lea to extend this fucntional pseudo to all elements<br> <flackr> q+<br> <TabAtkins> ydaniv: building on that, this proposal suggests using triggers to have additional actions, a new property state-trigger<br> <TabAtkins> ydaniv: jumping to examples, lets you connect the name of a trigger and adjust states<br> <TabAtkins> ydaniv: `timeline-trigger: --on-screen view(); state-trigger: --on-screen add-state(--visible);`<br> <TabAtkins> ydaniv: then `:state(--visible)` will work<br> <lea> q+<br> <TabAtkins> ydaniv: today people use classes for this, or custom elements. this connects all of this together into a declarative api<br> <TabAtkins> ydaniv: proposal for three new actions - add-state(), remove-state(), toggle-state()<br> <TabAtkins> ydaniv: could also trigger these via an event-trigger<br> <TabAtkins> ydaniv: today you'd hack around this with animation triggers, or container state queries, etc.<br> <TabAtkins> ydaniv: so i think this i smore straightforward for binding these together<br> <TabAtkins> ydaniv: some open issues<br> <TabAtkins> ydaniv: biggest from a convo yesterday was there might be big a11y concerns, same as css toggle<br> <TabAtkins> ydaniv: but since people can do all this today with JS, probably still worth solving easier rather than blocking<br> <kbabbitt> q+<br> <TabAtkins> ydaniv: everything is bikesheddable<br> <TabAtkins> ydaniv: some questions about custom-ident vs dashed-ident...<br> <TabAtkins> ydaniv: whether we want later an imperative API like we have for animation triggers<br> <TabAtkins> q+<br> <Rossen> ack flackr<br> <TabAtkins> flackr: i believe this can be completely done with triggers and fill-forward animations, especially a once() trigger<br> <TabAtkins> flackr: so given that, is there a big ergonomic advantage to adding new stuff<br> <Rossen> ack lea<br> <TabAtkins> flackr: two, would like to see how people would buiold it today, don't thin kit's that much harder and i think it would help inform future solutions<br> <TabAtkins> lea: might have missed it - what about cycles?<br> <TabAtkins> lea: it seems state-trigger can set a state, then you can select base don the state, how do we avoid a cycle?<br> <TabAtkins> ydaniv: currently i started very simple to see if there are blocks in the way,<br> <lea> Avoiding cycles was the motivation for the design in #12502 btw, otherwise this is much more elegant<br> <lea> Sorry, https://github.com/w3c/csswg-drafts/issues/12502<br> <TabAtkins> ydaniv: to answer Rob, today it can even be a one-liner to hook up classes or data attributes in response to events. so it's easy today, but this is more declarative and easier<br> <TabAtkins> flackr: specifically waht i meant is, it's already easy to make a declarative animation trigger that applies a state when the naimation trigger happens.<br> <lea> q+<br> <TabAtkins> flackr: so they won't need to use JS anyway once we ship that. so the q is how much this is needed if we can just change styles with an animation<br> <TabAtkins> ydaniv: there are cases where you just want to change styles, not run an animation. entire animation api is sometimes a bit much<br> <TabAtkins> ydaniv: another use-case for the future is to have this as a declarative mechanism for trigger scoped view-transitions, maybe<br> <TabAtkins> kbabbitt: same question as Lea for cycles<br> <Rossen> ack kbabbitt<br> <TabAtkins> kbabbitt: there is some precedent for how we scope this in CQs to guard against that... maybe it won't solve the use-cases here<br> <fantasai> TabAtkins: I don't believe from this presentation that there's potential for cycles, but confusing from presentation<br> <Rossen> ack TabAtkins<br> <fantasai> TabAtkins: This isn't a property like animation-trigger that defines stuff for other things to rely on.<br> <fantasai> TabAtkins: This is just, "when some other trigger occurs, then we can adjust states on the element". Doesn't respond to a state changing.<br> <fantasai> TabAtkins: The property is not named correctly for that.<br> <fantasai> TabAtkins: It doesn't define a trigger. It defines a response, like animation-trigger listens for triggers.<br> <fantasai> TabAtkins: It's like animation-trigger, not the trigger-defining properties.<br> <castastrophe> q+<br> <fantasai> ydaniv: Exactly, state-trigger property is analogous to animation-trigger<br> <fantasai> ydaniv: i.e. where you *reference* the trigger<br> <fantasai> ydaniv: and define the reaction to it<br> <Rossen> ack lea<br> <fantasai> lea: Does this affect :state() ?<br> <fantasai> TabAtkins: Yes, it does, but it's not cyclic in the same way that timeline-triggers are not cyclic<br> <fantasai> TabAtkins: What do you think is cyclic about this? What's the scenario that would cycle?<br> <fantasai> Lea: Thought you could set state foo via selector, and then use that to remove it<br> <fantasai> TabAtkins: It's not defining a trigger. It's responding to a trigger that has been defined.<br> <fantasai> TabAtkins: When an existing trigger source happens. Currently you can run an animation in response to that.<br> <fantasai> TabAtkins: This would allow us to also adjust the state-set.<br> <fantasai> TabAtkins: It is not causing an event trigger, it is saying how do I respond to a timeline or event trigger.<br> <fantasai> TabAtkins: Several people confused, so wanted to clarify!<br> <ydaniv> thanks TabAtkins!<br> <TabAtkins> fantasai: this seems cool, but also i'm not sure CSS changing the state is at the right level of abstraction<br> <TabAtkins> fantasai: there was a concern about authors being able to modify the state set in a way that CE devs aren't expecting<br> <Zakim> fantasai, you wanted to raise https://github.com/whatwg/html/issues/11466#issuecomment-3386922777<br> <fantasai> https://github.com/whatwg/html/issues/11466#issuecomment-3386922777<br> <TabAtkins> fantasai: this was raised on previous proposal, think it still applies<br> <Rossen> ack castastrophe<br> <TabAtkins> castastrophe: I think there needs to be more use-cases described for this, but i'm intrigued from design system perspective<br> <TabAtkins> castastrophe: many times we were building component UI, wanted to assign state that doesn't exist in HTML in styles, but didn't want to to be responsible for the JS<br> <ydaniv> q+<br> <TabAtkins> castastrophe: so don't necessarily want to manage a bunch of classes, just want a view component to trigger that state<br> <TabAtkins> castastrophe: so i think this is very clean for design systems, engineers never want to add a million state-based classes but i do want to acknowledge there is state<br> <TabAtkins> castastrophe: but i do think we need more use-cases, yeah<br> <TabAtkins> castastrophe: figure out where JS plays into it<br> <Rossen> ack ydaniv<br> <TabAtkins> ydaniv: def agree with Cass<br> <TabAtkins> ydaniv: we've had a lot of these features built for a long time, rolling it out now packaged as design system states<br> <TabAtkins> ydaniv: so this is based on existing design system use-cases, just declarative way to avoid having to maintain state separately or with JS<br> <TabAtkins> fantasai: so i think i understood from the discussion...<br> <TabAtkins> fantasai: there was a concern aobut cyclic, appears there sin't<br> <TabAtkins> fantasai: concern about CEs ability to reason about themselves, since this is coming from a different source<br> <hoch> q+<br> <TabAtkins> fantasai: and the ability to have a declarative way to manage state you can select off of is useful<br> <Rossen> ack hoch<br> <TabAtkins> hoch: one q abuot conflict resolution<br> <TabAtkins> hoch: can have multiple triggers, would be good to clarify the behavior if the same trigger says to add and remove a state, etc<br> <arronei> q+<br> <Rossen> ack arronei<br> <TabAtkins> arronei: a little concerned about the bikeshedding that may need to happen to clarify these names to amke sure people udnerstand this *isn't* cyclic<br> <TabAtkins> (agree, the use of *-trigger for both sides fo the equation is kinda bad actually)<br> <TabAtkins> arronei: so might be good to bikeshed the names)<br> <fantasai> TabAtkins: How locked-in are we on the name 'animation-trigger'?<br> <fantasai> TabAtkins: it's confusing that it's the opposite side of 'event-trigger' and 'timeline-trigger'<br> <fantasai> TabAtkins: The more we do stuff in this space the more confusing it's going to be<br> <fantasai> TabAtkins: We should come up with a better naming system<br> <arronei> random bikeshedding, *-hook, *-link, *-use, .....<br> <fantasai> TabAtkins: that makes it clearer whether we are defining or using the trigger<br> <astearns> *-trigger-response<br> <TabAtkins> Rossen: so there's clearly some interest in this<br> <TabAtkins> Rossen: and everything is bikesheddable, so that's ncie<br> <fantasai> I wonder if just swapping between trigger- and -trigger would help?<br> <TabAtkins> Rossen: how do we want to take this forward?<br> <kbabbitt> triggers-animation / triggers-state-change ?<br> <fantasai> ydaniv: good feedback. I was more concerned wrt a11y stuff, but nothing concrete yet<br> <TabAtkins> ydaniv: i guess we can continue on the issue<br> <TabAtkins> (we really want animatino-trigger to live in the animation-* namespace if possible)<br> <fantasai> ydaniv, might be useful to reach out to the a11y group?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13579#issuecomment-4164472570 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 18:09:30 UTC