- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 10:06:16 +0000
- To: public-css-archive@w3.org
Lots of things to process, so this is not an exhaustive response, but more some thoughts in no particular order: - I do agree that it’s ok not to gamut map when using the RGB forms. Author intent seems clear there. This way we can also avoid introducing things like `oklch-extended()` — just use RCS to convert to one of the RGB forms if you want to avoid gamut mapping. - I’m not a huge fan to gamut mapping to a particular gamut and getting stuck with it for time immemorial. We have already made this mistake once. I do think it could be ok if the screen gamut is considered. E.g. you gamut map to Rec.2020/P3 OR the device gamut, whatever is larger for that particular color. - I think one thing many people have not realized is that we would not wake up one day and suddenly we'd have displays capable of ProPhoto colors. Any gamut evolution happens incredibly gradually — going from sRGB to P3 took over a decade. So I don’t think the problem @ccameron-chromium is worrying about of extremely bright colors will be as prominent in practice, especially if dev tools evolve quickly to show gamut (it could be as simple as a gamut indicator like the one [here](https://elements.colorjs.io/src/color-picker)). - I think it's quite important to give authors control of what to prioritize: hue, chroma, lightness, relationships between colors, etc. since use cases have drastically different demands. For accessibility, I think preserving lightness should probably be the default. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2162619867 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 10:06:17 UTC