Re: [csswg-drafts] [css-color-4] lch() and lab() should use a % for their L argument, not a number (#4477)

+ If lightness is specified as a `<percentage>` (and hue as an `<angle>`), the order of components becomes arbitrary inside `lch()`.  
+ CIELAB _a_ and _b_ might not be percentages in disguise, but CIELUV _u_ and _v_ apparently are. They *could* be covered by the same function. 
    cie() = cie( 
     /* Lab */   [<number>{3}] 
     /* Lab */ | [<percentage> && <number>{2}] 
     /* Luv */ | [<percentage>{3}]
     /* Luv */ | [<number> && <percentage>{2}] 
     /* LCH */ | [<number>{2} && <angle>] 
     /* LCH */ | [<percentage> && <number> && <angle>] 
               [ / <alpha-value> ]? 
+ `<percentage>` may be more useful than (or just as useful as) `<number>` if `calc()` was allowed in color functions. 
+ `<hue>` is redundant with `<cmyk-component>`. 

We have several relevant precedents:
+ [`<alpha-value>`]( = `<number [0.0, 1.0]> | <percentage>` = [`<cmyk-component>`](
+ [`<hue>`]( = `<angle> | <number>`
+ [`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>`. 
+ In transformation matrices, the translation values are always in pixels and, unfortunately, never allow any unit symbol, but in dedicated properties and functions, they are required. 

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 `<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> ]? )

[css-values]( says in a note that we can never have a `<number-percentage>` value type due to how `calc()` works, and probably no `<integer-percentage>` either. Color components cannot be used with `calc()`, but if they ever shall be, it would make sense to allow standard, internal CSS value types (like `<percentage>`), even if conventional, external notation is also to be supported and needs to be expressed in another value type (like `<number>`). 

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)`. 

GitHub Notification of comment by Crissov
Please view or discuss this issue at using your GitHub account

Received on Sunday, 3 November 2019 10:48:08 UTC