Support opacity modifiers for colors in JIT

[adamwathan]

This PR adds a new syntax for specifying color opacity when using the JIT engine.

Instead of needing to use utilities like bg-opacity-50, text-opacity-25, or placeholder-opacity-40, this PR makes it possible to just tack the opacity right on to the end of the color:

- <div class="bg-red-500 bg-opacity-25">
+ <div class="bg-red-500/25">

The motivation for this is to remove the need to add new color opacity utilities any time we add other new utilities that are color based. For example, currently the gradient utilities do not support opacity at all:

<!-- This doesn't work -->
<div class="bg-gradient-to-r from-red-500 bg-opacity-50">

People expect this to work (#3875) but in reality the better solution would be something like this:

<div class="bg-gradient-to-r from-red-500 from-opacity-50">

The problem with this solution is it scales really poorly. Any time we add a new color utility, we need a new corresponding opacity utility, which means coming up with a new core plugin name, documenting it, etc.

<!-- This is the new solution -->
<div class="bg-gradient-to-r from-red-500/50">

This PR introduces an approach that allows you to apply opacity to any color by just adding /{opacity} to the end of the color, and it is handled at an earlier phase in the compiler so that no color related plugins even have to know that this syntax exists.

The opacity values you add at the end of the color name are taken from your opacity scale in your theme, and the utility-specific opacity scales are ignored, the idea being that this feature effectively deprecates that stuff.

This feature also supports arbitrary opacity values, in case you want to pull the opacity from a CSS variable or use some other one-off value, using this syntax:

<div class="bg-red-500/[var(--opacity)]">

This feature is only available in JIT mode, as making it work in the classic engine would introduce a tremendous amount of bloat due to the combinatoric explosion of classes.

[codecov-commenter]

Codecov Report

Merging #4348 (a006014) into master (6be7976) will decrease coverage by 0.05%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##           master    #4348      +/-   ##
==========================================
- Coverage   71.85%   71.80%   -0.06%     
==========================================
  Files         220      220              
  Lines        4769     4802      +33     
  Branches      790      802      +12     
==========================================
+ Hits         3427     3448      +21     
- Misses       1262     1268       +6     
- Partials       80       86       +6     

Impacted Files	Coverage Δ
src/plugins/fill.js	57.14% <0.00%> (ø)
src/plugins/placeholderColor.js	52.94% <ø> (ø)
src/util/pluginUtils.js	60.91% <73.68%> (+0.30%)	⬆️
src/jit/lib/generateRules.js	92.05% <100.00%> (ø)
src/jit/lib/setupContext.js	77.88% <100.00%> (+0.05%)	⬆️
src/plugins/gradientColorStops.js	62.50% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6be7976...a006014. Read the comment docs.

[MichaelDeBoey]

@adamwathan Will things like bg-gradient-to-r from-purple-400/50 via-pink-500/20 to-red-500/70 also work?

[adamwathan]

@MichaelDeBoey Yep they will!

[hmaesta]

Is there any possibility that this could be extend for shadows?

Instead of hard coding new colors in tailwind.config.js, we could just define sizes. The obvious problem I can see is that most shadows have more than one parameter (with different color opacities), so we would need a "template-like" syntax – but, to be honest, that doesn't look good.

# tailwind.config.js

  boxShadow: {
-   'lg-hard-coded-blue': '0 10px 15px -3px rgba(37, 110, 255, 0.1), 0 4px 6px -2px rgba(37, 110, 255, 0.05)'
+   'lg': '0 10px 15px -3px rgba({color}, 0.1), 0 4px 6px -2px rgba({color}, 0.05)'
  }

- <div class="shadow-lg-hard-coded-blue">
+ <div class="shadow-lg-blue-600">

[adamwathan]

@hmaesta Hey! I don't think this particular feature is a great way to add that sort of flexibility to shadows unfortunately. I would like to solve the "colored shadows" problem at some point though for sure, something that's been tumbling around in the back of my mind for like 2 years honestly.

[adamwathan]

This is now available to test in canary if you want to give it a go early:

npm install -D tailwindcss@canary