- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 16:48:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] [scoped] When we encounter a tag collision, which transition is skipped?`, and agreed to the following: * `RESOLVED: if you try to start a scoped transition inside an outer transition, it will skip` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: similar to previous issue, one element can't be in two transitions at once<br> <TabAtkins> vmpstr: we can still get tag collisions<br> <TabAtkins> vmpstr: so if you run a transition on an element .foo, and you start a new transition in its subtree<br> <TabAtkins> vmpstr: because eyou're in that scope, you do discover names that could be used in the outer transition<br> <TabAtkins> vmpstr: we proposed disallow this by skipping one of the transitions<br> <TabAtkins> vmpstr: then figure out which transition<br> <TabAtkins> vmpstr: we propose skipping inner transition here, which goes against "latest wins" general rule<br> <TabAtkins> vmpstr: want to skip inner because visually it's smaller on the screen, so outer transition seems "more important" to complete<br> <ntim> q+<br> <TabAtkins> astearns: think it makes some sense<br> <astearns> ack ntim<br> <TabAtkins> ntim: I think "first wins" would be most straightforward to impl and easiest to implement<br> <TabAtkins> ntim: the second one would fail because names were involved in previous<br> <TabAtkins> ntim: where "outermost" seems less predictable, depending on order being done<br> <TabAtkins> vmpstr: to be clear, due to previous resolution, "first wins" and "outer wins" are equivalent<br> <TabAtkins> vmpstr: if you're already running an inner transition and you start an outer, there's no conflict, the names are already scoped<br> <TabAtkins> ntim: ok<br> <TabAtkins> vmpstr: just to be clear this is opposite order to running two transitions on the same element. latter one wins there<br> <TabAtkins> TabAtkins: makes sense, in both cases it's what's probably most important to the user<br> <TabAtkins> ntim: think i don't feel too strongly, just want to rely on order sVT is called<br> <TabAtkins> ntim: rather than place in the tree<br> <TabAtkins> emilio: the only thing that matters here is where it is in the tree tho<br> <TabAtkins> emilio: like if they were in separate subtrees they'd both work<br> <TabAtkins> ntim: if you invert the calls, you'd get a different result<br> <TabAtkins> TabAtkins: right, if the inner starts first, it claims names then shields its subtree, so the outer can start and both run. if the outer starts first, it claims all the names, then the inner tries to start but its names are already claimed and it aborts<br> <fantasai> scribe+<br> <fantasai> TabAtkins: if you try to start a scoped transition inside an outer transition, it will abort<br> <fantasai> vmpstr: Returns a skipped transition<br> <fantasai> ntim: start outer transition after the inner one starts?<br> <TabAtkins> ntim: if you start an outer transition second, what happens?<br> <TabAtkins> TabAtkins: it runs, it just doesn't animate the alreayd-running inner element<br> <ntim> wfm<br> <TabAtkins> RESOLVED: if you try to start a scoped transition inside an outer transition, it will skip<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12323#issuecomment-4179134311 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 16:48:25 UTC