[v4] What's the v4 way to do bg-opacity?

[bep]

See https://play.tailwindcss.com/eT9ngvEbNS

[philipp-spiess]

You'll want to combine it into one class, e.g. bg-black/25: https://play.tailwindcss.com/gKIdKhBr3b

[adamwathan]

What if you don't know the color?

Yeah can't do that out of the box anymore unfortunately. What's the use case where you don't know the color but you do know exactly what opacity is going to look good with it?

[chasegiunta]

The opacity classes were pretty valuable when using libraries like CVA or clsx for composing class name strings for various components that had several color variations (buttons, alerts, etc). A simple example would be reducing the bg opacity in a disable state, or if you had a "light" button variant that would go 100% bg opacity on hover.

This ain't impossible to do now (it takes much more code configuration). Previously, it was simply easier to have the color utility class only control color, and not necessarily the alpha.

I also personally opted to use bg-opacity, ring-opacity etc classes instead of the /## equivalent simply due unnecessary bundle bloat in our gigantic application, but that may have been an unnecessary optimization.

[Garrett-R]

As a contrived example of the above comment, you can imagine this in TW v3 (using tailwind-merge or you could just concatenate the strings):

<div
  className={twMerge(
    isRed ? 'bg-red-10' : 'bg-blue-10',
    isDisabled && 'bg-opacity-50',
  )}
>
  Stuff
</div>

in TW v4, these needs to become:

<div
  className={twMerge(
    isRed ? 'bg-red-10' : 'bg-blue-10',
    isDisabled && isRed && 'bg-red-10/50',
    isDisabled && !isRed && 'bg-blue-10/50',
  )}
>
  Stuff
</div>

Not too bad if it's just isRed, but now imagine bgColor prop being passed into the component (that can take value like bg-blue-700).

You kind of can't handle that anymore unless you're sure you know all the value of bgColor you might be passed and hard-code each. Rather you'd probably need to now define a set of colors that are accepted.

[RobinMalfait]

If you want, you can achieve this with a CSS variable to get the same effect:

<div
  className={twMerge(
    isRed ? 'bg-red-100/(--opacity)' : 'bg-blue-100/(--opacity)',
    isDisabled ? '[--opacity:50%]' : '[--opacity:100%]',
  )}
>
  Stuff
</div>

It's more verbose, but it's very explicit.

[Garrett-R]

Ah thanks, that works!

In our case, it does mean a tiny amount of abstraction leak (although I suppose you can consider the CSS var below as part of the component's API).

Before we had this (simplified example):

<BlueBox className="opacity-50" />

function BlueBox({className}) {
  return (
    <div className={twMerge('bg-blue-400', className)}></div>
  );
}

After, it becomes:

<BlueBox className="[--bg-opacity:50%]" />

function BlueBox({className}) {
  return (
    <div className={twMerge('bg-blue-400/[var(--bg-opacity)] [--bg-opacity:100%]', className)}></div>
  );
}

Not a big deal though, thanks for the tip!