[v4] generated CSS variables clash with existing variables

[akphi]

What version of Tailwind CSS are you using?

v4.0.0

What build tool (or framework if it abstracts the build tool) are you using?

CLI

What version of Node.js are you using?

v21.7.3

What browser are you using?

Chrome

What operating system are you using?

macOS Sonoma 14.6

Reproduction URL

https://play.tailwindcss.com/qbun7ly6QS?file=css

Describe your issue

In our project, we have already defined our own color palette using CSS variables like --color-gray-200, --color-red-100 etc. like below

/https://github.com/finos/legend-studio/blob/f6028bc13825bf2006d6439c659417b269c272d2/packages/legend-art/style/base/_variables.scss#L18-L131

Now in v4, the auto-generated CSS classes from Tailwind will clash with those and cause us a headache to migrate over. I hope having a feature to enable adding a prefix to the namespace of Tailwind-generated CSS variables like --tw-color-red-100 (when prefix='tw') would be super helpful and allow a smoother transition for people.

I started a discussion thread on this #15711 but realized from the responses that this could be a more common scenario for projects upgrading to v4 than I realized, so I want to flag this as a bug.

Thank you so much for this great library!

[n3oAlex]

From the documentation it seems possible in v4 by overriding the default colors

@theme {
  --color-*: initial;
}

and then redefining tailwind colors (copy/paste + edit)

@theme {
  --color-*: initial;

  --color-tw-red-50: oklch(0.971 0.013 17.38);
  --color-tw-red-100: oklch(0.936 0.032 17.717);
  --color-tw-red-200: oklch(0.885 0.062 18.334);
  --color-tw-red-300: oklch(0.808 0.114 19.571);
  --color-tw-red-400: oklch(0.704 0.191 22.216);
  --color-tw-red-500: oklch(0.637 0.237 25.331);
...
}

It's not ideal, but for one time setup seems ok.

PS: Not sure if this works since I'm still in the process of migrating myself 😅.

[akphi]

From the documentation it seems possible in v4 by overriding the default colors

@theme {
--color-*: initial;
}
and then redefining tailwind colors (copy/paste + edit)

@theme {
--color-*: initial;

--color-tw-red-50: oklch(0.971 0.013 17.38);
--color-tw-red-100: oklch(0.936 0.032 17.717);
--color-tw-red-200: oklch(0.885 0.062 18.334);
--color-tw-red-300: oklch(0.808 0.114 19.571);
--color-tw-red-400: oklch(0.704 0.191 22.216);
--color-tw-red-500: oklch(0.637 0.237 25.331);
...
}
It's not ideal, but for one time setup seems ok.

PS: Not sure if this works since I'm still in the process of migrating myself 😅.

We did explore this approach but the problem is our current codebase relies on native tailwind classes bg-red-500, bg-sky-600, etc. so doing --color-*: initial will break those. What we're looking for is not just that having --color-tw-red-50 and so CSS variables available, but make sure native tailwind classes like bg-red-500 still work, i.e. tailwind will generate something like

.bg-red-500 {
  background-color: var(--color-tw-red-500);
}

[akphi]

@RobinMalfait Hi, I notice you're making a lot of fixes/adjustments for CSS variables in v4. Could you kindly opine here on what the team thinks of this proposal? As said, this is not a hard blocker but would require considerable effort on our end to migrate to v4.

Thank you so much!

[philipp-spiess]

Hey! I decided to move this to the ideas section since it's not something we're actively working on right now. Something you can already do is enable prefixing globally: https://play.tailwindcss.com/fKhulZfoj4?file=css This will prefix CSS variables but also all class names.

Another idea is to rely on theme inlining to not emit any variables: https://play.tailwindcss.com/mmZKx4FlSl