W3C home > Mailing lists > Public > www-style@w3.org > July 2009

Re: [CSS3 Colors] HSL colors, hue and allowed values, [CSS3 gcpm] CMYK colors and allowed values.

From: Bert Bos <bert@w3.org>
Date: Wed, 29 Jul 2009 16:55:24 +0200
To: www-style@w3.org
Message-Id: <200907291655.25144.bert@w3.org>
On Wednesday 29 July 2009, Ludger Buenger wrote:
> According to the working draft
> (http://www.w3.org/TR/2008/WD-css3-color-20080721/#hsl-color), HSL
> colors accept three parameters.
> The first HSL color parameter represents the hue and accepts numeric
> values representing an angle and should be interpreted as degrees
> modulo 360.
> Since CSS knows unit types representing angles (deg, rad and grad),
> I'd like to suggest that if an explicit unit type is set, this one
> should be used, if no unit type is given it should be interpreted as
> degrees.
> Current working draft only permits numeric values.
> Question: does it make sense to also accept percentage values with
> 100% equaling 360 degrees?

It is possible, in the sense that it could be defined without ambiguity, 
but is it needed? There are already quite a few ways to write colors. 
That is OK as long as they have clearly separate syntax and separate 
models (#, rgb, rgba, hsl, and hsla), but subtle variations in the 
syntax are confusing, I find.

E.g., rgb() allows both percentages and numbers 0..255 and in hindsight 
I think that was a mistake. There is no problem for the parser, but for 
a human author it is too much to remember. Especially now that the 
fourth parameter of rgba() is neither a percentage nor a number 0..255, 
but a number 0..1.

Apart from the programmer's point of view ("Nice, I can use a recursive 
function!") is there a case to be made for users? Because it is 
certainly important to make the job of the programmer easier, nobody 
likes bugs, but it should not make the user's job harder.

> The second and third parameter of an HSL color represent saturation
> and lightness and are defined to be percentages.
> Here we also have questions:
> Does it make sense to accept numeric values if the percent symbol has
> been omitted and how should they be interpreted?

The fact that it is not clear how to interpret them is a good argument 
for not allowing such numbers. I'm not saying that 
writing 'hsl(75,1,1)' thinking that it meant 'hsl(75,100%,100%)' when 
it actually means 'hsl(75,0.39%,0.39%)' will crash the space shuttle, 
but it's no doubt equally frustrating.

> Since the RGB color definition permits both percentage and numeric
> values, but numeric values are interpreted as a range from 0 to 255
> with 255 representing 100%, to me it makes sense to handle this
> similar in HSL colors.
> But I am not a colors expert, so maybe this is a bad idea.
> Regarding CMYK colors (from the current working draft of CSS3 gcpm
> http://www.w3.org/TR/2007/WD-css3-gcpm-20070504/#cmyk-colors):
> According to the example given in the gcpm working draft, the cmyk
> color function accepts 4 values being numeric float values in the
> range 0.0 to 1.0 representing the amount of color to be applied.
> Is there a rationale behind this allowed values definition differing
> from the definition of the allowed values in the rgb color function?
> >From my point of view, I would expect the allowed values of the cmyk
> > color function to be analogous to the rgb function:
> a percentage value or a value between 0 and 255 with 255 representing
> 100% - for the sole reason of being defined the same way as rgb
> colors are defined.

Note that it isn't certain at all that cmyk() will make it into the CSS  
standard. rgb() is well-defined by reference to the international sRGB 
standard, and hsl is defined by reference to rgb(), but we haven't 
found any usable definition yet of what cmyk() might mean. We might 
stick with rgb/hsl and leave it to individual device drivers to 
translate device-independent colors to device-specific CMYK values. Or 
we might go the other way and define explicit color profiles in CSS. 
(But given that we tried that before[1] and abandoned it, I'd say the 
odds are against.)

[1] http://www.w3.org/TR/2003/CR-css3-color-20030514/#atcolorprofile

Apart from that, I don't know what kind of numbers people typically 
expect for CMYK. The scales are clearly linear (unlike the circular 
scale of hue) and have two endpoints: minimum amount of dye and maximum 
amount of dye. What do other programs use to express that scale? What 
are people used to?

Postscript uses values between 0 and 1. But I know that is hardly a 
convincing argument, because nobody ever looks inside a Postscript 
file. The Gimp uses 0-100 (integer values only). Adobe Illustrator uses 
percentages (but allows decimals, such as "70.5%").

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Wednesday, 29 July 2009 14:56:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:37 UTC