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/CADsXd2OS92qUN_m0JLCv9n4Vo8%3D25QKoYLmS-KdPcCh4jhFzNA%40mail.gmail.com.
