- 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