This provides a new o: variant for your Tailwind CSS configuration. Any class using this variant will override other Tailwind CSS classes.
The purpose 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.
npm install tailwindcss-overrideplugins: [
require('tailwindcss-override')(),
],No plugin installation needed! Just add this CSS variant to your stylesheet:
@custom-variant o (&:not([z]));Note: In Tailwind CSS 4, JavaScript plugins are no longer supported. Instead, you add custom variants directly in your CSS using the @custom-variant directive.
<!-- MyButton.vue -->
<template>
<button class="font-semibold bg-blue-500"><slot/></button>
</template><MyButton>My Blue Button</MyButton>
<MyButton class="o:bg-red-500">My Red Button</MyButton>-
Only one "level" of override is possible using this approach. You can't override an override.
-
I haven't tested this with more complex classes like media queries.
-
This CSS feature is not supported in IE11 or Safari 8.x and below.
-
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.
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) matches anything, (b) raises selectivity, and (c) is compact.
If you're upgrading from Tailwind CSS 3 to 4:
- Remove the plugin from your
tailwind.config.js - Add the CSS variant to your main CSS file:
@custom-variant o (&:not([z])); - Your HTML stays the same - all existing
o:classes continue to work
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:
-
Don't style your components. I don't like this approach. I like reasonable, beautiful defaults.
-
Pass overridable styles as component properties. 1995 called, it wants its
<FONT COLOR>back! -
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
@applyso they can consistently override the default. -
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.
MIT