[v4] Safelist?

[ev3rlost]

With no tailwind.config.js in v4 anymore - how can we implement the safelist: [] option in v4? Is there a @safelist directive?

[adamwathan]

Not solved yet but something we're going to look into soon. I secretly wish no one used this feature though 😄

[ev3rlost]

Thanks for the info Adam! I imagine it must be a pain to implement 😄. But there are so many use-cases for it, specially for dynamic class names.

I understand the docs instead of writting like this:

<div class="text-{{ error ? 'red' : 'green' }}-600"></div>

... you have to write like this:

<div class="{{ error ? 'text-red-600' : 'text-green-600' }}"></div>

Thats using Blade. But what about Alpines conditional classes?

<div :class="error ? 'text-red-600' : 'text-green-600'"></div>

The above doesn't seem to work.

Would you suggest to just pop a div on the layout file and apply all those conditional classes to it and hide the div? That's what I've done but it seems realy hacky 😄

[quentinjeanningros]

any news about that ?

As long as it was in September. And tailwind 4 is officially out. Can't find any reliable solution to this.

I passed a whole day migrating a whole (react, ts, vite, twmerge) app manually to it. It's the only remaining issue. I would be a bit upset to give up so close to an end. Moreover, give up now will make me restart everything in maybe 2-3 month.

Had issue with gradients.

[patryd]

@adamwathan Hey Adam, using a lot of enterprise headless CMS setups, we always need to work with safelist as we are building mini page builders.

[RobinMalfait]

Hey everyone!

A new safelist option is coming. Instead of regex patterns you will be able to use bash brace expansion syntax.

More info in the PR: #17147

[ISOR3X]

Hi, just wondering if there is an update on this. I am using a variable name in my class name (something like bg-[rgb(var(--color-${color_var}) and without safelisting I am not sure how to get Tailwind to recognize the classes properly.
Alternatively, if anyone has a 'better' way of handling these situations please feel free to share them.

[wongjn]

You could consider using the style attribute like:

<div style="background-color: rgb(var(--color-${color_var}))">

[ISOR3X]

You could consider using the style attribute like:

<div style="background-color: rgb(var(--color-${color_var}))">

While that would solve the issue, it does prevent using it with Tailwind Variants without it becoming quite complex I think.
For reference I would have at least two button styles where each would have a different background color.

[wongjn]

If you are using Tailwind variants, you shouldn't need to use interpolation at all:

import { tv } from 'tailwind-variants';
 
const button = tv({
  base: '…',
  variants: {
    color: {
      primary: 'bg-[rgb(var(--color-primary))]',
      secondary: 'bg-[rgb(var(--color-secondary))]',
    },
  }
});

Or otherwise, consider providing more context to your desired usage.

[ISOR3X]

If you are using Tailwind variants, you shouldn't need to use interpolation at all

Since I have like 15 different colours I didn't want to type them all out. I got the idea from Nuxt UI v3, but I assume they are doing something additional that allows it to work.

[robsontenorio]

Is there any news on how safelist will work in v4?

(not using tailwind.config.js)

[adamwathan]

Not yet, until we tackle it I would just recommend creating a safelist.txt file somewhere that has all the classes you want to safelist and Tailwind will automatically scan that and include them. I really, really think the pattern-based stuff is a huge anti-pattern so I'm hesitant to make it too easy, we never need safelisting at all in any of the projects we work on so I'm really not convinced it's necessary, feels more like a band-aid.

How are you using it in your projects?

[robsontenorio]

@adamwathan

Ex: OrderStatus is a table. It contains short and long description about each status. And a extra column “color” with tailwind classes.

<span class=“{{ $order->status->color }}”> {{ $order->status->name }} </span>

More details about status here …

So, I use regex to safelist this color variations.

[Meatclump]

Not yet, until we tackle it I would just recommend creating a safelist.txt file somewhere that has all the classes you want to safelist and Tailwind will automatically scan that and include them. I really, really think the pattern-based stuff is a huge anti-pattern so I'm hesitant to make it too easy, we never need safelisting at all in any of the projects we work on so I'm really not convinced it's necessary, feels more like a band-aid.

How are you using it in your projects?

If I fetch content into my reactive app from a wordpress backend, is there a better way to include a predefined set of classes that the user can utilize than through a safelist?

[bozzhik]

it's a bit of a strange technical solution, but nevertheless
#14462 (comment)

[CanRau]

I guess it's always possible to include all supported classes somewhere, be it a component's allowed props or maybe even a text file you import somewhere, right?

[robsontenorio]

Of course this works. But , it’s not the same of safelist feature.

[ArturasTv]

I faced one use case for cms html content that uses Tailwind for styling. I think Tailwind v4 should natively support a safelist again.

[bozzhik]

same, check my reply in this discussion
#14462 (comment)

[quentinjeanningros]

As long as it's the only thing that prevent me from going to v4 I created an issue to know the development point of it.
#16591

[quentinjeanningros]

here a good answere made and explain the global issue with safelist and how to implement similar things

if anyone wondering #16592 (comment)

[bozzhik]

When migrating the project to Next.js v15 and Tailwind v4, I encountered an issue where I could no longer use safelist in the configuration.

Why i used safelist before

In one of my components, highlight colors were coming from the CMS. Since Tailwind requires the final version of a class to be present at build time, I had to write a small Python script that dynamically added the required classes to the Tailwind configuration, allowing me to use them for styling.

Now, the script generates a CSS file with the necessary classes, and everything works fine.

Here is the commit with the fix, if anyone would be interested
bozzhik/portfolio@fa16ffc

[edtorba]

Another good solution for cases where the "color" (hex, OKLCH, rgba or whatever) comes from a CMS is to use bg-(<custom-property>). For example, when rendering your element, you could do something like this:

<div style="--foo-bg: ${COLOR_FROM_CMS};" class="bg-(--foo-bg)">...</div>

This way, you end up with a single selector in the compiled Tailwind CSS, but it still covers any color coming from the CMS.

[bozzhik]

It looks pretty good. what about the color that needs to be set for the tailwind gradient?

[wongjn]

Same principle:

<div style="--foo-bg: ${COLOR_FROM_CMS};" class="bg-gradient-to-t from-(--foo-bg)">...</div>

[edtorba]

^ Yup, pretty much the same principle applies to any utility that supports custom values. It just comes down to what you’re trying to achieve. For instance, if it’s a unit and you need to perform calculations (e.g., calc), then [calc(var(--my-foo)+5px)] is a possible solution. For gradients, if you need to pass ‘to’ and ‘from’ (depending on the value format, of course), you can define two separate variables instead.

The most crucial aspect of variables is their naming, as they can inherit values. If you go too generic across multiple components, you might end up with unwanted inheritance. However, there are two ways to handle this: either ensure the variable is always explicitly defined or disable inheritance for that variable. 👀🫡

[arthurnstone]

@adamwathan

I read up on why you guys removed safelisting and your reasoning makes sense. That being said, it's still pretty important in our production React application where we do this:

<Flex px={4} py={12} mt={2}></Flex>

Those px, py, mt props are all converted to tailwind classes using a hook I wrote useTailwindProps.

We prefer doing it this way as it's more "React-y" and it standardizes how we use some of the more commonly used Tailwind utility classes.

The Tailwind docs state that it's best to avoid dynamic classes, but IMO that goes against modern frameworks such as React.

It'd be great if we could somehow register used classes at run-time (locally), IE save them to some file in the project that Tailwind reads when it detects a new class. This would remove the need for a safelist entirely for us. I could use that register function in my useTailwindProps hook.

It could look something like:
tailwind.register(bg-${props.bg}-500)

Storing all these classes in a safelist.txt file is a workable temporary solution, but certainly not ideal.

[RobinMalfait]

Hey everyone!

A new safelist option is coming. Instead of regex patterns you will be able to use bash brace expansion syntax.

More info in the PR: #17147