LGTM3
/Daniel
On 2024-09-11 17:39, Alex Russell wrote:
LGTM2
On Wednesday, September 4, 2024 at 7:39:25 PM UTC-7 Domenic Denicola
wrote:
Thank you so much for those detailed writeups. LGTM1; it's clear
this is future-extensible and you've carefully considered the
tradeoffs.
On Wed, Sep 4, 2024 at 11:30 PM David Baron <dba...@chromium.org>
wrote:
On Tue, Sep 3, 2024 at 11:00 PM Domenic Denicola
<dome...@chromium.org> wrote:
On Thursday, August 29, 2024 at 12:48:36 AM UTC+9 David
Baron wrote:
Anticipated spec changes
Open questions about a feature may be a source of
future web compat or interop issues. Please list open
issues (e.g. links to known github issues in the
project for the feature specification) whose
resolution may introduce web compat/interop risk
(e.g., changing to naming or structure of the API in a
non-backward-compatible way).
There are related open discussions in:
https://github.com/w3c/csswg-drafts/issues/10083
<https://github.com/w3c/csswg-drafts/issues/10083>
https://github.com/w3c/csswg-drafts/issues/10786
<https://github.com/w3c/csswg-drafts/issues/10786>
https://github.com/w3c/csswg-drafts/issues/10787
<https://github.com/w3c/csswg-drafts/issues/10787>
https://github.com/w3c/csswg-drafts/issues/10788
<https://github.com/w3c/csswg-drafts/issues/10788>
https://github.com/w3c/csswg-drafts/issues/10794
<https://github.com/w3c/csswg-drafts/issues/10794>
but I don't think any of these discussions justify
delaying shipping these changes. We can follow up with
future changes to reflect future spec resolutions.
I really appreciate the transparency in you finding and
listing all of these issues.
I tried to read through several of them but they're
relatively long, and in some cases, progress has been made
but not enough to fully close the issue.
Would you be able to give us a one- or two-sentence
summary for each of them, indicating what potential
breaking changes might come out of such discussions, and
why you think it'll be easy to fast-follow with such
future changes?
* The remaining work in w3c/csswg-drafts#10083
<https://github.com/w3c/csswg-drafts/issues/10083> is
about getting spec text written to reflect things that
we've already resolved regarding part-like
pseudo-elements. This affects the new part-like
pseudo-elements concept and not ::part() itself, although
it includes the interaction between the two. So it
doesn't affect anything that's currently shipping or
proposed to ship here.
* w3c/csswg-drafts#10786 <http://w3c/csswg-drafts#10786> is
about a disagreement between the spec (one one side) and
the implementations in Chromium, Gecko, and WebKit (all on
the other side). The implementations treat "disallowed"
as being invalid at parse time, whereas the spec says the
pseudo-classes and pseudo-elements that are disallowed
after part are valid at parse-time but never match. The
change proposed here is about increasing the set of things
that are allowed, so it reduces the space where the
disagreement that this issue covers applies. This change
could be made separately if we decide not to change the
spec (and thus need to change all implementations), though
the compat risk of making such a change does increase with
time.
* w3c/csswg-drafts#10787
<https://github.com/w3c/csswg-drafts/issues/10787> is
about the fact that the spec's wording on which
pseudo-classes are allowed after ::part() isn't specific
enough for all implementors to make the same (allowed vs.
disallowed) decisions for every pseudo-class. While we
should definitely make the spec better, the test results
<https://wpt.fyi/results/css/css-shadow-parts/pseudo-classes-after-part.html?label=master&label=experimental>
show that implementations now (with the changes I'm
proposing to ship) largely agree (many of the differences
there are about which pseudo-classes are implemented at
all), and this change is a clear improvement in interop
relative to the same test results on stable
<https://wpt.fyi/results/css/css-shadow-parts/pseudo-classes-after-part.html?label=stable&label=master>.
I think the substantive difference remaining is probably
whether :has() is allowed, and I'm comfortable defending
the position that :has() is clearly disallowed by the
spec's wording that disallows "pseudo-classes that match
based on tree information rather than local element
information". (Leaving :has() disallowed for now is also
a bias in favor of less change.)
* w3c/csswg-drafts#10788
<https://github.com/w3c/csswg-drafts/issues/10788> is
about whether the & nesting selector is allowed after
::part(). (I couldn't find any spec text that defines
this one way or the other.) I haven't changed this as
part of these changes, but the spec should be clear, and
we can change this later if needed. It currently doesn't
work in any of Chromium, Gecko, or WebKit.
* w3c/csswg-drafts#10794
<https://github.com/w3c/csswg-drafts/issues/10794> is
another issue that applies to the future work on part-like
pseudo-elements rather than this change. We need to audit
all the existing pseudo-elements to make sure their
definitions categorize them correctly.
* w3c/csswg-drafts#10806
<https://github.com/w3c/csswg-drafts/issues/10806> was
asking whether it made sense to allow view-transition
pseudo-elements after ::part(), or whether they should
have an exception to the "all pseudo-elements are allowed
after ::part()" rule. The consensus in the discussion
seemed to be that no further exception was warranted, so I
included the view transition pseudo-elements in these
changes, per the current spec. The test
<https://wpt.fyi/results/css/css-shadow-parts/pseudo-elements-after-part.html?label=experimental&label=master>
shows that this decision agrees with the implementation of
those pseudo-elements in progress in WebKit.
* w3c/csswg-drafts#10807
<https://github.com/w3c/csswg-drafts/issues/10807> was
asking whether ::slotted() is allowed after ::part(). In
this case the spec is clear that it is allowed (since all
pseudo-elements other than ::part() itself are allowed).
However, it's hard to implement, probably has weak or
nonexistent use cases, and existing implementations don't
do it properly (Gecko treats it as invalid, WebKit allows
it syntactically but it doesn't work). Pending the
resolution of this issue, I left ::slotted() as disallowed
in Chrome. (This means I knowingly left one case where
we're still not following the spec, by leaving the current
behavior rather than changing it as part of this intent.)
However, if the conclusion in that discussion is that it
is worth implementing, we could allow it later and
implement the underlying behavior. Doing so may well be
more work than the changes here.
-David
--
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 on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9c5c47a-d2c6-452a-836c-040c42cf68e9n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9c5c47a-d2c6-452a-836c-040c42cf68e9n%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 on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7afe855-bddc-41ad-915b-8ffd9f896191%40gmail.com.
