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

Re: [css-color] Exposing browser color parsing to JS

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 06 Aug 2014 19:08:30 +0200
Message-Id: <1407344910.809904.149844017.37592AB1@webmail.messagingengine.com>
To: www-style@w3.org
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.

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
- 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

While I think (b) is nicer, I suspect it is taking us too far into
topics that we are not actually interested in dealing with right now, so
I suggest going with (a).

-- 
- Florian
Received on Wednesday, 6 August 2014 17:09:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 6 August 2014 17:09:05 UTC