[v4] Some generated tailwind CSS variables are not prefixed.

[benjamin-andersen]

What version of Tailwind CSS are you using?

v4.0.14

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

Latest Tailwind Play

What version of Node.js are you using?

Latest Tailwind Play

What browser are you using?

Chrome

What operating system are you using?

macOS

Reproduction URL

Tailwind Play: https://play.tailwindcss.com/SLkLs6VhC4?file=css

Describe your issue

When using a prefix, I expect every tailwind generated CSS variable to use this prefix. This does not seem to be the case for certain utility classes, and can cause existing CSS variables to override the tailwind generated CSS variables.

Example:
If I set the prefix to foo, foo:translate-y-[50px] will generate the following CSS:

.foo\:translate-y-\[50px\] {
  --tw-translate-y: 50px;
  translate: var(--tw-translate-x) var(--tw-translate-y);
}

I expect foo:translate-y-[50px] to generate something like:

.foo\:translate-y-\[50px\] {
  --foo-translate-y: 50px;
  translate: var(--foo-translate-x) var(--foo-translate-y);
}

[adamwathan]

Hey! Yeah so it's only theme variables which are prefixed — stuff like --tw-translate-y are private internal variables that we use just to make certain features work, you're not really supposed to know about them or interact with them.

Is there a specific issue you are running into because of these not being prefixed with your custom prefix?

[benjamin-andersen]

Have you found a (good) solution to the problem? I'm in the same boat at the moment. We have quite a few applications that use are using tailwind themself, a component lib which we can upgrade to 4 at the same time. But at runtime we inject a module that still uses v3. We plan to upgrade this as well, but there is not graceful migration path as it seems.

I lose box shadows in tailwind 4 pathes due to conflicting tailwind 3 defintions.

@beckerei No unfortunately I have not found a good solution here. I ran into the box-shadow issue as well, and the "best" workaround I have is just re-writing the CSS manually in my global CSS file.

You can reference the docs for the CSS Tailwind has, but your CSS might look different depending on what you need. For me, it looks something like this:

@utility shadow-lg {
  box-shadow:
    0 10px 15px -3px rgb(0 0 0 / 0.1),
    0 4px 6px -4px rgb(0 0 0 / 0.1);
}

This is very cumbersome and it would be great if all of the CSS output by Tailwind was prefixed by the prefix you set. That would prevent any of these issues.

[beckerei]

I stumbled upon #10697 (comment) minutes ago.
So I will try to do this in my tailwind 3 project

[benjamin-andersen]

@adamwathan It's also worth noting, that this is a huge issue if you are using Tailwind to build a "widget" which is injected into an existing website. You'll be able to prevent 90% of any CSS conflicts by prefixing in Tailwind, but if that website also uses Tailwind (or an older version), the internal variables will clash and cause issues since they are not prefixed.

[beckerei]

We inject our navbar with good old server side includes into all kind of different apps, some are SPA, some are next, some are rails.

[beckerei]

Can confirmd that this fixed the problem for us 🚀

[abouolia]

+1. I would rather both local and global variables to be prefixed to avoid any potential issues. For instance, once used an external component its Tailwind styles applied under a body class .body .p3 (I don't agree to), resulted high CSS specificity, which caused some styles at my app level like translate is always ignored—unless I used !important.