Csswg-drafts: [css-color-4] Should the color() function accept 'lab' as a color gamut keyword

[smfr]

https://www.w3.org/TR/css-color-4/#color-function

Since we're adding support for lab/lch/gray colors, it seems reasonable for the color() function to accept 'lab' as a predefined colorspace (we would need to be explicit about the white point). I also wonder if we should also accept 'xyz'.

[svgeesus]

Since we're adding support for lab/lch/gray colors

Yes, I was very pleased to see that you were!

it seems reasonable for the color() function to accept 'lab' as a predefined colorspace (we would need to be explicit about the white point).

It could, certainly. That would just be a somewhat more verbose alias for the lab() function, right?

border-color: lab(65.5% -38.8 -6.9);
border-color: color(lab 65.5% -38.8 -6.9);

I also wonder if we should also accept 'xyz'.

Would that be absolute, or relative to the media white?

[smfr]

It could, certainly. That would just be a somewhat more verbose alias for the lab() function, right?

border-color: lab(65.5% -38.8 -6.9);
border-color: color(lab 65.5% -38.8 -6.9);

Yes, I think so.

I also wonder if we should also accept 'xyz'.

Would that be absolute, or relative to the media white?

I don't know what would be useful to authors. Maybe color() should let you specify the white point?

[svgeesus]

Ah. No, XYZ is independent of whitepoint. What I mean is that with relative XYZ, the luminance (Y) is scaled to 100 for the media white; while for absolute XYZ the Y is in candelas per square meter (so can take a very wide range of real-world values).

I'm not sure what XYZ adds, from an authoring standpoint. It is more user-hostile then sRGB (but is at least linear-light, not gamma corrected). I'm aware it is one of the two profile connection spaces in an ICC workflow (the other is D50 Lab), which I suspect is why you suggested it?

[Crissov]

That would just be a somewhat more verbose alias for the lab() function, right?

border-color: lab(65.5% -38.8 -6.9);
border-color: color(lab 65.5% -38.8 -6.9);

The current ED prescribes <number>, i. e. does not allow <percentage> (nor <angle> #4489) at all, but this should change soon by way of either #3450 or #4494.

color() = color( [ <ident>? [ <number>+ | <string> ] [ / <alpha-value> ]? ]# , <color>? )

[LeaVerou]

On one hand, this is extra testing and documentation work for little benefit.
On the other hand, I can see use cases if the gamut keyword is in a variable. But those cases are rather limited.

[una]

It seems like with our limited examples for color modification using lab as a default space, we've been seeing a lot of out-of-gamut results -- would this (color()) be a solution to provide fallbacks for those results?

[css-meeting-bot]

The CSS Working Group just discussed [css-color-4] Should the color() function accept 'lab' as a color gamut keyword, and agreed to the following:

• RESOLVED: Add lab keyword to color() function

The full IRC log of that discussion

<dael> Topic: [css-color-4] Should the color() function accept 'lab' as a color gamut keyword

<dael> github: https://github.com/w3c/csswg-drafts/issues/4649

<dael> smfr: I filed for completeness. It seemed like ti should be an option, no strong opinion

<dael> chris: Can, it's just that there's a shorter way to do same

<dael> smfr: Can make same argument for srgb

<bkardell_> +1 to alias

<dael> chris: Yes, but that's for legacy. Happy to add if it's helpful, just an alias

<dael> florian: Why not?

<dael> AmeliaBR: Only concern is if we don't define to include it there might be compat issues later if we want to include it but people have used it for their own custom colors

<dael> chris: That is true, yes

<dael> leaverou: Does that mean we add all the other color spaces as well?

<dael> AmeliaBR: Assume if we make a color function we'd want to be consistent

<bkardell_> it's good to be able to reason across the platform consistently

<dael> smfr: HSL is in srgb color space. This was more about being inclusive of different color spaces. lab, lch, and gray all use the color space.

<dael> chris: Yes, makes sense

<dael> leaverou: Fair enough

<dael> chris: Should we resolve then?

<dael> Rossen_: Any other opinions?

<dael> Rossen_: Objections to Add lab keyword to color() function?

<dael> RESOLVED: Add lab keyword to color() function

[svgeesus]

@una

It seems like with our limited examples for color modification using lab as a default space, we've been seeing a lot of out-of-gamut results

Yes, although partly that is because the examples have been using colors like red and yellow which are maximally saturated and thus right up against the corners of the RGB color cube. So even a small adjustment tends to push them outside the gamut. More normal real-world colors are less likely to fall outside of gamut when manipulated.

would this (color()) be a solution to provide fallbacks for those results?

It would, although gamut mapping to the closest in-gamut color is a more foolbroof and automatic method.

I have been wondering too about another function which takes a list of colors plus a colorspace, and returns the set of colors all adjusted together such that the most out of gamut color is just inside (and the rest are adjusted too, so their relative relationships are intact).

[LeaVerou]

I have been wondering too about another function which takes a list of colors plus a colorspace, and returns the set of colors all adjusted together such that the most out of gamut color is just inside (and the rest are adjusted too, so their relative relationships are intact).

That's quite manual too. It would be nice to have an opt-in to do this for entire elements automatically.