13:06:06 RRSAgent has joined #houdini 13:06:11 logging to https://www.w3.org/2025/08/20-houdini-irc 13:06:11 RRSAgent, make logs Public 13:06:12 please title this meeting ("meeting: ..."), astearns 13:07:20 futhark has joined #houdini 13:08:28 ydaniv has joined #houdini 13:08:35 DavidA has joined #houdini 13:08:37 present+ 13:08:40 fantasai has joined #houdini 13:08:46 andruud has joined #houdini 13:08:48 present+ 13:08:57 present+ 13:09:31 present+ 13:11:09 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12336 13:11:09 Topic: [css-animations-2] Move scroll and event animation triggers to independent namespace 13:11:09 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12336. 13:11:43 lea has joined #houdini 13:11:49 present+ 13:12:06 DavidA: we have the animation-trigger feature for controlling animations 13:12:18 DavidA: we initially wrote the spec with timelines in mind 13:12:44 DavidA: so there was a timeline range you enter to do something to the animation, and a range that you could exit to do something else 13:12:51 DavidA: so we had trigger actions attached to those ranges 13:13:14 DavidA: in expanding the trigger idea to include event based, like clicking an element and having that start an animation 13:13:33 DavidA: conceptually, there's enough diff between these two trigger types that they'd require a different set of properties 13:13:40 DavidA: so should have separate property sets 13:13:47 DavidA: that's the main proposition from this issue 13:13:58 DavidA: so there is another competing model 13:14:24 DavidA: so with separate proeprty sets we have timeline-trigger-* and event-trigger-* 13:14:42 (similar to the pattern of scroll-timeline and view-timeline) 13:14:54 DavidA: the other is that everything is an event. entering a timeline range is an event, exiting is as well 13:15:19 DavidA: the all-events model appears appealing, but we think there's some subtlely in the timeline concept that are properly reflected with just events 13:15:45 DavidA: so we think it's better to keep the property sets separate, to better capture different types of triggers 13:15:56 DavidA: it also simplifies some other aspects fo the syntax 13:16:06 DavidA: so proposal is to go with separate property sets 13:16:19 DavidA: timeline-trigger-* and event-trigger-* 13:16:29 scribe+ 13:16:39 TabAtkins: I discussed this a lot with fantasai 13:16:49 ... agree that this is the model to stick with 13:17:00 ... the seperate property sets 13:17:05 lea: is there more complete code snippets showing them? 13:17:20 DavidA: the issue is really long now, but i have an explainer 13:17:24 https://github.com/explainers-by-googlers/scroll-triggered-animations/blob/main/CSS_PROPERTIES.md#event-trigger-examples 13:17:53 q+ 13:19:04 lea: [question about explainer, tab explained it a bit] 13:19:12 lea: are the play/pause etc predefined? 13:19:14 TabAtkins: yes 13:19:27 lea: down the line could we have other things care about the triggers? 13:19:27 ydaniv: yes 13:20:04 lea: what's the scope of these triggers? 13:20:24 TabAtkins: similar to view timelines, visible to element+children by default, can be lifted up with a -scope proeprty 13:20:36 DavidA: actually we've been thinking would be better fo rthem to be global by default, with -scope limiting them instead 13:20:55 flackr: we should talk more about making things consistent 13:21:04 ydaniv: we had some back and forth in the issue 13:21:14 ydaniv: there were concerns about mixing view-related triggers with others 13:21:27 ydaniv: assuming this is a real concern so we don't want to mix things... 13:21:41 ydaniv: and that's a motivation for separating timeline triggers from the rest of the events... 13:21:52 ydaniv: then i can accept timeline triggers being separate properties 13:22:06 ydaniv: and we can always invent new events like view-enter() in the future 13:22:15 ydaniv: but this might indeed be a safer way to start, yeah 13:22:22 q? 13:22:22 ydaniv: i added a comment an hour ago in the issue 13:22:23 q+ 13:22:24 florian has joined #houdini 13:22:35 bramus has joined #houdini 13:22:39 https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3206045115 13:22:59 ydaniv: here, i suggested how to split up the properties between the elements, the api surface 13:23:04 present+ 13:23:27 ydaniv: making event-trigger a way to declare event triggers, timeline-trigger to declare timeilne triggers, then all the animation bheaviors (the action) only on animation-trigger 13:24:05 ydaniv: then animation-trigger is the name of the trigger (or an anonymous functional trigger), with some controls for changing the action or behavior 13:24:12 ydaniv: this implies an "always" starting trigger 13:24:28 ydaniv: if you don't specify another one it'll reuse the starting trigger for exit, otherwise you can specify 13:24:59 ydaniv: also, timeline triggers have two ranges, they're not allowed in the exit trigger; if you specify them in the first they ignore what's specified for end 13:25:05 ydaniv: so you avoid mixing 13:25:13 flackr: that's not exactly the concern, i can clarify 13:25:32 flackr: if viewenter and viewleave are discrete events, we can't ensure you've set them up correctly so you always get a viewleave before a new viewenter 13:25:46 flackr: if they're coming from a single timeilne trigger, we *can* ensure you get them in pairs 13:26:31 ydaniv: so it's important to ahve the same timleine, but diff ranges are okay 13:26:36 scribe+ 13:26:38 q? 13:26:42 ack ydaniv 13:27:12 TabAtkins: say you have a large interrange for the 1st one, enter it and dtriger, and then you have a smaller range in the middle. Would that imply you never trigger the middle? 13:27:35 TabAtkins: you have 2 timeline triggers, one large and one smaller nested inside it 13:27:35 … you have two ranges, a small one nested inside a larger one 13:28:18 TabAtkins: would you never trigger the inner one, since you're already in the outer? 13:28:59 flackr: no, those are indepdnent. the concern is that if you have a small enter range and a large exit, you could enter the enter range, leave it, then reenter before leaving the exit range, and pure events would fire a second enter; we want to avoid that 13:29:04 TabAtkins: makes sense 13:29:49 szager: my interpretation of ydaniv's proposal was the internal mechanism would have this infomration; the events were independent in the syntax but could still be linked to only fire in the correct order 13:30:17 szager: i think it's not correct then, to say we can't guarantee against two enters in a row. it would just be a little bit magical, maybe less intuitive to devs. 13:30:21 szager: would involve a bit of hidden state 13:30:43 szager: so my objection is this hidden bit of state would be easy to get wrong for devs, maybe confusing. better to force them to be more explicit about the ranges 13:30:55 flackr: dunno if i completely agree. for simple cases could just work. 13:31:09 flackr: but say you have an enter range on a and an exit on b, another has enter on a and exit on c... 13:31:19 szager: i see, so if you're mixing timelines... 13:31:28 flackr: there's no association fo the trigger timelines, so that's an issue 13:31:44 szager: so for mixed multi-timeline case, the event model can't guarantee consistency 13:31:53 q? 13:32:11 lea: this seems great overall 13:32:36 lea: on this specific design, have we considered having just a single event trigger and making timelines a kind of event? 13:32:59 TabAtkins: that's what we were just discussing ^_^ 13:33:21 flackr: say your animation start on a small view range, and only resets when it fully leaves the viewport 13:35:09 [explains this] 13:35:29 lea: can you have a shorthand to just set the exit range easily? 13:35:42 flackr: that's the default - if you don't specify an exit range, it matches the enter range automatically 13:35:53 szager: key thing is just that enter+exit have to be declared atomatically 13:35:59 *atomicly 13:36:14 lea: but if they're separate events, you could pass them both to the API... 13:36:25 szager: it's not functional that's th eproblem, it's that the enter+exit have to be tracked as a unit 13:37:23 lea: i could imagine using a click as a trigger to start an animation, then once it scrolls out you pause it, and when it comes back into the viewport... 13:37:28 ydaniv: that requires multiple triggers 13:37:34 ydaniv: which we're deferring 13:37:49 lea: what i'm concerned is we have some events that parallel some ui events, and timeline triggers that are a separate thing. 13:38:02 lea: are we likely to need more types of triggers? if so, do we want to add more sets of properties? 13:38:14 flackr: the reason for the separate namesapce is the properties for setting up the trigger depend on the type of trigger 13:38:24 vmpstr has joined #houdini 13:38:24 flackr: events are simple - just give the name fo the event 13:38:37 flackr: for timelines, we have to supply a bunch more, like setting up an intersection observer 13:38:50 TabAtkins: if we're adding more things then we add them as events 13:38:59 ... if they need special cases we add more properties 13:39:14 ... trying to cram all of that into a single model is not great syntactically 13:39:34 szager: coudl we talk for a moment about something from ydaniv's comment? 13:39:45 szager: specifying the actions in the animation-trigger rather than in the trigger element 13:40:07 szager: my concern here is that you have a `start exit?` which is timline-biased 13:40:13 szager: not clear ot me that an action specification like this makes sense for an event trigger 13:40:26 szager: could just say that exit is a no-op for events, but seems a little squirrelly 13:40:44 szager: so curious about what the motivation for having the action on the animation element is 13:41:14 szager: generally, the trigger element seems like the "controller" in MVC. if you were doing this in JS, you'd specify the action *in* the click handler on the trigger element, for example 13:41:21 ydaniv: a few reasons 13:41:49 ydaniv: If we want these trigger properties to be usable for other stuff later, then adding animation-related actions to those proeprties doesn't make sense 13:42:25 ydaniv: a second, say you want to name a click trigger, and you want it to play one aniamtion, reverse a different one 13:42:36 ydaniv: you'd have to declare two nearly-identical triggers 13:42:55 ydaniv: so my suggestion is that this just declares a trigger, you can use it however you want. the animation decides what to do with the event 13:43:22 szager: what about this issue of being timeline specific, with the start+exit tirggers? 13:43:40 szager: if we later wanted more options for a new type of trigger, would we have to alter this syntax? enter+exit+something else? 13:44:19 szager: looking at the third example in your comment, the exit trigger seems timeline-specific 13:44:36 ydaniv: in the case of timelines, you don't need an exit trigger. it's inherent to the timeline 13:45:09 ydaniv: but if you have an event trigger for the animation start, and you want to reverse on every click, you can just add reverse; dont' need an exit trigger 13:45:19 ydaniv: but wanted one event for starting, and another event for reversing or pausing 13:45:33 ydaniv: so in that case, start with this trigger, do the reverse/reset with another event 13:45:59 szager: a little confused aobut terminology. you said "exit", that applies just to timelines for me 13:46:09 ydaniv: exit means "end" here, start and end 13:46:09 szager: i'm confused 13:46:23 flackr: i think he just means you can specify a different event for an end trigger 13:46:41 ydaniv: so you can have click on this button to play forwards, click on another button to play backwards 13:46:46 szager: and click on a third to reset? 13:46:53 flackr: that's my concern too, there's more than two actions 13:47:03 szager: yeah, i'm concerned it'll get hairy, cramming too much into this 13:47:41 DavidA: i'm also concerned abou thow this maps to the JS api, not clear what instantiates the animation trigger 13:48:02 DavidA: right now you just have the trigger on the source element. not enough to attach the animation to it, you have to add the action as well 13:48:09 q+ 13:48:20 DavidA: becuase if you reuse the trigger you can have a different action on a different element 13:48:38 TabAtkins: my concern here is that we're currently deferring the ability to add multiple triggers 13:48:58 ... while timelines have the concept of 2 events mixed together, other events don't have them 13:49:16 ... I think we should have just one event properly and then figure out the rest 13:49:42 flackr: i think you said pretty well what i wanted to say 13:49:56 flackr: the idea of having start+stop and making triggers independent of animations... 13:50:12 flackr: the only way I can see doing that is having basically a third thing that provides the link between an event name and an action 13:50:21 flackr: it could be that this is a functional syntax in the animation-trigger syntax 13:50:31 flackr: animatino-trigger: action(--foo play) 13:50:47 flackr: and we spec that timeline triggers generate two events, events generate all the events that are possible 13:50:55 flackr: taht's the way to go about it rathe rthan specializing timelines 13:51:02 szager: terminology point 13:51:21 szager: there are "events" from UI. timelines ahve "actions" (enter/exit). we have "behaviors". 13:51:43 szager: event is a 0-dimensional UI event, action does the thing. Timeline has two actions, enter and exit, each is linked to a behavior. 13:53:10 proposed resoluition: use timeline-trigger-* and event-trigger-* separate property sets 13:53:32 RESOLVED: use timeline-trigger-* and event-trigger-* separate property sets 13:53:42 TabAtkins: do we ahve a proposed reoslution for attaching behaviors to triggers, or take it back to the issue? 13:54:09 DavidA: can we defer for the moemnt and see if we can land on a proposal? 13:54:16 flackr: yeah, think there's three ways it could potentially work 13:54:34 DavidA: i do recognize yehonatan's concerns making the triggers animation specific, making them less reusable 13:55:33 ydaniv: if we're settling now on just using a single trigger in animation-trigger, and then a behavior, we can go back to the older syntax, a keyword for the behavior and once/repeat/always/state 13:55:48 ydaniv: i think that's something that can work both for timelines and events 13:56:06 ydaniv: by default "once" 13:56:23 ydaniv: and if we ahve a timeline, it uses the two ranges 13:56:58 szager: this ocmes back to my original attempt to cast events into the timeline behaviors, we had objections to those 13:57:22 ydaniv: i just think, in all our proposals, the default action is to play 13:58:00 ydaniv: we can split things more when we add multiple triggers to an animation. but for now, you always play first, then do something else on subsequent events 13:58:36 scribe+ 13:58:56 TabAtkins: either need to allow multiple clicks in the action in some way or talk about multiple triggers on one animation so we can assign multiple behaviors to a given click 13:59:32 TabAtkins: this split of once / always state felt very confusing, defined purely about actions in the animations api rather than what the author or user saw happened 14:00:04 TabAtkins: it's possible it was just confusingly authored, but it seems more consideration needs to happen about what behavior of events are 14:00:19 TabAtkins: Lots of ways to potentially do this. The behaviors need to be TBD for a bit 14:00:45 szager: i need to head out, but i think this needs more discussion, yes 14:01:01 flackr: i think having multiple triggers isn't controversial, it's just a question of what the splitting mechanism is 14:01:02 szager has left #houdini 14:01:11 flackr: we already have comma-separated list coordinating with the naimation list 14:01:17 flackr: we need another delimiter, then 14:01:30 flackr: maybe spaces is sufficient and we coudl go with that 14:01:41 DavidA: a nice thing about animation-trigger just being the name, that's pretty easy 14:02:05 flackr: right, if anmatino-trigger is a shorthand for a bunch of values, that's very hard. but if it's just trigger, or trigger+behavior, we can probably do it pretty easily 14:02:30 DavidA: in JS, think of TimelineTrigger object 14:02:44 DavidA: if it's an object, maybe you can listen to its events 14:02:58 DavidA: that would still be something we can map somehow to be used outside of animation context 14:03:55 DavidA: even if we implicitly bake the actions into these, it woudln't stop us getting the signals 14:04:13 flackr: I think we can consider this issue resolved, and open a new issue about exactly how we associate beahviors 14:04:41 github-bot, topic https://github.com/w3c/csswg-drafts/issues/11910 14:04:42 Topic: [web-animations-2][css-animations-2] Should animation-trigger-exit-range be constrained to being greater than or equal to animation-trigger-range? 14:04:42 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11910. 14:05:09 DavidA: this came from our earlier discussion 14:05:24 DavidA: the use-cases we can think of, it's useful to have the exit range as a superset of the enter range 14:05:37 q+ 14:05:55 DavidA: it seems like it could just create unexpected beahvior if they're not matching 14:06:10 DavidA: so i propose we help authors by enforcing this 14:06:22 flackr: >= for animation ranges is hard to calculate 14:06:38 flackr: i proposed in the issue that once a trigger enters, it doesn't exit until it's out of both ranges 14:06:46 flackr: so you could specify totally separate ranges, it just wouldn't be meaningful 14:07:03 flackr: but it would mean we don't have to coerce the ranges so one is greater than the other 14:07:59 DavidA: i think my initial concern is if you were still in the entry range but now out of the exit range... that would trigger exit action 14:07:59 q+ 14:08:23 DavidA: so you have separate enter and exit ranges. 14:08:39 DavidA: you go into the entry range, you trigger the naimation, but then you're immediateyl outside the exit range 14:08:49 DavidA: but your proposal addresses that 14:08:50 ack flackr 14:09:04 flackr: yeah so if you're in either range, you haven't exited the range 14:09:30 ydaniv: one exception is, if you ahve a place where an author specified two ranges that don't overlap, you could be somewhere in the middle... 14:09:35 ydaniv: oh, you'd just be exited 14:10:06 TabAtkins: i'm fine with either a union of the ranges, or a bounding range 14:10:24 flackr: i just didn't want to ahve to compute the bounding range, especially in the computed style 14:10:40 TabAtkins: ah, i wasn't thinking of it being reflected into the style 14:10:55 flackr: as long as it's not reflected, i'm not opposed to using a bounding range 14:11:03 flackr: but i do think eitehr solves the problem 14:11:10 flackr: i have a slight preference for the simpler thing 14:12:25 TabAtkins: my problem with union is just that if the two ranges are disjoint, you effectively ignore the exit range entirely. but that's weird - in the more common case where you ranges overlap, just not perrfectly, it's indistinguishable, so that's fine. 14:12:50 proposed resolution: the "actual" exit range is the union of the specified enter and exit ranges 14:13:00 RESOLVED: the "actual" exit range is the union of the specified enter and exit ranges 14:13:24 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12581 14:13:24 Topic: [css-animations-2] animation-trigger Name Clash Resolution 14:13:24 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12581. 14:13:59 flackr: you can specify the same name ident for event-trigger and timline-trigger 14:14:21 q+ 14:14:21 DavidA: two different elements in the same scope that define the same name for a given trigger 14:14:31 DavidA: and a single element defining both an event and timeline with the same name 14:14:46 DavidA: in the first instance, i propose we follow the precedent from anchorpos of using last in tree order 14:14:47 q+ 14:15:01 DavidA: for the same element establishing both, we consider that invalid 14:15:09 flackr: you get neither working? 14:15:12 DavidA: yes 14:15:33 flackr: for the first case, this goes back to the issue about having three things now that want to have some sort of tree scoping/visibility - anchorpos, timelines, triggers 14:15:40 flackr: ideally all would ahve the same scoping semantics 14:15:52 flackr: but we have different now. anchors are globally visible, timeline are scoped to defining elements 14:15:57 flackr: both can be given an explicit scope 14:16:08 flackr: they also have different behaviors if multiple elments define the same name. 14:16:15 flackr: anchors use the last, timelines become invalid 14:16:19 flackr: so i'd love to unify these 14:16:34 flackr: don't know what exactly the behavior is, maybe the anchor model largely 14:16:54 TabAtkins: do you thin kit's possible to change timeline scope at this point? 14:17:10 flackr: i don't think it's so widely adopted it would be a compat risk 14:17:40 andruud: it's that way for a reason, we coudln't define this to "go back". if an animation depends on a timeline, and the timleine doesn't appear until later in style resolution, how do you resolve that? 14:17:55 andruud: timeline-scope creates a "placeholder" timeline that later gets attached 14:18:10 andruud: anchor instead uses interleaving, with requirements about rendering order 14:18:23 andruud: so not sure we can change how timeline works for scroll-driven animations 14:18:45 flackr: when you encounter a timeline name that hasn't been define dyet, you'd walk up to th enearest timeline scope, and implicitly create a placeholder timeline 14:18:57 flackr: and then when we find a timeline for that name, we'd re-run the lifecycle 14:19:23 andruud: hm, i'd buy that 14:19:39 q- 14:19:45 flackr: i think that creates a consistent answer for the developers 14:19:52 ydaniv: this is basically an implicit timeline-scope:all on the root 14:20:32 flackr: so do we support timeline-scope:all? 14:20:32 bramus: no, not yet 14:20:38 ydaniv: haven't specced it, just resolved to add it 14:20:50 flackr: okay, well timeline-scope:all basically requires all the machinery we'd need here alreayd 14:20:58 flackr: i suspect the compat risk is low, we can measure 14:22:51 proposed resolution: change timeline scoping to be global by default (like anchor names), and have triggers do the same 14:23:07 bramus: concern is apple is currently implementing SDA, and they're not in the room 14:23:40 bramus: just making sure Anders is fine with this, he was first to implement this 14:23:44 andruud: it's fine 14:23:54 andruud: do we need an equivalent "placeholder" for timeline triggers? 14:24:05 flackr: because the trigger... not sure, maybe 14:24:20 andruud: the act of the trigger appearing could cause the animation to immeidatley play and ahve an effect that frame, so we need something 14:24:32 flackr: yeah. i think it's doable 14:24:59 TabAtkins: objections to the proposed reoslution? 14:25:12 RESOLVED: change timeline scoping to be global by default (like anchor names), and have triggers do the same 14:25:35 TabAtkins: and someone needs to be sure to let the Apple devs doing SDA know about it. 14:25:41 ydaniv: firefox also has it behidn a flag 14:27:10 TabAtkins: returning to the main issue - if multiple elements define the same trigger name, do we use the last in tree order (matching anchor) as David suggested, or make them all invalid (matching timeline)? 14:27:21 flackr: For anchor, was there an affirmative reason? 14:27:31 TabAtkins: yes, there use-cases for having multiple elments with the same anchor name, and taking the last 14:27:58 flackr: yeah, i think we make the timeline decision just for simplicity. use-cases for multiple anchors witht eh same name probably apply similarly here, so i'd like to match. 14:28:22 TabAtkins: do we want to try and change the timeline clash behavior as well, to match? 14:28:51 flackr: i'd like to. there's some complexity; right now we just maintain a count, and it's used if there's only one. we'd now track them all and use the last. 14:29:22 TabAtkins: Yeah, i see how it's technically very similar. 14:30:08 flackr: partial loading is an issue. if youre document is partially loading, you might start using one timeline, then have to switch to another when more of the document loads in 14:30:15 flackr: we alreayd have a mechanism for changing the timeline for an animation 14:31:20 TabAtkins: so proposed resolution from flackr is to change timeline clash resolution to use last in tree order 14:31:26 ydaniv: i'm okay if there's no compat issue 14:31:36 flackr: seems even less liekly to be a problem, since it's an error case today 14:32:09 RESOLVED: change timeline clash resolution to use last in tree order 14:33:19 bramus: so timeline-scope changes to match anchor-scope, limiting the scope of a timeline? 14:33:26 flackr: yes, the cucrrent behavior no longe rmakes sense 14:33:57 TabAtkins: so back to the original issue, when multiple elements declare the same trigger name, david suggests using last in tree order. 14:34:01 TabAtkins: any objections? 14:34:23 RESOLVED: When multiple elements declare clashing trigger names, the last in tree order wins (matching anchorpos and now timelines) 14:35:30 TabAtkins: for same element, multiple timelines or events with the same name 14:35:56 flackr: we already have this issue in view and scorll timelines, their names are in the same namespace. 14:36:04 DavidA: I think I found that scroll timelines win 14:36:07 TabAtkins: is this specified? 14:36:13 anders: yes; flackr: no 14:36:28 andruud: it was discussed, using scroll timelines was intentional at the time 14:36:30 https://drafts.csswg.org/scroll-animations-1/#timeline-scoping 14:36:32 flackr: ah it is specced 14:36:50 "In case of a name conflict on the same element, names declared later in the naming property (scroll-timeline-name, view-timeline-name) take precedence, and scroll progress timelines take precedence over view progress timelines." 14:37:10 flackr: so i'm not opposed to arbitrarily defining a similar precedence order 14:37:16 flackr: not sure why we decided it this way, tho 14:37:28 DavidA: i think i just considered it invalid and wanted a simple answer 14:37:41 DavidA: if we ahve more triggers, we'll have to define mroe precedence 14:38:01 flackr: i dont' think that's hard. just want consistency 14:38:09 DavidA: i also dont' think we'll have more types of triggers, tbh 14:38:21 DavidA: so my rec in that case is to prefer timeline triggers, they feel a little more specific 14:38:43 flackr: i might go more arbitrary, scroll is alphabetically before view, maybe we match and have event preferred over timeline 14:38:51 flackr: this is an edge case, don't need a strong reason 14:39:39 proposed resolution: if a name is multiple in one property, last wins; if a name is defined by both event and timeline, event wins (because it's alphabetically earlier) 14:40:01 RESOLVED: if a name is multiple in one property, last wins; if a name is defined by both event and timeline, event wins (because it's alphabetically earlier) 14:40:44 github-bot, end topic 14:41:12 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12611 14:41:12 Topic: [web-animations-2][css-animations-2] Set of actions for animation triggers 14:41:12 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12611. 14:41:43 flackr: we've set up our triggers such that a named trigger has some set of associated actions 14:41:51 flackr: UI events, or enter/exit for timelines 14:42:04 flackr: there are, i think, 3 ways to associate them with an animation behavior 14:42:17 flackr: 1) in trigger definition, specify this action has this behavior 14:43:02 flackr: 2) like ydaniv proposed, on the animating element you specify the behavior, and there's something about exit behaviors 14:43:18 flackr: the only way i can make this make sense is that the exit has another behavior in the animation-trigger proeprty 14:43:39 flackr: 3) an explicit syntax, maybe functional, in animation-trigger that links a trigger name to an animation behavior 14:43:46 flackr: i think third is most generic and conceptually simple 14:43:53 flackr: it leave sit so triggers don't mention animations 14:44:01 flackr: and we can do more stuff with triggers in the futre 14:44:49 ydaniv: in option 2 i allowed 2 triggers, was continuing the line tab and elika took 14:44:56 futhark has left #houdini 14:45:04 ydaniv: but if we go back to just allowing one trigger, you spec the trigger you want and the behavior 14:45:15 ydaniv: the old pattern of once/repeat/alternate/state 14:45:54 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 14:46:17 DavidA: what's maybe not great here is we have to reinterpret bheavior in the event trigger context 14:46:44 flackr: i know stefan has concerns about this as well. option 3 shouldn't be contentious, it's extensible. triggersa re just event sources 14:47:04 DavidA: we'll have to modify the JS interface, so trigger.addAnimation(), you'll also specify the behavior 14:47:13 flackr: yeah, we can modify idl to match once we decide on css 14:47:28 ydaniv: making sure i get this right 14:47:42 ydaniv: with event triggers, you don't ahve behavior of start/end 14:47:50 s/behavior/action/ 14:48:04 ydaniv: so for now we only allow events to play forwards 14:48:23 ydaniv: in option 3 we add a function that ties an event to an action, like play or reverse 14:48:27 animation-trigger: trigger(--trigger-name, , behavior) 14:48:39 ydaniv: so how do you specify clicking to start and pause or wahtever 14:49:02 flackr: you add two triggers, and we specify that animation-trigger can do multiple triggers 14:49:20 animation-trigger: trigger(--timeline-trigger, enter, play) trigger(--timeline-trigger, exit, pause) 14:49:26 DavidA: i was interpreting option 3 as, if you want multiple event associations, you don't need more than on even ttrigger 14:50:30 flackr: does this example make sense? 14:50:57 ydaniv: but the behavior alway sstarts with playing 14:51:08 flackr: we could default to that, yeah, but it' snot necessarily what you always want 14:51:22 DavidA: yeah, you might want alternate on clicking so it always inverts the playback rate 14:51:29 s/inverts/negates/ 14:51:55 TabAtkins: I found most useful is that the 4 actions are use most times 14:52:03 ... we should imply a lot of things 14:52:18 ... being able to say what a trigger does in a specific animation phase is useful 14:52:41 flackr: i agree. i think when we define the behavior part, we define that the behavior can depend on the current animation state 14:53:17 flackr: i think "play and restart" can be different from "play but do nothing if it's already playing" 14:53:24 flackr: similarly, "play if paused, reverse if finished" 14:53:45 DavidA: the "once" behavior needs to be covered too 14:54:02 flackr: that can also be based on animation state. "play if paused, do nothing if idle" 14:54:20 DavidA: doesn't this imply some state for the trigger? 14:54:23 flackr: no 14:54:37 DavidA: say you play on click, something else pauses it, then you click again. what should happen? 14:54:43 flackr: i think all of the state should just be animation state 14:55:01 TabAtkins: what would that look like? 14:55:27 ... my idea is that we imply couple of behavior keywords the imply these behaviors, but specify a particular phase 14:56:20 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 14:57:43 flackr: that's most general, yeah. start with all-phase behaviors, then see if per-phase is needed? 14:58:24 TabAtkins: when me and david explored this, we realized a bunch of keyword variants are needed 14:58:57 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 14:59:04 DavidA: can we return to the core issue here? 14:59:20 flackr: yeah, i think we've come to an agreement on animation-trigger behavior 14:59:52 DavidA: do we want to make sure we have syntax sapce for multiple triggers on a single animation? 15:00:05 TabAtkins: looks like flackr's syntax is just fine for that, trigger() functions space-seaprated in animation-trigger 15:00:16 flackr: bikeshedding welcome on names, but yeah 15:00:40 ydaniv: another concern, we mentioned timelines being "1d" versus events beign "0d" 15:00:45 ydaniv: do we need an issue to talk about that? 15:01:32 flackr: for 2d stuff, i put in the proposal for a view trigger, it's 2d by default 15:01:50 DavidA: i think he's saying that view-trigger is another trigger type, but pointer-trigger would be yet anohter 15:02:09 flackr: we can define that space, maybe we can combine views and pointers 15:02:15 flackr: timeline trigger is a single dimension 15:02:19 ydaniv: we can bake that in? 15:02:57 DavidA: actually, thinking about intersecting multiple timeslines to make a "2d" version. works for both view and pointer 15:03:09 ydaniv: and sometimes you want intersection, sometimes you want "either" timeline 15:03:47 flackr: for timelines, I think intersection is what matters. "either" timeline is done with multiple triggers 15:03:59 flackr: i'm not opposed to intersection of timelines. need a specific proposal, but seems reasonable. 15:05:20 proposed resolution: syntax TBD, but go with option 3, where animation-trigger takes a trigger(name, behavior) function 15:06:34 [discussion about event type] 15:06:49 flackr: for timeline, there's entering and exiting, each of those have a behavior 15:06:58 I have made the request to generate https://www.w3.org/2025/08/20-houdini-minutes.html fantasai 15:07:29 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 15:08:21 flackr: for events, like trigger(--source, click play) 15:08:34 i/Topic: [css-animations-2] Move scroll/scribenick: TabAtkins 15:08:40 I have made the request to generate https://www.w3.org/2025/08/20-houdini-minutes.html fantasai 15:08:54 TabAtkins: ah, i thought event types were listed in event-trigger-* 15:08:59 flackr: initially, but we're moving away from that 15:09:04 TabAtkins: ok, makes sense then 15:09:36 trigger(, [ ]#) 15:10:07 ydaniv: so timeline-trigger is still a set of properties, but event-trigger is just a single longhand then 15:11:04