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

[I split this out of the JS color classes thread, as it's actually a
comment on how the spec handles CMYK colors in general; the CMYKColor
class just follows the structure of the device-cmyk() function.]

On Wed, Aug 6, 2014 at 10:08 AM, Florian Rivoal <florian@rivoal.net> wrote:
> On Mon, Jul 14, 2014, at 01:00, Tab Atkins Jr. wrote:
>> Okay, the proposal is now specced:
>> <http://dev.w3.org/csswg/css-color/#apis>
>
> RGB, HSL and hex are different representation of the same color in the
> same color space, so having the conversion between each is cool, and
> does not require any assumption about color spaces. Everything is pretty
> much syntax level conversions.
>
> On the other hand, CMYK is a not a syntax conversion, but a different
> color space. Or to be more accurate, a different family of color spaces.
>
> I don't think it is appropriate to have implicit conversion between
> colors in an RGB color space and a CMYK color space without specifying
> which.
>
> As currently specified, CMYKColor(RGBColor rgb) applies the so called
> naïve coversion defined in http://dev.w3.org/csswg/css-color/#cmyk-rgb
> for when the user agent is not aware of the output device’s color
> profiles.
>
> This falls short of giving authors the ability to actually use the
> objects to do proper color math, including good RGB<->CMYK conversions,
> and risks deceiving poorly informed people into thinking that toCMYK
> performs a conversion that is as neutral as toHSL.
>
> I think there are 2 possible approaches here:
>
> 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.

The spec currently allows browsers to use whatever knowledge they
might have about the device's color space to aid it in converting
between sRGB and the device-cmyk space; if they have no knowledge, it
provides a naive algorithm which gets sorta close.  In the future we
definitely need to add some capability to provide color profile
information so these conversions can be done accurately.

> b) We want to enable color conversions, and possibly other type of color
> math. In this case, we should:
> - Include a colorSpace attribute on color objects
> - Have constructors take an optional argument specifying which color
> space you want, defaulting to sRGB on RGB objects when omited, and to
> naïve CMYK on CMYK objects when omited

naive CMYK is just sRGB.

> - toRGB() on CMYKColor and toCMYK() on RGBColor should take the same
> optional parameter, with the same defaults
> - a convertColorSpace function should be added on CMYKColor and
> RGBColor, so that you can do RGB to RGB or CMYK to CMYK color space
> conversions
> - come up with some definition of a ColorSpace class (or RGBColorSpace
> and CMYKColorSpace classes), to use in the constructors and methods
> above

I agree that we need to do something like this, and think that your
suggested approach is approximately what we'll do.  I'd like to wait
until we have some idea of how CSS is going to handle this in general,
though.

~TJ

Received on Thursday, 7 August 2014 23:32:03 UTC