[css-color-4] lab and oklab inconsistencies

[Juanmihd]

This is a question regarding parsing and serialization of lab, lch, oklab and oklch values.

The lightness in all these four color spaces can be specified either as a <percentage> or as a <number>.
In both lab and lch, these values are interpreted this way:

Percent reference range
for L: 0% = 0.0, 100% = 100.0
for C: 0% = 0, 100% = 150

Instead for oklab and oklch , these values are interpreted this way:

Percent reference range
for L: 0% = 0.0, 100% = 1.0
for C: 0% = 0.0 100% = 0.4

We believe that it would be clearer if both behave in a similar way.

Is there any reason why this was decided this way?

This issue impacts as well ab values in lab vs oklab.

[svgeesus]

This is because CIE Lab (and LCH) define Lightness as 0 to 100, while Oklab defines their Lightness as 0 to 1.

W3C did not define either standard, we just reference it. Hence the reference ranges for percentages. And CSS is not going to require a CSS-only version of either standard. The best we can do is make the percentages both go from 0% to 100%.

[mysteryDate]

This is because CIE Lab (and LCH) define Lightness as 0 to 100

So then if we accept both percentages and non-percentages for lab then:
lab(50% 0.5 0.5) = lab(50 0.5 0.5)

So we're saying that 50% is equivalent to 50, which feels extremely wrong.

[svgeesus]

That is, nevertheless, how the CIE defines it. And people need to be able to copy and paste values from other applications, from physical measurement devices, and so on.

CSS defines percentages in a similar way in other places. 50% is not always equivalent to 0.5.

[tabatkins]

Yup, in CSS a percentage is not fundamentally equivalent to a number, it instead represents progress along some arbitrary range (which might be a number, a length, an angle, etc). Similarly, "width: 50%;" isn't equivalent to "width: 0.5;" (which would be invalid), it's equivalent to some length value (like 200px) calculated from the "available width".

[Crissov]

Indeed, CSS is making a concession to authors and tools by supporting <number> values in functional color notations, whose meanings and ranges are defined outside W3C, at all. Such convenience syntax has been established early on with rgb() also accepting <number[0,255]>.

We could argue – and I believe it already has been argued – whether it makes sense to accept arbitrary mixes of percentages and numbers. That is, like rgb(), the syntax for Lab spaces might be better defined as:

lab() = lab(<lab>)
oklab() = oklab(<lab>)

<lab> = [<percentage> | none]{3}
      | [<number> | none]{3}
      [ / [<alpha-value> | none] ]?

or even:

<lab> = [ [<percentage> | none]{3} [ / [<percentage> | none] ]? ]
      | [ [<number> | none]{3} [ / [<number> | none] ]? ]

instead of:

lab() = lab
      (
      [<percentage> | <number> | none]
      [<percentage> | <number> | none]
      [<percentage> | <number> | none]
      [ / [<alpha-value> | none] ]?
      )

This argument applies likewise to hue angles:

<lch> = [<percentage> | none]{2} [<angle> | none] [ / [<percentage> | none] ]?
      | [<number> | none]{3} [ / [<number> | none] ]?