W3C home > Mailing lists > Public > www-style@w3.org > August 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 13 Aug 2014 12:48:52 -0700
Message-ID: <CAAWBYDCLBRO6WU5rxSgo5F=_sSZ5ZsmpYtqY-WRL+sQGoGnUig@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC