On Tue, Mar 25, 2025 at 10:37 AM Vladimir Levin <vmp...@chromium.org> wrote:
> 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? > I don't think the risk here is developer confusion. The risk is that adding a unique ID attribute becomes an unsafe operation. That would mean that e.g. CMSes that have multiple actors contributing code to the page (e.g. the developer, the theme and plugins) would now need to police/prevent all actors from using `view-transition-name: auto` because some combinations of code would result in weird and hard to figure-out bugs. That seems like a fundamental shift, which I'd argue we need to make only if we have very good reasons to go that path. On the front of interop risk of not shipping this - what happens today if developers are using `auto`? Do we expect them to feature detect it? And if so, what do we expect them to do in the fallback case? > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NQKc%2Bh_JK4sDxYKN0YDLJbff8qL1facbxZipvsYw0v2Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOmohSJxHZ8pkxEyjY7j%2BoS7fUONEpMZe6qfm%3D7B8fAB9MEL1Q%40mail.gmail.com.
