W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [css-color] wider/deeper colors

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 16 Feb 2016 22:09:22 +0900
Cc: Simon Fraser <smfr@me.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
Message-Id: <A8C0C25F-61B0-45ED-B1F8-226F1658F01D@rivoal.net>
To: Chris Lilley <chris@w3.org>

> On Feb 16, 2016, at 18:34, Chris Lilley <chris@w3.org> wrote:
>> 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.

sRGB, AdobeRGB or ProPhoto get you quite far along, but if we're working with straight out of camera images, such as DNG (which are supported in Safari) or other raw formats, then each camera has its own color profile. In that case, if you're trying to match a background color to a color found inside the image, referring directly to the image as to define the color space makes things much easier.

>>  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.

Something like this:

@colors "foobar" {
 profile: url("foobarRGB.icc"), url("someotherRGB"), sRGB;

and it's the author's job to have in the fallback list things that use compatible models? Falling back form foobarRGB to someotherRGB to ultimately sRGB is fine, but not all color spaces have an r g and b axis.

We can also provide a last resort CMYK space, but ICC profiles can be defined not only in rgb, cmy, cmyk, or monochrome, but also if I understand correctly any number (up to 16) of axes. How do we deal with fallback then?

> Also we don't need xyz (or lab) in that list; they don't need a
> profile, they are already fully defined.

Doesn't that mean that CIEXYZ and CIELAB should be built-in profiles, along with sRGB, so that you can do color("CIELAB" 50 96 -42) ?

>> 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?

Ooops, I forgot about the CSS4 color function, so I was using the name
for a different purpose. I meant the function which Tab called icc()
function which should have a syntax like this:

( <string> [ <number>+ | <string> ] [, <alpha-value> ]? )
Received on Tuesday, 16 February 2016 13:09:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC