[topic] Theming Web Components w/ Global CSS

[thescientist13]

Code of conduct

• I agree to follow this project's code of conduct.

Description of request

Proposal

One of the great features introduced with Web Components was Shadow DOM. However, this also introduced some real challenges with (most) active and current CSS styling libraries and tools, which have only ever had to assume / support a single "global" scope for CSS, and by association, all the massive amounts of projects and sites using them.

Examples include

• Bootstrap
• Font Awesome
• Tailwinds
• Normalize

Description

While on the surface it might seem counter-intuitive to advocate for this when using Web Components, but I think it's important to remember that WCs are an umbrella of specifications, and so AFAIK, there is no rule that says you have to use all features together. In fact, I think one could argue that the "purity" of Shadow DOM could be pointed to as a friction point for adopting WCs because if you're using any of those existing CSS solutions and just want to componentize your app as custom elements, your barrier to entry just increased because of some of the only known work arounds you have to implement (as I know them anyway) are to

1. Shim / inline that global CSS into the Shadow DOM of every custom element, which will lead to significantly larger bundle sizes.
2. Disable Shadow DOM. This does mean that any 3rd party WCs you use need to support this too, or else they will introduce an impenetrable "shadow boundary".

I think ultimately this can help adoptees make better and more informed decisions and hopefully custom elements (with optional / value added Shadow DOM) can be that gateway into the wider world of WCs.

Outline

1. Introduction of CSS, Shadow DOM and the central "conflict"
2. Option A (no Shadow DOM) w/ caveats - no <slot>, 3rd party shadow boundaries
3. Option B (inline all shared CSS) w/ caveats - bundle size bloat, tooling
4. Other option?
5. Transitioning from global CSS to Shadow DOM based CSS (aka is there a happy path for this?)
6. Conclusion, link to spec and community channels, companion GitHub repo with examples, etc

In general I think the over-arching theme should be seen less as not advocating for Shadow DOM or "enabling" global CSS for ever, but rather, as I think is how the real world is, that incremental adoption strategies should be possible.

I think it would be great to highlight that a developer, team, or large organization's design system can still take advantage of custom elements (an arguably higher ROI) even if they don't immediately also adopt and thus re-write their CSS or entire design system to satisfy Shadow DOM. It should be very possible to do one, then the other as I think an all or nothing mentality does more harm than good. (IMO).

---

I think an article like this plays very well into one of the big themes / topics from our W3C report, which was on design systems and theming w/ WCs. This article could certainly be a stepping stone to that larger discussion combined with more articles that could hopefully provide a great guide on how to start a design system today. This would benefit from sourcing a lot of community examples so hopefully we can get some solid community involvement here to really flesh out the abstract with the tangible! 🙌

Related link(s)

• "open-stylable" Shadow Roots WICG/webcomponents#909
• CSS Bundling (and dropping PostCSS as core dependency) ProjectEvergreen/greenwood#763 (comment)
• add option to disable / opt-out of Shadow DOM to support global CSS libraries fernandopasik/lit-redux-router#60
• https://lit.dev/docs/components/shadow-dom/#implementing-createrenderroot

Are you interested in authoring this content?

• Yes

[thescientist13]

@Westbrook
Sorry, meant to capture this as part of the last meeting, and I know we're still defining our IA (Information Architecture) but was curious to get your thoughts on the viability of a topic like this. as per a comment you made on Twitter re: not advocating for supporting globals css, as it could be seen as going against the grain of WCs.

I can certainly see that side of the argument, but also can acknowledge myself and others' feedback and challenges getting custom elements to play in a Shadow DOM world, when using styles from a very global CSS world. A guide like this was intended as a way to bridge that gap as a good way to help "split" the cost of adopting WCs; at least get onto custom elements, and adopt Shadow DOM if / when there is a good time to move away from your global CSS library.

I can also see from your point that for this specific initiative here (WCCG), it might send mixed messages, and so maybe should be left to someone's personal blog instead. So, just wanted to get the conversation started with you before committing to content on this topic and potentially as a way to inform our content practices / recommendations as it relates to the IA.

Looking forward to hearing your thoughts. 👍

[sashafirsov]

Shim / inline that global CSS into the Shadow DOM of every custom element, which will lead to significantly larger bundle sizes.

That would not be needed if the resource could be referenced from within the page, say by ID. In current concept the resources reuse is underdeveloped. We could preload it via LINK, but can not apply by referencing that link declaratively, instead URI is the main link point. Once style would permit something like

@import ref("#my-css-or-link-tag-id")

the volume concern should go away along with bundle concept. Reused CSS sub-bundle in similar to JS fashion would be assembled by build toolchain and reused across WC.

Of course the scope and base url for module has to be solved, which is part of css/html module discussion.

[sashafirsov]

Disable Shadow DOM. This does mean that any 3rd party WCs you use need to support this too, or else they will introduce an impenetrable "shadow boundary".

It would be true if we apply to WC mode=open as it is of now. Most likely this mode would be kept for compatibility reasons, hence another mode something like mode=inject would reflect the WC acting almost as HTML include. Of course with templates/slots respected as in light-dom-element. mode=light meant for customizable by container CSS still not leaking back from WC to outer scope.

mode= closed, open, light, or inject could co-exist happily. Even more, developer could make them act identical if the CSS could be reused as in previous comment. There are samples of light and shadow DOM which render same UI with common CSS in and out of shadow.

[sashafirsov]

2. Option A (no Shadow DOM) w/ caveats - no , 3rd party shadow boundaries

I do not see the need to exclude slots and templates. Those are essential part of WC and should be presented in light version as well. There is a reference implementation and tooling lib to support templates in light DOM.

Even more. I been working in enterprise projects which do utilize slots in usual DOM with WC as loading and attaching to DOM API. The CSS was happily scoped by this tag prefix. Simple and efficient.

[thescientist13]

Yeah, in my mind I don't exclusively map Shadow DOM to Web Components, but I understand how compelling it is a feature to deliver a single file component experience, as it were. Either way, I am hoping to understand the philosophical angle of this group as a whole, if it's worth making the push for WC in a light Dom world, or if it should just focus on making it as easy and clear to use WCs with Shadow DOM. (Maybe this is what adoptedStyleSheet will solve, and so maybe a better way to focus our efforts instead of open stylable shadow roots?)