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?
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.
