tailwindcss-override

tailwindcss-override

What does this plugin do?

This plugin adds a new o: variant to your Tailwind CSS configuration. Any class using this variant will override other Tailwind CSS classes.

The purpose of this plugin is to allow you to use Tailwind CSS classes to create components with reasonable default styles, while still allowing the component user to override those styles with Tailwind CSS (adding only the o: prefix).

There's no run-time JavaScript involved, this is all pure CSS.

How do I use it?

1. Install

npm install tailwindcss-override

2. Add this to your tailwindcss.config file in the module.exports object

plugins: [
	require('tailwindcss-override')(),
],

3. Create a component with a default style

<!-- MyButton.vue -->
<template>
	<button class="font-semibold bg-blue-500"><slot/></button>
</template>

4. Override as needed for your component instances

<MyButton>My Blue Button</MyButton>
<MyButton class="o:bg-red-500">My Red Button</MyButton>

Caveats

1. Only one "level" of override is possible using this approach. You can't override an override.

2. I haven't tested this with more complex classes like media queries.

3. This CSS feature is not supported in IE11 or Safari 8.x and below.

4. Like any variant, using this will increase your CSS bundle size, since the o: variants are defined as separate rules from the classes they are based on.

How does it work?

When you use o:bg-red-400, a CSS rule is created for the selector o\:bg-red-400:not([z]) to match it. The :not([z]) is tacked on to force a higher specificity above a normal class selector (i.e., above other Tailwind CSS classes). The :not([z]) selector was chosen because it (a) matche anything, (b) raises selectivity, and (c) is compact.

Why did I create this plugin?

I've been making web apps since 1995, and I really enjoy using Tailwind CSS.

But as a component author, there are also a few annoyances with the utility-class approach. One is that I like to create components that have reasonable default styles, but that also allow the component user (usually me!) to "tweak" the style later. But with TailwindCSS's "flat" approach (there's not much actual "cascading" going on, just lots of individual classes), this becomes difficult. The usual recommendationa are:

1. Don't style your components. I don't like this approach. I like reasonable, beautiful defaults.

2. Pass overridable styles as component properties. 1995 called, it wants its <FONT COLOR> back!

3. Use a higher-level selector in your component instance. Yes, but that means having to go back to semantic classes and deeper selectors, and either not being able to use TailwindCSS classes for those component instances, or having to use them with @apply so they can consistently override the default.

4. CSS-in-JS. I.e., try to rewrite the whole logic of "what overrides what" in JavaScript and apply the "winning" classes/styles dynamically. A few people are working on this, but it feels kludgy, slow, and brittle to me for 99% of use cases.

I came up with a similar idea in early 2021, and even created a plugin for it. The idea with that plugin was to let the component author use a special variant to create low-specificity Tailwind selectors using the new-ish where() selector. The problem is, the specificity was a bit too low, so Tailwind's "reset" stylesheet made it impossible to use that plugin to style anything that is part of the reset (since those resets operate at the element level).

This plugin works the opposite way, allowing the developer to raise a Tailwind CSS class's selectivity so it overrides some other (normal) Tailwind class definition.

This variant can be used in combination with other variants, such as hover:. I have not tried it with media queries, dark mode, or a few other variants, but I'm hopeful it will work with them as well, and I'm open to PRs if it doesn't.

License

MIT