- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Aug 2022 16:39:29 +0000
- To: public-css-archive@w3.org
> Is this above characterization correct? Yes, this is correct (assuming the gamut mapping math is correct, which is @svgeesus' purview). Yes, if you gamut map a CSS color and Canvas does not do gamut mapping, it logically follows that you will not get the same color if gamut mapping is needed. Are you implying that because canvas produces broken results, CSS needs to do so as well? It is far more important to get a color closer to the author intent (@svgeesus [demonstrated above](https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1219663823) what kind of poor results clipping produces), rather than to accommodate the odd case where the same CSS color is displayed next to the same canvas color. That said, ideally Canvas should also add a mode that properly gamut maps OOG colors. Perhaps you would be interested to work on that proposal? We can discuss gamut mapping algorithms all you want, and I think it's highly likely that a better algorithm exists than what is currently in the spec, and I’m sure both I and all other CSS Color editors would welcome input towards producing a better gamut mapping algorithm. However, if the proposal here is to remove gamut mapping from the spec entirely, or to make it an informative note and let UAs get away with simple per-component clipping, I would be willing to formally object to that. It would render wide gamut colors unusable and is both author-hostile, user-hostile, and harmful for accessibility. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1225971274 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 August 2022 16:39:31 UTC