Csswg-drafts: [css-color] Lab and LCH pseudo functions differ too much from others

[Crissov]

In Specifying Lab and LCH: the lab() and lch() functional notations, there’s no reason given why these should not use mandatory commas between values and the obviously more appropriate types instead of generic <<number>>.

Current definitions

    <dfn>lab()</dfn> = lab( <<number>> <<number>> <<number>> , <<alpha-value>>? ) 

    <dfn>lch()</dfn> = lch( <<number>> <<number>> <<number>> , <<alpha-value>>? ) 

Proposed definitions

    <dfn>lab()</dfn> = lab( <<percentage>>, <<number>>, <<number>> [, <<alpha-value>>]? ) 

    <dfn>lch()</dfn> = lch( <<percentage>>, <<number>>, <<hue>> [, <<alpha-value>>]? ) 

I’m glad there are no laba() and lcha variants and wish rgb() and hsl() could be retrofitted, so that rgba() and hsla() could be deprecated, especially now that <<alpha-value>> accepts percentages. If <<hue>> didn’t accept unit-less numbers for legacy reasons, one could even imagine a unified cie() function notation.

[tabatkins]

Omitting commas is intentional; I'm proposing in https://github.com/w3c/csswg-drafts/issues/266#issuecomment-230898208 we remove all of them now (including the one separating alpha from the other args). Functions are just named chunks of CSS syntax, and we use commas in CSS syntax for very specific reasons, not just as a value separator (whitespace already accomplishes that). We've got a bunch of legacy functions, but I'm trying my best to fix things where I can when we introduce new stuff.

Types should indeed be corrected; I opened #278 just a little bit ago before I saw this issue.

There are no legacy issues for <hue>, only for hsl(). Hue in lch() should just be an angle, simple as that.

The lab() and lch() functions are different enough that unifying them isn't a good idea, even if you can grammatically distinguish them; only the first argument is shared between the two. Giving them distinct names is a good thing.

See #275 for a proposal to just fold rgb() into the color() function, which provides the "optional alpha" behavior so you can ignore rgb()/rgba() as legacy syntax.

[svgeesus]

L in lch and lab is indeed a number in the range 0 to 100 (except some currently rare high dynamic range applications, where I have seen L as high as 400). I didn't specify it as a percentage, because it is never given as a percentage anywhere lab or lch is used. Thus, I valued compatibility with existing usage. I can see usability issues if the percent sign is required, as people will forget to add it.

I don't strongly oppose percent, but wanted to document the reasons for the original design decision.

I can see Tab's point that commas are not needed for unambiguous parsing. I do think that comma to separate color ags from alpha is more readable.

Attempting to unify lab and lch would be confusing and a regressive step. The self-documenting names and compatibility with existing practice is, as Tab says, a good thing. cie would be a vey poor choice (what about the other cie spaces like XYZ, xyY, LCHuv, and so on)

[Crissov]

I believe internal consistency is more important than external consistency (e.g. bearing angles), so

1. hue needs to accept angular units (I’m not 100% sure they must be mandatory, since:)
2. all color functions should separate components in the same way (I don‘t care which, but commas are well established).

However, it seems this issue can be marked as duplicating #266 and #278. So it can be closed if the square brackets for the alpha value have been added or the preceding comma (which the question mark need to apply to, too) has been removed.

PS: Percentages are not inherently restricted to 0%–100%, e.g. rgb(110%, 80%, 50%) is legal if I remember correctly, but I’m not sure rgb(-10%, 80%, 50%) is, too. The spec just needs to define whether and when clamping may happen, see #289. rgb is also a precedent for unit-less numbers, although with 10-bit color components its 8-bit 0…255 is not sufficiently accurate any more (and neither is hex notation).

[svgeesus]

rgb values outside 0.0% to 100.0% were indeed allowed but were poorly defined, see #288 and css4-color will discourage their use and do per-component clamping if they are specified. It is correct that 0..255 numbers are 8bit only, this is a historical limitation based on the time CSS1 was defined (indexed displays were common and truecolor 24bit displays were seen as high-end). The percentage notation was to disambiguate numbers like 0 or 1 which a 0.0..1.0 range would have made problematic; this is why we ended up with a 0.0% to 100.0% for specifying meaningful colors. These are numerically equivalent to 0.0 to 1.0 (100/100).

I agree that consistency is good, but there are so many things to be consistent with :) for example some have argued for mandatory commas between components like rgb() has, because all the existing color-related notations use commas except for hex notation; while Tab argues against commas because in some non-color parts of CSS comma is used to separate lists.

The discussion on commas and separators for alpha is ongoing and vigorous. Leaving this issue open until that settles down.

[Crissov]

One advantage of percentages is that it’s a general rule and thus intuitive that 100% is a large value compared to 0%, and it’s probably either the inherited/default or the maximum value – whichever makes more sense. A mere 1.0 or 1, on the other hand, could be just a tad more than 0.0 or 0, but it could also be on the other end of the scale – it’s impossible to know or guess without learning the conventions that apply. Please let’s agree that unit-less numbers should remain the exception in CSS, not become the rule.

Put in other words, nobody should be encouraged to use rgb(0, 100, 255) (nor #ABCDEF)!

[tabatkins]

Okay, this thread is addressed at least somewhat. lch() now uses <hue>, same as hsl().

I still agree that the first argument is a percentage, so I'm keeping this open until we resolve that for sure.

[tabatkins]

Actually, I'll close this one, and keep open the issue I opened that's slightly more specific about just the types.