Insane idea to give components *overridable* default TW classes

[richardtallent]

I'm converting some components over to Tailwind. Easy enough:

<template>
   <button class="p-3 rounded-md bg-gray-100 text-gray-600 border-gray-300 centered"><slot/></button>
</template>
<script>
export default {
  name: "MyButton",
}
</script>

When when I use those components, sometimes I want to override portions of their default style. This can't be done with Tailwind classes reliably, since all classes having the same CSS selectivity score, which means whichever class is last in the Tailwind CSS (not the last one in the component instance's final class list) wins.

<my-button class="p-2">Still way too much padding here...</my-button>

Tonight, I was thinking about the fairly new :where() selector. A where() selector always has a selectivity score of 0 regardless of what is inside the parenthesis, meaning a mere class selector will override it. Support is mixed but it's getting close to critical mass.

So what if we were to use this to create a variant of each style (say, with a prefix of def: or d:), specifically meant for component authors, to define a "baseline" or "default" style?

.p-2, :where(.d\:p-2) { padding: 0.5rem; }
.p-3, :where(.d\:p-3) { padding: 0.75rem; }

When authoring components, we could then use these prefixed classes for anything we want the component user to be able to override:

<template>
   <button class="d:p-3 d:rounded-md d:bg-gray-100 d:text-gray-600 d:border-gray-300 d:centered"><slot/></button>
</template>

As a component user, I could then just use the normal Tailwind classes to override the defaults, meaning this now works as expected:

<my-button class="p-2">Ah, that's nice...</my-button>

Here's a Fiddle with a more complete example:

https://jsfiddle.net/richardtallent/qLp4mby6/

This is a bit of a hack, but still feels like a contender among other solutions I've seen so far, such as:

1. Not using TW classes for components, but instead using semantic classes (perhaps with @apply for some TW UX benefit) to define the default style, then ensure the build process loads that CSS before Tailwind. Clunky at best.
2. Adding a component property for each overridable style (e.g., a bg prop with a default of bg-gray-100) and string those props together to create the class list. Messy, creates a ton of unnecessary JS, and doesn't handle partial overrides well (e.g., what if the component has a prop for border but you only want to override border-style?).
3. Using a JavaScript library (I think I saw one floated here recently) to "resolve" the default vs. override class list by actually parsing out which classes should be in the final list. Certainly way more flexible than props, but a lot of work to get right and bound to have gnarly edge cases.
4. Foregoing use of TW classes as a user of the components.
5. Defining components without a default style for anything that should be configurable.

Seems like this solution would be fairly compact, too (only need new selectors, not a copy of each rule), should purge just as well as anything else.

This would also allow component users to use semantic or other custom classes to override styles without having to worry about whether those classes will be loaded before or after Tailwind.

Thoughts?

Would this wreak havoc on interactions with other variants or pseudo-classes?

Any other fatal flaws I'm not thinking of?

[richardtallent]

Update:

The plugin I wrote for this didn't work 100% of the time, because the specificity of :where() is too low to override the "reset/normalize" spreadsheet that is included with @tailwind base.

So, I went the opposite direction and created a plugin variant o: that has a higher specificity than a "normal" Tailwind CSS class, allowing normal Tailwind CSS classes to reliably override other Tailwind CSS classes.

https://github.com/richardtallent/tailwindcss-override