Hey John thanks for mentioning TAC CSS! I recently rebuilt a React-based design system into a TAC-based design system. We’re now dependency-free and framework-agnostic, down to just 7 tiny kb, and getting better SEO and a11y for free.

Something else caught my eye: “They end up discovering that they can’t use global styles”.
I was under that impression for the first few years of doing WC until I learned how much global styles do in fact penetrate Shadow DOM and that even global stylesheets can easily be imported into WC. There’s surprisingly 8 ways to style Shadow DOM and 5 of those are done from the outside in: https://jordanbrennan.hashnode.dev/8-ways-to-style-the-shadow-dom

The thoughts and approaches mentioned in this article dovetail nicely with those mentioned in https://jordanbrennan.hashnode.dev/tac-a-new-css-methodology, by the way.

Custom HTML tags sans-Shadow DOM make a ton of sense for app/site-specific “components” like page skeletons, layouts, idiosyncratic UI, and wrappers/customizations around 3rd-party components. At least, they make sense if you care deeply about your markup structure, SEO, A11y, Web Vitals like LCP and CLS, JS payload size, and progressive enhancement.

The Shadow DOM and its encapsulation capability, however, seems very appropriate and useful for packaged 3rd-party components as a way for component authors to control the component public API in terms of behavior, content (slots), and styles. Take, for example, https://shoelace.style/. It’s a great example of customization in tandem with the Shadow DOM through features like slots, CSS custom properties and CSS parts. If these sorts of components could be customized without limits, then the ways a consumer could break them would wreak havoc on maintenance and support. The same applies, I think, to a well-maintained component collection for an internal design system, like https://opensource.adobe.com/spectrum-web-components/.

In my experience, where folks tend to go sour on web components is trying to wrangle with how to use Shadow DOM for app-specific components. They end up discovering that they can’t use global styles, or their sacred Tailwind cow, querySelector doesn’t seem to work as they expect, and they’re like, “what’s the point of making things harder”, and they totally write off web components as a technology because XYZ popular framework doesn’t have these constraints.

The custom element aspect of web components, of course, doesn’t require using the Shadow DOM–you still get JS “upgrading” and sweet-looking CSS selectors for free–so I’m glad to hear folks are coming around more and more to using them for this.

You mentioned a benefit for Shadow-DOM as encapsulation (which I’ve used before as well) but really, should there be so much JS on your page that you have collisions? JS has just gotten way out of hand. Coming from the massive JS framework perspective you automatically think, “of course you should encapsulate” but really? Do you?

Thanks, great article.

class NewComponent extends HTMLElement {
  connectedCallback() {
    const html = `
    <header>
      <slot name="hdr"></slot>
    </header>
    <main>
      <slot name="mn"></slot>
    </main>
    <footer>
      <slot name="ftr"></slot>
    </footer>`;
    this.childrenToSlots(html);
  }

  childrenToSlots(html, src_elems) {
    var template = document.createElement("template");
    template.innerHTML = html;

    const slots = template.content.querySelectorAll("slot");
    for (const slot of slots) {
      const slotChildren = this.querySelectorAll(`[slot='${slot.name}']`);
      slot.replaceWith(...slotChildren);
    }

    this.replaceChildren(template.content);
  }
}
customElements.define("new-comp", NewComponent);

https://jsfiddle.net/f5pr21ju/

https://twitter.com/junaidbhura/status/1735426353103843409