[csswg-drafts] [css-color-4] Fallback strategy for nonexistent color spaces? (#6129)

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-4] Fallback strategy for nonexistent color spaces? ==
This comes from #5931, which is a closed issue. Here is the discussion so far:

@leaverou:

> > Do we also need a way for authors to provide fallbacks for nonexistent color spaces, which was another function of the fallback parameter?
> 
> Nonexistent colorspaces result in `invalid color` which produces `opaque black`.

How would authors be able to handle failure here? Especially since custom color spaces depend on separate HTTP requests, which could always fail for whatever reason. We don't want websites to suddenly turn all black because an HTTP request failed, do we? That would be terrible, both for accessibility and usability.

Some thoughts:

- What if instead of opaque black, the property becomes invalid at computed value time, which would set it to `unset`. That is a far more reasonable fallback for most cases.
- I wonder if instead of having a _color fallback_, we should really have _color space fallbacks_. What do I mean by that? A `@color-profile` descriptor that basically says "if my ICC profile doesn't load, treat my coordinates as this color space". E.g. if we link to a profile for OKLab and it doesn't load, treat coords as Lab. Or if we link to an RGB profile, we can say, as a fallback, treat params as sRGB or P3 or whatever built-in RGB color space is closest to the one we linked to.

@tabatkins:

I'm not *strongly* opposed to doing more IACVT, but I'd like to avoid adding it to more things if we can; it's an awkward compromise that still doesn't give any guarantee that the result is readable.

I *do* quite like the "color space fallback" idea, designating which of the predefined colorspaces treats its first three arguments "close enough" to your desired colorspace to work as a last-ditch substitution. That seems to solve the problem quite well. Should we choose a default for this, or require it to be explicitly specified on each `@color-profile` rule?

@faceless2:

I also really like the "color space fallback" solution. Assuming the author hasn't just messed up, the way this is going to come into play is if the profile is unavailable. Lea's suggestion would almost certainly be the least visually jarring result.

Obviously if we have `@color-profile foo { src: url(missing.icc) }` we don't really know enough about the missing profile to determine which space to choose as a fallback. A presumption based on the number of components is what I'd suggest - one component is grayscale, three is `sRGB`, four uses `device-cmyk`.

This will fail for lab profiles, and  for "exotics" with two or more than four components - which can just fall back to black as they do now. And three color spaces that are not RGB are super rare in the real world. Given we're falling back to black  now, falling back to an equally incorrect color isn't a step backwards. While testing I frequently turned whole pages black, as my missing profile meant both text _and_ background were black. Frankly anything is an improvement over that.

@LeaVerou:

> While testing I frequently turned whole pages black, as my missing profile meant both text _and_ background were black. Frankly anything is an improvement over that.

Yup, that is exactly what I was trying to avoid, so I think failing to opaque black is unacceptable in *any* case.

Probably the best possible fallback will come from the fallback color space. Note that this could also provide a good fallback while the profile is loading, preventing huge color shifts, which would otherwise deter many authors from using ICC profiles. People could even use it as progressive enhancement. I have also heard there were concerns from the Blink team about having colors that depend on an HTTP request, hopefully this should help alleviate them.

However, there is not always a built-in color space that is reasonable, so I don't think we can make this descriptor mandatory. While most ICC profiles are RGB and CMYK, they are not the only ones. This is where IACVT comes in, which, as a last resort, produces far more accessible results than just opaque black everywhere. If we don't want to use IACVT, another option might be to use the property's initial value **if** that is a color, otherwise `transparent`. This prevents the "black text on black background" problem, and doesn't make the entire declaration invalid like IACVT would.

@carlosame:

Although I'm reluctant to post in closed issues, I want to add that "opaque black" is probably not the most adequate choice because it is not printer-friendly. As was mentioned, it is possible that large chunks (or entire pages) of a document become black, and for printing use cases a likely outcome is the toner cartridge being wasted. white or transparent seem more sensible choices, toner-wise.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6129 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 23 March 2021 18:17:23 UTC