- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Feb 2024 18:46:58 +0000
- To: public-css-archive@w3.org
First, I don’t think restricting gamut mapping to a particular gamut simplifies anything. You still need to have a reasonable gamut mapping algorithm, and once you do, you may as well apply it to colors outside that gamut to produce *something* reasonable. Otherwise, the question of how to handle these colors remains (and no, clipping is never acceptable). One idea I came up with during the meeting to bridge the two schools of thought (device independence / perceptual uniformity and [baking gamuts in]((https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1944207376)). What if we define the chroma percentage this way? **I.e. for each H, L, percentages in chroma correspond to the max chroma in the p3 (or rec2020?) gamut.** That's what the reference ranges were meant to be anyway, and they were just defined as fixed ranges for implementation convenience. UAs could even precompute the max chroma across fixed sampling points to make this a very fast lookup. Alternatively, we could keep the reference range as-is (especially since this has now shipped) and introduce an `of <colorspace>` syntax. So you could do things like `oklch(90% 100% of display-p3, 350)`, which also has the advantage of readability, clarity of author intent, and future-proofing (because different color spaces can be specified). The downside (beyond verbosity) is implementation: precomputing patches becomes less worthwhile, but caching these computations could still work (or a combination: precomputing across large increments for an upper bound, then caching more granular calculations). -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1944401323 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 February 2024 18:47:01 UTC