[css-color] out of range lab and lch values

[svgeesus]

https://drafts.csswg.org/css-color/#specifying-lab-lch

Need to define handling for out of range numbers. Clip L, wrap H? Have also seen L up to 400, specifically for high dynamic range situations.

I propose that css-color-4 leaves high dynamic range out of scope. Addressing it requires looking at color re-rendering, which is complex and should be left to a later version when there is more industry experience to draw upon.

Given that, it is clear that L should be clamped to the 0 to 100 range, that H should be wrapped to the 0 to 360 range, that C should have negative values clamped to 0 and that a, b are unbounded.

[svgeesus]

Need to decide what, if anything, to do for high dynamic range on luminance.

As stated in the opening comment, punt to a later level.

[frivoal]

Given that, it is clear that L should be clamped to the 0 to 100 range

Maybe that's right, but it isn't clear to me. Why not leave it unclampled, and leave the behavior out of 0 100 to be undefined, and see if browsers vendors come up with something useful we can later specify in a later level?

Normatively clamping seems dangerous to me, as it means authors can (and therefore will) rely on the clamping to happen, and then if we ever want to do something else we're stuck.

Am I missing something?

(I agree with the rest of your comment)

[svgeesus]

If we ever want to do something else then we are not stuck, because a high dynamic range system that used Lab (or XYZ) would also need a tone mapping function. So normative clamping seems fine in these functions.

[tabatkins]

Oof, if we're clamping it between 0 and 100, then this is absolutely a percentage, not a number. It's exactly identical to hsl()'s lightness. (Well, values between 0% and 100% are warped slightly differently, but the 0% and 100% values are the same.)

[svgeesus]

It is wildly different to the meaningless hsl() lightness, but looking purely at the syntactic part okay, call it a percentage if you want.

[ylafon]

In the current draft, Lightness in lab() is allowing out-of-bound values like 400 (well, not directly but there is a strong hint in the text that at least it is not clamped), outside of the 0-100 range, but nothing is said for negative values, is it clamped to 0 or does it make the definition invalid?

[svgeesus]

Hi @ylafon good question.

L, as a measured value, can never be less than zero. I also can't think of any intermediate computation which would cause it to become less than zero, although values somewhat greater than 100 can arise.

The 400 value to maybe account for HDR is handwaving.

[svgeesus]

Given that, it is clear that L should be clamped to the 0 to 100 range, that H should be wrapped to the 0 to 360 range, that C should have negative values clamped to 0 and that a, b are unbounded.

Modifying my proposal in light of discussion:

Given that, it is clear that negative values of L should be clamped to the 0, that H should be wrapped to the 0 to 360 range, that C should have negative values clamped to 0 and that a, b are unbounded.

Values of L greater than 100 will be undefined. I need to play with conversions, suspect it just results in rgb values greater than 1.0, which will be clamped.