- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 20 Aug 2025 14:40:47 +0000
- To: public-css-archive@w3.org
The Houdini Task Force just discussed `[css-animations-2] animation-trigger Name Clash Resolution`, and agreed to the following: * `RESOLVED: change timeline scoping to be global by default (like anchor names), and have triggers do the same` * `RESOLVED: change timeline clash resolution to use last in tree order` * `RESOLVED: When multiple elements declare clashing trigger names, the last in tree order wins (matching anchorpos and now timelines)` * `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)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: you can specify the same name ident for event-trigger and timline-trigger<br> <flackr> q+<br> <TabAtkins> DavidA: two different elements in the same scope that define the same name for a given trigger<br> <TabAtkins> DavidA: and a single element defining both an event and timeline with the same name<br> <TabAtkins> DavidA: in the first instance, i propose we follow the precedent from anchorpos of using last in tree order<br> <andruud> q+<br> <TabAtkins> DavidA: for the same element establishing both, we consider that invalid<br> <TabAtkins> flackr: you get neither working?<br> <TabAtkins> DavidA: yes<br> <TabAtkins> 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<br> <TabAtkins> flackr: ideally all would ahve the same scoping semantics<br> <TabAtkins> flackr: but we have different now. anchors are globally visible, timeline are scoped to defining elements<br> <TabAtkins> flackr: both can be given an explicit scope<br> <TabAtkins> flackr: they also have different behaviors if multiple elments define the same name.<br> <TabAtkins> flackr: anchors use the last, timelines become invalid<br> <TabAtkins> flackr: so i'd love to unify these<br> <TabAtkins> flackr: don't know what exactly the behavior is, maybe the anchor model largely<br> <TabAtkins> TabAtkins: do you thin kit's possible to change timeline scope at this point?<br> <TabAtkins> flackr: i don't think it's so widely adopted it would be a compat risk<br> <TabAtkins> 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?<br> <TabAtkins> andruud: timeline-scope creates a "placeholder" timeline that later gets attached<br> <TabAtkins> andruud: anchor instead uses interleaving, with requirements about rendering order<br> <TabAtkins> andruud: so not sure we can change how timeline works for scroll-driven animations<br> <TabAtkins> 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<br> <TabAtkins> flackr: and then when we find a timeline for that name, we'd re-run the lifecycle<br> <TabAtkins> andruud: hm, i'd buy that<br> <andruud> q-<br> <TabAtkins> flackr: i think that creates a consistent answer for the developers<br> <TabAtkins> ydaniv: this is basically an implicit timeline-scope:all on the root<br> <TabAtkins> flackr: so do we support timeline-scope:all?<br> <TabAtkins> bramus: no, not yet<br> <TabAtkins> ydaniv: haven't specced it, just resolved to add it<br> <TabAtkins> flackr: okay, well timeline-scope:all basically requires all the machinery we'd need here alreayd<br> <TabAtkins> flackr: i suspect the compat risk is low, we can measure<br> <TabAtkins> proposed resolution: change timeline scoping to be global by default (like anchor names), and have triggers do the same<br> <TabAtkins> bramus: concern is apple is currently implementing SDA, and they're not in the room<br> <TabAtkins> bramus: just making sure Anders is fine with this, he was first to implement this<br> <TabAtkins> andruud: it's fine<br> <TabAtkins> andruud: do we need an equivalent "placeholder" for timeline triggers?<br> <TabAtkins> flackr: because the trigger... not sure, maybe<br> <TabAtkins> andruud: the act of the trigger appearing could cause the animation to immeidatley play and ahve an effect that frame, so we need something<br> <TabAtkins> flackr: yeah. i think it's doable<br> <TabAtkins> TabAtkins: objections to the proposed reoslution?<br> <TabAtkins> RESOLVED: change timeline scoping to be global by default (like anchor names), and have triggers do the same<br> <TabAtkins> TabAtkins: and someone needs to be sure to let the Apple devs doing SDA know about it.<br> <TabAtkins> ydaniv: firefox also has it behidn a flag<br> <TabAtkins> 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)?<br> <TabAtkins> flackr: For anchor, was there an affirmative reason?<br> <TabAtkins> TabAtkins: yes, there use-cases for having multiple elments with the same anchor name, and taking the last<br> <TabAtkins> 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.<br> <TabAtkins> TabAtkins: do we want to try and change the timeline clash behavior as well, to match?<br> <TabAtkins> 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.<br> <TabAtkins> TabAtkins: Yeah, i see how it's technically very similar.<br> <TabAtkins> 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<br> <TabAtkins> flackr: we alreayd have a mechanism for changing the timeline for an animation<br> <TabAtkins> TabAtkins: so proposed resolution from flackr is to change timeline clash resolution to use last in tree order<br> <TabAtkins> ydaniv: i'm okay if there's no compat issue<br> <TabAtkins> flackr: seems even less liekly to be a problem, since it's an error case today<br> <TabAtkins> RESOLVED: change timeline clash resolution to use last in tree order<br> <TabAtkins> bramus: so timeline-scope changes to match anchor-scope, limiting the scope of a timeline?<br> <TabAtkins> flackr: yes, the cucrrent behavior no longe rmakes sense<br> <TabAtkins> TabAtkins: so back to the original issue, when multiple elements declare the same trigger name, david suggests using last in tree order.<br> <TabAtkins> TabAtkins: any objections?<br> <TabAtkins> RESOLVED: When multiple elements declare clashing trigger names, the last in tree order wins (matching anchorpos and now timelines)<br> <TabAtkins> TabAtkins: for same element, multiple timelines or events with the same name<br> <TabAtkins> flackr: we already have this issue in view and scorll timelines, their names are in the same namespace.<br> <TabAtkins> DavidA: I think I found that scroll timelines win<br> <TabAtkins> TabAtkins: is this specified?<br> <TabAtkins> anders: yes; flackr: no<br> <TabAtkins> andruud: it was discussed, using scroll timelines was intentional at the time<br> <flackr> https://drafts.csswg.org/scroll-animations-1/#timeline-scoping<br> <TabAtkins> flackr: ah it is specced<br> <flackr> "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."<br> <TabAtkins> flackr: so i'm not opposed to arbitrarily defining a similar precedence order<br> <TabAtkins> flackr: not sure why we decided it this way, tho<br> <TabAtkins> DavidA: i think i just considered it invalid and wanted a simple answer<br> <TabAtkins> DavidA: if we ahve more triggers, we'll have to define mroe precedence<br> <TabAtkins> flackr: i dont' think that's hard. just want consistency<br> <TabAtkins> DavidA: i also dont' think we'll have more types of triggers, tbh<br> <TabAtkins> DavidA: so my rec in that case is to prefer timeline triggers, they feel a little more specific<br> <TabAtkins> flackr: i might go more arbitrary, scroll is alphabetically before view, maybe we match and have event preferred over timeline<br> <TabAtkins> flackr: this is an edge case, don't need a strong reason<br> <TabAtkins> 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)<br> <TabAtkins> 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)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12581#issuecomment-3206707173 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 14:40:48 UTC