tailwindcss-def v0.1.0

tailwindcss-def

What does this plugin do?

This plugin adds a new def: variant to your Tailwind CSS configuration. Any class using this variant can be overridden by other TailwindCSS classes.

So, this allows you to create a component (Vue, React, etc.) that has default classes for various styles, but when you use that component, you can override those defaults with normal Tailwind (or other) classes.

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

How do I use it?

1. Install

npm install tailwindcss-def

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

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

3. Create a component with a default style

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

4. Override as needed for your component instances

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

Which classes should I default?

Whichever ones you want the component user to be able to easily override. Probably not everything.

Caveats

1. Only one "level" of override is possible using this approach. You can't override an override. Well, you can, but you're back to the normal limitations of either using a class that is added before Tailwind's classes, or that has a higher CSS selector specificity (e.g. a deeper selector or an !important directive).

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

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

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

How does it work?

This variant wraps your class in a :where() selector. These have a lower specificity than a class, which allows them to be overridden by a simple class.

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. Hello, 1995 is calling, 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 naming, 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. Feels kludgy, slow, and brittle to me.

I came up with this idea earlier this year, and decided it was time to make it a reusable plugin.

License

MIT