Unexpected behavior when custom `@theme` vars and `@utility` share same names

[ivodolenc]

Hi, I just bumped into an issue where having a custom CSS variable defined in @theme with the same name as a custom tw @utility causes duplicate classes to be generated, with incorrect properties. This breaks the CSS and results in styles not rendering properly on the page.

I'm using the latest version of tailwind in a sveltekit project with the default configuration. I also tested this in the official tw playground and I see the same behavior. Screenshots are attached so you can immediately see that something's wrong.

Playground link

I spent more than half an hour trying to find the problem. After renaming the custom variable, everything worked fine again. I believe this should be addressed, since CSS variables --custom-name and tw utilities .custom-name are diffirent concepts and shouldn't interfere with each other.

I'm running into this because I want to define a custom utils and vars for variable font in the @theme config:

@theme {
  --font-400: 'wght' 400;
  --font-ss-3: 'ss03' 1;
}

So I can use it later with custom util:

@utility font-400 {
  font-variation-settings: var(--font-400);
}

@utility font-ss-3 {
  font-feature-settings: var(--font-ss-3);
}

or via custom css directly if needed:

p {
  font-variation-settings: var(--font-600);
  font-feature-settings: var(--font-ss-3);
}

These variable names should remain isolated, custom properties under @theme shouldn’t conflict with custom @utilities.

In short: everything works as expected unless a custom @theme variable shares its name with a custom @utility, in that case, CSS breaks due to conflicting class generation.

[wongjn]

As a workaround, you could consider prefixing your variable so that it doesn't start with the --font namespace: https://play.tailwindcss.com/9w6Brvhp9w?file=css

[ivodolenc]

Yes, but as a workaround. The main point here is to stay consistent, because if I later need to use this directly in CSS, I know the class name is font-600, so I just need to write the same name in the original var(--font-600) function. There's no need for prefixes because that can get complicated and confusing very quickly.

Honestly, all of this could have been avoided if we had a native solution for using @apply. Since @apply is strongly discouraged in V4, this all becomes very difficult when trying to write custom CSS quickly. Custom CSS is needed when we need to style dynamic content for markdown, which I use a lot.

Also, if we want to completely switch to native CSS, what is the purpose of --sizing(), --alpha(), and other similar Tailwind functions and directives? Why would we use them and not @apply?

Sorry, I know this is a topic for another discussion, but I think if I could use @apply regularly without worrying about what others will say nowadays or whether it will become obsolete, I wouldn’t encounter this kind of problem.

Now I have to write full CSS and use var(), calc(), etc. everywhere. If we gain some good features with the new Tailwind version, we also lose some good ones too, so in the end, it’s not such a great update in real project examples. I’m talking about a real project, not examples from documentation pages, right?