Support OKLab and OKLCH

Hey, thank you so much! Really excited to see this looked into, I’m very happy to see this getting some attention!

I just wanted to add that just adding OKLAB and OKLCH as selectable color models and then adding individual extended functions around the application, like being able to specify the gradient interpolation color space but still having those colors technically just be RGB, may not fully express the potential or ideal scope of this request and exactly what people have been really asking for, especially across the related threads you listed. I think what you described, with either the addition of OKHSL and OKHSB color modes or just a circular picker, is a pretty good summary of this specific thread, but at the same time I feel like while it’s depth might have been appropriate when the original post was written back when OKLab and OKLCH “will soon become the standard in web browsers“ as the original poster said 4 years ago, the feature as you described 4 years later might be a shallow cut in today’s landscape, leaving people immediately asking for more just to catch up to the standard. Sorry that this is a long message, I cut it down a ton but still ended up so long, I hope its helpful though at least.

I can't tell exactly what the majority of what people came to this thread looking for is, I think at some point people were just dying for absolutely any support and therefore didn’t even try to describe what a complete integration of OKLAB/OKLCH would look like. This reply is my attempt to share this viewpoint to hopefully make sure Figma actually catches up for real and for the long term, when it comes to OKLAB/OKLCH. OKLAB/OKLCH's massive adoption is for many reasons, and some of those benefits may be limited or dropped altogether depending on how deep the support goes. Additionally, the related threads you linked seem to also focus on different aspects of this that might not fit under your description depending on how they are interpreted.

What I seem to be seeing the most in this specific thread though is people just looking for an extension of the color picker and the gradient renderer to allow converting underlying RGB colors to/from OKLAB/OKLCH colors purely at an interface level, or to otherwise adapt traditional color models like HSB and HSL to use the Oklab color space under the hood to improve perceived uniformity for gradients, but while still strictly maintaining the existing sRGB/Display P3 color gamut and RGB system overall.

However, I feel like actual, industry-competitive support for OKLAB/OKLCH requires deep engine-wide support for the storing, editing, and rendering OKLAB/OKLCH colors natively all the way from making variables to showing them in the editor and prototype viewports to exporting artifacts using them in supported formats like CSS or SVG, with a warning if you try to export OKLAB colors outside the sRGB gamut in unsupported formats. I can't speak for everyone here, but from what I can gather it seems like though any amount of support would help, it also seems like in the big 2026 we are also kinda past the point where anything other than a deep, complete engine overhaul to support designing with, previewing, and exporting artifacts using OKLAB/OKLCH all the way down would just be a waste, and would probably still leave Figma way behind the broader web landscape.

I noticed that your description doesn't mention color gamut at all, but one of the largest benefits of the OKLAB color space is that it's device independent and unbounded. I think I vaguely remember that Figma does let you switch your project from rendering in sRGB to Display P3 color gamuts, but that when you do so it simply stretches the sRGB color space to fit the Display P3 gamut, wreaking your colors. Projects should be able to have RGB colors alongside OKLAB/OKLCH colors, so maybe leave the color profile system to just define the gamut that RGB values are mapped to, and let OKLAB/OKLCH colors automatically use your display’s full color gamut irrespective of the selected color profile.

It's also good to mention, which I don't think anyone else has yet, that just as the sRGB color space has RGB, HSB, and HSL, OKLAB/OKLCH also has OKHSB(OKHSV) and OKHSL, which I think would also be imperative to include to properly utilize it’s perceived uniformity in those axes. Similarly, CSS has OKLAB/OKLCH versions of the rgba() function, oklab() and oklch(), so from there is would also clearly make sense to have an OKLAB/OKLCH CSS color model option. At that point though, maybe rather than just adding these as additional color model options, there's some deeper change like a separate color space selector either for that individual color, or perhaps for the project overall or something, I don't know.

This is kinda just a specific I noticed when writing this so I thought I should share, but the nature of the existing graphical picker being a square with specifically the hue as the slider, forces either that pattern to be broken to support the addition of just OKLAB/OKLCH, or for OKHSV and OKHSL options to be added as well. In short, OKLCH is polar with the lightness being the slider instead of the hue, and the OKLab model doesn’t have a hue parameter at all, so if neither OKHSV or OKHSL models are added, then what would be shown instead? If either one were twisted to fit the square picker or rearranged so the slider represents hue, that’s functionally the same as just adding OKHSV and OKHSL models only less useful.

Here is a small interactive tool made by Björn Ottosson, the creator of OKLab and OKLCH, demonstrating different color pickers for some of the different color models and how they compare with the HSV and HSL pickers, though it’s missing pickers for raw OKLAB/OKLCH: https://bottosson.github.io/misc/colorpicker

Lastly, nobody mentioned it yet but I feel like to make full usage of the perceived uniformity of OKLAB/OKLCH, I would strongly request potentially extending the recent addition of variable aliases with added transparency to also allow changing the brightness or saturation or any of the other potential axes provided by the possible color models, of the source color variable.

If full native storing and rendering of OKLAB/OKLCH colors isn't added, adding variable aliases with OKLAB/OKLCH or even OKHSV/OKHSL parameter offsets would still allow people to benefit from the perceptual uniformity of the color space without doing a deep engine overhaul.