Re: [WICG/webcomponents] Web components should be able to easily adapt to the host page while maintaining enapsulation (Issue #986)

Well, I completely forgot I had started this thread, and [just commented the following](https://github.com/WICG/webcomponents/issues/909#issuecomment-1936910846) in #909 : 

> I've been thinking about this problem on and off for years.
> 
> ### The problem with `open-stylable`
> I think a big use case is having components that are able to adapt to the style of the page they’re dropped in (especially when combined with [`inherit()`](https://github.com/w3c/csswg-drafts/issues/2864)) without requiring author effort to integrate them. This means that anything that requires the surrounding page to use a special opt-in (e.g. `/shadow/`) is suboptimal (it's better than nothing, as it may be adopted as a convention, but it's still suboptimal).
> 
> There are use cases that truly don't need outside-in style encapsulation. Using WC by a page author for templating within that page is a prime example of that. It would also be perfect for something like [`<md-block>`](http://md-block.verou.me). An all-or-nothing solution like `open-stylable` will work well for such use cases.
> 
> However, for reusable widget use cases (typically not written by the page author, but a third party), usually _some_ degree of style encapsulation is desirable, depending on how much you intend the element style to diverge from a typical instance of its type. E.g. suppose you’re creating a modal dialog component. You are far more likely to want to inherit button styles from the surrounding page for its footer buttons (e.g. OK, Cancel, etc.) than for the close button.
> 
> ### Use case patterns
> Looking at the use cases under that pain point, I do see some patterns:
> 
> 1. Component styles should not leak out. That’s a type of style encapsulation that is almost always desirable.
> 2. You typically want select page styles to trickle in, but you don’t typically want to pull in entire stylesheets. In my experience, you typically you want to pull in base styles, i.e. elements and their states (things like `input[type="text"], input:not([type])`, `button:hover`, `button:focus:not(:focus-visible)`, `select > option`. For that reason, you also typically don’t need these page styles to match across Shadow DOM boundaries (not that there aren’t use cases for that, but I think they are very few)
> 3. As discussed above, you need to be able to opt-in on a per-subtree basis, not for your entire Shadow DOM
> 
> ### Potential solution 1
> I wonder if a solution that would fit these use cases better AND may actually be more implementable might be something like:
> 
> * We introduce an attribute to control how style encapsulation works (name TBB, let’s call it `adoptstyles` for now). It inherits, and using `adoptstyles` on a descendant changes the behavior for that descendant subtree. Or, alternatively, each element needs to opt-in separately. Or, even better, it’s a CSS property so both patterns are easy.
> * It starts off with three values, let’s call them `none` (default), `basic`, `all`. `none` is the current situation and `all` is what `open-stylable` does, but for that particular subtree. `basic` only applies page rules whose selectors match certain criteria (discussed below). This also gives us room to introduce more keywords in the future.
> 
> Selector matching would happen entirely within the Shadow root.
> 
> **Which rules should `basic` pull in?**
> 
> This will likely need a fair bit of iteration, but I think a reasonable starting heuristic is to eliminate selectors containing any authorland identifier, for example selectors that include:
> 
> * ids and classes
> * All attribute selectors where the attribute starts with `data-`
> * Attribute selectors where the attribute is `class`, `id`, or `name`
> 
> ### Potential solution 2
> Same as above wrt the opt in, but instead of filtering out authorland selectors, the entire stylesheet is imported but as a different CSS layer, so that it’s trivial to override.



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

Message ID: <WICG/webcomponents/issues/986/1936916230@github.com>