So what if you could have all the benefits of Shadow DOM and be able to very easily style though it with regular CSS? That’s literally what I want. Looks like Brian Kardell has a brand new library to allow for exactly this: half-light.js. (A quick evolution of his shadow-boxing library.) I’d prefer it at the platform level, but hey, 100 lines of code is great.

half-light.js is a very tiny (~100 LoC) library that lets you express styles for shadow doms in your page in your CSS (it should be CSS inline or linked in the head). You can specify whether those rules apply to both your page and shadow roots, or just shadow roots, or just certain shadow roots, etc.

Fair warning: I’m just some dude on the internet with an opinion here. I’m coming at it from an author’s perspective who has only written a handful of web components. But I like the idea of them, I like the web platform, and I’ve been trying to watch them for what feels like a long time. I don’t have the wider perspectives of those who have been in the trenches, speccing and implementing these things.

Let me get right to it. What I mean is using a pseudo selector to break through the Shadow DOM and then be able to style inside it, from any CSS on the page:

my-component::i-know-what-im-doing {
  .something-inside {
    /* yay, we're in! */
  }
}

Now that selector is just tongue-in-cheek (reminds me of React’s dangerouslySetInnerHTML), but the idea I’m serious about. Maybe it’s something more straightforward like:

my-component::root {
  .something-inside {
    /* yay, we're in! */
  }
}

my-component::root footer h3 {
  /* When you're in, select and style like normal CSS */
} 

This is not possible right now, and I wish it were.

Current Styling Options of Shadow DOM Web Components and Why I Don’t Like Them

I’ll elaborate on the thoughts I posted in another article about Web Components. Here are what seem to be the current possibilities for styling a Shadow DOM Web Component:

• Styling specific elements with ::part is a very niche styling approach that is not a real styling solution. It tosses out the power of CSS (selectors) which seems silly.
• Styling by documenting somewhere that certain CSS --custom-properties are in use, thus you can set them from the outside, and they will cascade in to affect inner styling. This is also limited, not offering the real power of CSS, and to me not a real styling solution.
• Styling by injecting a <style> tag into some template literal in the JavaScript itself. This feels awkward and ad hoc to me. Writing CSS as a string is not great (you’d be lucky to get autocomplete, lining, etc.) I’m not a fan.
• Styling with an adopted stylesheet means an additional web request for each component or back to using a string which is either awkward or slow.

I don’t want to do any of those. They all force me out of the styling workflow of the rest of my website, and tend to push me towards nope, screw it decisions.

The Advantages of This Approach

• You still get the encapsulation. For the most part, anyway. The JavaScript encapsulation stays the same. Even CSS encapsulation is still there. Random CSS will not leak in. You have to be very specific, making the component name part of the selector and using the specific pseudo-selector to reach into these components. That’s not accidentally done.
• You can now style things with the best styling API around: CSS.
• You can concatenate/bundle the styles for your site how you already are doing it. You just… style stuff.
• You can now choose to create Shadow DOM Web Components, and get the excellent feature of <slot>s, without being penalized with difficult styling choices.
• All the other styling methods are still there.
• It would allow people to build and distribute a Shadow DOM Web Component with very basic styling and they could just tell people: hey you wanna style it? Go for it.

OK bye.