- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Mar 2024 19:01:23 +0000
- To: public-css-archive@w3.org
> The problem that I want for us to focus on solving here is how to avoid having authors specify colors that are far beyond their display's capability to produce. > This takes away the ability from the author to specify content (too) far outside of their display's capabilities. "Their display" and "other user's displays" and "any physically realizable display" are all different, though. And I am very uncomfortable with any implementation where someone specifies, say, a color inside `rec2020` or, in the near future, `rec2100-pq` (thus, a real-world visible color which is expected to be within gamut of a physical display at some point) and what they see _bears no relation_ to that color. Lightness is not preserved. Chroma and Hue become weirdly altered. Part of that support will certainly need to happen through devtools and some through code editing tools, which nowadays typically provide a single color patch and could easily display the sort of compact, color-coded gamut flags seen in @LeaVerou [gamut mapping demos](https://colorjs.io/apps/gamut-mapping/?) on color.js. But part of it is displaying a non-surprising representation of that color, on whatever screen. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1981581384 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 March 2024 19:01:25 UTC