Support for different themes within the same site

[walidvb]

Imagine a website where every page can be custom with different designs. Particularly, inputs, buttons, cards etc. They cannot always be componentized as we cannot set a generic padding/alignment or even children, so the html needs to be written everytime.

I'm trying to devise a theme system to support passing configs for colors, borderRadius etc that would play well with tailwind.
My go-to solution is CSS variables as they are very powerful and would support anything required

The general idea is to pass to tailwind a set of values that are linked to CSS variables, and to override them with a style="--my-var: blue" property on a parent html element.

I've come up with a proof of concept, and I would love some opinions on whether this(or a better implementation of this) would scale, and what caveats I should be concerned with:
https://play.tailwindcss.com/M1JFeRJGWW?file=config

I feel like this can be optimized perhaps by using a plugin, and auto-generating a lot of these classes. In this sense, from the following config:

const theme = {
  extend: {
    colors: {
      btn: { 
        bg: {
          default: 'blue',
          hover: 'red',
       }
    }
  }
}

would generate the following CSS:

:root{
  --btn-bg: blue;
  --btn-bg-hover: red;
}

.btn{
  @apply bg-btn-bg;
}
.btn:hover{
  @apply bg-btn-bg-hover;
}

Nice to have:

Support for --tw-text-opacity etc

[MichaelAllenWarner]

If you search around, you'll find some plugins that do this sort of thing. There are a variety of approaches. Here is a recent one that I think shows some promise: https://github.com/RyanClementsHax/tailwindcss-themer

The CSS-variable approach has the great virtue of minimizing the work required to incorporate new themes: instead of combing through your components/templates for all the theming conditionals you've used and augmenting them with new logic-branches and utility-classes, you can just define the variable-values for the new theme. It comes at a cost, though:

• You have to look at abstract utility-classes like bg-btn-bg-hover in your markup (I'd much rather see the actual colors, which is more in the spirit of Tailwind IMO).
• You have to come up with those abstract names.
• The more you use this approach, the more you find that different components have different theming needs, and that means making more variables (and coming up with more abstract names, like bg-btn-bg-hover-secondary, where themes basically have sub-themes) and/or making more themes (where two themes might be almost identical, differing only by one or two variable-values).

Depending on the size of your project, the explicit-utility alternative can be perfectly viable and arguably preferable, especially if you're consistent about how you express the branching logic (so that you can easily do a project-wide search when you need to add a new theme). The explicit-utility method can also be improved with custom variants, allowing for syntax like className="theme-green:bg-green theme-purple:bg-purple" (used in conjunction with some theming flag higher up in the DOM) instead of, say, className={theme === 'green' ? 'bg-green' : theme === 'purple' ? 'bg-purple' : ''}. That way you can just set the theme-flags where they're needed and not have explicit conditionals everywhere.

And of course, the explicit-utility approach isn't mutually exclusive with the CSS-variable approach. Maybe there's a sweet spot that can combine them both, where you use abstract CSS variables for a few key properties that are likely to be consistent across components and themes (like base background-colors and text-colors), and then fill in the gaps as needed with explicit classes?

Not sure if there's a good one-size-fits-all solution here.

[walidvb]

thanks for the extensive answer – i had not found tailwindcss-themer yet, but indeed it looks like exactly what i have in mind.
My use case is for a platform that creates pages for partners, so the theme can be wildly different, although it's usually mainly a matter of changing the tokens. It is notable that a a piece of html would not exist in two themes at all, but always within its own page.(so no multiple theme support – ie no theme-green:bg-green theme-purple:bg-purple)
I hear regarding naming, and that is my main concern. This said, with some ts magic and the tailwind vs code plugin, you should get a decent DX.
Also, most names would be quite utilitarian, just on a component level(not very tailwind, i know): input, card, button etc.
The naming challenge arises anyways also in building the site itself, and hopefully we can come up with a sensible mapping between the two.

I'll have a closer look at the library, as it may suit my needs very well!

Thanks again!