Dynamic color interpolation via JIT color-mix() (e.g. bg-red-250)

[brandonmcconnell]

Summary

Introduce support for JIT generation of intermediate color shades, shorthand syntax to be able to color-mix shades of the same color (e.g. .bg-red-250), by leveraging the native CSS color-mix() function.

For example, if someone wanted to use shades in-between red-200 and red-300 that would be equivalent to red-225, red-250, red-275, they would need to manually add that shade to their theme (and manually include the entire color's shades to not overwrite the entire color), add custom classes to their CSS for each, or use a complex arbitrary value inline using color-mix() to achieve those values (Tailwind Play):

<div class="bg-red-200">red-200</div>
<div class="bg-[color-mix(in_oklch_shorter_hue,var(--color-red-200),var(--color-red-300)_25%)]">red-225</div>
<div class="bg-[color-mix(in_oklch_shorter_hue,var(--color-red-200),var(--color-red-300)_50%)]">red-250</div>
<div class="bg-[color-mix(in_oklch_shorter_hue,var(--color-red-200),var(--color-red-300)_75%)]">red-275</div>
<div class="bg-red-300">red-300</div>

Tailwind CSS's compiler could introduce this same convention as a JIT-only shorthand for ease of use, so the same result could be achieved like this:

<div class="bg-red-200">red-200</div>
<div class="bg-red-225">red-225</div>
<div class="bg-red-250">red-250</div>
<div class="bg-red-275">red-275</div>
<div class="bg-red-300">red-300</div>

Implementation note ⚠️

This would be purely a JIT feature. It would not pre-generate CSS variables for every possible numeric value but rather create the specific color-mix() rule only when a corresponding class is used in the HTML/template files. As a result, these values would also not be suggested using Intellisense, which is a similar. trade-off for other similar features in Tailwind CSS v4 that support arbitrary values.

These intermediate colors would be supported, but not as official values, just as a z-67 z-index value would not be an "official value". Users—if they really wanted to—could use classnames like bg-red-462 though that would not generally be considered helpful. In most cases, users might reach for this for -25, -50, and -75 values.

Motivation

Tailwind's default color palette with stops from 50 to 950 provides a great baseline. However, in some cases, designers and developers need slightly adjusted shades that fall between these predefined stops. Currently, achieving this requires either:

1. Defining numerous custom colors in the theme.
2. Using arbitrary values like bg-[#...], which can be verbose for simple shade adjustments.
3. Resorting to a v3-style JS config for Tailwind CSS solely to interpolate colors using my tailwindcss-lerp-colors package. This is not possible in the CSS config setup.

With Tailwind v4 making square brackets optional for simple values (e.g. z-67 → z-index: 67 (Tailwind Play)), there's an opportunity for a similarly more intuitive way to access in-between shades of colors.

Proposal

Color stops between built-in shades

Introduce the ability for Tailwind's JIT engine to recognize patterns like bg-{colorName}-{numericValue} (e.g., bg-red-250, text-blue-515, border-emerald-880) where the numeric value is not one of the standard stops (50, 100-900, 950).

When such a class is detected, Tailwind would generate the necessary CSS on-the-fly using the native color-mix() function to interpolate between the two nearest standard color stops via the built-in CSS variables (e.g., --color-red-200) in the user's theme.

For example, bg-red-250 could generate CSS similar to this:

/* Standard interpolation: bg-red-250 */
.bg-red-250 {
  /* Tailwind calculates 50% based on the distance between 200 and 300 stops */
  background-color: color-mix(in oklch shorter hue, var(--color-red-200), var(--color-red-300) 50%);
}

/* With opacity modifier: bg-red-250/50 */
.bg-red-250\\/50 {
   /* Note: Opacity mixing typically happens in a different space like oklab */
   background-color: color-mix(in oklab,
      color-mix(in oklch shorter hue, var(--color-red-200), var(--color-red-300) 50%) 50%,
      transparent
   );
}

Color stops between built-in start/end color-stops and white/black, respectively

Shades between 0-50 and 950-1000 could also be achieved using this same method, calculating the distance between white/black and the respective nearest shade.

For example:

/* Interpolation below 50 (white <-> 50): bg-red-25 */
.bg-red-25 {
  /* Tailwind calculates 50% based on the distance between 0 (white) and 50 */
  background-color: color-mix(in oklch shorter hue, white, var(--color-red-50) 50%);
}

/* Interpolation above 950 (950 <-> black): bg-red-975 */
.bg-red-975 {
  /* Tailwind calculates 50% based on the distance between 950 and 1000 (black) */
  background-color: color-mix(in oklch shorter hue, var(--color-red-950), black 50%);
}

(Note: The exact color-mix() parameters, like color space (OKLCH recommended for perceptual uniformity) and hue interpolation method, are open for discussion, but oklch shorter hue seems like a strong default).

Benefits

• Increased Flexibility: Provides much finer control over color shades without theme clutter.
• Intuitive Syntax: Leverages the familiar -{number} pattern, consistent with opacity and arbitrary value scales.
• Performance: Uses native CSS color-mix() for efficient browser rendering; avoids adding hundreds of predefined CSS variables.
• Future-Proof: Aligns with modern CSS features.

Discussion Points

• Is this a desirable feature for the community?
• Thoughts on the proposed syntax (e.g. bg-red-250)?
• Best defaults for color-mix() parameters (color space, hue interpolation)?
• Potential edge cases or implementation challenges?

[elieven]

Much needed!

[adamwathan]

I think this could be a neat addition but I'm not sure how to add it without suddenly being very prescriptive about color names, or assuming that just because someone has bg-primary-100 and bg-primary-200 that bg-primary-150 should actually be in between them, and that those numbers don't just have some other meaning for that person's project.

I'm also extremely allergic to configuration so I don't want to make this some sort of option if we did add it.

How would this work if for example someone loaded in a Radix color scheme where the naming is like bg-red-1 through bg-red-12? What's the "trigger" that tells Tailwind it's safe to support interpolation?

[brandonmcconnell]

My thought was that none of these interpolated colors would support autocompletion, but they would be picked up by Tailwind JIT, and support increments of 0.25, regardless of the scale, similar to how spacing utilities currently work (Tailwind Play).

So for radix, someone would have access to bg-red-1, bg-red-1.25, bg-red-1.5, bg-red-1.75, etc. And hypothetically, someone could also use a color utility like bg-blue-402.25 with their Tailwind colors. It's a bit obnoxious, but I think we could leave that up to the user, like how you caution users against too much bash brace expansion when using @source inline().

The function dynamically just looks for the closest upper and lower bound and uses those numbers to calc the average between the two for the distances between them (not always a perfect 50% (e.g. someone's palette consists only of 50, 300, and 500, and they use bg-color-350).

[elieven]

That might be too restrictive. I for example use 910 and such as there is so much of a difference between 900 and 950. Also I can see myself using some 10 variants even in less contrasty shades. I am not arguing for going with steps of 10 but saying the increments might not be as clear.

[brandonmcconnell]

@elieven To clarify, you would hypothetically have 399 possible stops between each shade (assuming a distance of 100 units and 0.25 increments).

Example: blue-100.25, blue-100.5, blue-100.75, blue-101, …, blue-199.75, etc.

It would certainly be fewer shades for a pallet like Radix UI, but many of those palace aren't strictly linear either, so it's not quite apples to apples.

[elieven]

Oh in my head it registered as increments of 25 nor 0.25. 0.25 seems an incredibly small increment.

[brandonmcconnell]

Yes, exactly— certainly not suggested for use when working with standard 50-150 palettes, but it would help those working with palettes like 1-12 so they can more granularly control their interpreted colors.

[adamwathan]

Here's a fun demo just showing how this would look, the interpolated colors turn out pretty nice as long as you've got enough of your own predefined color steps:

https://play.tailwindcss.com/GzNxLqSR0i

[elieven]

This is what I'm currently doing manually in the config and even then I sometimes want even more values between certain shades for nice subtle borders, hover & active states... Would you suggest manual config to be the way to go? it's not the end of the world but would sure be nice to have some more elegant solution.

[brandonmcconnell]

Agreed. That's an even better demo than the one I linked above. 👌🏼