Use oklab instead of oklch for color-mix(…) and gradients

[adamwathan]

Fixes #15184, #14955

There's a strange bug in Safari < 18 where mixing a color with transparent or with a gray tone, the resulting color looks as if it's been interpolated through a red-ish color.

Here's the same blue to transparent gradient in Safari 17 using OKLAB and OKLCH for comparison:

In other browsers, both of these examples look identical.

This bug also shows up when using an opacity modifier right now because we use in oklch in our color-mix(…) calls:

This PR updates all of the affected places in Tailwind to use in oklab instead of in oklch which then renders everything as expected in all browsers.

The big unfortunate change here is changing the default behavior of gradient utilities like bg-linear-to-r to use in oklab instead of in oklch. This means you get muddier gradients by default when creating a gradient between two regular colors (no transparent or gray), like how they looked in v3:

This feels worth it though to avoid people getting bitten by this Safari bug without realizing it, and people can always opt in to using OKLCH with classes like bg-linear-to-r/oklch. The nice thing about making this opt-in is that no one will opt-in to this when using transparent or gray because it won't make things look any different/better, and the only places where it does make things look better do work as expected in Safari anyways.

[sandros94]

the resulting color looks as if it's been interpolated through a red-ish color

just leaving a personal comment, since the issue shown perfectly describe a lch (1976) behavior.
When mixed with neutra/transparent its hue will shift (especially blues). That is the exact reason why oklch (2020) exists. I would personally, and intentionally, leave oklch instead of defaulting to oklab. Just to make this issue more apparent and get an upstream fix faster, because this might just be a case of variables being mixed up in Safari, always triggering a lch instead of a oklch calculation.