- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 10 Sep 2025 17:01:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[web-animations-2][css-animations-2] animation-trigger CSS syntax`. <details><summary>The full IRC log of that discussion</summary> <fantasai> DavidA: At the F2F, we discussed the syntax for animation-trigger, and we came up with a trigger() function<br> <fantasai> DavidA: accepts name of the trigger, triggering action/event, and the behavior triggered<br> <fantasai> DavidA: But some concerns about expressing the action there<br> <fantasai> DavidA: what we came up with was rather than having 3 parameters, we make the event or action optional, and then you only have to specify the name of the trigger and the resulting behavior<br> <fantasai> DavidA: one of the changes is, previous proposal used high-level names, apart from name of trigger oculd give a set of names local to that trigger<br> <fantasai> DavidA: which the animation-trigger can refer to<br> <fantasai> DavidA: Dropping that high-level name as well<br> <fantasai> DavidA: When you omit the event from the trigger function parameter, then the behavior specified is associated with all the actions or events that were specified on the trigger<br> <fantasai> DavidA: So, proposal we look to get on today is makign that event parameter optional<br> <fantasai> DavidA: Some more recent comments on issue<br> <fantasai> DavidA: wrt specifying events on the user of the trigger<br> <fantasai> DavidA: I think this change goes a little bit more in that direction, because it makes the event optional<br> <fantasai> DavidA: Author can define event on the trigger and just associate with the target<br> <fantasai> DavidA: exception to that is, with exit action or event of the timeline trigger<br> <fantasai> DavidA: which is main difference between an event trigger and a timeline trigger<br> <fantasai> DavidA: we think that treating that exit action as part of special case is good, reflects how timeline triggers are different from event triggers<br> <ydaniv> q+<br> <astearns> ack fantasai<br> <noamr> fantasai: I agree, making the event optional helps us go in that direction<br> <noamr> fantasai: the timeline trigger and event triggers have more similarities than we think<br> <noamr> fantasai: a timeline has a concept of entering/exiting. some DOM events have the same pairing, like key/mouse/focus<br> <noamr> fantasai: in/out relationship between a bunch of event pairs<br> <noamr> fantasai: "it starts animating when hovering and stops animating when no longer hovering"<br> <noamr> fantasai: this should be very similar to timeline triggers.<br> <noamr> fantasai: no objection to making events optional but concerns about overall design<br> <fantasai> DavidA: You still get ease of expressing that in this case<br> <fantasai> DavidA: Let's say for a mouse over vs mouse out<br> <fantasai> DavidA: You would simpy be able to define two triggers on a source element, and name one of them --mouse-over and the other --mouse-out<br> <fantasai> DavidA: and on the target you would specify the behavior by binding --mouse-over and --mouse-out to start and end animations<br> <fantasai> DavidA: Making a comparison to you and Tab's original proposal, you specify roughly the same thing<br> <fantasai> DavidA: We wouldn't assume that because you specify mouse out also do something on mouse over<br> <fantasai> DavidA: So I think we're still making it as easy to describe that case, but without forcing a start and end concept on event triggers<br> <fantasai> DavidA: that fundamentally applies to timeline triggers, but not necessarily to event triggers<br> <astearns> ack ydaniv<br> <fantasai> ydaniv: I agree with fantasai that timeline trigger is something important, and usage should be trivial and important to solve<br> <fantasai> ydaniv: specifically view timelines<br> <fantasai> ydaniv: something that we don't want to overcomplicate, and make it trivial to get right<br> <fantasai> ydaniv: I had some concerns in the issue about event triggers but also timeline triggers<br> <fantasai> ydaniv: I also don't understand why we expose enter and exit there, and have 3 arguments for timeline triggers and 2 for event triggers<br> <fantasai> ydaniv: seems like something to reoslve before we agree on it<br> <fantasai> ydaniv: I had another proposal<br> <fantasai> [tries to find it]<br> <fantasai> ydaniv: Something proposed before by flackr, that we use something like event-trigger function and timeline-trigger function, instead of generic trigger function<br> <fantasai> ydaniv: then each can have its own arguments<br> <fantasai> ydaniv: I had some suggestions about event trigger<br> <fantasai> ydaniv: first of all, event-trigger should only take name and list of events<br> <fantasai> ydaniv: what fantasai says, that some of them are paired, like pointer enter and leave<br> <fantasai> ydaniv: we should probably somehow generalize that into either higher-level events or generalize the usage inside the trigger somehow<br> <fantasai> ydaniv: regarding timeline triggers, I suggested also using only two arguments so that you only reference a name and give it a behavior<br> <fantasai> ydaniv: if you want exit behavior, separate with a slash<br> <fantasai> ydaniv: I didn't see any specific comment about whether this is something acceptable or not<br> <fantasai> ydaniv: but I do want to make it easier than exposing enter and exit, where you can specify something that doens't make any sense<br> <fantasai> ydaniv: enter-pause, and exit-reset, I don't think there's any use case for it<br> <flackr> I don't think that we should actively try to avoid allowing specifying things that don't make sense, we should prefer to keep the model as simple as possible<br> <fantasai> DavidA: Having event-trigger and timeline-trigger have different number of args ... we're trying to keep the syntax the same<br> <fantasai> DavidA: You just write the name of the trigger and the behavior<br> <ydaniv> my proposal: https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3228775877<br> <fantasai> DavidA: In the exit case, yo uhave to specify exit events<br> <fantasai> DavidA: that's an opposite of enter, that's a weird thing about timeline triggers<br> <fantasai> DavidA: whereas for events, they are each independent conceptually<br> <fantasai> DavidA: One thing about a trigger function now, instead of event-specific or timeline-specific<br> <fantasai> DavidA: we can always add a more specific trigger function<br> <fantasai> DavidA: having trigger() doesn't prevent that<br> <flackr> q+<br> <fantasai> ydaniv: I agree it doesn't prevent it, but I think if we do have a single generic function, it should be done right.<br> <fantasai> ydaniv: current proposal, I see stuff that is a bit funky to me<br> <fantasai> DavidA: other point, this thing about pairing behaviors that don't make sense<br> <fantasai> DavidA: you wouldn't have an incentive to do it<br> <fantasai> DavidA: you can always write nonsensical things in JS<br> <fantasai> DavidA: I don't see that as a drawback of this proposal<br> <fantasai> DavidA: Even writing something like enter pause, exit reset<br> <fantasai> DavidA: Maybe one of the things in Tab and fantasai's original proposal, mixing timeline and event triggers<br> <fantasai> DavidA: that's one thing we get from this<br> <fantasai> DavidA: with behaviors we want to specify, not every combination makes sense<br> <fantasai> DavidA: but not incentivized to combine random things<br> <astearns> ack flackr<br> <fantasai> flackr: Listning to this discussion, one idea was maybe both event triggers and timeline triggers could have concept of entering and exiting<br> <fantasai> flackr: so animation syntax would always have enter and exit action<br> <fantasai> flackr: event triggers that only specify enter actions never remain active, so they can trigger multiple times<br> <fantasai> flackr: I should probalby write this up more formally, but that might help these two things look the same<br> <fantasai> +1 flackr<br> <ydaniv> to flackr, that could work, we had such tries before<br> <fantasai> astearns: Is it possible tresolve to make the action parameter optional?<br> <fantasai> flackr: I think we're still bikeshedding the whole thing :)<br> <fantasai> astearns: ok, let's take back to the issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3275768732 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 September 2025 17:01:25 UTC