The biggest thing about most of the new color spaces are that they can represent colors that are not in the sRGB gamut (the colors that our monitors can display). So if you have red `rgb(255 0 0)` and convert to Lab, you get `lab(54.29 80.82 69.9)`, but you can get "even more red" with Lab and go to `lab(56.69 92.92 99.17)`. This last color can not be represented in sRGB. How this affects the gradients in the picker, I'm not entirely sure. These are the basic categories of colors after the change: - Lab/Oklab (Lightness, a, b): `Lightness` which is similar to a brightness slider, where 0% fades to black and 100% fades to white. `a` is a "green to red" slider and `b` is a "blue to yellow" slider. - Lch/Oklch (Lightness, chroma, hue): `Lightness is the same as for lab/oklab. `chroma` is similar to saturation and `hue` is good old hue. - XYZ (color(xyz ..), color(xyz-d50 ..), color(xyz-d65 ..)): This color space can represent any color in any color space. - All others(rgb(), color(..)): They are RGB based, except they can represent colors outside of sRGB gamut as mentioned. If we want to change the way the picker functions, I think lab/lch is where we can "innovate", but for the rest I think the current implementation should be good (keeping the gamut issue in mind). Current Chromium implementation shows a little line where the sRGB color spaces ends. You can also switch to any other color space from the picker. Once you have a color outside of sRGB, they show a little warning to indicate you can't convert back to sRGB based format. Sample of how Lab functions: https://colorizer.org/ Some inner working of how Lab works:: http://color.support/coloratlas.html Sample of how Lch functions: https://css.land/lch/
Bug 1632548 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The biggest thing about most of the new color spaces are that they can represent colors that are not in the sRGB gamut (the colors that our monitors can display). So if you have red `rgb(255 0 0)` and convert to Lab, you get `lab(54.29 80.82 69.9)`, but you can get "even more red" with Lab and go to `lab(56.69 92.92 99.17)`. This last color can not be represented in sRGB. How this affects the gradients in the picker, I'm not entirely sure. These are the basic categories of colors after the change: - Lab/Oklab (Lightness, a, b): `Lightness` which is similar to a brightness slider, where 0% fades to black and 100% fades to white. `a` is a "green to red" slider and `b` is a "blue to yellow" slider. - Lch/Oklch (Lightness, chroma, hue): `Lightness` is the same as for lab/oklab. `chroma` is similar to saturation and `hue` is good old hue. - XYZ (color(xyz ..), color(xyz-d50 ..), color(xyz-d65 ..)): This color space can represent any color in any color space. - All others(rgb(), color(..)): They are RGB based, except they can represent colors outside of sRGB gamut as mentioned. If we want to change the way the picker functions, I think lab/lch is where we can "innovate", but for the rest I think the current implementation should be good (keeping the gamut issue in mind). Current Chromium implementation shows a little line where the sRGB color spaces ends. You can also switch to any other color space from the picker. Once you have a color outside of sRGB, they show a little warning to indicate you can't convert back to sRGB based format. Sample of how Lab functions: https://colorizer.org/ Some inner working of how Lab works:: http://color.support/coloratlas.html Sample of how Lch functions: https://css.land/lch/