Lightness out of range

[waywardmonkeys]

There is a test in svgtypes for when HSL values are out of range from parse time.

It expects hsl(800, 150%, -50%) to result in rgba(0, 0, 0, 255) as the lightness is clamped to 0, and so the value is a black color.

While the CSS Color Module 4 spec says that, when parsing HSL, saturation is clamped, it does not say it about lightness.

• Section 4.2 does say to clamp alpha.
• Section 5.1 does say to clamp r, g, and b when parsing rgb().
• Section 7 says to clamp saturation for HSL.
• Section 9.3 says to clamp L for Lab and Lch.
• Section 9.4 says to clamp L for OkLab and OkLch.
• Section 13.2 says that when gamut mapping to ran rgb destination, the out of range lightness values should be handled by resulting in either black or white colors.

Even if we clamp at parse time, we'd have to think also about what to do when the lightness has been modified (like via map_lightness) and is now out of range due to calculations.

[tomcur]

I did a little bit of digging.

1. HSL's lightness used to be clamped, but it became unbounded in w3c/csswg-drafts@44c3778, discussion at [css-color-4] Allow out-of-gamut HSL/HWB colors (previously "Move gamut mapping to a future spec") w3c/csswg-drafts#8444.
2. Oklab/Lab became bounded in w3c/csswg-drafts@d504654, discussion at Powerless a,b and chroma for Lightness >= 100% w3c/csswg-drafts#7924.
3. The incorrect "powerless" statement there was changed in w3c/csswg-drafts@96be933, discussion at [css-color-4] [css-color-5] inconsistent mentions of powerless components in white. w3c/csswg-drafts#8609.

The reason Oklab/Lab are clamped appears to be that they're not great at predicting colors outside of SDR. The reason HSL became unbounded is because it roundtrips fine to sRGB.

I believe Lab and Oklab in theory also roundtrip fine, they're just matrix multiplies and cubes, though they get into floating point issues sooner. Maybe this is a question for the spec authors.