Something about Lit/web components that's not written clearly on the label is the hoops you have to jump through to style elements. If you're using tailwind in the whole app, you just want to pull it into your custom elements without much boilerplate. My main app compiles a single minified app.css, it felt not so modular to now include that in every single component. The alternative is create a subclass that injects tailwind into Lit components. It'd be perfect it just had a switch to inherit everything the page already has.

▲ hunterloftis 18 hours ago | parent | next [-]

> It'd be perfect it just had a switch to inherit everything the page already has.

It does! <https://lit.dev/docs/components/shadow-dom/>

By default, Lit renders into shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.

However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:

    static styles = [themeStyles, componentStyles]

Then you define your shared styles in `themeStyles`, which is shared across all components you wish to have the same theme.

▲ gitaarik 17 hours ago | parent | next [-]

I also made a simple lib to make it easy to implement common styles in your Lit components:

https://github.com/gitaarik/lit-style

▲ g0wda 18 hours ago | parent | prev [-]

oh nice! I didn't know that you can just make it use light dom.

  protected createRenderRoot() {
    return this;
  }

And that's what it takes! I like using tailwind/utility classes so for the styles I'd need to have layers of compiled css files rather than one giant one.

	▲	WickyNilliams 10 hours ago \| parent [-]
		The major downside of using light DOM is that elements cannot compose neatly since there's no delineating between what the component itself rendered and child content. When you need to re-render your component, how does the component know not to replace the child content you rendered, Vs the child content it rendered into the light DOM. That's why the shadow DOM and slots were necessary, because then there's no intermingling of your content Vs the component's This may not be a problem if you don't intend to compose your components. But if you do you will hit limits quickly

▲ spankalee 18 hours ago | parent | prev [-]

There's a long standing standards issue for this: https://github.com/WICG/webcomponents/issues/909

While you can easily turn rendering to shadow DOM off on a per-component basis, that removes the ability to use slots. It only really works for leaf nodes.

Pulling a stylesheet into every component is actually not bad though. Adopted stylesheets allow you to share the same stylesheet instance across all shadow roots, so it's quite fast.