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

> Yeah, I think the TLDR (please correct me if I'm wrong or expand as necessary) is that we ended up deciding to focus on an initial version of an API which allows the page's author to mark a subset of the document-level stylesheets to be included inside shadow trees.
> [snip]
> Importantly, that doesn't mean that this problem is dealt with completely once we provide such API, but seems it cover the biggest / most common use cases, and we can work on solving more complex use cases incrementally after this.

Unfortunately I couldn't join this meeting, but I do have reservations about this proposed solution. I worry it's [overfit](https://fibery.io/blog/100-posts-about-products/overfitting-in-product-design/) to very specific use cases, does not provide a clear migration path for WC authors, and does not mesh well with current authoring practices.

First, as a general product principle, prioritization doesn't just depend on how *common* pain points are, but also how *painful* they are, i.e. taking into account factors like:
- Do workarounds currently exist? 
- If so, how high friction are they? 
- Do these workarounds produce a good enough result in the average case? 
- How many use cases are covered by the workaround?

In this specific case, the use cases where component and page are controlled by the same entity are _common_, but far less _painful_. Stylesheets can *already* be marked with some authorland convention and imported in the component via JS at creation time (so the only FOUC is the usual WC FOUC that authors already deal with via `:not(:defined)`).

The *most* painful use cases, are those where **component and context are controlled by different entities**, so they cannot depend on a shared contract. While at first glance it looks like an attribute on `<link>` and `<style>` would solve this problem by introducing a platform convention, in practice a WC author cannot depend on this convention being followed by the host page, which is a problem with any opt-in method.

Are these use cases common? Yes, but far less than they should be, because the existing WC suite of technologies is very hostile to them. [When I polled authors a while ago](https://twitter.com/LeaVerou/status/1697245010650148924), **the % of authors who mainly used WC made by others was tiny**, which IMO explains their relatively low adoption compared to the original vision. WC were not meant to just be a templating solution with scoping, but to cover gaps in the platform, and empower authors to do more without having to learn more, by giving HTML superpowers. That said, there are still thousands of WC made for generic use, and currently most of them have to [bundle an entire design system along for the ride](https://shoelace.style/tokens/typography). Does the design system not work with the design or the surrounding page? Tough luck, good luck writing hundreds of custom properties specific to each component, or styling `::part`s with no access to their different states or subtrees.

But even with pages that are willing to do the work of separating general styles from page-specific styles, there is no guarantee that the separation is actually accurate so that as a WC author I can trust it. Not only is this very error-prone, especially over time, it's also a bit of a continuum, rather than black & white. E.g. if I'm styling `button` in `section.highlights` differently than general `<button>` elements, I'd expect a WC's buttons in the same section to follow the same styling. 

Lastly, even if we lived in a perfect world where a) all authors will do this and b) they will do it perfectly, it does not encourage good authoring practices and does not mesh well with how websites are developed today. Authors don't want to have multiple stylesheets, CSS is often authored in places that are not even CSS files, and authors have no control over the `<link>` or `<style>` tags actually used to embed their CSS (e.g. see single page components in frameworks like Svelte, Vue, etc.). Also, in the example above where I want to style all buttons in `section.highlights` a certain way and have WC be able to use that, the CSS for section.highlights living in two separate files is recipe for disaster (even within the same file, when styles for the same thing used to be spread across one large MQ it led to tons of authoring errors especially over time).

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

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