Re: [w3c/webcomponents] Theming options for shadow roots (#864)

I'd like to chime in as someone who's working on shifting towards Web Components (via LitElement) from a jQuery / vanilla JS (not the library) codebase, by transitioning existing elements from jQuery to being Web Components.

What appeals to me about Web Components is that they're part of the spec (React, Vue, and Angular all recreate the spec, and I can't deal), meaning they're perfectly interoperable with everything (including jQuery, React, Vue, etc).

I can transition something from jQuery to a Custom Element -- let's say I turn what was typically an included template file with global JS hooks into a single Cusotm Element -- and then interact with that Custom Element with jQuery or vanilla JS. 

Nothing else has this no-strings-attached support. I can't just turn a single part of a jQuery app into a React/Vue/Angular element and use it in a clean, sane way while keeping everything else jQuery.


**Anyways**,

My experience with encapsulation has been a mixed bag. For Leaf (or mostly-Leaf (which I understand is a nonsense term)) elements, as discussed previously, it works pretty well -- the nesting is typically never too serious that in-component fixed styling is fine.

But you quickly run into yet another "all-or-nothing" situation where you need to make/style _everything_ in Web Components, or _nothing_. This is exactly what I dislike about the mega-frameworks that require you adopt their entirely new paradigms.

I've seen two major solutions to "_I just need my page's styles / FontAwesome [or some other font] / bootstrap / whatever_":

1. Simply include a `<style>` element in the shadow root of your element that points to your desired CSS file. If it's already present in the page root, the thought is that this will have minimal impact on performance. I have seen nobody provide evidence for the actual performance impact of this technique.
2. Don't use Shadow DOM at all. I do this by overriding `createRenderRoot()` to `return this;` (typically it creates a shadow root element instead; returning 'this' means that the element's contents are written to itself as its Light DOM children.) Basically, no encapsulation.


I prefer #2, although it feels very dirty. But it works, and it doesn't seem to harm performance, and I can't really think of a reason why I care that much about my own website's app-specific elements being encapsulated -- the client (users) **will always** be able to bust into them to change whatever they want, so there's no ENFORCEMENT, it's just a "do you want it bad enough?" gap. 


We talk about "anti-behaviors" like !important but... we have !important. Sure, you shouldn't use it if you're a good webdev, but you have the ability to if you know what you're doing or think that you know what you're doing.


### GreaseMonkey

I like the users of my website. They're creative. A lot of them have written custom scripts and stylesheets for my website, because it's created in a sane way (it's just HTML, JavaScript, and CSS). People can tinker with it, learn from it, expand on it, and improve _my own understanding_ through the process.

Forced encapsulation on Web Components destroys this. You can't write a stylesheet to theme the way a specific button looks anymore, because that button is a sub-component of a sub-component, thirty shadow DOM levels deep, and your sheet can't target it.

Websites should not be compiled binaries. Or at least, we should be able to create websites that are not compiled binaries without breaking the spec to do so. 

I truly believe that the ability to tinker with a website by viewing its source code and making tweaks to the stylesheet or injecting JavaScript is imperative to instilling curiosity and an interest in software engineering in young minds. The more we force encapsulation, the less this is possible.

So honestly I'm probably just not going to use Shadow DOM at all for most of my components, and I haven't really seen any compelling reason not to in this context. 

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