[css-color-4] lch() and lab() should use a % for their L argument, not a number

[tabatkins]

(Migrated this sub-issue from #278.)

In lch() and lab(), the L (lightness) argument normally ranges from 0 to 100, similar to hsl()'s L argument going from 0% to 100%. It can go above 100, 100 still represents "full white" with no hint of the hue color; higher values just indicate brighter, more luminous whites. (Wikipedia even defines the L argument as being 0-100, with no mention of higher values!)

We should be consistent in our usage here, and make L just a <percentage> in these two functions, like they are in hsl().

(a/b/c are all much more arbitrary values with no theoretical max, so keeping them as an arbitrarily-defined number rather than a percentage makes more sense.)

@svgeesus Thoughts? This would prevent the collision of number/percentage meaning that you were concerned about in #3450, too. ^_^

[svgeesus]

I'm somewhat reluctantly (because I value consistency with existing use in the wild, which never uses a %) concluding that for CSS, a % will be how we go. Also, for the collision/disambiguation aspect (if it is optional, does 50% mean 50 or 0.5) that percent needs to be mandatory, not optional.

I'm okay with making the change, and seeing what feedback we get on it.

[Crissov]

• If lightness is specified as a <percentage> (and hue as an <angle>), the order of components becomes arbitrary inside lch().
• <percentage> may be more useful than (or just as useful as) <number> if calc() was allowed in color functions.
• <alpha-value> is redundant with <cmyk-component>.

We have several relevant precedents:

• <alpha-value> = <number [0.0, 1.0]> | <percentage> = <cmyk-component>, wherein <number> = calc(<number>% * 100%)
• <hue> = <angle> | <number>, wherein <number> = <number>deg
• rgb(), wherein the 3-tuple is required to be of a single type, i. e. either 8-bit <integer [0, 255]>{3} (or simply <number>{3}) or <percentage>{3} and not a mix of both, although the optional fourth parameter is <hue>, thus may (but need not) match <percentage> and cannot match <integer>.

I see no reason, why <lightness> = <percentage> | <number [0, 100]> would pose an actual problem, even if <alpha-value> and <cmyk-component> work differently, because in <hue> we already have a case where the unit is simply optional. Percentages are the internally consistent dimension to use here. External consistency should be of secondary concern or at least not prohibit internal consistency.

For Lab(), the second and third parameter, a and b, could be normalized as percentages (e. g. with a [0, 160] or [0, 255] range), but that would be more appropriate for u and v in Luv(), which is not part of CSS.
Chroma C could be normalized as a percentage as well, e. g. within [0, 255], which is well above the actual encountered maximum chroma value of about 230, but this would be very unconventional.

At least for LCH(), we could, much as in rgb(), require authors to either use units for all components (where possible) or for none:

lch() = lch( <number>{3} | [<percentage> && <number> && <angle>] [ / <alpha-value> ]? )

This would also make it possible to use the alternate HLC order of components (like HSL). This is impossible when using <number> for lightness and <hue>, although it would work with <angle> if either chroma always follows lightness or is always the second component:

lch() = lch( <number>{3} | [<number>{2} && <angle>] [ / <alpha-value> ]? )

By the way:

• lab() and lch() do not link to their definitions in heading 8.1, whereas all other color functions do.
• In Lab to LCH conversion and in the informative sample code, one could use C = hypot(a, b).