[css-color] add `xyy` and/or `xyz` functions

[dpk]

I think there should be a way to specify colours by direct reference to coordinates in the CIE 1931 xyY and/or XYZ systems.

Use case: These spaces may not be intuitive for human authors, but for scripts which generate colours out of some other, non-CSS-supported colour space, most of them will be converting to xyY or XYZ and then to sRGB or P3 or Rec.2020; they could reduce the chance of errors in their own code, and duplication of code which doubtless already exists in the user-agent (which, undoubtedly, will be converting from e.g. sRGB to P3 by going through xyY or XYZ, and thus already knows how to convert from these spaces to the display target space), by simply avoiding the last step. Converting to Lab or LCH for these purposes has the same problem of being potentially bug-prone and being an ultimately unnecessary transformation.

If the specified colour is outside the target gamut of the stylesheet the rule should be invalid. Though I see that this involves making the validity of rules dependent on the gamut of the output device, hmm.

[svgeesus]

If the code can already correctly convert from whatever source format to XYZ and then to sRGB, I see no good reason why the trivial conversion from XYZ to Lab would be "error prone".

In addition, Lab uses a known reference white and adaptive state while for XYZ, one needs to specify what is the adaptation state. Notice that the sample code in the specification uses XYZ at two stages, with different meaning 9before and after chromatic adaptation).

On the other hand, one good reason to add XYZ would be where absolute, rather than relative, luminance needed to be directly specified.

So I am not against adding them, but it needs to be well specified exactly what is being referred to by a given XYZ measurement. (Absolute vs. relative, unadapted vs. adapted).

Perhaps you could explain the use case a bit more: in particular what color space is the input to this script.

As to making rule validity depend on target device gamut, that is a fragile solution compared to the usual rendering intent and gamut mapping procedure which is standard in the industry.

[dpk]

I hoped to generate xyY coordinates from the Munsell colour space, using interpolation from the renotation data file. D3.js also has support for some ‘unusual’ colour spaces which would probably benefit from this. Scripts generating rendering content intended to be printed to the screen for proofing could also take care of handling specific devices’ CMYK spaces.

[svgeesus]

Thanks for describing your use case. Note the following:

There are three files available for download. All are of the same format: six columns of Munsell hue, Munsell value, Munsell chroma, CIE x, y, and Y. The chromaticity coordinates were calculated using illuminant C and the CIE 1931 2 degree observer.

so these values cannot be used directly as xyY in any case - they would need chromatic adaptation to D65 for display, and to D50 for Lab. Failing to do so would introduce substantial error.

[svgeesus]

I note that @smfr also suggested adding XYZ, partly because ICC uses either XYZ or Lab as a profile connection space. In both cases, a D50 whitepoint is used.