- From: fantasai <fantasai@escape.com>
- Date: Tue, 04 Jun 2002 01:21:34 -0400
- 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...
http://lists.w3.org/Archives/Public/www-style/1996Apr/0029.html
| > 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:
http://www.research.ibm.com/people/a/aleksand/pdf/icip2002-1.pdf
(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
"orange"'.
~fantasai
[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>
http://lists.w3.org/Archives/Public/www-style/2002May/0143.html
[2] Andy. "Re: X11 Colors (was Last call comments on CSS3 module: color)",
www-style (2002-05-30).
message-id: <3CF5B775.F8D555E1@mac.com>
http://lists.w3.org/Archives/Public/www-style/2002May/0204.html
Received on Tuesday, 4 June 2002 01:18:53 UTC