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: Ludger Buenger <ludger.buenger@realobjects.com>
Date: Wed, 29 Jul 2009 20:10:23 +0200
Message-ID: <96458C389BF1724995FFD7FAD8892637350F26@ex.nc-sb.de>
To: "Brad Kemper" <brad.kemper@gmail.com>
Cc: <www-style@w3.org>
Ok, quite some answers so far.

I just pick some to answer because partially they overlap.



Chris Murphy wrote:
> I'd like to read of some examples of these "some applications of CSS".  

To generate PDF/A compliant PDFs from HTML cmyk is required in conjunction with ICC profiles. PDFreactor rendering engine is such an application that does that.



Tab Atkins wrote:
> Well, I know that the reason for hsl() and cmyk() being the way they are is
> because that's how most software dealing with those color spaces represents
> them.

For cmyk I found percentages to be the common unit type used and not floating point numbers between 0 and 1.
 
That's why I would have expected percentages in the first place but nothing was said in the gcpm module and therefore has been the reason why I started questioning the currently allowed value types in the first place.



Brad Kemper wrote:

> I don't really have any problem with an optional unit type being used for
> degrees in HSL, except that I don't think many people would actually type
> it, and it seems unnecessary since degrees is the only type that can be used
> there.

I agree with those stating that other unit types than degrees will be inconvenient and therefore very unlikely to be used.

I just observed this for completeness.
CSS in general supports rad and grad which are hardly used anywhere so they could be dropped with the same argument in other places to.
As well as other rarely used unit types: the pica unit comes to my mind which certainly has is justified but honestly rarely used.



Bert Bos wrote:

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

I fully agree with you that the most important thing is to make the user's job easy.

And here I see the problem: we very often have to express a value range from "no color/no alpha/no arbitrary other value" to "full color/full alpha/full arbitrary other value" for different color types.

How do we make the job for the user easiest?

I see the following conflict:
1) On the one hand I doubt that it eases things for a CSS user/author if every color type has a different way to express the value ranging from no to full color/alpha/etc to be used. A common convention for expressing a value from a range "no color" to "full color" in CSS certainly eases cross media stylesheet development for screen and print devices.

This is the rationale behind suggesting to use 0..255 for numeric values or 0%..100% if one needs fractions.
I consider the alpha value in the rgba notation ranging from 0 to 1 to be certainly confusing.

2) On the other hand I fully agree that if there are specific established notations for colors outside of CSS (e.g. the degrees for the HSL hue) we should follow these established conventions.

Summarized if established conventions outside of CSS require a certain notation we should follow this one but on the other hand allow users to re-use CSS knowledge when experimenting with colors by using a unified notation for as many color value ranges as possible.

> Apart from that, I don't know what kind of numbers people typically expect
> for CMYK.

I'd expect percentages, since that is what our print customers tend to use to define cmyk colors.
How numerical numbers map to a percentage value I'd consider secondary.


Best regards,

Ludger


 
--
Dipl.-Inf. Ludger Bünger
Senior Software Engineer
Product Development
- - - - - - - - - - - - - - - -
RealObjects GmbH
Altenkesseler Str. 17/B6
66115 Saarbrücken, Germany
Tel +49 (0)681 98579 0
Fax +49 (0)681 98579 29
http://www.realobjects.com
ludger.buenger@realobjects.com
- - - - - - - - - - - - - - - -
Commercial Register: Amtsgericht Saarbrücken, HRB 12016
Managing Directors: Michael Jung, Markus Neurohr
VAT-ID: DE210373115
Received on Wednesday, 29 July 2009 18:12:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT