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

> Nolan's point, if I understand it, is that some people will want to override the wishes of the component author. I haven't seen people ask for this.

@matthewp At Salesforce this has come up countless times with our "base" components, but to take an example from my OSS [`emoji-picker-element`](https://github.com/nolanlawson/emoji-picker-element):

1. It offers [a bunch of CSS custom properties to customize it](https://github.com/nolanlawson/emoji-picker-element?tab=readme-ov-file#css-variables).
2. However, if you search for [how people are using it](https://github.com/search?utf8=%E2%9C%93&q=emoji-picker-element+createElement%28%27style%27%29&type=code), you can find 40+ cases where they inject a custom `<style>` to override something. E.g. they [change the border radius, give it a box-shadow](https://github.com/The-Commit-Company/Raven/blob/a5f5db0a9dd349a1022054a50e4814c77249ec04/raven-app/src/components/common/EmojiPicker/EmojiPicker.tsx#L18), etc.
3. Of course I could keep adding CSS custom properties, but there is an almost infinite long-tail here.
4. Alternatively, I could use `::part`, but this also devolves to adding `::part` to every single element in the picker, including non-semantic wrapper `<div>`s, just so I don't miss anything that someone may want to style.
5. At which point a consumer might _still_ be annoyed that either 1) their global `bootstrap.css` doesn't automatically style `<button>`s – you have to explicitly enumerate the `::part`s (as expressed in [Lea Verou's issue](https://github.com/WICG/webcomponents/issues/986)) or 2) they want to customize something that CSS can't affect, such as the ordering of the elements (e.g. folks have asked to [put the favorites bar on top](https://github.com/nolanlawson/emoji-picker-element/issues/323#issuecomment-1851798633)).

This is kind of the point I'm getting at in the post – you end up exposing so many possible customizations, and you still don't capture them all, which has led some people to the conclusion that you need to avoid shadow DOM entirely and expose everything in light DOM via `<slot>`s.

Everything that's been proposed above solves some part of this, but not the whole thing – that's kind of my point.

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

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