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

Re: [css-color] wider/deeper colors

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 17 Feb 2016 12:34:30 +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: <61A27522-E6EA-4574-8945-918FA31F654F@rivoal.net>
To: Chris Lilley <chris@w3.org>

> On Feb 17, 2016, at 00:16, Chris Lilley <chris@w3.org> wrote:
> 
> Hello Florian,
> 
> Tuesday, February 16, 2016, 2:09:22 PM, you wrote:
> 
>>> On Feb 16, 2016, at 18:34, Chris Lilley <chris@w3.org> wrote:
>>>> (Florian wrote:
>>>> 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;
>> }
> 
> Yes (although a wider one than sRGB would likely be used in this
> case). Clearly, the color will not be correct, but it will be closer
> than just showing transparent black or black or something. In that, it
> is fairly similar to font fallbacks.
> 
>> 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.
> 
> Correct.
> 
>> We can also provide a last resort CMYK space,
> 
> And I think we should. Perhaps coated SWOP?

US centric, but sounds like a reasonable choice to me.

>> 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?
> 
> Yes, they can. 

What do we do then? If we don't know if a color triplet is rgb or cmy or something else,
providing a default fallback (which would probably be sRGB) makes little sense.

The simple version is to not have a default fallback, and if you don't specify one yourself, 
we go with currentColor / current background.

Can we do better? This is why I was suggesting we could have a descriptor giving
the color model, so that even if we don't have a fallback profile, we at least
have some sense about what the axes represent. But then again, that would only provide
a finite list, and if we go that way, there's no reason we can't profile a list
of fallback spaces, rather than just coordinates systems, and it still doesn't help
if we run into exotic axis models.


 - Florian
Received on Wednesday, 17 February 2016 03:37:42 UTC

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