Re: [csswg-drafts] [css-view-transitions-2] Revisit the behavior of skipping the view transition when there are duplicate names (#13438)

The CSS Working Group just discussed `[css-view-transitions-2] Revisit the behavior of skipping the view transition when there are duplicate names`, and agreed to the following:

* `RESOLVED: when dupe VT names, that particular name doesn't transition, but the rest does`
* `RESOLVED: note recommending a console warning`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> vmpstr: when we run a VT, there are several conditions we check that can result in an error, which abort the transition<br>
&lt;TabAtkins> vmpstr: this particular issue isa bout dupe VT names<br>
&lt;TabAtkins> vmpstr: so when we discover two or more elements with the same name, transition is invalid and skipped<br>
&lt;TabAtkins> vmpstr: we'd like to loosen the restriction<br>
&lt;TabAtkins> vmpstr: some options to do<br>
&lt;TabAtkins> vmpstr: like picking the first VT name we find, or the last<br>
&lt;TabAtkins> vmpstr: or just removing the dupe participants and running the rest<br>
&lt;ntim> q+<br>
&lt;TabAtkins> vmpstr: no strong pref from me, Emilio seems to like the first, others suggest last is more consistent with css<br>
&lt;astearns> ack ntim<br>
&lt;TabAtkins> ntim: what's the motivation for loosening?<br>
&lt;TabAtkins> vmpstr: first note that I think we should also still issue a console warning<br>
&lt;TabAtkins> vmpstr: motivation is it' sless jarring for the user to still run the transition rather than nothing and get an instant state change<br>
&lt;TabAtkins> vmpstr: I think the error is kinda nice because eit forces the mistake to be obvious<br>
&lt;TabAtkins> astearns: I like running at least the things that aren't duped, on the principle of doing all that we can understand and just dropping what doesn't make sense<br>
&lt;emilio> q+<br>
&lt;TabAtkins> astearns: dont' have much preference on dropping dupes vs picking one or the other<br>
&lt;TabAtkins> qa+<br>
&lt;TabAtkins> q+<br>
&lt;TabAtkins> emilio: my pref is pretty weak, I'd be okay with any of these<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: I think keeping the first is slightly less impl work<br>
&lt;emilio> TabAtkins: echoing what astearns said, when we have some confidence that what we can do is still going to make sense we still try to do it<br>
&lt;emilio> ... don't have a very strong opinion here<br>
&lt;emilio> ... if there's any conclusion about which one is best great, but the three feels pretty arbitrary<br>
&lt;emilio> ... given that there's still value in making the author look at the mistake it might be better to just drop that element altogether<br>
&lt;TabAtkins> astearns: also sounds simplest to impl<br>
&lt;fantasai> +1 to TabAtkins<br>
&lt;emilio> wfm<br>
&lt;TabAtkins> vmpstr: sounds good<br>
&lt;TabAtkins> astearns: proposed resolution, when dupe VT names, that particular name doesn't transition, but the rest does<br>
&lt;TabAtkins> emilio: I guess we need to be a bit careful to make sure we don't trigger a transition if nothing is left...<br>
&lt;TabAtkins> vmpstr: we have rules for handling that<br>
&lt;TabAtkins> RESOLVED: when dupe VT names, that particular name doesn't transition, but the rest does<br>
&lt;TabAtkins> ntim: should we resolve on console warning?<br>
&lt;TabAtkins> TabAtkins: that's browser UI, we don't specify that<br>
&lt;TabAtkins> astearns: would you be ok with a note?<br>
&lt;TabAtkins> TabAtkins: oh yeah that's fine<br>
&lt;TabAtkins> astearns: proposed note recommending a console warning<br>
&lt;TabAtkins> RESOLVED: note recommending a console warning<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13438#issuecomment-4179042941 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:31:30 UTC