Allowing CSS combinators postfixed to the ::slotted() or :host selectors

[trusktr]

Borrowing some ideas from #883, I think it would be great to allow combinators after ::slotted(whatever), for example ::slotted(.foo) .bar > .lorem + ip-sum. Similarly, the previous selector would be effectively the same as :host > .foo .bar > .lorem + ip-sum for styling purposes, but :host also does not allow combinators to be appended to it.

Here's a live example showing that it currently doesn't work:

https://stackoverflow.com/questions/62842418

On the same token, being able to use these selectors in querySelector and querySelectorAll would be very convenient.

Here's a live example that shows that querySelector('::slotted(.foo)') doesn't work despite being a valid selector, and also showing that postfixed combinators throw an error:

https://codepen.io/trusktr/pen/d4a45f1efc9eccc0fdb20164566bada4?editors=1010

Having these features as expansions on the current spec would allow what the OP in #883 asks for: it would make it very easy to style the input tree that a custom element end user provides.

There are currently complicated ways to achieve this (see comments below).

[trusktr]

For those reading email, sorry, I submitted the thread early without any content, and edited the original post.

[castastrophe]

What does the ::slotted syntax add that the querySelector("[slot].foo") would not cover? Slotted content is light DOM so you shouldn't need to run that query inside shadowRoot.

[calebdwilliams]

Wouldn’t querySelector('::slotted(.foo)') give away that a shadow DOM exists (even in a case where the shadow root is closed)? It seems to me like host.querySelector('.foo') should suffice from a DOM API perspective although I agree the CSS selector from within a shadow root would be a nice addition if the performance worked out.

[trusktr]

@castastrophe Thanks for that question! It's not quite what I'm asking about though.

The `::slotted` selector runs within a shadow root context (f.e. in a shadow root `querySelector`, or in a shadow root's `<style>` element), but this is already expected behavior. More details (click here to expand)...

const root = this.attachShadow(...) // 'this' is a custom element

root.innerHTML = html`
  <style>::slotted(.foo) { ... }</style>
  <slot></slot>
`

The ::slotted(.foo) selector in this example is in fact still an implementation detail encapsulated inside the (custom element's) shadow root.

The [slot].foo selector does a similar thing, but does it from the outside of the custom element (i.e. outside of the shadow root), so it is a tool used on the outside of a custom element's internal shadow tree by an end user of the custom element.

The custom element itself could in fact run this code internally: this.querySelector('[slot].foo'), but the style of the shadow root actually can't contain such a selector as it would not select anything. For example, this won't work on the inside of a custom element:

this.attachShadow(...).innerHTML = `
  <style>[slot].foo { ... }</style>
  <slot></slot>
`

because it will not select nodes from the light tree that have been "slotted" into the shadow root; instead it will select nodes that are within the shadow root's own DOM that have a slot="" attribute (and in that example there aren't any).

In other words, calling this.querySelector('[slot].foo .bar') on a custom element selects any elements in the light tree with a slot attribute even if they are not actually slotted.

So inside of a custom element's implementation (in its shadow root), the ::slotted(.foo) selector is useful for selecting actually-slotted elements from the light tree, which is something that only the custom element (its shadow root) would care about (otherwise, as @calebdwilliams mentioned, the user would be aware of the shadow root's existence if they could run that selector on the custom element instead of on the custom element's (possibly closed and invisible) shadow root).

END DETAILS

Anywho, all of the aforementioned is already an existing concept.

The main ask of the OP is to be able to take a selector like ::slotted(.foo) (which already works, within a shadow root) and to be able to append combinators to it. For example ::slotted(.foo) .bar or ::slotted(.foo) > .bar.

As an example, try running the following in your console (tested in Chrome).

What you'll notice is that the square will be colored deeppink, but the expected result is for the square to be cyan.

The reason is because the ::slotted(.foo) selector is working fine, but the ::slotted(.foo) .bar selector doesn't do anything (unlike what we may expect).

class MyEl extends HTMLElement {
	connectedCallback() {
		const root = this.attachShadow({mode: 'open'})
		root.innerHTML = /*html*/ `
			<style>
				:host { display: block; }
				
				/* This works. */
				::slotted(.foo) {
					background: deeppink;
				}

				/* This does not work. */
				::slotted(.foo) .bar {
					background: cyan;
				}
			</style>
			<slot></slot>
		`
	}
}

customElements.define('my-el', MyEl)

document.body.insertAdjacentHTML(
	'beforeend',
	/*html*/ `
	<my-el>
		<div class="foo">
			<div>
				<div class="bar"></div>
			</div>
		</div>
	</my-el>

	<style>
		my-el {}
		.foo {
			width: 50px;
			height: 50px;
		}
		.foo div {
			width: 100%;
			height: 100%;
		}
	</style>
`,
)

Expected result:

Actual result:

Live demo

[castastrophe]

Ah, thank you for the code example. This is not really about the ::slotted selectors then. This is about the fact that a web component cannot style or access any descendent greater than a direct child, top-level nodes inside slotted content. Your .bar class is nested, which is why ::slotted cannot influence it. https://developers.google.com/web/fundamentals/web-components/shadowdom#slots

[castastrophe]

That is not to say that is not a valuable conversation to have - whether or not a component should be able to style more than just top-level nodes inside a slot - but I do think it's a different topic than the title and description here imply.

[castastrophe]

I wanted to share this codepen that plays around with a few different ways you can use slotted selectors and pseudo elements: https://codepen.io/castastrophee/pen/OJMKeKa

[Danny-Engelman]

That is not to say that is not a valuable conversation to have - whether or not a component should be able to style more than just top-level nodes inside a slot

Continue the conversation with its full history, that started 5 years ago, and resulted in V1 ::slotted only taking a simple selector,
because ::content and <content> in V0 (allowed for complex selectors, never implemented in FireFox & Safari) did not perform.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/content (deprecated)

( 2015 #331 ) "::slotted" pseudo elements
( 2018 #745 ) ::slotted() should full support complex selector!!

The main take away from 5 years of W3C standards discussions is:

I am not the one to disagree with a Components Lead Developer

[castastrophe]

Thank you for the links. I am aware of the current spec. Five years is a long time in tech and specs are not immutable. As efficiency is improved, new options may be available. I also was not implying the conversation should be_started_, but pointing out on this thread that it's a different conversation than this one.

[bathos]

FWIW, if complex slotted light dom selectors were permitted, I'd expect the selector in the examples above to be ::slotted(.foo .bar), not ::slotted(.foo) .bar. The latter seems to describe a slotted light dom element ".foo" with a descendent shadow element ".bar". Since that scenario can't seemingly occur, the problem might not be obvious ... but switch to just about any other combinator and you get a scenario that can occur (e.g. ::slotted(.foo) + .bar - "style the shadow .bar when preceded by a slot with an assignee matching .foo").

AFAIK, selectors like this are also not currently permitted, but I'm unsure if that's a matter of deliberate design or not; they still seem to adhere to query-direct-assignees-only.

Edit:

Thinking about this further, I guess + ... also would never match, given the slot itself is "in the way" - the assignee is not a sibling. So perhaps this distinction doesn't matter, at least so long as CSS continues to have no "backwards" selectors.

[Danny-Engelman]

If you want to track selectors (in this case :host-context) about to be removed from the spec also read:

w3c/csswg-drafts#1914

[trusktr]

but I do think it's a different topic than the title and description here imply.

@castastrophe Did you mean the title I chose doesn't match what I proposed in the OP? If so, in my mind I think it matches because it says "combinators postfixed to the ::slotted() selector", and then I am describing what I believe would be intuitive for that to do.

[trusktr]

FWIW, if complex slotted light dom selectors were permitted, I'd expect the selector in the examples above to be ::slotted(.foo .bar), not ::slotted(.foo) .bar. The latter seems to describe a slotted light dom element ".foo" with a descendent shadow element ".bar".

@bathos That is not intuitive because it is impossible. Why would someone be thinking that, when it doesn't exist?

That's like if I said .foo > .bar should select any .foo elements that have greater amount of text content than the .bar element with largest amount of text. But I'd be making things up at that point.

I think a better interpretation is this:

• ::slotted(.foo .bar) represents an element in the light tree that matches .foo .bar in the light tree (it is a descendant of a .foo element anywhere in that light tree). I think that's intuitive.
• ::slotted(.foo) .bar represents the .bar element that happens to be a descendant of a slotted .foo element. This is also intuitive.

I guess + ... also would never match,

If we think intuitively about this, then: a selector like ::slotted(.foo) + .bar would style a .bar element that happens to be the "adjacent sibling" of a .foo element where the .foo element is a slotted element. This is intuitive.

Note that the .bar element could very well be distributed to an entirely different slot (but still have the styling specified for that selector). That makes intuitive sense and could be totally useful.

[trusktr]

@Danny-Engelman, @hayatoito's comment you screenshotted shows no performance metrics. I am not a browser developer, but I very much doubt (I could be wrong) that ::slotted(.foo) .bar could really be so slow that it matters for the vast majority of use cases.

I wrote a comment about that at #745 (comment).

What I mean is, there's plenty of ways to make really slow selectors in regular DOM, without any shadow DOM even existing. We should not throw out an idea based on a single thought that said it would be slow without any viable data.

What if I said "multi-pass WebGL rendering is slower than single-pass rendering, so we should throw out multi-pass APIs".

But in fact, multi-pass rendering can be very useful when the performance implications fit within given constraints.

It would be great to give web developers useful selectors, and then explain to them that they should avoid re-running these selectors repeatedly; but that it is fine if the cost fits within performance requirements for the application.

I feel that we're prematurely optimizing here. However I know that the web APIs can't be reversed (though I've been imagining how to do that without breaking the web).

Every single DOM API that exists can technically be slooow if we examine it within the context of a particular use case that happens to be the worst use case where we'd never want to perform the given action in the way it is performed.

The following would not be ideal (if selectors like ::slotted(.foo) .bar were supported) unless the use case still fits withing some given performance requirements:

connectedCallback() {
  requestAnimationFrame(function loop(t) {
    this.shadowRoot.querySelector('::slotted(.foo) .bar + .baz').style.transform = `rotateY(${10 * Math.sin(t * 0.001)}deg)`
    requestAnimationFrame(loop)
  })
}

The following may be much better (if the selector were supported) for a use case in which the functionality works as intended:

connectedCallback() {
  const el = this.shadowRoot.querySelector('::slotted(.foo) .bar + .baz')

  requestAnimationFrame(function loop(t) {
    // does not re-run the selector every time:
    el.style.transform = `rotateY(${10 * Math.sin(t * 0.001)}deg)`
    requestAnimationFrame(loop)
  })
}

---

@hayatoito (and @emilio from the other thread) Can you please expand on the performance issues, and provide useful metrics that we can reference here?