Skip to content

[css-color-4] parsed-value-time lightness clamping #11549

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tomcur opened this issue Jan 21, 2025 · 0 comments
Open

[css-color-4] parsed-value-time lightness clamping #11549

tomcur opened this issue Jan 21, 2025 · 0 comments
Assignees
Labels
css-color-4 Current Work

Comments

@tomcur
Copy link

tomcur commented Jan 21, 2025

The specification of parsed-value-time lightness clamping differs for different color spaces.

Section 7 says to clamp saturation for HSL, but not lightness. Sections 9.3 and 9.4 say to clamp lightness for Lab/Lch and Oklab/Oklch respectively.

I did a little bit of digging.

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

The reason HSL became unbounded appears to be its ability to round trip fine with the RGB models.

In theory, though perhaps not recommendable, specifying lightness above 100% is more or less fine for these perceptual models and the math round trips with the RGB models. As far as I understand it, 100% lightness in general (and white point in specific) of these color spaces is not a pole but a smooth point; though I believe these color spaces do start to lose their predictive power when outside of their "natural gamuts".

If lightness is at or above 100%, it is the choice to preserve lightness over chroma during gamut mapping to, e.g., sRGB, that maps these colors to white. A different choice of gamut mapping technique could map to a chromatic color, and that color could change with further increasing lightness. On an HDR display the color may be in gamut.

The current wording prevents specifying colors brighter than media white, whereas those can currently be specified in HSL, XYZ, and the various RGB models. Would it make sense to drop the required parsed-value time clamping of lightness for the perceptual models Lab/Lch/Oklab/Oklch?

@svgeesus svgeesus added the css-color-4 Current Work label Jan 21, 2025
@svgeesus svgeesus self-assigned this Apr 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-color-4 Current Work
Projects
None yet
Development

No branches or pull requests

2 participants