- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Mon, 04 Mar 2024 21:37:42 +0000
- To: public-css-archive@w3.org
@nex3 I am so sorry. I keep reading over this issue, reading over related issues, and trying to come up with a self-consistent set of principles for when clamping happens and why; but in some cases the "why" is "historical precedent from CSS Color 3" and stuff like that. So I don't form a coherent answer and leave it to come back to. That must be very frustrating, my apologies. The "in practice" is because CSS Color 3 puts two different things into one paragraph: parse-time clamping of HSL input and display-time clamping to the device gamut: > If saturation is less than 0%, implementations must clip it to 0%. If the resulting value is outside the device gamut, implementations must clip it to the device gamut. This clipping should preserve the hue when possible, but is otherwise undefined. (In other words, the clipping is different from applying the rules for clipping of RGB colors after applying the algorithm below for converting HSL to RGB.) Because implementations at that time assumed all screens were sRGB, and also because `hsl()` serializes as `rgb()` with only 8-bit precision, implementations of that time can't be blamed for condensing that into one operation on input. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9484#issuecomment-1977503873 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 4 March 2024 21:37:43 UTC