Re: [w3c/webcomponents] Allowing CSS combinators postfixed to the ::slotted() selector (#889)

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

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. It says "combinators postfixed to the ::slotted() selector", and then I am describing what I believe is intuitive for it to do. Any better title idea?

> 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".

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. Also 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**_.

@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 https://github.com/w3c/webcomponents/issues/745#issuecomment-668922849.

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.

That sort of thought is like saying "multi-pass WebGL rendering is slower than single-pass rendering, so we should throw out multi-pass APIs". But multi-pass rendering can be very useful _when the performance implications fit within given constraints_.

We should give web developers useful selectors, and then explain to them that they should avoid re-running these selectors repeatedly; and that if they need to then it is perfectly fine if it fits within performance requirements for the application.

I feel that we're prematurely optimizing here.

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 be bad (if it were supported, but it isn't):

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

####  while the following may be _**perfectly fine**_ and never ever cause any performance issue for its use case:

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

requestAnimationFrame(function loop(t) {
  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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/889#issuecomment-668931088