Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support opacity modifiers for colors in JIT #4348

Merged
merged 3 commits into from May 14, 2021
Merged

Support opacity modifiers for colors in JIT #4348

merged 3 commits into from May 14, 2021

Conversation

@adamwathan
Copy link
Contributor

@adamwathan adamwathan commented May 13, 2021

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
Copy link

@codecov-commenter codecov-commenter commented May 13, 2021

Codecov Report

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

Impacted file tree graph

@@            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
Copy link
Contributor

@MichaelDeBoey MichaelDeBoey commented May 13, 2021

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

@adamwathan
Copy link
Contributor Author

@adamwathan adamwathan commented May 13, 2021

@MichaelDeBoey Yep they will!

@hmaesta
Copy link

@hmaesta hmaesta commented May 14, 2021

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 adamwathan merged commit 87df93d into master May 14, 2021
3 checks passed
3 checks passed
@github-actions
build (12)
Details
@github-actions
build (14)
Details
@github-actions
build (16)
Details
@adamwathan adamwathan deleted the jit-color-opacity branch May 14, 2021
@adamwathan
Copy link
Contributor Author

@adamwathan adamwathan commented May 14, 2021

@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
Copy link
Contributor Author

@adamwathan adamwathan commented May 14, 2021

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

npm install -D tailwindcss@canary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants