[css-shadow-parts] Make `::slotted()` a combinator

[LeaVerou]

Currently ::slotted() is a functional pseudo-element, which causes no end of problems:

1. No way to get slotted elements with querySelector() or any of the other DOM APIs that take selectors (querySelectorAll(), closest(), `matches(), etc)
2. No ability to target descendants (see also)
3. No ability to target siblings
4. No ability to target pseudo-elements
5. No way to detect slots that have content (with a combinator this is simply :has(/slotted/ *)
6. No specificity for styling (making it a combinator won't outright solve this, but gives us a way around the web compat issues)

The intended way of going from one element to another based on their relationship in the DOM is combinators. That's why combinators exist. Even introducing a combinator that is just as restricted in syntax as the pseudo-element (minus the restrictions that are inherent to it being a pseudo-element) fixes many of these problems, and paves the way for relaxing the restrictions even further down the line.

Sure, it is a wart to have a combinator with a restricted syntax, but it's only one wart (and possibly even a temporary one) which allows us to solve numerous others.

Sure, all of these can be special-cased for ::slotted(), but that adds cognitive overhead for authors and complicates implementations in a way that is (a) perpetual (special casing needs to persist forever) and (b) unbounded — these special cases will only keep increasing.

Yes, we can't get rid of ::slotted() for the foreseeable future, even if we add this, but at least we can stop special casing stuff around it, and just direct authors to /slotted/. And who knows, maybe even down the line usage could drop below the axing threshold.

Other notes:

• Making it a pseudo-class is not an option, as discussed in [scoping] Consider making :slotted(...) a pseudo class #7305 . However, unless @fantasai and I are missing something, it should be possible to make it a combinator (/slotted/), which would address all of the above.
• ::part() has similar issues, but is not equally trivial to turn into a combinator because that would give the outside world access to too much of the shadow subtree, but ::slotted() refers to the light DOM so doesn't have these problems.

[Westbrook]

All of those targeting options sound AMAZING! 😍

When you say "make it a combinator", what does that really mean? Is that a syntax change? Is that an interpreter change? Something else?

If this is an interpreter change, is there room to as part of this investigation to look into ways that we might alter the specificity of a ::slotted() selector? By default, it is very low, which leads to usage of the !imporant flag when attempting to "require" certain visual delivery of slotted content. Being able to manage this more explicitly via the selector in some way would prevent needing to use !imporant across a myriad of rules.

If this allows for targeting descendants, is there any benefit to investigating the inclusion of :host in this conversation as well? It also refers to the light DOM, and while we've recently seen Safari add support for the :has() selector to it, there are many other concepts that could be productive added to it (e.g. :host-context equivalent selection) that would be looked on quite favorably by the community.

One other ::slotted()-centric question that I've seen recently is the quest for :has(::slotted(*)). Any change these two ideas vibe together?

[LeaVerou]

All of those targeting options sound AMAZING! 😍

When you say "make it a combinator", what does that really mean? Is that a syntax change? Is that an interpreter change? Something else?

Combinators are things like >, +, ~ etc. They are used to target elements based on their relationships.

If this is an interpreter change, is there room to as part of this investigation to look into ways that we might alter the specificity of a ::slotted() selector? By default, it is very low, which leads to usage of the !imporant flag when attempting to "require" certain visual delivery of slotted content. Being able to manage this more explicitly via the selector in some way would prevent needing to use !imporant across a myriad of rules.

The problem is not that its specificity is low, but that it operates on an entirely different level of the cascade. @mirisuzanne, @fantasai and I were discussing how to address this just the other day, but it's orthogonal to this. If you have any pointers to discussions about this problem (besides the issue I linked to above) they would be useful.

If this allows for targeting descendants, is there any benefit to investigating the inclusion of :host in this conversation as well? It also refers to the light DOM, and while we've recently seen Safari add support for the :has() selector to it, there are many other concepts that could be productive added to it (e.g. :host-context equivalent selection) that would be looked on quite favorably by the community.

This is also a separate issue, but any pointers you may have are useful, so we can open a new issue to discuss it!

PS: I merged your two consecutive comments, hence the deleted comment notice below 😊

[EisenbergEffect]

Yes, please. A thousands times yes.

[Westbrook]

Sorry for not being more clear here:

Combinators are things like >, +, ~ etc. They are used to target elements based on their relationships.

Does that mean we would alter the interpretation of ::slotted() or pair it with something that altered the syntax of :host ::slotted(input) to (pretend use %) :host % input? I'm looking to see what you're thinking regarding the size of the delta here: plug-n-play, additive, breaking, etc.

I'll hunt down related issues/content on those other points, as I know they've been brought up in other contexts, I just can find them just this minute.

[bennypowers]

This would solve so many problems our design systems team has come across. I could list 5 reports just from the last week!

[LeaVerou]

Does that mean we would alter the interpretation of ::slotted() or pair it with something that altered the syntax of :host ::slotted(input) to (pretend use %) :host % input? I'm looking to see what you're thinking regarding the size of the delta here: plug-n-play, additive, breaking, etc.

Not sure I fully understand your question, but we can certainly not remove ::slotted() (yet) or alter its interpretation as that would cause compat issues, this would be an addition. If once the combinator is well established, ::slotted() usage drops below a certain theshold, maybe we could remove it then.

Btw no need to use a placeholder symbol, for something like this I don't think more ascii art is appropriate, something like /slotted/ is fine.

One small downside of a combinator is that you need to target the element the combinator operates on, i.e. the slot element, which makes for somewhat awkward syntax e.g. slot /slotted/ input or just * /slotted/ input instead of ::slotted(input).

This would solve so many problems our design systems team has come across. I could list 5 reports just from the last week!

Please do!

[bennypowers]

A major issue we're running into is lightdom (i.e. app-level) css interfering with our component styles.

There are some cases where we can ::slotted(thing) { what: ever !important; } but we can't at all do that with nested content. So we have to choose between flexible components or effective distribution, a choice which is liable to produce neither outcome.

We're offering workarounds with our lightdom stylesheets, but we'd prefer not to have those at all, and just do everything in shadow DOM, which would be easier to use, more performant, and more maintainable.

Maybe @heyMP would like to elaborate

[LeaVerou]

A major issue we're running into is lightdom (i.e. app-level) css interfering with our component styles.

I see. So, making ::slotted() a combinator wouldn't directly help with that (the problem is that shadow DOM styles operate on a different level of the cascade), though it would make it easier to address it, since with this approach at least you're targeting the element in question directly, and not through another element. I do plan to file a separate issue for this, so more info and use cases is certainly welcome.

[bennypowers]

yes, exactly. it would remove the need for more-error-prone lightdom stylesheets, and given a later proposal to somehow bump the priority of ::slotted, would allow us to write-once-run-everywhere at greater scale and pace.

[heyMP]

As mentioned above, the low specificity of ::slotted() causes us a lot of pain. Any CSS reset file wipes out our styles which forces us to use !important everywhere.

Other than that, the ability to have complex selectors will go a long way. We could eliminate the requirement of having to load a lightdom.css file just to target elements in an unordered list. 😀

[romainmenke]

Is there overlap with #7346 ?

[LeaVerou]

Is there overlap with #7346 ?

Yes, but the ability to add combinators after ::slotted() would only solve some of the issues with it, not all.