Re: CNS colors

On Mon, 22 Apr 1996 19:42:48 +0200, you wrote:

>
> >  This mapping has three advantages:
> >  
> >  1.	It is really simpler to specify hue, saturation and lightness
> >  	than to specify RGB values.
> >  2.	It is simple to implement.
> >  3.	Nearly everybody has a utility to look at and fiddle with 
> >  	colors so specified, namely the MS-Windows color selector 
> >  	dialog. Still one could use this or some other tool for
> >  	color selection and then put the resulting RGB values into
> >  	the HTML file.
> 
>
>While it's true that many people have access to Windows, there are
>still a large number of people, especially on the internet, who
>don't use Windows.  Inflicting something as odd as the MS color
>scheme on people who aren't already MS victims seems cruel...  ;)
>
>
> >  It has one big disadvantage: it is wrong (i.e. it disagrees with
> >  nearly everything that we know about the physics of color and vision).
> >  It is simple, sloppy and undocumented (translate: made by Microsoft).
> >  On the other hand, specifying raw RGB values isn't any better.
> 
>
>This seems like an awfully big disadvantage.  Since the goal of using
>color codes in most cases is the specification of colors on RGB monitors,
>keeping the mechanism for specifying the codes as close to RGB as 
>possible seems the best and simplest approach to me.  

As I mentioned above, RGB values are no precise color specifications,
either.

>Just to throw
>out another common method for choosing colors, let's consider the
>Mac color chooser.  The user is presented with a color spectrum arranged
>in a circular pattern, with a slider bar beside it to specify the 
>lightness/darkness of the particular color chosen.  This system is
>simple, intuitive, and generates RGB codes without forcing the user
>to delve into the wonders of hexadecimal...

I do not know the details of the Mac color selector, but as you
describe it, it seems equivalent to the MS-Windows selector (only here
you have a square instead of a circle and a white/gray line at the
bottom instead of a white/gray point in the center).

And as you say, it may not be correct, but it is simple and intuitive.
So, if a color specification based on HLS/color names is implemented
in CSS, there should be a (agreed) method of converting it to RGB. And
this method should be simple.

Either this or restrict color specification to RGB values. Or let's
specify a table of RGB values for a selected set of colors. Otherwise
it is not clear to me, what RGB values of "dark red" should be.

>
>It would be better, IMO to use some kind of simple front-end control
>(preferably the standard one that's used on the user's platform) to
>choose a color from some kind of color wheel, and feed the resulting
>RGB values into the style sheet definition.
>
>While we're talking about RGB codes, I'd like to see more people start
>using decimal RGB values, rather than hexadecimal.  While it's not too
>difficult to convert between the two, it's still annoying and reeks
>of technogeeks inflicting their arcane secrets on the rest of us...  :)

Well, floating point values for RGB are in the spec. But you may think
that floating point values for RGB are for technogeeks, too. So drop
floating point and allow integer in the range 0..255 instead? No
objections from my side.

Regards

Wolfgang Rieger

Buero fuer Software-Entwicklung           Email: rieger@bse.de
                                          WWW  : http://www.bse.de/
Rosenheimer Str. 214                      Phone: +49 89 497738	
81669 Munich, Germany                     Fax  : +49 89 497738

Received on Wednesday, 24 April 1996 19:50:19 UTC