- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Sep 2020 16:07:32 +0000
- To: public-css-archive@w3.org
> If a color() specifies an invalid color but its fallback is valid, is the color() call valid? It seems like it should be, as this is how var() fallbacks work, but we need to resolve. Yes, otherwise fallback doesn't mean anything. > It is currently specified that if a color space is not supported, the color is invalid. However, if the color space is a <dashed-ident>, the color should be invalid at computed value time, since the color space may always be loaded later. Keyword-defined color spaces can be invalid at parse time, which means their fallbacks can be provided via the cascade. Ah, there's some confusion here. "Invalid color" has nothing do with parsing validity, and thus doesn't touch on notions of IACVT at all. `color(--unknown)` will just render as transparent black, not trigger anything related to variables. Whenever a @color-space is changed/added/removed, any color() functions referencing it just get re-checked and might change the color they represent. `color(unknown)` would indeed be invalid at parse-time, as normal, because it doesn't match the grammar. (If the spec currently says that an unknown dashed-ident makes the function invalid, that's no good and needs fixing.) > If the <dashed-ident> color space is available, but the arguments are incorrect, the color should still be invalid at computed value time, because the @color-profile rule can always be removed and replaced with a different one, for which the arguments are valid. Contrary, for a keyword color space, the validity of the arguments is known at parse time. Yup. > If the fallback applies both when the (<dashed-ident>) color space is not available and when the color is out of the screen gamut, how do you reasonably provide separate fallbacks for these two cases? I imagine the fallback one may want to provide could be significantly different for manual gamut mapping or for an undefined color space. For example, if the color space is unavailable, the fallback must be in a different color space. Whereas, if the color space is available but the color is out of gamut, the fallback could still be in the same color space, just with different arguments. Ooh, good point. That suggests we might want to limit ourselves to the "color-space not yet loaded" case, and leave gamut-handling to something else (addressed below). That simplifies the fallback logic significantly, as well. > I wonder if it would be best to provide a media query or other type of conditional to check if a color space is available? Yes, the "in-gamut" MQ case is being discussed in #5045; I think it's a great idea. We could also address this inline with something like an `in-gamut()` function, which takes 1+ colors and selects the first one in the device's output gamut, auto-forcing the last one into gamut if necessary. (And maybe allowing a mapping strategy to be selected for that last one? Then it's useful even for a single argument.) > How does one provide a fallback to lch()? It's not available as a predefined color space on color(), and the lch() function doesn't have a fallback parameter. I suppose it's possible via color(--nonexistent, lch(...), fallback) but that's clunky (and depends on having multiple fallbacks, which I'm not convinced we need). Then again, perhaps the in-gamut MQ can resolve these cases. This supports the argument that gamut fallback should be handled separately from "undefined colorspace" fallback. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5046#issuecomment-693507252 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 September 2020 16:07:33 UTC