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/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/d9c5c47a-d2c6-452a-836c-040c42cf68e9n%40chromium.org.
