Proactively responsive themeing

[Westbrook]

Currently, the theme files point to :host or .sl-theme-{kind} which implies that they need to be leveraged within a shadow root :host or against a managed "root" (something that applied the class). This could happen via an app root (e.g. <my-app>), in every element via CSS Module scripts and constructible style sheets, or via a little JS magic:

<script>
  const media = matchMedia("(prefers-color-scheme: dark)");
  document.scrollingElement.classList.add(media.matches ? "sl-theme-dark" : "sl-theme-light");
</script>

I would assume this has to do with optionally delivering themes custom to the app/site in contrast to the default OS preferences.

For developers that are happy relying fully on the OS preferences, would you consider expanding the selector usage (or the processed file output, something like dark.styles.js but dark-root.css) to include :root and better support OS preference based theming at the top of the page via something like @import url('/path/to/themes/dark.css') screen and (prefers-color-scheme: dark); (or similar via <link> or pre-processor)?

It seems that at some point this was concidered as this concept was included in the instructions for customizing the light theme, though interestingly not in the instructions for customizing the dark theme.

---

Appendix
While light-dark() is only newly "Baseline", it is a really nice way to address both following OS preferences by default while easily allowing for site local preference application, as seen in this demo.

[Westbrook]

Looking closer, I realize this may actual be a bug and not a feature request in that the Light Theme actually includes :root at the code level:

shoelace/src/themes/light.css

Lines 1 to 3 in 76b495a

	:root,
	:host,
	.sl-theme-light {

While the Dark Theme does not:

shoelace/src/themes/dark.css

Lines 1 to 2 in 76b495a

	:host,
	.sl-theme-dark {

This could also explain the discrepancy in the documentation, too.

Should :root be available in both files? If so, then I can convert this to an issue, or even a PR if you'd like.

[claviska]

Hey, Westbrook! Apologies for the late response. The light theme having :root and the dark theme not having it is by design. Historically, light has been the default mode for Shoelace whereas dark was opt-in. Without the :root in the light theme, one would need to add a class regardless of which theme they wanted to use, which would have been another barrier to entry.

As support for light-dark() increases, we'll definitely leverage it more in themes! I think Safari is the biggest concern, since it wasn't added until 17.5.

[Westbrook]

Interesting that at the app level you prefer light, but don't apply a preference at the component level, e.g. :host. A bit confusing to start, but ease to cover over with something like the following, now that I understand the expectations here.

const theme = matchMedia("(prefers-color-scheme: dark)");
const applyTheme = (): void =>
	document.scrollingElement!.classList.add(theme.matches ? "sl-theme-dark" : "sl-theme-light");
theme.onchange = applyTheme;
applyTheme();

export { theme };

Or at the component level, via @imports or <link> elements. Gotcha.

Thanks for the additional historical info. 👍🏼

[claviska]

Interesting that at the app level you prefer light, but don't apply a preference at the component level

Currently, we expect that a light DOM stylesheet (which sets CSS custom properties, or "design tokens") is loaded by the user in order for components to render properly. Not saying this is the best approach moving forward, but it seemed like the best one a few years ago. 😄