Get lightnes channel as % in OKLCH?

[maybebansky]

I'm working with OKLCH. I need to get the lightness channel as a % as that's how it's typically displayed in CSS eg oklch(15.352% 0.0368 183.61)

By default it seems this library doenst use % for lightness and instead a range from 0-1. When I multiply these decimals by 100 to get the % value I sometimes run into the issue JavaScript has in multiplying decimals eg 0.15352 * 100 = 15.351999999999999.

I know that this is a qwerk of JavaScript and not the fault of this library per se, but is there an easy way to get the lightness channel as a % to save me from finding some work around?

import colorjs from "colorjs.io";

const colorStr = "oklch(15.352% 0.0368 183.61)";
const color = new colorjs(colorStr);
const lchMap = {
  l: {
    value: Number(color.oklch.l * 100),
    min: 0,
    max: 100,
    step: 0.1,
  },
  c: {
    value: Number(color.oklch.c),
    min: 0,
    max: 0.4,
    step: 0.01,
  },
  h: {
    value: Number(color.oklch.h),
    min: 0,
    max: 360,
    step: 1,
  },
};

export default function App() {
  return (
    <div className="App">
      <p>L = {lchMap.l.value}</p>
    </div>
  );
}

https://codesandbox.io/p/sandbox/gracious-tdd-vsymvs?file=%2Fsrc%2FApp.tsx%3A1%2C1-33%2C1

[facelessuser]

I know that this is a qwerk of JavaScript and not the fault of this library per se, but is there an easy way to get the lightness channel as a % to save me from finding some work around?

This is not a problem with JavaScript, but the way floating point arithmetic works in all modern computers. The data type cannot store an infinite amount of decimal places to preserve exact precision, so at times you will get what you have demonstrated in your opening question. The slight imprecision is introduced during the mathematical conversion from the lightness value to the percentage value.

Even if Color.js provided a specific function to get precision, you would still get decimals with the exact same behavior. The library automatically doing it vs you doing it will not change the results. You can round values off if you do not like repeating decimals.

So generally, I would view this as two separate questions.

1. Can color.js expose a way to convert a value to a percent? A decision would need to be made. I will leave this up to others to answer.
2. Will color.js exposing a percentage accessor fix the floating point imprecision? No, you would need to round off noise to the precision you are looking for if you find the result a problem.

[LeaVerou]

This is not a problem with JavaScript, but the way floating point arithmetic works in all modern computers.

Given that what they are doing is outputting to a string, what they want to do is totally possible, and the default number.toLocaleString() does it out of the box.

[LeaVerou]

First, I do think we should use <percentage> for lightness by default, so I suggest opening an issue on that. Using a 0-1 number is extremely awkward. We may even want to use <percentage> for chroma by default, though I'm less in favor of that because there are CSS WG discussions about potentially changing what that means.

Second, that seems like an excellent use case for custom formats:

let turquoise = new Color("oklch(.7 .1 180)");

turquoise.toString({format: {
	name: "oklch",
	coords: [
		"<percentage>[0, 255]",
		"<number>",
		"<angle>"
	]
}})

Here’s a color notebook showing this: https://colorjs.io/notebook/?storage=https%3A%2F%2Fgist.github.com%2FLeaVerou%2F80cf3f377267a0380edbf59db1bf0db0

[facelessuser]

First, I do think we should use for lightness by default.

Numerically or in serialization? I believe it was requested to numerically return the values as percentages, not necessarily during serialization, though that could be desired as well.

As I understood, it was asked that color.oklch.l return percentages. This is very different than just changing the default serialization. I'm not sure I like that idea, but I am indifferent to how they are serialized.

[LeaVerou]

Oh no, I was talking about serialization. color.oklch.l needs to remain consistent with what l would return in RCS.

[facelessuser]

Okay, that seems perfectly fine then.