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

On Fri, 08 Aug 2014 01:31:16 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:
>> a) We keep the scope of this to pure syntax level convenience, and then
>> no conversion between RGB and CMYK should be provided. This gives
>> authors basic building blocks to build any color logic they want,
>> without any assumption about what they are going to do with it.
>
> This is not acceptable for device-cmyk(); it would imply that you have
> to specify *every* color in the page, including those normally set by
> the UA, with device-cmyk() if you want to use it for *any* color.  If
> you can mix device-cmyk() and rgb(), you should be able to convert
> between CMYKColor and RGBColor.

My problem is that as long as you're converting between RGB and HSL, you  
need no assumption about the color space. You might be in sRGB (quite  
likely), you might be in adobe RGB, it doesn't matter, the objects as you  
proposed them are neutral to that (and I think that's good).

But as soon as you convert from RGB to CMYK, this is no longer true. You  
can't do the conversion without knowing what you're converting from and to.

I don't object to having pair of standalone utility functions, one that  
takes an RGBColor, assumes it is in  sRGB, and converts it to "naive"  
(sRGB) CMYK, and one that does the opposite. But I do not want these  
functions to be methods of the RGBColor and CMYKColor classes.

With a function, the RGBColor object is only assumed to be in sRGB if you  
use it in a context that demands that it is, such as the sRGBtoNaiveCMYK  
function (and pretty much very other browser supplied API). With a member  
method, RGBColor would always implicitly be sRGB. A user intending to use  
the class (maybe extending it, maybe not) to store adobe RGB would  
probably not be to fond of having methods that assume something else.

  - Florian

Received on Wednesday, 13 August 2014 17:02:47 UTC