HSL algorithm can divide by zero

Is there a reason the HSL algorithm does not implement the part relating to when L == 0 or L == 1 found on the wiki: https://en.wikipedia.org/wiki/HSL_and_HSV#From_RGB?

The L == 1 is the part that is of particular concern as it causes a divide by zero:

let color = new Color("srgb", [2, 0, -2]).to('hsl');

Will yield:

hsl(30 Infinity% 0%)

I’m not sure if this is an oversight or purposeful, and a clean methodology for handling the case has not been outlined yet.

EDIT: Correction, both these cases can cause division by zero.

[facelessuser]

The question is, should the inputs be coerced into [0 … 1] first.

I’m not sure it makes much of a difference, but I personally do in my library.

This change will also impact HWB, right?

In my library it did as I specifically, when going from HWB to HSL, go HWB -> sRGB -> HSL. A matter of fact, basically all my HWB conversions go through sRGB when going to/from HSL or HWB. But Colorjs.io goes from HWB -> HSV -> HSL and that path doesn’t have a problem with divide by zero as far as I can tell.

With that said, Colorjs.io does take a path mine does not which looks like it might have issues, particularly this line let s = 100 - (100 * w) / (100 - b);. There doesn’t seem to be a check to protect against a divide by zero here.

		hsv (hwb) {
			let [h, w, b] = hwb;

			// Now convert percentages to [0..1]
			w /= 100;
			b /= 100;

			// Achromatic check (white plus black >= 1)
			let sum = w + b;
			if (sum >= 1) {
				 let gray = w / sum;
				 return [h, 0, gray];
			}

			let v = 1 - b;
			let s = 100 - (100 * w) / (100 - b);
			return [h, s, v * 100];
		},

To pull off the divide by zero, the case is pretty contrived, but possible:

> new Color("hwb(0 -10000% 10000%)").to('hsv').coords
[0,Infinity,-9900]

Because I pass through HWB -> sRGB -> HSV, I don’t see this issue, but with that said, after you asked this, I ran a quick test, and I don’t know that the HWB to HSV conversion is correct in Colorjs.io. Ignoring hue, you can see that value is quite different. I suspect the path through sRGB is fine and that the issue is with the direct HWB -> HSV conversion, but one of them is probably wrong.

> new Color("hwb(37 10% 100%)").to('hsv').coords;
[37,0,0.091]
> new Color("hwb(37 10% 100%)").to('srgb').to('hsv').coords
[300,0,9.091]

[facelessuser]

All known issues have been fixed in #79. Changes can be reviewed there. I made sure, as discussed, that R, G, B are in the range [0, 1] as well.