Re: [csswg-drafts] [web-animations-2][css-animations-2] Set of actions for animation triggers (#12611)

The Houdini Task Force just discussed `[web-animations-2][css-animations-2] Set of actions for animation triggers`, and agreed to the following:

* ``RESOLVED: timeline-trigger-* and event-trigger just define the source element. on the animating element, `animation-trigger: trigger()#` specifies source element, action, and behavior. (`[trigger()+ ]#` for multiple triggers on a single animation``

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: we've set up our triggers such that a named trigger has some set of associated actions<br>
&lt;TabAtkins> flackr: UI events, or enter/exit for timelines<br>
&lt;TabAtkins> flackr: there are, i think, 3 ways to associate them with an animation behavior<br>
&lt;TabAtkins> flackr: 1) in trigger definition, specify this action has this behavior<br>
&lt;TabAtkins> flackr: 2) like ydaniv proposed, on the animating element you specify the behavior, and there's something about exit behaviors<br>
&lt;TabAtkins> flackr: the only way i can make this make sense is that the exit has another behavior in the animation-trigger proeprty<br>
&lt;TabAtkins> flackr: 3) an explicit syntax, maybe functional, in animation-trigger that links a trigger name to an animation behavior<br>
&lt;TabAtkins> flackr: i think third is most generic and conceptually simple<br>
&lt;TabAtkins> flackr: it leave sit so triggers don't mention animations<br>
&lt;TabAtkins> flackr: and we can do more stuff with triggers in the futre<br>
&lt;TabAtkins> ydaniv: in option 2 i allowed 2 triggers, was continuing the line tab and elika took<br>
&lt;TabAtkins> ydaniv: but if we go back to just allowing one trigger, you spec the trigger you want and the behavior<br>
&lt;TabAtkins> ydaniv: the old pattern of once/repeat/alternate/state<br>
&lt;TabAtkins> flackr: that behavior has something that happens when the action starts and the action stops, so that's a second thing just for timeline triggers<br>
&lt;TabAtkins> DavidA: what's maybe not great here is we have to reinterpret bheavior in the event trigger context<br>
&lt;TabAtkins> flackr: i know stefan has concerns about this as well. option 3 shouldn't be contentious, it's extensible. triggersa re just event sources<br>
&lt;TabAtkins> DavidA: we'll have to modify the JS interface, so trigger.addAnimation(), you'll also specify the behavior<br>
&lt;TabAtkins> flackr: yeah, we can modify idl to match once we decide on css<br>
&lt;TabAtkins> ydaniv: making sure i get this right<br>
&lt;TabAtkins> ydaniv: with event triggers, you don't ahve behavior of start/end<br>
&lt;TabAtkins> s/behavior/action/<br>
&lt;TabAtkins> ydaniv: so for now we only allow events to play forwards<br>
&lt;TabAtkins> ydaniv: in option 3 we add a function that ties an event to an action, like play or reverse<br>
&lt;flackr> animation-trigger: trigger(--trigger-name, &lt;action name>, behavior)<br>
&lt;TabAtkins> ydaniv: so how do you specify clicking to start and pause or wahtever<br>
&lt;TabAtkins> flackr: you add two triggers, and we specify that animation-trigger can do multiple triggers<br>
&lt;flackr> animation-trigger: trigger(--timeline-trigger, enter, play) trigger(--timeline-trigger, exit, pause)<br>
&lt;TabAtkins> DavidA: i was interpreting option 3 as, if you want multiple event associations, you don't need more than on even ttrigger<br>
&lt;TabAtkins> flackr: does this example make sense?<br>
&lt;TabAtkins> ydaniv: but the behavior alway sstarts with playing<br>
&lt;TabAtkins> flackr: we could default to that, yeah, but it' snot necessarily what you always want<br>
&lt;TabAtkins> DavidA: yeah, you might want alternate on clicking so it always inverts the playback rate<br>
&lt;TabAtkins> s/inverts/negates/<br>
&lt;ydaniv> TabAtkins:  I found most useful is that the 4 actions are use most times<br>
&lt;ydaniv> ... we should imply a lot of things<br>
&lt;ydaniv> ... being able to say what a trigger does in a specific animation phase is useful<br>
&lt;TabAtkins> flackr: i agree. i think when we define the behavior part, we define that the behavior can depend on the current animation state<br>
&lt;TabAtkins> flackr: i think "play and restart" can be different from "play but do nothing if it's already playing"<br>
&lt;TabAtkins> flackr: similarly, "play if paused, reverse if finished"<br>
&lt;TabAtkins> DavidA: the "once" behavior needs to be covered too<br>
&lt;TabAtkins> flackr: that can also be based on animation state. "play if paused, do nothing if idle"<br>
&lt;TabAtkins> DavidA: doesn't this imply some state for the trigger?<br>
&lt;TabAtkins> flackr: no<br>
&lt;TabAtkins> DavidA: say you play on click, something else pauses it, then you click again. what should happen?<br>
&lt;TabAtkins> flackr: i think all of the state should just be animation state<br>
&lt;ydaniv> TabAtkins: what would that look like?<br>
&lt;ydaniv> ... my idea is that we imply couple of behavior keywords the imply these behaviors, but specify a particular phase<br>
&lt;TabAtkins> TabAtkins: have several behavior keywords that imply behaviors in each phase, but let you also specify a single phase that you're giving a behavior to. then either the trigger() can tka emultiple phase behaviors, or multiple trigger()s can be used, one for each phase<br>
&lt;TabAtkins> flackr: that's most general, yeah. start with all-phase behaviors, then see if per-phase is needed?<br>
&lt;TabAtkins> TabAtkins: when me and david explored this, we realized a bunch of keyword variants are needed<br>
&lt;TabAtkins> TabAtkins: but i think it's okay to start with single keywords defining all four phase behaviors, and see if it explodes and needs per-phase keywords later<br>
&lt;TabAtkins> DavidA: can we return to the core issue here?<br>
&lt;TabAtkins> flackr: yeah, i think we've come to an agreement on animation-trigger behavior<br>
&lt;TabAtkins> DavidA: do we want to make sure we have syntax sapce for multiple triggers on a single animation?<br>
&lt;TabAtkins> TabAtkins: looks like flackr's syntax is just fine for that, trigger() functions space-seaprated in animation-trigger<br>
&lt;TabAtkins> flackr: bikeshedding welcome on names, but yeah<br>
&lt;TabAtkins> ydaniv: another concern, we mentioned timelines being "1d" versus events beign "0d"<br>
&lt;TabAtkins> ydaniv: do we need an issue to talk about that?<br>
&lt;TabAtkins> flackr: for 2d stuff, i put in the proposal for a view trigger, it's 2d by default<br>
&lt;TabAtkins> DavidA: i think he's saying that view-trigger is another trigger type, but pointer-trigger would be yet anohter<br>
&lt;TabAtkins> flackr: we can define that space, maybe we can combine views and pointers<br>
&lt;TabAtkins> flackr: timeline trigger is a single dimension<br>
&lt;TabAtkins> ydaniv: we can bake that in?<br>
&lt;TabAtkins> DavidA: actually, thinking about intersecting multiple timeslines to make a "2d" version. works for both view and pointer<br>
&lt;TabAtkins> ydaniv: and sometimes you want intersection, sometimes you want "either" timeline<br>
&lt;TabAtkins> flackr: for timelines, I think intersection is what matters. "either" timeline is done with multiple triggers<br>
&lt;TabAtkins> flackr: i'm not opposed to intersection of timelines. need a specific proposal, but seems reasonable.<br>
&lt;TabAtkins> proposed resolution: syntax TBD, but go with option 3, where animation-trigger takes a trigger(name, behavior) function<br>
&lt;TabAtkins> [discussion about event type]<br>
&lt;TabAtkins> flackr: for timeline, there's entering and exiting, each of those have a behavior<br>
&lt;RRSAgent> I have made the request to generate https://www.w3.org/2025/08/20-houdini-minutes.html fantasai<br>
&lt;TabAtkins> ydaniv: not quite. you ahve a view tiemline and two ranges. when you enter you apply one behavior. then you range changes, when you exit.... right, you ahve another behavior<br>
&lt;TabAtkins> flackr: for events, like trigger(--source, click play)<br>
&lt;fantasai> i/Topic: [css-animations-2] Move scroll/scribenick: TabAtkins<br>
&lt;RRSAgent> I have made the request to generate https://www.w3.org/2025/08/20-houdini-minutes.html fantasai<br>
&lt;TabAtkins> TabAtkins: ah, i thought event types were listed in event-trigger-*<br>
&lt;TabAtkins> flackr: initially, but we're moving away from that<br>
&lt;TabAtkins> TabAtkins: ok, makes sense then<br>
&lt;TabAtkins> trigger(&lt;dashed-ident>, [&lt;action> &lt;behavior>]#)<br>
&lt;TabAtkins> ydaniv: so timeline-trigger is still a set of properties, but event-trigger is just a single longhand then<br>
&lt;TabAtkins> TabAtkins: do we want to resolve on this syntax precisely?<br>
&lt;TabAtkins> flackr: yeah. we can review later<br>
&lt;TabAtkins> proposed resolution: timeline-trigger-* and event-trigger just define the source element. on the animating element, `animation-trigger: trigger()#` specifies source element, action, and behavior<br>
&lt;TabAtkins> proposed resolution: timeline-trigger-* and event-trigger just define the source element. on the animating element, `animation-trigger: trigger()#` specifies source element, action, and behavior. (`[trigger()+ ]#` for multiple triggers on a single animation<br>
&lt;TabAtkins> RESOLVED: timeline-trigger-* and event-trigger just define the source element. on the animating element, `animation-trigger: trigger()#` specifies source element, action, and behavior. (`[trigger()+ ]#` for multiple triggers on a single animation<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3206863438 using your GitHub account


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

Received on Wednesday, 20 August 2025 15:21:13 UTC