Re: [WICG/webcomponents] "open-stylable" Shadow Roots (#909)

**Problem Summary Attempt**

There are a number of specific use cases which seem mostly to boil down to (1) Shadow DOM is needed for its ability to isolate DOM and provide composition, but (2) more styling flexibility is desired than it provides by default.

The desirable flexibility is potentially all of the capabilities of CSS, but there are some concrete use cases:
* apply a legacy stylesheet to a shadowRoot you didn't create
* override styling defaults in a shadowRoot you didn't create
* overriding need to style something not otherwise exposed in a shadowRoot you didn't create
* provide components that are not opinionated about styling
* provide components with a richer CSS API than is possible with `:part(...)` or custom propertiers, e.g. to allow using combinators.

**Solution Requirements**

* provide the desired styling flexibility outlined above
* decoupled from custom elements, since Shadow DOM doesn't require custom elements
* decoupled from Javascript, since Shadow DOM now has a fully declarative format
* primarily configured via CSS, since this is the lingua franca for styling
* configurable via shadowRoot options to allow shadow root authors ultimate control
* and similarly also configurable via declarative shadowRoot options (decoupled from script)

**Proposal**

This builds on the ideas described by [Brian](https://github.com/bkardell/half-light) and [Chris](https://frontendmasters.com/blog/a-modest-web-components-styling-proposal-an-i-know-what-im-doing-selector/) and many others...

1. Provide a `/shadow/` combinator that explicitly targets contents of Shadow DOM.
2. Provide a mechanism to control whether or not the `/shadow/` combinator matches a given shadowRoot
   * via an explicit shadow root option available both in the imperative JS and declarative HTML API's. 
   * via an explicit CSS property, perhaps a special value for `appearance`.
3. _Note: The following would be widely useful beyond just Shadow DOM._ Provide a mechanism for specifying a named set of css rules, similar to `@layer` but that does not apply at all by default, e.g. `@ruleset a {...}` and an acccompanying css property `rulesets: a b c;` which would apply the rulesets where the outer selector matches. This could be used with css nesting, `@scope`, and `/shadow/`
4. Provide a mechanism to assign ruleset names to style and link elements: `<link rel=stylesheet ... ruleset=utils>`

This would allow using something like bootstrap in a shadowRoot as follows: 

```html
<link rel=stylesheet href="./bootstrap.css" ruleset="bootstrap">
<style>
  my-element /shadow/ { 
    rulesets: bootstrap; 
  }

  /* and "deep" application, perhaps something like.. */
  @ruleset deepBootstrap {
    /shadow/ {
      rulesets: bootstrap deepBootstrap;
    }
  }
  
  :defined {
    rulesets: deepBootstrap;
  }
</style>
```

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

Message ID: <WICG/webcomponents/issues/909/1936757672@github.com>