[csswg-drafts] [css-color-4] proposed breaking change: predefined XYZ is D65 adapted, not D50 (#6722)

svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-4] proposed breaking change: predefined XYZ is D65 adapted, not D50 ==
Originally raised in https://github.com/WICG/color-api/issues/24 and also related to https://github.com/w3c/csswg-drafts/issues/6061

Most RGB colorspaces use a D65 whitepoint. (The sole exception in CSS Color 4 is ProPhoto RGB, which uses D50; other examples include DCI-P3, which has a weird greenish white, and ACEScc which has a white similar to, but not the same as, D60).

In practice this means that most RGB to RGB conversions will proceed via CIE XYZ with a D65 whitepoint. In some cases, there will need to be chromatic adaptation, when the white points differ, because the user is assumed to be adapted to the reference white.

So internally, color conversion code will have various different **relative** XYZ spaces; the question becomes which one to expose to the user (by CSS syntax). 

Because most practical use of CIE Lab has a D50 white, at first I defined the white for XYZ in CSS to be D50 as well. 

This causes some issues (adaptation is needed) when:
- calculating WCAG 2.1 contrast, which assumes a D65 white
- using OKLab and OKLCH (which use a D65 white)
- creating uv chromaticity diagrams for most RGB spaces
- performing most calculations that one might want to do on XYZ in a Color object model
- HDR usage such as PQ Rec.2100 or Jzazbz will also need an **absolute** XYZ; in both those cases, D65

So in [WICG/color-api](https://github.com/WICG/color-api) I proposed that the exposed XYZ be relative, D65 adapted.

For consistency, this means CSS Color 4 should also change to use relative, D65 XYZ in the `color()` function.

This is a breaking change in that it affects any existing usage of `color(xyz ...)`. It does _not_ affect any other usage (such as `lab()` or `lch()`), other code or any other conversions, because all the various XYZ versions are still needed internally anyway. It only affects what is exposed and can be specified directly in XYZ.

Usage is effectively zero at this point (I just checked the [draft CSS Almanac 2021 crawl results](https://docs.google.com/spreadsheets/d/12vQIA0xsC5Jr3J9Sh03AcAvgFjMAmP1xSS6Tjai9LF0/edit#gid=1420025896)) so the impacts are:

- slight inconvenience for WebKit and BFO Publisher maintainers
- change a few tests in WPT
- back out a WCAG 21 fix (re-adapt to D65) in color.js

@weinig @faceless2 


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6722 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 11 October 2021 14:52:05 UTC