Re: [css-color] Doubts on how we handle device-cmyk() and similar things

On Wed, Oct 8, 2014 at 7:42 AM, Florian Rivoal <> wrote:
> On Wed, 08 Oct 2014 00:06:13 +0200, Tab Atkins Jr. <>
> wrote:
>> We don't normally do that sort of forward design, and I don't think
>> it's necessary to protect ourselves against code trying to set a
>> non-existent .profile attribute today.
> If there was new and independent functionality hanging off .profile, I'd be
> perfectly fine with that. But what happens there changes the meaning of the
> fields we're already exposing (.r .g .b), and that makes me a bit more
> nervous. Maybe I shouldn't be.

I don't think you should be. ^_^

> Another thing is that I wonder if introducing the concept of color profile
> right now wouldn't inform the class hierarchy differently. Some of the
> information would be redundant between the profile and the class (what type
> of color space you're in: rgb vs xyz vs cmyk), and maybe that suggests we
> should consider how to get rid of differentiated classes.

The class hierarchy has nothing to do with color space; it's based
entirely on the values you use to *specify* a color.  This is
intentional, because color spaces are confusing and most people don't
know about them, nor should they have to.

So adding profiles shouldn't have any effect on the class hierarchy.


Received on Wednesday, 8 October 2014 17:39:16 UTC