Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

L is for lightness (0-100%), C is for chroma (0-0.5), H is for hue (0-360deg).

Lightness dictates how white or black a color is, chroma dictates how saturated it is, and hue is which angle on the color wheel it occupies. Varying these one at a time lets you intuitively pick colors that are close to one another in the space of human perception. And CIE Lab colors are especially nice because they cover more than the sRGB gamut that we're all used to defining with HSL or RGB, so you can really make the most of your fancy wide color gamut monitor.



Unfortunately in the CSS implementation of oklab Chroma takes priority over Lightness, so if you have high Chroma and Lightness at 100% that results in a color outside the RGB gamut, it will not give you white, but the lightest color with that Chroma. To me this is quite counterintuitive.


with my posh upper-crust wide color gamut eyes *big eyelashes flutter-winking*


> L is for lightness (0-100%), C is for chroma (0-0.5), H is for hue (0-360deg).

My programmer brain immediately jumped away in disgust.

I'm sure there's many good reasons for choosing those, but it seems to me it could have easily have been done with 3 percentages (0-100% for the 3 numbers). Way easier to work with programmatically.


Hue is a cyclic value, so it has to be in degrees

Chroma cap is dependent on Lightness and Hue, so it has to be unsized to preserve "equal delta leads to equal color distinction" concept

In color spaces you just don't have any math that can be done without following its structure

You may check https://oklch.com/ on how the color space looks like


> Hue is a cyclic value, so it has to be in degrees

There's nothing magical about the number 360. You can do cycles in the 0-1 range. You can even make trigonometry with that (no radians). See:

http://pico8wiki.com/index.php?title=Sin




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: