Csswg-drafts: [css-color] lch() function needs to use CSS types properly.

[tabatkins]

H being defined as "a number between 0 and 360" is super-janky, we have <angle> for a reason.

Similarly, L should be a percentage, since the normal range is 0-100. It's okay for %s to go over 100 or below 0 if necessary, the 0%-100% range should just represent the standard bounds.

I think the only one that really needs to be a number is C.

[frivoal]

I agree on H (even though this will make things a tad more verbose). It is an angle, so it should be written as such, and whatever angular notation CSS has now or in the future should be OK.

I am less sure about L. It is a number between 0 and 100, so slapping on a % sign on it is tempting, but it is not the way it is usually written, and it feels wrong. 50% is normally synonymous with 0.5, and L=0.5 in common notation is an almost pitch black luminosity different from the middle luminosity of L=50.

If we were inventing the notion of Lab without context, I would agree with defining L as a percentage (or a number between 0 and 1). But we're not, we're discussing a notation for an per-existing concept, and as such, keeping the usual notation in place seems sensible.

But it really does look like a percentage though, so maybe I can be convinced otherwise...

[svgeesus]

I agree that H is an angle (by definition). It is also always written in degrees, in existing useage, so forcing people to add the string "deg" to it is needless verbosity. When transcribing a measurement (from a spectrometer, for example) they will need to remember to edit the hue angle to 30deg instead of 30, or it won't work. This is a usability drawback with no compensating advantage except for theoretical purity. I chose compatibility with existing practice as preferable.

L is, as Florian says, not a percentage. 50% is 0.5, which is 100 times less light than 50. Percentages are fine when the range is 0.0 to 1.0, which is not the case here.

[LeaVerou]

Per the robustness principle, we should accept both numbers and angles in H. This is both compatible with hsl(), and prevents the most errors while allowing the user to make the tradeoff of readability vs verbosity that they prefer.

[tabatkins]

This is a usability drawback with no compensating advantage except for theoretical purity. I chose compatibility with existing practice as preferable.

You should be choosing compat with CSS, not with outside usage. The latter just results in an inconsistent language with annoying footguns. We _must_, _at minimum_, make the argument [ <angle> | <number> ].

I don't particularly want the "or <number>" part either - "unitless angles" are not applicable across all of CSS, so it's another random oddity that people have to remember - they can omit the unit if they're using degrees in _these_ places but not _those_ places. Better to be consistent and let people learn only a single way to do things; saving three characters (but losing a small amount of readability) isn't worth it.

[tabatkins]

Okay, lch() now uses <hue>, same as hsl(). That accepts <number> | <angle>.

I still argue that lightness is a percentage. In most cases it's interpreted the same as the lightness in hsl() - 0 is black and 100 is white. The fact that you can go above 100% doesn't make this not-a-percentage, any more than the fact that you can exceed 100% in RGB means that those channels aren't percentages. There is a useful minimum and maximum value that is typically observed, and those are typically written as 0 and 100, which is basically percentages.

Trying to argue that 50% == .5, rather than 50, is silly. By the same argument, vw units wouldn't be percentages, when they clearly are - we're just expressing them in a more-specific unit that equals 1% of the viewport width. We had the same argument (50vw or .5vw) when we first designed those units, and the group agreed that it's easy and natural to make percentage-like units use a [0-100] range rather than [0,1].

[svgeesus]

Okay, lch() now uses <hue>, same as hsl(). That accepts <number> | <angle>.

SGTM

[tabatkins]

My edit only addressed the H part of lch(). The other part, about lightness, is still open.