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/CAG0MU3j%2BFboFs2Yh7kE_%3Dx3Qzb%2BwckNCh7xsqybNNU5X-0OdEQ%40mail.gmail.com.
