Add support for "unimportant" styles

[brandonmcconnell]

Foreword— Yes, I'm aware there have been similar requests and even related ongoing discussions (I even listed many of them below), but this request itself is not redundant to those, even if the end goal, the heart of the matter, is related.

Background

It is often necessary—when working in component-oriented development—to add default styles to a component and then override those using styles passed in via props. When passing Tailwind classes as props, it is not uncommon to run into the issue of one class on applying its styles because an "equivalent" class already exists on the relevant component.

Orthodox countermeasures

In this situation, the usual path is either to—

• (a) use the important flag on the prop being passed in to override the class used in the component
• (b) rewrite the component in such a way that it accepts those particular classes using as optional props of their own and then conditionally load them or their defaults using a ternary statement inline.

This is what both of those methods look like in practice:

(a) using the important flag → !

OUTER component

<Button class="!bg-indigo-500" />

INNER component

<button class="bg-gray-500"></button>

The problem with (a) is that it requires the developer to always be aware of which classes are defined in the component(s) they are using, and when they run into a conflict like the one mentioned above, to then inspect that component to see what class(es) are being applied and then either use an important flag, or alternatively…

(b) using class-specific props

OUTER component

<Button bgClass="bg-indigo-500" />

INNER component

<button class="{bgClass ?? 'bg-gray-500'}"></button>

The problem with (b) is that it requires continuous rebuilding each time a new style needs to be supported as a prop, rather than being able to create a truly reusable component with the bulk of style-related logic being handled purely by Tailwind classes.

The proposal: unimportant classes

Tailwind already supports "important" (!important) styles using the exclamation mark ! to the left of a class name, as demonstrated in the above examples. I propose a similar pattern "unimportant" styles, using two consecutive exclamation marks !! to the left of a class name.

While CSS does not natively support any kind of !unimportant flag, this should be as simple as layering unimportant utilities below the standard utilities, or declaring them earlier in the cascade to give them a lower priority.

With this pattern supported, we can simply use unimportant classes when adding any styles to components that are expected to be overridden and use standard classes in other cases. Then if a user wants to override an unimportant class, they only have to pass a standard class without resorting to using an important modifier for standard cases, and then in the event that a developer chooses to override a className which is not usually meant to be overridden, they can still the important modifier, only now more appropriately.

How would this look in practice? Something like this:

OUTER component

<Button class="bg-indigo-500" />

INNER component

<button class="!!bg-gray-500"></button>

Workarounds

The best workaround I've seen for this so far is one that @adamwathan (quite possibly you, reader 👀 ) mentioned in discussion #1446 where he demonstrated a pattern that the Tailwind team uses, essentially adding a variant that scopes styles under html tags and uses :where(&) to zero out the specificity.

I really like this pattern and would even propose using the same pattern for this, but with the new syntax of !!. Though, if something like initial: or default: is preferred, that's fine as well, and I would love to see one of these solutions make it into Tailwind core. The user demand seems to be there for it, and if the Tailwind team itself even saw a need for it internally, why not include support for it across the board?

Closing remarks

I'm happy to help brainstorm this a bit more. If not this solution, I think there must be something along these lines that can be done to solve this specificity problem.

This could also be the solution to a question many GitHub ideas and discussions have touched on in the past—

• Why is the first class more important than the latter? #8120
• How to set overwrite-able defaults with Tailwind via classNames utility func #7310
• override/priority of classes based on their order #6795
• How do I override component styles? #6375
• add :where() aka 'not important' option #6074
• How to increase the specificity of tailwind util classes #5080
• Insane idea to give components *overridable* default TW classes #3523
• !important variant #2646
• Override base styles scoped to a container, yet still allowing for element-level customization #2452
• [Feature Proposal] CSS class override utility for component composition. #1446
• probably others…

[brandonmcconnell]

The general solution to this is to add a custom variant which uses :where() to decrease the specificity of the selector, though a better and more flexible solution is to use the excellent https://github.com/dcastil/tailwind-merge package by @dcastil.

Closing this discussion as resolved.

[mwnciau]

I've created a Tailwind plugin, tailwind-unimportant, that does just this without needing to use tailwind-merge. Features:

• Apply "unimportant" variant classes with lower specificity than the default utility classes
• Unimportant classes have a higher precedence than the base styles
• Variants for multiple levels of unimportance, useful for when you are using components within components

Example, taken from the readme of the project:

// text-blue takes precedence over -:text-green, which takes precedence over --:text-red
<a class="--:text-red -:text-green text-blue">
    The link is blue
</a>

[dcastil]

Nice, this looks cool! 🙌

[brandonmcconnell]

I really like your approach here and how you built this. Great work!

[Khaldor48]

Really great work, thank you very much! This is neat solution! I can't believe they don't have this feature in their core.

[terradestroyer]

how to use this with typescript? it needs "type", right?

[iBobik]

Workaround (default bg color):

[:where(&)]:bg-slate-50