W3C home > Mailing lists > Public > www-style@w3.org > June 2002

Re: X11 Colors (was Last call comments on CSS3 module: color)

From: fantasai <fantasai@escape.com>
Date: Tue, 04 Jun 2002 01:21:34 -0400
Message-ID: <3CFC4E5E.70DFC9D1@escape.com>
To: www-style@w3.org

Tantek Çelik wrote:
> Agreed.  We should not redefine "orange" for example.
> Here is a concrete proposal:
> Deprecate the X11 color names in CSS3 Color and SVG 1.1.*
> Keep the HTML4 color names.
> Keep the CSS2 system colors.**

Sounds like a good plan.

> Post your proposal on a website and send the URL to www-style NOW so that
> we can discuss it in the working group(s) and possibly include it in the
> next version of CSS3 color.

No color name proposals from me. :) I think CNS looks very appropriate,
although I would follow Johnny Axelsson's suggestion and "combine modifier
and adjective" [1] for lightness.

I have, however, a question for Chris...

 |  > 1.   It is really simpler to specify hue, saturation and lightness
 |  >      than to specify RGB values.
 | Yes. Especially if lightness really does correspond to how light
 | something appears - a desirable property, I'm sure you will agree. Try
 | calculating the HLS values of blue (RGB 0000FF) and yellow (RGB
 | FFFF00) and tell me - which *looks lighter*. HLS assigns them the same
 | lightness. This is clearly totally incorrect.

How does lightness work in CNS? Is CSS 'yellow' the same as 'medium vivid
yellow', or is it lighter than 'medium'? I would expect 'medium yellow' to
be a bright yellow, not some strange color with the apparent darkness
(contrast with white) of #0000FF.

I think conceptually, if you pick a lightness and then assign a hue, you
will get a different color than if you pick a hue, and then apply a
lightness relative to the original color...

One thing I noticed while playing with Windows' HSL color picker is that
the blue turns violet once you start making it lighter than #0000FF, and
a some other colors also distort.

Something I picked up while running a Google search:
(Google's HTML: http://www.google.com/search?q=%22METHOD+FOR+COLOR+NAMING%22)

In terms of color proposals in general, I think a number/expression-based
system of modifying colors would be a good way of addressing relativity.
Something like "colorName + rgb(40,40,60)" and "#FFFF00 - hsl(0,0,50)".
But I'm not asking for that this late in CSS3.

I agree that @-rule defined colors [2] would make stylesheets easier both
to write and maintain, whether the color names are included inline or
through a separate file. However, I disagree that @color XYZCorpBG #666666
is appropriate for CSS. A general templating facility would be preferable
in such cases, and this, I believe, is beyond the scope of CSS. (You can't,
for example, specify image backgrounds with a color name, even though they
should be defined together with the colors). On the other hand, the ability
to extend the list of available color names for a given file, as in defining
'paleblue' as #b0d8ff, can make a stylesheet easier to understand and does
not appear, to me, to have such inconsistency with the language. Thus it
seems that whether user-defined colors belong in CSS or not is a matter of
perspective. I am aware that the existence of one perspective may preclude
its inclusion.

> * Personally I want to keep "orange" if we can make exceptions.  Perhaps we
> let folks nominate specific X11 colors (maybe just one per person ;-) NOT to
> deprecate, and if there are no objections we keep those few colors?

I have no objection to keeping "orange", since I expect any new color naming
scheme to include it, and, as you pointed out above, 'we should not redefine


[1] Axelsson, Johnny. "Re: Last call comments on CSS3 module: color; musing
        and a transparent question", www-style (2002-05-23).
        message-id: <NE9D8TS517151TO3Z3XRMTOSQ53QPQ.3ced25f8@falcon>

[2] Andy. "Re: X11 Colors (was Last call comments on CSS3 module: color)",
        www-style (2002-05-30).
        message-id: <3CF5B775.F8D555E1@mac.com>
Received on Tuesday, 4 June 2002 01:18:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:02 UTC