Use oklab instead of oklch for color-mix(…) and gradients
#15201
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
philipp-spiess
approved these changes
Nov 27, 2024
adamwathan
pushed a commit
that referenced
this pull request
Nov 27, 2024
After the changes in #15201, our Windows CI started to fail. The problem is that lightningcss now needs to convert `oklch` colors into the `oklab` space to inline some `color-mix()` functions. The problem, though, is that this calculation seems to have rounding differences between macOS, Linux, and Windows. Since we still want to _define the default color space in `oklch`_ and _use lightningcss as a post-processor in our unit tests so we have a better coverage of the output_, this PR attempts to fix the issue by adding a custom vitest serializer. It will find usages of the `oklab()` function with arguments that have lots of decimal places (at least 6 decimal places). What it then does is simply cut off any excess decimal places to truncate the output to 5 places. E.g.: ```diff - oklab(62.7955% .224863 .125846 / .75); + oklab(62.7955% .22486 .12584 / .75); ``` ## Test Plan I updated the CI workflow file to make all three builds run in CI and observed that they are now all green again. <img width="609" alt="Screenshot 2024-11-27 at 14 54 52" src="https://github.com/user-attachments/assets/73fe6da5-30e3-4fd4-83ea-115b1f1602a6">
just leaving a personal comment, since the issue shown perfectly describe a |
tongrow
pushed a commit
to tongrow/tailwind-normalize
that referenced
this pull request
Jun 2, 2025
…windlabs#15201) Fixes tailwindlabs#15184, tailwindlabs#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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #15184, #14955
There's a strange bug in Safari < 18 where mixing a color with
transparentor 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 oklchin ourcolor-mix(…)calls:This PR updates all of the affected places in Tailwind to use
in oklabinstead ofin oklchwhich 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-rto usein oklabinstead ofin 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.