Intent to Ship: allow more pseudo-elements and pseudo-classes after ::part()

[David Baron]

Contact emails

dba...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-shadow-parts-1/#part

Summary

CSS selectors that use the ::part() pseudo-element are allowed to have other CSS pseudo-elements (except ::part()) and many types of other CSS pseudo-classes after them. (Combinators are still not allowed after :part(), and pseudo-classes that depend on tree structure are not allowed.) Previously Chrome only allowed a limited set of pseudo-classes and pseudo-elements after ::part(). This changes to allowing all of the pseudo-classes and pseudo-elements that should be allowed. It means selectors such as ::part(part-name):enabled and ::part(part-name)::marker are now allowed.

Blink component

Blink>CSS

Motivation

This allows CSS selector features to be combined in ways that were intended during the design of the ::part() feature. It allows more styling of things that web components expose as parts. This change also provides a more solid foundation for building future CSS pseudo-elements (currently known as "part-like pseudo-elements") on top of the ::part() feature. This includes new pseudo-elements such as ::details-content and new pseudo-elements for styling customizable <select>.

TAG review

Original TAG review for the feature was https://github.com/w3ctag/design-reviews/issues/230

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/css-shadow-parts/pseudo-classes-after-part.html https://wpt.fyi/results/css/css-shadow-parts/pseudo-elements-after-part.html

Flag name on chrome://flags

None

Finch feature name

CSSPartAllowsMoreSelectorsAfter

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/40623497 and https://issues.chromium.org/40825557

Estimated milestones

Shipping on desktop	130
Shipping on Android	130
Shipping on WebView	130

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.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5195333643272192?gate=5140576434126848

Links to previous Intent discussions

Intent to Prototype (for a larger feature that this is a part of): https://groups.google.com/a/chromium.org/g/blink-dev/c/Q1OX6ZA_aaE/m/ALwkAOfHAwAJ

This intent message was generated by Chrome Platform Status and edited by hand.

[Domenic Denicola]

On Thursday, August 29, 2024 at 12:48:36 AM UTC+9 David Baron wrote:

Contact emailsdba...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-shadow-parts-1/#part

Summary

CSS selectors that use the ::part() pseudo-element are allowed to have other CSS pseudo-elements (except ::part()) and many types of other CSS pseudo-classes after them. (Combinators are still not allowed after :part(), and pseudo-classes that depend on tree structure are not allowed.) Previously Chrome only allowed a limited set of pseudo-classes and pseudo-elements after ::part(). This changes to allowing all of the pseudo-classes and pseudo-elements that should be allowed. It means selectors such as ::part(part-name):enabled and ::part(part-name)::marker are now allowed.

Blink componentBlink>CSS

Motivation

This allows CSS selector features to be combined in ways that were intended during the design of the ::part() feature. It allows more styling of things that web components expose as parts. This change also provides a more solid foundation for building future CSS pseudo-elements (currently known as "part-like pseudo-elements") on top of the ::part() feature. This includes new pseudo-elements such as ::details-content and new pseudo-elements for styling customizable <select>.

TAG reviewOriginal TAG review for the feature was https://github.com/w3ctag/design-reviews/issues/230

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Low risk.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests?Yes

https://wpt.fyi/results/css/css-shadow-parts/pseudo-classes-after-part.html https://wpt.fyi/results/css/css-shadow-parts/pseudo-elements-after-part.html

Flag name on chrome://flagsNone

Finch feature nameCSSPartAllowsMoreSelectorsAfter

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/40623497 and https://issues.chromium.org/40825557

Estimated milestonesShipping on desktop130Shipping on Android130Shipping on WebView130

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?

 

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5195333643272192?gate=5140576434126848

Links to previous Intent discussionsIntent to Prototype (for a larger feature that this is a part of): https://groups.google.com/a/chromium.org/g/blink-dev/c/Q1OX6ZA_aaE/m/ALwkAOfHAwAJ

[David Baron]

• The remaining work in w3c/csswg-drafts#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 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 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.  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 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 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 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 shows that this decision agrees with the implementation of those pseudo-elements in progress in WebKit.
• w3c/csswg-drafts#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

[Domenic Denicola]

Thank you so much for those detailed writeups. LGTM1; it's clear this is future-extensible and you've carefully considered the tradeoffs.

[Alex Russell]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

--
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+...@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.