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

Some thoughts & questions (adapted from [mastodon discussion](https://front-end.social/@AmeliaBR/109938668078829176)):

- IMO, there should be two-way opt-in for style crossover. The web component author would need to explicitly pull in external styles in the CSS, or somehow make the elements visible to external selectors (with element attributes or settings used when adding the shadow tree). But the page author should also need to enable the style crossover, either with an attribute on the embedding custom element, or a JS option when registering the custom element class. (Either of which is still a lot easier than re-writing your full stylesheets to use custom properties or ::part selectors.)  For nested web components, there would need to be opt-in all the way up the tree.

- Selectors are used for more than just style rule matching. Is there a benefit or risk in also opting-in to visibility for `querySelector` (and similar)?

- Is it enough to just say that, for example `<button>` within the shadow tree should match a `button` selector from the light(er) DOM, or should there be a way to say that `<my-button>` (that is, a nested custom element) or a `<div role="button">` should appear to be a button for the purpose of the host document's stylesheets?

- This feature needs to avoid naming clashes for classes and data-attributes (i.e., the same class name used in the external page for a different meaning than how it is used by the web component author; this is the main reason for wanting encapsulation of stylesheets). But for the proposal to be useful, it would need to support a full set of selectors based on HTML semantics (type attribute, aria, pseudoclass / pseudoelement). Is it realistic to define a global allowlist / blocklist of visible attributes? Or would the web component author need to configure this somehow?
  
  Similarly: lots of typographic and form styles depend on sibling or parent/child relationships, so you'd want to support complex selectors. But this breaks the encapsulation of the shadow DOM tree, and could create brittle dependencies where an extra wrapping div or span, or a nested web component or slot element, would throw off the styles.

- I know there has been some spec discussion related to other named items in stylesheets (imported fonts, animation keyframes, and custom properties) and how they are interpreted when styles inherit across shadow boundaries. I don't know whether that's all been specified yet, but this would make it all the more urgent that it is cleared up in a way that avoids unintentional name clashes.

- How would / should the CSS cascade combine shadow/light(er) DOM style rules on a single element? Do the existing rules around slotted and host pseudo selectors make sense if generalized, or would additional cascade rules be required?

- Do existing rules about selector matching (on light and shadow DOM trees separately) vs style inheritance (on the slotted tree) still make sense for the desired use cases?

To answer many of these questions, it would help to have a collection of use cases for web components with a mix of slotted and templated elements where styling should be harmonized with the parent document, and examples of how WC authors are currently handling it (by building up templates all in the light DOM, or by copying stylesheets into the shadow DOM, or using complex custom props systems, or ???).

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

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