[css-color-4] Device-independent color definitions

[GPHemsley]

The sections on device-independent colors (Lab/LCH/OkLab/OkLCH) seems to intermingle normative and informative prose, making it hard to distinguish what is needed for implementation and what is simply a history lesson.

This then has a knock-on effect on the actual syntax of the functions, because certain concepts are either silently alluded to or are unspecified altogether, in both cases assuming too much about the reader's familiarity with the concepts and thus ability to fill in the gaps.

For example:

• How are <number> values to be interpreted? Everything but the grammar itself talks only about percentages.
• What are the additional tables of "Percentages" and "Percent reference range" meant to be used for? The data there is either redundant with or not directly referenced by the definition.
• Terms like "Lightness" and abbreviations/variables like "L" seem to be used interchangeably throughout the definitions, which makes it hard to keep track of what values are used where.

Can this section be clarified more to differentiate parsing vs. processing, and otherwise focus on the aspects related to implementation? More linked terms may also help.

[svgeesus]

The text for Lightness indeed only talks about percentages, because CSS WG early on decided that percentages were mandatory and only much later was this relaxed to also allow number, like everyone outside of CSS WG expects.

The first argument specifies the CIE Lightness. This is a number between 0% (representing black) and 100% (representing white), Values less than 0% must be clamped to 0% at computed-value time; values greater than 100% are clamped to 100%.

I agree that this needs to be edited to take into account that numbers are now allowed (and are the serialized form).

@GPHemsley wrote:

What are the additional tables of "Percentages" and "Percent reference range" meant to be used for?

Converting percentages to numbers

Terms like "Lightness" and abbreviations/variables like "L" seem to be used interchangeably throughout the definitions, which makes it hard to keep track of what values are used where.

Yeah I agree that should be

Lightness (L)

at first usage, so it is clear they are the same concept; one is the name and the other is the symbol. Same for Chroma and C.

[GPHemsley]

So, just to clarify, is the following true?

• lab(-10 0 0) should serialize to lab(0 0 0)
• lab(110 0 0) should serialize to lab(100 0 0)

Due to clamping in the range 0% to 100% and then converting to number format according to the Percent reference range values?

It seems current implementations may not do that, especially at the upper limit? (Indeed, WPT seems to encourage otherwise.)

[GPHemsley]

And how does hue serialize? Does it use number or degree? Is it clamped to 0..360?
How should lch(-10% -10% 360deg) serialize?

[GPHemsley]

It looks like dfb8a21 touched on some of this.

And there is some new discussion around clamping in #7677 that may be relevant.

[svgeesus]

Yes, recent edits were driven by the early clamping discussion in #7677 but as you note, impact this issue as well.

So, just to clarify, is the following true?

• lab(-10 0 0) should serialize to lab(0 0 0)
• lab(110 0 0) should serialize to lab(100 0 0)

Yes. From Specifying Lab and LCH: the lab() and lch() functional notations

Values less than 0% or 0 must be clamped to 0% at parsed-value time; values greater than 100% or 100 are clamped to 100% at parsed-value time.

And how does hue serialize? Does it use number or degree? Is it clamped to 0..360?
How should lch(-10% -10% 360deg) serialize?

From Representing Cylindrical-coordinate Hues: the <hue> syntax:

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].

So <hue> serializes as number (of degrees), which follows on from the CSSWG resolution on color components in Color 5 which also went with number.

I'm actually unclear whether this should be [0, 360) which seems better but I saw some use of [0, 360] in other threads so cautiosly went with that. But now we removed the specified option from Hue Interpolation I think [0, 360) makes more sense and preserves the 1:1 colorimetric identity between different syntactic forms.

[svgeesus]

@GPHemsley could you take another look at Device Independent Colors and check that all your concerns have now been addressed?

[svgeesus]

Having re-read through that section it appears that all the concerns raised here have been addressed:

• Marked introductory, tutorial sections as informative
• Explicitly stated that both number and percentage can be used to specify the component values L, a, b and C
• Explicit clamping of L to [0..100] for Lab and [0..1] for Oklab
• Reworded percent reference range
• Reworded, first mention is "In Lab, the first argument specifies the CIE Lightness, L." and then L is constently used

Also in serialization, the use of the percent reference ranges to perform percentage to number conversion is made explicit, with each subsection linking back to the reference ranges for that conversion. Extra examples were added to illustrate this.

[svgeesus]

Closing this (and other issues where no change to the spec is expected).