Re: [WICG/webcomponents] Allowing CSS combinators postfixed to the ::slotted() or :host selectors (#889)

Ah, ok. I see what you did, which I missed before.

It is a very bad solution because it totally obliterates the end user's tree (removes it from their DOM, and places it into an internal shadow root). This has several critical issues:

- The end user's styling no longer applies
  - for example, when the end user writes the custom element in the top level Document, and adds top-level styling in the document, this styling will not style the elements as they were expecting, because the elements have been moved into a shadow root.
- The end user will have a _very false sense of what the tree structure is_. They will have errors like this:
  ```js
  const el = document.querySelector('component-with-slots').children[0] // it is undefined, but it should be an `<h1>`
  el.style.foo = 'bar' // runtime error!!!
  ```
- The code is very cryptic. It is very difficult to understand what is happening.
- This all leads to highly un-maintainable code, both for the end user, and for custom element authors.
- More resource usage: two shadow roots per custom element, and extra CPU usage moving nodes every time one of the custom elements is created.

I would suggest for anyone reading this, **_never ever write code that way_**. That is simply not an acceptable solution because the downsides highly outweigh any benefits.

@Danny-Engelman Unless there is some solution we've missed, you shown why clearly we need a solution, so as to avoid complicated and highly undesirable workarounds.

The most acceptable solution that I can think of right now is, to implement scoped styling:
  - Instead of creating an extra layer of shadow root,
  - write a special style handler in the custom element that attaches certain styles to the custom element's nearest root node (either a Document, or a ShadowRoot).
  - In those styles, style the desired elements using scoped styles (for example with UUIDs or similar) so that the style affect only the particular element.
  - This would require setting a unique attribute (or similar) on the custom element, for example `<component-with-slots data-style-id="12345">`
  - The style processing mechanism inside the custom element could convert a selector like `:outside span` to `component-with-slots[data-style-id="12345"] span`
  - Or better yet, to semi-polyfill the concept of this issue's OP, it could convert `::slotted() span` or `:host > * span` to `component-with-slots[data-style-id="12345"] > * span`.
    - Note, I was hoping `:host > * foo` would essentially be a working alternative for `::slotted() foo`, but `:host` also does not accept combinators after it. I will reflect this in the title.
  
This would be _much_ less invasive to the end user's API contract (the end user's input (light tree nodes and attributes) should ideally be left in-tact and undisturbed, because that is theirs to manipulate).

There is no simple solution to this, as far as I can tell so far.

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