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?

[adamwathan]

Hey! To me this is all expected behavior — anything you declare under --font-* inside of @theme creates new font-family utilities, just like adding anything under --color-* creates new color utilities.

If you want to define a variable called --font-600 that does not drive the existing utilities in Tailwind, just don't define it with @theme:

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

I'm not sure what you mean about @apply here, what would you rather do than what you're doing in the original post by using @apply?

Stuff like --spacing() is very useful in stuff like arbitrary values when you need to use calc(), like py-[calc(--spacing(1)-1px)], using @apply wouldn't help there.

[ivodolenc]

Thanks for taking the time to respond and help, I appreciate it!

anything you declare under --font-* inside of @theme creates new font-family utilities,

Ah, I see, I didn't know about this --font-* behavior.

If you want to define a variable called --font-600 that does not drive the existing utilities in Tailwind, just don't define it with @theme:

Honestly, I haven't tried this at all. This is what I need, thanks a lot for the advice, this fixes the issue!

I was of the opinion that all variables related to configuration or theme should be written inside @theme.

---

Regarding @apply, if it were recommended to use that directive, I would do this instead:

@utility font-400 {
  font-variation-settings: 'wght' 400;
}

and later use it like this:

p {
  @apply font-400;
}

So I wouldn't need any additional custom variables at all.

Right now this works fine, but there are many cases where people say that it is not recommended to use the @apply directive in the new version 4 and how it could be deprecated etc.

I think this all started when you officially tweeted that @apply shouldn't have been introduced in the first place, so everyone loses their minds when @apply is mentioned, but actually this is the best thing about Tailwind.

This is a big win for writing custom CSS quickly, no need to even think about what the real name of a CSS property is or anything like that, just apply the class name and that's it.

Right now I have to write full stylings and think about the real CSS which slows me down a lot.

Also, when i need to write transitions with custom css, using apply is easy:

p {
  @apply transition-colors;
}

This becomes difficult to reproduce with native css.

Stuff like --spacing() is very useful in stuff like arbitrary values when you need to use calc()

I know, but this could have been written simply like this:

p {
  margin-top: calc(var(--spacing) * 4);
}

or

<div class="pt-[calc(var(--spacing)*4)]"></div>

It's a nice addition and all, but if we can use some functions and other non-native directives, why are people so against @apply?