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

On Wed, Aug 13, 2014 at 10:02 AM, Florian Rivoal <florian@rivoal.net> wrote:
> 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.

Once again, the CMYKColor class is merely echoing the behavior of the
device-cmyk() function.  I'm not comfortable with making a change to
one without changing the other.

If you have a suggestion as to how to make device-cmyk() work better,
we can discuss that, and after it's adopted I'll have CMYKColor mirror
it.

~TJ

Received on Wednesday, 13 August 2014 19:49:43 UTC