- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Mar 2021 23:45:48 +0000
- To: public-css-archive@w3.org
> > 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. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5931#issuecomment-803194422 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 19 March 2021 23:45:51 UTC