mirror of
https://github.com/tailwindlabs/tailwindcss.git
synced 2025-12-08 21:36:08 +00:00
961e8da8fd
Fixes https://github.com/tailwindlabs/tailwindcss/discussions/15184, https://github.com/tailwindlabs/tailwindcss/issues/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: <img width="747" alt="image" src="https://github.com/user-attachments/assets/1cb09b00-0d84-4284-be34-103726d8af03"> 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: <img width="744" alt="image" src="https://github.com/user-attachments/assets/b029c5f1-0c5c-4119-80ba-dfeabe25927e"> 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: <img width="740" alt="image" src="https://github.com/user-attachments/assets/d02e7596-4c99-4ba3-b929-d2db4911c8e9"> 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. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>