Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lowering for oklch does not work when using numeric or mixed values #809

Open
mayank99 opened this issue Sep 16, 2024 · 5 comments
Open

Comments

@mayank99
Copy link
Contributor

Currently, lightningcss lowers the following correctly (albeit with an unnecessary conversion from oklch to lab):

--color-1: oklch(100% none none);
--color-2: oklch(100% 0 0);

Whereas the following are ignored completely:

--color-3: oklch(1 0 0);
--color-4: oklch(100% 0% 0deg);

See playground.

I came across a similar issue (#445) which was closed by 835e5bc, but it doesn't work in the latest version.

@mayank99 mayank99 changed the title lowering for oklch does not work when using numeric values lowering for oklch does not work when using numeric or mixed values Sep 16, 2024
@mayank99
Copy link
Contributor Author

mayank99 commented Oct 2, 2024

Aside: should the extra conversion from oklch to lab be considered a bug?

There could be some slight differences between the color formats. I noticed a difference in precision too. For example, oklch(99.06% 0.002 247.84) becomes lab(98.9092% -.247002 -.70672).

@mattpilott
Copy link

mattpilott commented Oct 13, 2024

Id also like to understand the conversion from oklch to lab, was expecting to still see oklch in the final css 🤓

@devongovett
Copy link
Member

That commit was reverted in 81cd955 . At some point the spec changed to accept numbers or percentages for all components instead of one or the other. Unfortunately this is a breaking change for Lightning CSS because it changes the way calcs work. There is a PR #465 to update to the latest spec, but it is now waiting for a major version release unfortunately. In the meantime, you can use percentages.

As for the conversion to lab, that's because you have specified browser targets that do not support oklch but do support lab. According to MDN, oklch is only supported in Chrome 111 and Firefox 113, but the targets in the playground are set to 110 for both.

@mayank99
Copy link
Contributor Author

mayank99 commented Nov 3, 2024

Thanks for the response. That's unfortunate about the breaking change, but using percentages is not a big deal I suppose.

I'm not sure that the reasoning for the lab issue is correct. lab and oklch have equal browser support, afaict (see caniuse). Even if I lower the targets some more, lab is still used (see playground). The fallback for older browsers is not the lab but rather the hex colors. So the correct combination would be hex (fallback) + oklch (untransformed).

@devongovett
Copy link
Member

That's true. I guess Safari was the difference. 15 supported lab and 15.4 added support for oklab. In this case you aren't targeting any Safari browsers so it could probably be avoided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants