It's unconvincing re: deprecation risk that Apple has decided in the short run that they don't want to unship to deliver a better feature (without the benefits of developer-oriented quality protections that our process provides). We should always be trying to answer the question "*does this solve an important problem well?"*
If Safari has to take some first-mover disadvantage in this case for doing a bad job, so be it. Best, Alex On Tuesday, March 25, 2025 at 8:30:22 PM UTC-7 Vladimir Levin wrote: > On Tue, Mar 25, 2025 at 1:52 PM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 3/25/25 1:39 PM, Yoav Weiss (@Shopify) wrote: >> >> 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. >> >> In my experience, there's always a non-zero specificity foot gun risk for >> non-trivial sites, depending on how your CSS is written (or more likely, >> legacy of CSS you inherited). It sucks when you run into it, but I don't >> think this change is novel in that sense. >> >> 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? >> >> Currently in Blink, use of auto would have no effect as it is a reserved > keyword (in `view-transition-name`) and would not act as a custom ident. > > With respect to fallbacks: > In the MPA cases, `view-transition-name` matching, without `auto`, can > only happen by idents. To avoid the need to code unique names in CSS, the > developer can write something along the lines of `view-transition-name: > attr(id type(<custom-ident>))` or `view-transition-name: attr(data-vtn > type(<custom-ident>))` as Jake suggested. Of course, if they choose `id` as > the attribute to mirror, it would be exactly the same as saying `auto` with > all the same concerns for multiple developers stepping on each others' toes. > > In SPA cases, I imagine `match-element` suffices, unless the author > explicitly wants the `auto` behaviour of prioritizing `id` and falling back > to `match-element`, in which case they can write something like > `view-transition-name: attr(id type(<custom-ident>), match-element)`. The > latter may be a valid case for situations in which DOM is recycled > > Thanks, > Vlad > >> >> >> >>> >>> 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/54fc599d-3e1a-4d0b-88c5-4a2db9f93410%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54fc599d-3e1a-4d0b-88c5-4a2db9f93410%40chromium.org?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/2440bb50-7fb4-480f-9022-460bebed2a62n%40chromium.org.
