- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 May 2020 00:32:59 +0000
- To: public-css-archive@w3.org
Oof, yeah, I really didn't define that well enough. I *think* I didn't intend for out-of-gamut to do anything special here; the fallback was just for color-spaces that haven't loaded and such. That said, it sounds reasonable to me to make it also mean "not in the output gamut". If we do that, tho, we still want to distinguish between "out of gamut" and straight up "invalid"; we don't want to resolve color() to transparent black just because the last color in its list was out-of-gamut! Instead we want to try and render that color, using the existing gamut-correction stuff that we'd do with anything else. So yeah, the logic then becomes: * if the specified color is decodeable and in-gamut, use it. * if the specified color is decodeable and out-of-gamut, attempt to use the fallback. If the fallback is an *invalid* color, instead use the specified color anyway. * if the specified color isn't decodeable, use the fallback. (If the fallback ends up being invalid too, that's fine, it'll just make the outer function an invalid color too.) -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5046#issuecomment-635018431 using your GitHub account
Received on Thursday, 28 May 2020 00:33:01 UTC