[csswg-drafts] [css-color-4] Correct/simplify normalization in hue interpolation (#9335)

yarusome has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-4] Correct/simplify normalization in hue interpolation ==
Since https://github.com/w3c/csswg-drafts/commit/f46b5d4011cf16402c134165038cedf2126d6152, any `<hue>` is already normalized to be within the range `[0, 360)`, so the algorithms in [12.4.1. shorter](https://drafts.csswg.org/css-color/#hue-shorter), [12.4.2. longer](https://drafts.csswg.org/css-color/#hue-shorter), [12.4.3. increasing](https://drafts.csswg.org/css-color/#hue-increasing) and [12.4.4. decreasing](https://drafts.csswg.org/css-color/#hue-decreasing) *already work as expected* without the third paragraph under [12.4. Hue Interpolation](https://drafts.csswg.org/css-color/#hue-interpolation):

> Both angles and their difference need to be constrained to [0, 360) prior to interpolation. To do this, the minimum number of turns that fit in the lesser angle is added or subtracted from both angles, bringing the lesser angle into the range [0,360); and if the difference between them is greater than or equal to 360° then the minimum number of turns to bring the difference into the range [0,360) is further subtracted from the greater angle.

In addition, even if the normalization of `<hue>` is skipped before the above paragraph, it still fails to achieve what it claims. Example: `(θ₁, θ₂) = (300, 600)` passes through intact.

**Note:** I'm opening this issue as a follow-up to #8838 because it would simplify a lot for explaining the (conditional) equivalence of `short`/`longer` and `increasing`/`decreasing` in https://github.com/mdn/content/pull/28943.

Cc @svgeesus.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9335 using your GitHub account


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

Received on Monday, 11 September 2023 11:12:11 UTC