- From: Chris Lilley <chris@w3.org>
- Date: Tue, 16 Feb 2016 10:34:53 +0100
- To: Florian Rivoal <florian@rivoal.net>, Simon Fraser <smfr@me.com>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
Hello Florian, Monday, February 15, 2016, 1:07:08 AM, you wrote: > On Feb 12, 2016, at 11:16, Simon Fraser <smfr@me.com> wrote: >> I think we’re prefer to avoid referencing external resources for >> colors. What do you show before the resource is available? Transparent? > That's a real issue, and we should find some way of dealing with > the fall back, but I don't think we can have a solution that > does not allow for external color profiles. Absolutely. Otherwise we fail at one of the commonest use cases - CSS for print publishing, where there is an external profile for the target printing device but we want the same colors shown on screen. > Otherwise we're not > going to be able to do color matching with images, or to have print specific color profiles Yes, color matching to wide-gamut images is the other really common use case (and these are likely to be in AdobeRGB, or an even wider space like ProPhoto) > Maybe specifiying in the at-rule what kind of color model we're > defining can give us an idea (even if approximate) of what to do > when the resource hasn't loaded. > @colors "name" { > profile: url() | from-image(); Extracting a color profile from the one embedded in an image is interesting. > model: rgb | xyz | cmyk | ...; > } I think that is better done with fallbacks, like the ones in a font stack. Given that we have some predefined names, they can be used last in the same way that generic font-families are. Also we don't need xyz (or lab) in that list; they don't need a profile, they are already fully defined. > Or maybe we can extend the color function to have an explicit fallback. > Or maybe we can define that the color function defaults to > currentColor, Do you mean the existing CSS4 color function, or the function that used to be called icc-color? > or do that in most contexts but default to the > background color in other contexts. > Or maybe all of the above. That does sound a little complex but I agree that currentColor is going to be a better fallback than transparent black or whatever. -- Best regards, Chris Lilley Technical Director, W3C Interaction Domain
Received on Tuesday, 16 February 2016 09:35:12 UTC