[Tailwind 3.1.2] Gradient issue: to-[color]-[number] is not displayed even if specified

[Infinituum17]

[Tailwind v3.1.2, React v18.1.0, Node v17.0.1, Chrome, Windows]

I copied the example described here and pasted it onto my main (and only) css file. Apparently in version 3.1.2 "via-[color]-[number]" causes a conflict with "to-[color]-[number]".

When "via-...-..." is added, the gradient shows only the "from-...-..." color and the "via-...-..." color, even if the "to-...-..." color is specified.

(My project has only one css file (screenshot below) and the other styles I apply are inline-classes, but I've tried removing them and it doesn't solve the issue)

Main issue:

index.css:

Chrome devtools:

[adamwathan]

I can't seem to reproduce this:

https://play.tailwindcss.com/gwJXfjag2V

Can you provide a proper reproduction? As mentioned in the issue template it's required, otherwise it causes us to waste a lot of time, like I just did trying to create the reproduction by hand 🤪

[rohmann]

@adamwathan I think it's a 3.1.2 issue. I tried it out as well and it works in the sandbox, but on 3.1.2 it overwrites --tw-gradient-to with a color that has zero opacity.

@supports (color: rgb(0 0 0 / 0))
body {
    --tw-gradient-to: rgb(59 130 246 / 0);
}

I tried this CSS:

body {
  @apply m-0 p-0;
  @apply h-screen w-screen;
  @apply bg-gradient-to-tr from-teal-500 via-blue-500 to-cyan-500;
}

[adamwathan]

Hey! I've created another reproduction here myself using v3.1.2 and can't reproduce:

https://github.com/adamwathan/tailwind-repro-8597

Run npm run dev to test it.

I'm not sure where that @supports query would be coming from, Tailwind doesn't generate that. Must be other tools/plugins involved, so a reproduction is important 👍

[adamwathan]

@rohmann Sorry, thought you were the OP originally! Appreciate all the help you've been offering in issues and discussions lately, really a huge help 👊

[rohmann]

No worries! Thanks! I think I figured out the issue here. The @supports rule is coming from the create-react-app stack. My local test env was just following the tailwind docs with React. After ejecting cra and tinkering around, I found the issue goes away when postcss-preset-env is removed.

Simplified, Tailwind outputs the --tw-gradient-to property multiple times.

body {
  @apply bg-gradient-to-tr from-teal-500 via-blue-500 to-cyan-500;
}

produces this:

body {
  --tw-gradient-to: rgb(20 184 166 / 0);
  --tw-gradient-to: rgb(59 130 246 / 0);
  --tw-gradient-to: #06b6d4;
}

Then if postcss-preset-env is involved, it transforms the above to...

body {
  --tw-gradient-to: rgb(20 184 166 / 0);
  --tw-gradient-to: #06b6d4;
}

@supports (color: rgb(0 0 0 / 0)) {
  body {
    --tw-gradient-to: rgb(59 130 246 / 0);
  }
}

...and that causes the color to reset to the other value.

Technically, nothing wrong with the Tailwind CSS output. It looks like an edge case bug in how postcss-preset-env protects rgb colors with slash syntax. They should probably just ignore properties that get redeclared in a different syntax.

That being said, it could be fixed on the Tailwind side if the custom property was only output once.

[adamwathan]

Ah that sucks. CRA continues to be a major source of pain for us because of how opinionated it is around PostCSS 😕 Going to close this as not our issue then, but would highly discourage using CRA. Use Vite instead, it an amazing environment for client-side React apps like CRA is, but with a much smoother experience especially with Tailwind 👍