[Feature Proposal] CSS class override utility for component composition.

[harryhorton]

First, ❤️ Tailwind!!!

Problem

Working within the scope of a large FE application (my use case is React with hundreds of components), it's common to create styled components that are composable. Reading through the doc notes on composability, the standard answer seems to be to split the utilities that COULD change into their own classes (or in our case, components that would merge the class list with the base).

While that seems like it could work, in our situation, splitting things up this way doesn't feel reliable as we often receive adjustments to styles that can wildly change the look of a component that we're composing off of. It would result in having a lot of base components with next to no utility classes, and a lot of additional utilities on a hierarchy of composing components that feels like it would be difficult to manage. Additionally, if render functions or props were used to override all of the classes, then a developer would easily loose track of duplicate utilities across compositions, where they should have been simply extending the base.

It's possible to work within the limitations of the current recommendation, but, after testing, I don't expect this to be a good developer experience at scale.

Possible solution

Create a JS utility that can merge utility classes based on what can be overriden.

This would allow developers to write base common styles on a usable component, while easily using component composition to override only the utilties that they wish to change.

tailwindMerge('bg-gray-500 p-4 mb-3', 'bg-blue-500 pr-2 mb-4') => 'p-4 bg-blue-500 pr-2 mb-3'

React

const BaseButton = ({ className, ...props }) => (
  <button className={tailwindMerge('bg-blue-700 px-3 py-1', className)} {...props} />
);

const SpecialButton = ({ className, ...props }) => (
  <BaseButton className={tailwindMerge('bg-green-700 px-5 py-2 text-lg', className)} {...props} />
);

This would also work with other front-end frameworks.

Additional considerations.

• Since developers can add custom utilities, it would be helpful if there was an override group configuration option in the tailwind config.

[benface]

I would very much like to see something like this. I'm not sure if it makes sense for it to be part of the main codebase though.

[harryhorton]

Probably doesn't make sense in the main codebase, but I wanted to raise the issue here to get more feedback. I tried my hand at understanding the tailwind full config and developing something for this. It turned out to be a lot more complicated than I was initially expecting. I'm happy to do the work and create an NPM module for it, but I'll definitely need some guidance on how to get the full computed config via JavaScript and how to get the class string groups and match them with config groupings to do the merge.

[adamwathan]

This is a pretty complex problem and probably out of scope for Tailwind itself unfortunately.

how to get the full computed config via JavaScript and how to get the class string groups and match them with config groupings to do the merge.

^ This of course is the really hard part and I can't even provide guidance on a good approach for doing it :/

One day I'd like to explore a proper CSS-in-JS flavor of Tailwind that would handle stuff like this better but I'm going to close this for now as a "not working on this any time soon" sort of thing unfortunately. If you do end up hacking on it as a separate project I'd love to see how it goes 👍

[mariusmarais]

@adamwathan I'm currently struggling with integrating TailwindUI (team license, yey!) into an existing React app due to this composability issue. I've taken a stab at a merge function here: https://github.com/mariusmarais/tailwind-cascade

I've managed to figure out grouping, and out-of-group overrides, but would appreciate some advice on consuming the Tailwind config. A pointer or two on where to start should be enough.

Thanks

[stevica-canadi]

Its quite easy to get the config by using the
const resolveConfig = require("tailwindcss/resolveConfig");

so you can then code it like this for ex.

const resolveConfig = require("tailwindcss/resolveConfig"); const customConfig = require("src/tailwind.config"); const config = resolveConfig(customConfig);

And there it is the whole config in json with all custom added props.

[sgarcia-dev]

Hello @adamwathan! it seems like @dcastil was able to solve this problem with https://github.com/dcastil/tailwind-merge 🙂

// last conflicting class wins
twMerge('p-5 p-2 p-4') // → 'p-4'

// resolves non-trivial conflicts
twMerge('inset-x-px -inset-1') // → '-inset-1'
twMerge('bottom-auto inset-y-6') // → 'inset-y-6'
twMerge('inline block') // → 'block'

// supports arbitrary properties
twMerge('bg-black bg-[color:var(--mystery-var)]') // → 'bg-[color:var(--mystery-var)]'
twMerge('grid-cols-[1fr,auto] grid-cols-2') // → 'grid-cols-2'

Have you taken a look at this yet? Community response seems largely positive, and enough people seem to be in agreement that this is a feature tailwind could largely benefit from for JS SPAs for a while now.

• https://twitter.com/tannerlinsley/status/1550475765468213248 (TanStack creator/maintainer)
• https://dev.to/diogoko/overriding-tailwind-classes-in-react-4po3

Do you know if there's a chance we could see this sort of functionality merged into the official Tailwind package? ❤️ Or something similar that addresses this?

[adamwathan]

I haven't played with it myself because I've never had this problem, but it seems to work great for the people who need it 👍 I would just recommend using this package if it solves a problem you have, no real reason it needs to be first-party.

Personally I've always treated this problem as a sign that the component has opinions baked into it that should be external, or that there is a subcomponent to extract that can have less opinions. It's definitely possible I just haven't run into a super compelling motivating problem though.

[SeanRoberts]

I wrote one of the earlier helpers in this thread but I never use it anymore, @adamwathan is completely right. Once you get a better handle on writing good public APIs for your components that map options to your design system well you don't need it. I tend to provide className as an escape hatch and if someone really wants to force a component beyond what it's meant to do they can use the ! modifier.

[SeanRoberts]

I created a really simple and naive helper for this but there are a number of utilities it doesn't work with at all. The approach is to simply split each classname by the final instance of - and then rebuild based on the last value of each class with those prefixes. Where it falls apart is on utilities like border and text where multiple utilities share the same prefix (e.g. text-red-500 text-xl)

The proper solution would be to iterate over each classname, figure out which utility it belonged to, and then make sure each utility only has one value. However, like @harryhorton I have no idea how to actually begin doing that. The only other alternative would be to tweak your own tailwind config so that no two utilities have the same prefix (e.g. replace text with text-color and text-size)

Anyway, here's the little helper I created, it is still useful as long as you only stick to utilities that don't share prefixes, but it's probably just as likely to drive you insane when you can't figure out why you can't set text size and text colour at the same time. Again, just to be clear to anyone who stumbles into this issue: This snippet not a good solution! Don't start using it without understanding why it will probably break your code

import cx from 'classnames';
import { ClassValue } from 'classnames/types';

/*
  Wrapper around the classnames library that makes later instances of any
  Tailwind utility classes take precedence.  e.g.:

  twcx('text-18 text-14 p-0') returns 'text-14 p-0'
  twcx('p-0', { 'p-1: true }) will return 'p-1'
*/

export default function twcx(...classes: ClassValue[]) {
  const classlist = cx(...classes).split(' ');
  const result = classlist.reduce((result, c) => {
    const prefix = c.substring(0, c.lastIndexOf('-') + 1 || c.length);
    return { ...result, [prefix]: c };
  }, {});

  return Object.values(result).join(' ');
}

If there was a future breaking change in a major release that gave each utility its own prefix then this would be trivial but I can't imagine there's very much appetite from the overall user-base for that.

[mariusmarais]

You could setup some matching functions in precedence order... First hit assigns grouping, last item per group wins.

I use a prefix, so it's getting a little complicated, but you could then pass unrelated classes through there as well, which would be typical in a React className extension:

import { ClassValue } from 'classnames/types';
import classNames from 'classnames';
import { groupBy, partition } from 'lodash';

function createTailwindDedup({ prefix }: { prefix?: string } = {}) {
  const RULES: Array<(name: string) => false | string> = [
    n => [/^text-[^-]+-\d\d\d$/, /^text-white$/].some(r => r.test(n)) && 'text-color',
    n => /^text-\d+$/.test(n) && 'text-size',
    n => n.replace(/^(.*)-[^-]*$/, '$1') // standard tailwind
  ];

  return function twcx(...args: ClassValue[]) {
    const classes = classNames(...args).split(' ');

    const [checkClasses, skipClasses] = prefix ? partition(classes, c => c.startsWith(prefix)) : [classes, []];

    const groups = groupBy(prefix ? checkClasses.map(n => n.replace(prefix!, '')) : checkClasses, n => {
      for (const r of RULES) {
        const v = r(n);
        if (v) {
          return v;
        }
      }
      return n;
    });

    return skipClasses.concat(Object.values(groups).map(g => (prefix ? prefix : '') + g[g.length - 1])).join(' ');
  };
}

[
  [{ prefix: 'tw-' }, 'tw-text-18 tw-text-14 tw-p-0'],
  [{}, 'p-0', { 'p-1': true }],
  [{ prefix: 'tw-' }, 'tw-text-white', 'tw-text-red-400']
].forEach(([config, ...args]) => {
  const twcx = createTailwindDedup(config as any);

  console.log(config, ':\n', args, '=>', twcx(...args), '\n\n');
});

Result:

{ prefix: 'tw-' } :
 [ 'tw-text-18 tw-text-14 tw-p-0' ] => tw-text-14 tw-p-0 


{} :
 [ 'p-0', { 'p-1': true } ] => p-1 


{ prefix: 'tw-' } :
 [ 'tw-text-white', 'tw-text-red-400' ] => tw-text-red-400

This is getting pretty close to a package and obviously would need many tests :)

RULES NOT COMPLETE - DO NOT USE

I think that could work, but would we'd need to define all the rules.

Please tell me someone already built this

[harryhorton]

@SeanRoberts looks cool! Thanks for sharing! I tried creating utilities too, but there was complicated to try to cover all the use cases.

I ended up using https://github.com/ben-rogerson/twin.macro

Not as good for minimal css, but great for the kind of flexibility I needed. By compiling to CSS, you can do simple overrides and easily use tailwind classes via props.

I start with classes only, and move to twin macro when I need more flexibility.

[SeanRoberts]

@harryhorton Oh cool, I hadn't heard of this before! What approach do you use for the problem we're talking about in this issue? Does it just handle merging classnames automatically? If you do <div className={twp-0 p-2} /> does that just take care of it? If so this seems like a perfect solution.

[harryhorton]

@SeanRoberts My preferred approach looks like this:

If I'm not doing anything programmatic with tailwind classes

 const Thing: FC = ()=>(<div className="bg-red-500" />)

If I have ANY conditional logic, I'll take this approach:

import tw from "twin.macro";
import { ButtonProps } from "./types";
import styled from "styled-components";

export const StyledButton = styled.button<ButtonProps>(
// using the styled components array form makes it really easy to conditionally include styles.
  ({ flat, fullWidth, small, text, disabled }) => [
   // this is the base/default
    tw`text-white rounded px-6 py-2 bg-blue-600 shadow`,
   // these are conditional overrides and additions
    fullWidth && tw`w-full`,
    small && tw`text-sm px-5 py-1`,
    flat && tw`bg-transparent shadow-none`,
    text && tw`p-0 bg-transparent shadow-none`,
    disabled && tw`opacity-75`,
  ]
);

Passing values like nubmers or colors is a little wonky as I'm pretty sure twin-macro will complain if anything but a complete tailwind class is output, but I haven't had to do that yet.

One of the benefits of this approach is that it makes it easy to mix with regular CSS using styled components. With overrides, anything that comes after will override the first just like css (because that's what it copiles to).

Another benefit is that you can use Styled components to compose styles together using tailwind. Something you can't easily do with just classes and requires overrides.

Hope that helps!

[SeanRoberts]

@harryhorton Awesome, thanks for sharing! Hopefully at some point we'll have the tools to be able to just merge the classNames rather than having to generate more CSS with a macro but this definitely solves the problem for me and probably anyone else who finds this issue in the meantime.

[mariusmarais]

Been looking at this some more this morning... Found https://github.com/muhammadsammy/tailwindcss-classnames who has classnames => plugin mapped out, but using just that would lump all margins together, all paddings together, etc., instead of per direction.

Someone could map everything by hand, but ideally TailwindCSS could generate a list of classes and their grouping at build time, maybe into a separate file? It would then be quite simple to load that and handle 'last write wins'.

{
"m-0": "margin",
"m-1": "margin",
"m-x-1": "margin-x",
"-m-x-1": "margin-x",
...
"uppercase": "typography-casing",
"lowercase": "typography-casing"
}

It feels like that info should be available inside the build system somewhere? Or maybe the ruleset isn't as complicated as I think it is, and my approach above could work?

[SeanRoberts]

I think that mapping of classname to grouping is really going to the key to having a utility that works perfectly for this. Especially because classes are dynamically generated, so one team might use classnames like "text-14 text-16 text-18" and another might use "text-sm text-lg text-xl". Splitting by hyphens also completely falls apart when you get into classes like "bg-red-500" or "text-extra-big"

I think it would either need to be part of the build step, or a separate tool that reads your config file and generates the manifest.

[mariusmarais]

Not promising anything, but I've spent the last couple of hours playing with options and I'm now busy manually capturing everything into a map...

[mariusmarais]

I captured all the class names manually and put it in a package: https://github.com/mariusmarais/tailwind-cascade

@harryhorton @SeanRoberts, would you mind taking a look to see if this covers your use cases? Working for me so far, but I haven't really made anything very complex with it yet.

It currently uses a build-time generated config, but could be modified to read tailwind.config.js, but that would require more insight into Tailwind than I currently have.

[SeanRoberts]

@mariusmarais This looks great! I think it'll work in the vast majority of cases, thanks for putting all the work in. I don't think we'll be able to have something bulletproof until there's a way to get access to the actual config object, but this is really close.

[jonaskuske]

Another alternative would be to generate utilities with lower/higher specificity than the normal ones, which you can use when you want to override something or allow something to be overridden. You could for example generate base variants that appear before the normal utilities in the stylesheet (but are otherwise the same):

/* generated CSS */
.base\:text-red { color: red }
.base\:text-blue { color: blue }

.text-red { color: red }
.text-blue { color: blue }

const Text = ({ className, children }) => (
  <p className={`base:text-red' ${className}`}>{children}</p> 
)

<Text className="text-blue">I am blue, da ba dee, da ba di</p>

This is sort of similar to the props-based approach @harryhorton proposed as you'll still have to explicitly declare which style props should be overridable by consumers and which shouldn't (not a bad idea anyway imo), but you wouldn't have to deal with two different style APIs (style props and tw classes) across the codebase anymore.

You could also do the opposite, generate utilities that appear after the normal ones. This feels similar to !important so I went with the ! but it doesn't actually have the same downsides: since the "important" classes only beat the normal ones by being declared later in the stylesheet instead of having a higher specificity score, they can still be overridden by hover: styles and so on:

/* generated CSS */
.text-red { color: red }
.text-blue { color: blue }

.text-red\! { color: red }
.text-blue\! { color: blue }

const Text = ({ className, children }) => (
  <p className={`text-red ${className}`}>{children}</p>
)

<Text className="text-blue!">I am blue, da ba dee, da ba di</Text>

However, the downside of both of these approaches is that they only allow to increase specificity by one level (two if you combine base, normal and important), so you can override once but after that you're SOL. Should be fine for most cases but not as flexible as CSS-in-JS libs, so worth pointing out.

Anyway, not sure if this could be done via a Tailwind plugin without having to copy-paste Tailwind core? 😅
(@adamwathan)

[mariusmarais]

Yes, I went down that route initially, building the CSS twice, first normally, then with the important: "#app" trick to increase specificity. It works, but only to the level that you're willing to duplicate, as you mention. In my project I'm replacing Bootstrap piece by piece, so I need !important just for Tailwind to get out of bed in some cases :)

I think a JS function that can compute overrides is the best way to solve this problem. I think my experimental package works quite well, and has handled everything I've thrown at it.

However, its major weakness is still the grouping of Tailwind classes. I don't really see a way out unless Tailwind generates the / a grouping file as part of the build.

I've looked at the Tailwind source, and it looks like it wouldn't be too difficult to add a grouping specifier for the base utilities, but the onus would be on every plugin to opt-in by specifying a grouping, which won't happen unless the overriding is a core feature of Tailwind. One could expose something in the config to provide grouping info as a stop-gap for users, but ultimately it wouldn't work without critical mass of plugins opting in.

The reason for the opt-in requirement is simple: because there's no naming convention enforced, there is no way to know which classes are in conflict without the author providing that information, which I think is actually a good thing. Well-designed Tailwind plugins will need to give thought to how their pieces compose with the base in any case.

I think the alternative of parsing the generated CSS in JS, and essentially having a mirror implementation of CSS rules to determine overrides would be terrible. If this idea appeals to you, just go with your preferred CSS-in-JS solution, it will work much better than building a CSS-in-JS lib into Tailwind.

[joseDaKing]

Nice idea, the metadata generated should also include all the variants for each group so they will not conflict. You could also generate metadata for media queries so they can be used for removing elements from the code and not hiding elements with CSS. If atomic CSS is not used problems could occur but that the responsibility of the plugin maker, but either way I would write my own plugins so it is not a big problem for me. The best thing about your approach is that would not require breaking changes, do you think we should notify Adam and the other people working/maintaing the library.

[mariusmarais]

Yes, I would love it if someone with more insight into the codebase could weigh in. I don't really like summoning people to discussions, but where goes... @adamwathan could you please take a look or delegate? 😄

A concrete example is here https://github.com/mariusmarais/tailwind-cascade and it goes deeper into the mechanism in the readme.

How feasible is it for Tailwind to generate the override from config?

[anton-nikiforenko]

You could create special css classes for your components in tailwind components layer and apply mixins to such classes: https://tailwindcss.com/docs/extracting-components

@layer components {
  .base-button {
    @apply bg-blue-700 px-3 py-1;
  }
  .special-button {
    @apply bg-green-700 px-5 py-2 text-lg;
  }
}

For BaseButton with className='bg-red-500 py-0' applied styles will correspond to bg-red-500 px-3 py-0:

const BaseButton = ({ className, ...props }) => (
  <button className={'base-button ${className}'} {...props} />
);
const SpecialButton = ({ className, ...props }) => (
  <button className={'special-button ${className}'} {...props} />
);

[ianjamieson]

Untested, but I suppose you could create a "last" breakpoint in your tailwind config:

const { screens } = require('tailwindcss/defaultTheme');
module.exports = {
  theme: {
    ...
    screens: {
        xs: '370px',
        ...screens,
       override: '0px'
    },
   ...
  }
}

Then override:bg-green-700 would always override bg-blue-700 as it would be compiled last in the CSS

⚠️ See updated solution further down the page

[mariusmarais]

That's quite clever, but you would still have only one override level :-/

[muubar]

worked for me! thanks a lot!

[richardtallent]

Awhile back I came up with another pure CSS solution:

#3523

Like @ianjamieson's solution, it only allows for one "level" of override.

The difference is that it provides a variant that "underrides" normal class selectivity. So, as a component author, you can set up some "default" colors, etc., and the component user can override them with normal Tailwind classes.

[mariusmarais]

Again, pure genius :)

But I think we're seeing that overriding is something that would be useful in core, since so many people are coming up with novel ways of achieving it, but all with fundamental limitations.

I'm starting on a new project now and I'm giving the CSS-in-JS thing a try with twin.macro and emotion. I don't really like it that much (too much magic), but it has solved every single scenario I can think of.

[abradley2]

Just my 2 cents:

Most of the problems around needing an override system go away once you accept it's better to just split major visual distinctions of a single component into separate components. And for minor visual distinctions, to just not have the component apply any default version of that class so there's no issue with "override precedence".

Being able to tell what something will look like in the browser just by glancing over the markup in your component is one of the strong guarantees of Tailwind- and arguably one of the theses of Atomic CSS in general. Large amounts of conditionals and overrides done purely for the sake of fitting 4 visually distinct versions of a single component into a single render call subtracts from this I feel. It's definitely what we're used to in other popular UI frameworks so I feel where the desire comes from. But I think building this into Tailwind would overly encourage this behavior- even if there's sparse exceptions where it'd be nice to have in a responsible way.

[mariusmarais]

I'd argue the opposite. If we have class-level overriding, then you can override by just using the classes from Tailwind. If you don't, you end up with these monstrosities where props are used to dynamically build classes or styles. (That's what your example actually shows, using props to build classes.)

The whole point is to not do that.

In my usage (React), we have a standard <MyButton/> that applies our general brand guidelines. But when you put three of them next to each other, and you want to go from [==] [==] [==] to [=|=|=] you can't by just adding classnames. So you end up with silly props to apply classes only in certain cases.

Whereas, if you can override simply with classnames, it's as easy as:

<div>
  <MyButton className="w-24 rounded-r-none">Left</MyButton>
  <MyButton className="w-24 rounded-none">Middle</MyButton>
  <MyButton className="w-24 rounded-l-none">Right</MyButton>
</div>

// on top of a 
const MyButton = ({className, children, ...other}) => {
  return <button className={
    magicMethod("text-sm w-32 border border-gray-300 rounded-md cursor-default", className)
  } ...other>
    {children}
  </button>;
};

(Note that there are no additional props to what a button takes.)

That ^^ doesn't work right now because of the definition order of the CSS width & rounded classes. An especially nice foot-gun is that w-48 will work but w-24 won't. It does work through my mapping util (magicMethod), but that needs to be updated by hand and kept in sync with TW versions, config, etc.

You are essentially advocating to split this example into two (with additional prop direction=L/R/M) or four (for L/R/M each) base components, which cannot share common branding classes, or to go back to slightly better custom CSS with @apply.

So, to clarify, the idea is build LESS, SIMPLER base components that allow overriding, not complex components that have branching logic and gotchas.

Do you really think multiple components is a better choice, or have you simply accepted it as the only option?

[mariusmarais]

(Sorry for more text...)

The above is possible using some of the workarounds mentioned in this thread, but the following isn't: a "ribbon button" component, because overriding that would require an entirely new additional overridable layer or duplication. For example:

const RibbonButton = ({className, position, children, ...other}) => {
  const borderTypes = { left: 'rounded-r-none', middle: 'rounded-none', right: 'rounded-l-none' };
  return <MyButton
    className={magicMethod(borderTypes[position], 'w-24', className)}
    ...other
    >
    {children}
    </MyButton>;
}

Overriding that ^ again to add more stuff might be difficult, depending on where you used what, meaning the component-authoring process becomes whack-a-mole with Tailwind.

(These examples might seem trivial and convoluted at the same time, but in a large app the component hierarchy can become immense -- either vertical with inheritance or horizontal with mixins / @apply / manual copy & paste. If components can be stupid-simple, but still override-able, things are much more manageable, especially when working with branding guidelines.

Think of adding standardised disabled state to that base button, or "canHover" apply standard overridable classes, or so-on.)

[abradley2]

Tailwinds UI has a separate React button component for the following:

• Button with leading icon
• Button with trailing icon
• Primary Button
• Secondary Button
• White Button
• Round Button

It's certainly not un-idiomatic to repeat components.

While I can't speak for the creators; I think Tailwinds favors comprehension over configuration, that it's better to have multiple inflexible components with understandable markup than to have a single flexible component that offers little hint of what it actually looks like on browser.

I think your example case though is pretty easily expressed without worrying about override precedence. When I do need "overrides", I feel it's better expressed by not having the "base class" defined in the base component at all- instead insisting that all uses of the component provide for this. It's simple when they're all part of the same file

<div>
  <LeftButton>Left</LeftButton>
  <MiddleButton>Middle</MiddleButton>
  <RightButton>Right</RightButton>
</div>

/* Buttons.tsx */
export const DefaultButton = button("w-32 rounded-md)
export const LeftButton = button("w-24 rounded-l")
export const MiddleButton = button("w-24")
export const RightButton = button("w-24 rounded-r")

const button = (className) => (function Button ({children, ...other}) {
  return <button ...other className={clsx("text-sm border border-gray-300 cursor-default", className)}>
    {children}
  </button>;
})

I commonly see people resorting to stuff like this in tailwinds where I can't even glean what the component looks like slightly just by glancing over the body of render as I should be able to do:

  return <button 
    className={clsx(
      props.buttonType === buttonClass, props.className)}
  >
    {props.LeftIcon ? <span className={clsx(leftIconContainerClass, props.leftIconContainerClassName)}><Props.LeftIcon>
    {label}
   { props.rightIcon ? .... etc

and my feeling is adding this to core would further encourage this approach

[mariusmarais]

I agree that specialised components make sense, but I disagree that it's preferred to have duplicating styles once you do that. I would like to have base styling handled at the base level. Maybe one higher than the actual logic component like headlessui, but certainly not every time you use it.

I also agree that your last example is a mess, I'm also trying to do away with that kind of thing in base-level components.

But it feels like only half of the maintainability question is answered. What about rebranding? Refreshing all UI because your callcenter upgraded to 1080p screens? Your field agents switching to a ruggedised device with and odd screen?

If every project is clean slate build & ship, then that approach works, but working on a constantly expanding core business operations project you need better answers for long-term maintainability. Maybe TW isn't really aimed at that segment, but it could be, or at least not make it worse.

[stevica-canadi]

On the other hand, Tailwind CSS intellisense has a similar function, for example if you type in two classes that will override each other in the className it will give you a warning.

So there is an existing logic for that inside that plugin repo

I thinks its
https://github.com/tailwindlabs/tailwindcss-intellisense/blob/master/packages/tailwindcss-language-service/src/diagnostics/getCssConflictDiagnostics.ts

I will try to understand the logic behind it :) But its not quite so simple, maybe somebody will figure it out :)

[ianjamieson]

A better solution now will be to use the JIT compiler and the
Built-in important modifier. Taken from there example, you can have:

<p class="font-bold !font-medium">
  This will be medium even though bold comes later in the CSS.
</p>

[ianjamieson]

@adamwathan - with my blade components I have a panel for example which is used like:

<x-panel>
<h2>Some title</h2>
<p>Some paragraph</p>
</x-panel>

Which has a default space-y-md class. But sometimes, we want to have space-y-lg. So for me the trade off of requiring everytime to write this:

<x-panel class="space-y-md">
<h2>Some title</h2>
<p>Some paragraph</p>
</x-panel>

Is worth it, otherwise I am expecting a backend dev using these components to have to always remember how to add the space between and what space it should be.

[adamwathan]

For tweaks like that consider just defining a prop.

<x-panel spacing="lg">

...where the default is medium.

[ianjamieson]

Yeh I was going down that route initially, but then I was coming across times where maybe that prop needs to be used on multiple components. And I was defining logic to add the classes on each individual component as well.

This was abstracted using traits, but then if you have just a simple component you need still create an additional PHP class, consume the properties in the PHP class and include the trait.

I ended up coming to a logical conclusion to have something like <x-panel override-space-x="lg"> That could be a generic attribute that is applied to all components, override-tailwind-class-name="overridewith". But I felt that could also get complicated as well.

[jackblackCH]

Thank you for this! I tried hard searching for my issue and found this solution!

[jeremy303]

Won't use of the JIT feature really inflate our production bundle size, since tailwind would no longer be a dev dependency? Especially if we use additional tailwind extensions such as tailwind-typography?

[joseDaKing]

Hi, everybody if you are using React, you could then use xstyled. Xstyled is a CSS utility library written on top of styled-components and emotion, thereby it makes overriding CSS much easier. The library is good alternative for this stuff.

[szamanr]

this is my solution using the classnames library to render classes conditionally:

<button className={classNames([className], {
  "bg-white": !className.match(/\b(bg-)/),
  "border border-gray-200 rounded": !className.match(/\b(border)/),
  "px-3 py-1": !className.match(/\b(p|px|py|pt|pr|pb|pl)-/),
})} />

here className is the custom prop passed to the component, and you can group the base classes by type and specify a keyword which will override them if present in the passed className. note the word boundary selector (\b) which will make sure it catches bg-4 but not foobgbgbgbgbgbgbar.

gets a bit messy with things like padding, but does a good job overall.

[dcastil]

Hey @harryhorton! I think I solved the issue you have here → https://github.com/dcastil/tailwind-merge. The main difference is that the merge function is called twMerge() so you save yourself typing 6 extra characters. 😄 You can also configure it to match custom Tailwind configs!

[AaronBeaudoin]

@adamwathan:

One day I'd like to explore a proper CSS-in-JS flavor of Tailwind that would handle stuff like this better but I'm going to close this for now as a "not working on this any time soon" sort of thing unfortunately. If you do end up hacking on it as a separate project I'd love to see how it goes 👍

Perhaps now that Tailwind v3 is out and looking great it's a good time to revisit this idea? I think the benefits of this approach could be huge, specifically this thread's idea where styles (including atomic classes) are scoped to components like their surrounding JS, and then styles and classes outside can override them. I think it makes a lot of sense.

The props approach kind of conflicts with the philosophy of avoiding naming styles for things, and it harder to read then creating some base component and then wrapping it in another component which add styles or modifies existing styles.

[richardtallent]

Here's my solution, as a plugin:

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

This adds a "def:" variant you can use in a component to specify TailwindCSS classes you want to be default styles. Any class using this variant can be overridden on a component instance with normal TailwindCSS classes.

Example:

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

4. Override as needed for your component instances

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

This only gives you one "level" of override before you have to resort to other means to get more specificity, and doesn't work in Safari 13 and below, but otherwise, it's a simple, no-JS-required solution.

And I have to mention, this is my first plugin, the Tailwind CSS plugin and variant architecture is very easy to work with!

[benface]

Cool solution :)

[Sylvenas]

👍👍👍 That's brilliant.

[adamwathan]

Here's an approach very similar to @richardtallent's idea but adds html to the beginning of the selector to keep the specificity high enough to override base styles:

https://play.tailwindcss.com/1j10rEZpsq?file=config

Downside is the specificity is too low to defeat component styles still, so not totally perfect.

Personally I think the right solution for this sort of thing is a prop on the component for controlling this:

function MyComponent({ radius = 'default' }) {
  let radiusClass = {
    default: 'rounded',
    full: 'rounded-full'
  }[radius]

  return (
    <div className={`${radiusClass} ...`}>
      {/* ... */}
    </div>
  )
}

<MyComponent radius="full" />

That's how we've always handled this in our own projects 👍🏻

[erhankaradeniz]

This does not work for buttons, as the base style reset has a higher specificity see your example

[AaronBeaudoin]

Hey all, another approach I've found to this problem that seems promising (if you use Vite) is to simply not using vanilla Tailwind.

Instead, I'm using UnoCSS, another atomic CSS library by antfu which I discovered recently that has full support for Tailwind, but with a lot more too. There's a bunch of great things it does that I won't mentioned here since it would be off-topic, but the relevant feature for this thread is that when using the Vite plugin you can scope the generated classes using a few different strategies:

• If you're using Vue, scope to the .vue file with vue-scoped.
• If you're using Svelte, scope to the .svelte file with svelte-scoped.
• Or, best of all, you can scope to the current module with per-module (Experimental).

This doesn't necessarily directly address the issue of the CSS cascade, but so far from my testing it seems that this strategy—combined with the different way that UnoCSS generates the classes when compared with vanilla Tailwind—resolves the issue.

I'd be interested to hear if you all have the same experience.

[loy-lin]

@AaronBeaudoin Hi. I'm interested in this approach, but I failed to see how it could help to resolve this issue. Could you explain more?

[mwnciau]

I've managed to solve some of the problems others have run into and have created a Tailwind plugin, tailwind-unimportant, that creates class variants that can be used in components. 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

E.g.:

// 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>

[richardtallent]

This is great! Glad someone cracked that nut! Looks like this is going to make my "override" plugin obsolete, which is a good thing!