Note that we've agreed to separate this intent into two separate intents for `match-element` (https://groups.google.com/a/chromium.org/g/blink-dev/c/o3JcMI6dGdY/m/bg3z-WX3BwAJ) and `auto` (https://groups.google.com/a/chromium.org/g/blink-dev/c/KCizytrJUMA/m/dqg_mEX4BwAJ). This intent is deprecated by the other two.
Thanks, Vlad On Wednesday, March 26, 2025 at 11:03:00 AM UTC-4 Alex Russell wrote: > 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/ab326baa-bd49-46c7-b18c-58b64dba3770n%40chromium.org.
