I'm not convinced this is a huge footgun. Yes, it's a convenience value that allows auto matching in MPA where there is no other way to automatically match without changes to the dom (for a custom attribute). Doing these modification is not far from just giving unique names to view-transition-name, albeit with less typing.
Is it perfect? No. I suspect that the dynamic id case that Jake gave in conjunction with auto naming is the only problematic case in that the transition won't match to what the author may want (although it's also wrong to say it isn't what they want -- it's something of which they have to be cognizant). I agree with Noam that the discrepancy in Interop is likely cause more confusion in these cases. I'm not using Interop as justification for shipping this, but only pointing out that IMHO the problem with auto is not as severe as described in this thread. As for the next steps, I'm fine with continuing the discussion with TAG. With respect to CSSWG, my sense is that the discussion in this thread won't sway the decision. I'd like to understand what decision we would make here if TAG agrees with Jake's concern. Again to reiterate, the concern is valid, but is the risk of this developer confusion great enough to prevent us from adding this feature? Thanks, Vlad On Tue, Mar 25, 2025, 7:37 a.m. Jake Archibald <jaffathec...@gmail.com> wrote: > I've summarised the issues with this proposal in the TAG thread > <https://github.com/w3ctag/design-reviews/issues/1001#issuecomment-2750966335> > . > > On Tue, 25 Mar 2025 at 10:44, Noam Rosenthal <nrosent...@chromium.org> > wrote: > >> >>> >>> *Until this feature (correct me if I'm wrong), adding a unique ID to an >>> element was safe. With this feature, that's no longer the case.* >>> >>> >>> This seems like a worthwhile question to bring back to the TAG and/or >>> the CSSWG. Looking at the TAG review, it doesn't seem like it was discussed. >>> >> >> Happy to take this back to TAG, but would defer to Vlad for next steps. >> Not counting on this leading to anything actionable though as Apple were >> very adamant about keeping things as is in the last few discussions about >> this, >> following the CSSWG process that things can stay in the spec unless there >> is a consensus to remove them. >> >> This should 100% *not* be the reasoning for shipping a feature we think >>> is bad. >>> >> >> If API owners think that this is "bad" then we definitely shouldn't ship >> it, or ship only match-element which everyone seems to agree on. >> I would describe this as "not ideal" and that keeping interop on this is >> the lesser evil. >> >> >>> Are we seeing real-life interop pressure? How many sites are already >>> using `auto`? What's the user experience in Chromium for ones that do? >>> >> >> It's not an existing backwards compat issue. But we'd be introducing a >> slight inconsistency from the get go which IMO is arguably worse than >> shipping the whole thing. >> As a web developer I'd probably end up being confused by this whole thing >> if Webkit and chromium end up shipping something slightly different with a >> lack of consensus attached to it. >> >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NQKc%2Bh_JK4sDxYKN0YDLJbff8qL1facbxZipvsYw0v2Q%40mail.gmail.com.
