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/10786 >> https://github.com/w3c/csswg-drafts/issues/10787 >> https://github.com/w3c/csswg-drafts/issues/10788 >> 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 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/CAM0wra8U%2B00fYhnfPoZO%3Du66Cmz1yGiZAkTW2Pt3VONMYP%3Dzpg%40mail.gmail.com.
