Post

you nerdsniped me to learn `oklch` properly today, sir! 🫡 random detail that made me like it even more: > As Ottosson explained, he chose the name Oklab because the model does an OK (adequate) job

signals doesnt really remove what you're describing as "painful raw api," at least I dont anticipate it will for you. but maybe?! lemme know

i see what you mean. however i think that's beyond single color picking? there's many tools out there that do take full advantage of color manipulation and palette tooling around color.js, could then pivot to another color tool?

I pick a color (in oklch), I obtain a color value. Now, while <color-input> is built around color.js, if I want the lightness component of this color value, I re-import color.js, I declare mycolor=new Color(value); lightness = mycolor.oklch.l

It’s a web centric color picker matching the capabilities of the browser; designers and developers can use it. If the space you’ve chosen is lch or oklch, C (chroma) will adjust what you’re used to using as saturation. Or pick hsl and you can adjust saturation in the limited sRGB gamut

From a UX perspective, I strongly believe that angular values like hue should be selected with full radial controls. Speaking of which, why do we have no <input type> for that – mouse pointer inaccessibility of spin controls?

Not all the color spaces have angular hue, wanted to try and limit the learning required to pick a color. I think there’s been pitches for a web standard circular range input, you could go cast your vote or share potential ideas to help it move forward?

From a nerd perspective, I think the categorization is a bit off, though common. “Standard” are various representations (cartesian, cylindrical, prismatic, …) of the legacy sRGB space with notational variants (octet integer, percentage, hexadecimal). The *lab and *lch options are either CIE or OK, …