- From: Lea Verou via GitHub <noreply@w3.org>
- Date: Thu, 23 Oct 2025 20:51:32 +0000
- To: public-css-archive@w3.org
I just had an idea about how this could be exposed: we already _have_ a concept of an exposed shadow tree: open shadow roots! It's just that currently, they are all-or-nothing, so in practice most userland components use open shadow trees and most built-in ones use closed shadow trees. **But what if instead of a binary, it was a continuum? What if every shadow root included both an open and a closed version and you could designate a subset of your closed shadow tree to be exposed as an open shadow tree and vice versa?** So in such a future, whether a shadow tree is declared as `open` or `closed` would only affect what the default is, i.e. whether elements need to be opted in or out. Then, both primitives become useful to both parties: userland components can choose to omit certain elements (or even parts of elements, e.g. certain attributes) from the open tree, and built-in elements can opt-in certain elements to become part of their open shadow tree. There are so many benefits to this approach: - No need for the cornucopia of parts that we see in today’s components or the numerous pseudo-elements that we need to add to make built-ins stylable — just a regular tree, with relationships that can be targeted - a combinator to style elements in open shadow roots can be back on the table, because component authors can *define* what that can target - Existing primitives _just work_. `element.shadowRoot` would contain the exposed tree (and `null` if there is none). The full tree can still be accessed by using the return value of `attachShadow()`. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10939#issuecomment-3439115852 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 October 2025 20:51:33 UTC