Bug 277538 – WPT css/css-color/parsing/relative-color-out-of-gamut.html fails lab/lch-to-hwb tests

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Gerald Squelart]

LayoutTests/imported/w3c/web-platform-tests/css/css-color/parsing/relative-color-out-of-gamut-expected.txt has two "expected" failures:
```
FAIL Property color value 'hwb(from lab(100 104.3 -50.9) h w b)' Colors do not match.
Actual:   color(srgb 0.587758 1.593503 0.775713)
Expected: color(srgb 1.59343 0.58802 1.40564).
Error: assert_array_approx_equals: Numeric parameters are approximately equal. property 0, expected 1.59343 +/- 0.01, expected 1.59343 but got 0.587758

FAIL Property color value 'hwb(from lch(100 116 334) h w b)' Colors do not match.
Actual:   color(srgb 0.588021 1.593364 0.776217)
Expected: color(srgb 1.59328 0.58828 1.40527).
Error: assert_array_approx_equals: Numeric parameters are approximately equal. property 0, expected 1.59328 +/- 0.01, expected 1.59328 but got 0.588021

```

I believe these are due to the changes to `ColorConversion<HWBA<float>, ExtendedSRGBA<float>>::convert()` in bug 272984:
It now uses the sample algorithm `rgbToHwb` found at https://drafts.csswg.org/css-color-4/#rgb-to-hwb, which just uses the full `rgbToHsl` algorithm at https://drafts.csswg.org/css-color-4/#rgb-to-hsl.
However right above `rgbToHsl` there's this note:
> Special care is taken to deal with intermediate negative values of saturation, which can be produced by colors far outside the sRGB gamut.

In the tests above, `lab(100 104.3 -50.9)` is first internally converted to `rgb(1.59350276, 0.587758303, 1.40554833)` (which is close to the final expected srgb, and which is clearly out-of-gamut).
And when this gets converted to HWB, the current algorithm computes a negative saturation, and the initial hue computation of 311 gets treated with "special care" and flipped to 131, eventually giving the unexpected srgb color.
Note also that the (negative) saturation is not even kept in , so we've lost the reason why the hue was flipped.

So I think we should remove the "special care" from the algorithm. (And maybe the specs could be tweaked to avoid this situation?)
I've tested this change (will post PR soon), and it fixes these two failures. Bonus: It also fixes the similar failures in color-mix-out-of-gamut.html.

Alternatively, if the algorithm is really to be used that way, then the resulting tests may need revising to account for this. But that would seem less correct to me.
Sam: Thoughts, opinions?

[Radar WebKit Bug Importer]

<rdar://problem/133045692>

[Gerald Squelart]

Pull request: https://github.com/WebKit/WebKit/pull/31636

[EWS]

Committed 282101@main (d26cb4ae7f44): <https://commits.webkit.org/282101@main>

Reviewed commits have been landed. Closing PR #31636 and removing active labels.