Safelist not working for background colors opacity

[miguilimzero]

What version of Tailwind CSS are you using?

v3.0.7

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

Laravel Mix v6.0.6

What version of Node.js are you using?

v16.13.1

What browser are you using?

Chrome

What operating system are you using?

Manjaro Gnome

Reproduction URL

https://github.com/srdante/tailwindcss/blob/master/tests/safelist.test.js

Describe your issue

1. The lack of warning about bg-opacity-* changes.
2. The safelist not working for the new opacity classes format.

While upgrading to Tailwind CSS 3, I noticed the bg-opacity-* classes despite being generated correctly in the css file, they are not mentioned anywhere on the upgrade guide page (https://tailwindcss.com/docs/upgrade-guide) and they are completely gone from the v3 documentation (v2: https://v2.tailwindcss.com/docs/background-opacity).

After searching on the v3 documentation, it is possible to come to the conclusion that the color classes are now used with {class}/{opacity} style to control opacity (example: bg-sky-500/50). However, in my project the color classes for some components are dynamically generated, and for that they need to be in the safelist.

The problem starts when no pattern expressions works for these type of classes (500/50). Even using third party tools confirming that the regex is correct, it's not working for Tailwind CSS compiling engine. Here is an online regex testing showing that the expression is correct and working: https://regex101.com/r/WDFZJ7/1

[adamwathan]

Sorry I’m not understanding the issue — the bg-opacity-* all still exist and work for backwards compatibility, we just removed them from the documentation because we want to encourage the color opacity modifier instead.

Can you share a reproduction that shows that they can’t be safe listed? There’s no reason I can think of that that shouldn’t work and I can’t reproduce it myself.

[adamwathan]

I see what you mean now after looking at the regex — pattern-based safelisting in v3 only supports base utility names, so the /50 can't be matched currently. Your best bet in this case is to list the whole utility as a static string:

  safelist: [
    'bg-red-100',
    'bg-red-500/50',
  ],

[miguilimzero]

Yes, this would be viable if I needed to safelist only a few classes, but the components support any color, and for that I would have to safelist several classes of all available colors.

Unfortunately I don't have enough knowledge to do a pull request to add the safelist capability to these types of classes.

But leaving that aside, as I really can't help at all. I think it would be worth adding some annotation about the bg-opacity-* classes in the v3 documentation.

[robertvanhoesel]

the bg-opacity-* all still exist and work for backwards compatibility, we just removed them from the documentation because we want to encourage the color opacity modifier instead.

@adamwathan in absence of regex based safelisting, can we safely use the bg-opacity-* in combination with generated base classes using regex or is this very likely to be deprecated in a v4?

[mrinx]

I see what you mean now after looking at the regex — pattern-based safelisting in v3 only supports base utility names, so the /50 can't be matched currently. Your best bet in this case is to list the whole utility as a static string:

Could we just not add another option - let's say opacities, similar to variants, and just cycle through them and add them like that? It makes total sense in terms of complexity that /50 can't be matched, but safelisting bigillion color classes manually is an overkill and using *-opacity-* classes is not that nice/simple either.

[Bryanoxx]

I agree with the previous comment, maybe adding a variant dedicated to the safelist for this purpose of opacity, because I also encounter this issue for dynamic background colors with opacity ✅
Exemple of the idea : variants: ['opacity'] that would enable all the classes /50, /100, /200, ...

[BayBreezy]

This would still be a nice feature to have... Ran into the issue while trying to customize the @nuxthq/ui components

[wongjn]

Opacity syntax (both old and new) can now be safelisted with regex: https://play.tailwindcss.com/0Wwi2Q6se5?file=config (open the Generated CSS panel).