[css-color-4] Serialization rules for hue component of lch() and oklch()

[weinig]

It was brought to my attention in #7750 that in CSS Color 4 the <hue> is is defined with the following:

This number is not constrained to the range [0,360] but is unbounded. Certain operations, such as hue interpolation, may normalize the hue angle during calculations.

(https://www.w3.org/TR/css-color-4/#hue-syntax)

Currently in WebKit, we normalize hues to [0, 360] for serialization, but I can't find anything that requires that in the spec.

It would be good to clarify the intent and perhaps add some examples of hue > 360 and hue < 0 getting serialized.

[tabatkins]

Yeah, that serialization would cause a behavior change in some cases. Specifically, in "specified" hue interpolation, there's a big difference between "from 10deg to -10deg" and "from 10deg to 350deg". ^_^

[svgeesus]

Currently in WebKit, we normalize hues to [0, 360] for serialization, but I can't find anything that requires that in the spec.

The spec is currently silent on resolving and serializing hue in the polar forms oklch() and lch(). The issue doesn't arise for hsl() and hwb() because the original hue is lost on conversion to rgb().

It should not be, and I agree with the point made in #7750 that being required to track the originally-specified hue is onerous and only makes a difference in hue interpolation with specified. So I would be in favor of explicit normalization to [0, 360) (and dropping specified).

[weinig]

As a counterpoint, in WebKit it is not onerous to track the original-specified angle, in fact it is less overall code. I don't see a good reason to unconditionally normalize and drop specified. The only reason it didn't work as spec in WebKit was a misunderstanding on my part.

[weinig]

Also, my personal opinion is that it makes sense more sense to serialize with the original angle here, as long as we have it.

[svgeesus]

The resolution for this issue and for

• [css-color-4] Hue interpolation "specified" should be removed #7750 (comment)

should be made together so that they are consistent. I see some implementers arguing for normalizing and some not; and that also affects the utility of the specified hue keyword as well. If we normalize, we should drop specified (completely, not just move to a later specification).

[svgeesus]

Now that specified is removed in #7750 I have changed the <hue> definition for early canonicalization, thus allowing a freer choice for internal representation of colors and maintaining the 1:1 colorimetric identity between different syntactical forms:

Because this value is so often given in degrees,
the argument can also be given as a number,
which is interpreted as a number of degrees
and is the [=canonical unit=].

This number is normalized
to the range [0,360].

This also enables the edits from #7876 where channel keywords for hues return a number.