- From: Natalie Weizenbaum via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Nov 2023 00:45:05 +0000
- To: public-css-archive@w3.org
I've been doing some additional poking around with this in relation to https://github.com/sass/sass/issues/3737, and I'm a bit confused about some related behaviors in [the latest draft of Color 4](https://drafts.csswg.org/css-color/). This draft doesn't mention any kind of clamping at any point for `hsl()` syntax (unlike `rgb()` which clamps all its channels), and it says that "HSL colors resolve to sRGB". At the same time, the sample conversion algorithms explicitly say that they expects the saturation and lightness to be "in reference range `[0,100]`" and the red, green, and blue components to be in `0..1`. (For what it's worth I believe these conversion algorithms do work as written to round-trip out-of-gamut colors.) Browsers (I've tested Chrome and Firefox) also _do_ seem to clamp colors specified with `hsl()`. `color-mix(in xyz, hsl(0, 0%, 500%) 50%, black)` and `color-mix(in xyz, hsl(0, 0%, 100%) 50%, black)` both render as `color(xyz 0.4752279635 0.5 0.5445288754)`, despite the fact that the former should have much higher lightness than the latter. Should this be considered a bug in the browsers' implementation (or just not adopting the latest spec soon enough)? This is particularly important for Sass, because we need a way to represent out-of-gamut legacy colors that's both compatible with older browsers _and_ preserves the semantics of the out-of-bounds colors in modern browsers. We had originally been emitting `rgb()` with out-of-gamut values, but it looks like that's now clamped, so I'm hoping that out-of-gamut HSL will work instead. -- GitHub Notification of comment by nex3 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9484#issuecomment-1809363180 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 November 2023 00:45:07 UTC