Re: [csswg-drafts] [css-color-4] Parse-time clip of HSL negative saturation for modern syntax? (#9222)

Sorry, I am still confused...  so what should be the serialized value of `hsl(0 150% 40%)`?

  1. `rgb(204, 0, 0)` (current browser output)
  2. `rgb(255, 0, 0)`
  3. `rgb(255, -51, -51)`

  > > Should it be considered a bug if saturation is also capped at 100% before conversion to RGB?
  >
  > Yes, and that should be observable via `color-mix()` when output to `color(srgb ...)`. I mean clamping will happen during conversion to `rgb()` but not before conversion.

I conclude that answer 1 is eliminated because the saturation is capped before conversion... unless I am missing how it happens *during conversion to `rgb()`* but the [conversion algorithm](https://drafts.csswg.org/css-color-4/#hsl-to-rgb) does not clamp the saturation or the resulting rgb channel values: the result of `hslToRgb(0, 150, 40)` is currently `[255, -51, -51]`.

Assuming answer 2 is expected:

  > > But I cannot find where clamping values outside of [0,255] after conversion to RGB, is defined.
  >
  > It is in 5.1 The RGB functions: `rgb()` and `rgba()`:
  >
  > > Values outside these ranges are not invalid, but are clamped to the ranges defined here at parsed-value time.

The only way I see for this to apply would be to convert `hsl()` at parse time (unless it is nested in another color function), which is unspecified, and to consider the resulting `rgb()` as if it was present in the input and clamp its channel values at parse time, as specified.

-- 
GitHub Notification of comment by cdoublev
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9222#issuecomment-2127066306 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 23 May 2024 13:07:58 UTC