W3C Logo

CSS3 Module: Color — Disposition of Comments

Tantek Çelik (Microsoft) <tantekc@microsoft.com>


This document details the responses made to issues in the CSS3 Module: Color Last Call specification. The comments were raised by the public (via www-style@w3.org) or other W3C Working Groups.


This document describes the disposition of comments in relation to the Last Call Working Draft of CSS3 Module: Color that were made during the Last Call period which ended 28 February 2003. Each issue is described by the name and contact information of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.

Comments regarding the Last Call are shown in the left column like this.

Items that are accepted are shown with a light green background like this. Such items typically imply that as a result of the comment, a change was made in the specification.

While items declined are shown with a light red background like this.

Items deferred to a subsequent version (such as feature requests) are shown with a light yellow background like this.

Finally, simply informative responses (answers to questions, elaborations, etc.) are styled with a light blue background like this.

Comments Received

[css3-colors] Comments on Last Call From: Christoph Päper (christoph.paeper@tu-clausthal.de), Date: Sun, Feb 16 2003 and Responses 1, 2, 3, 4
# Comment Answer

· <alphavalue>, rgba, hsla etc.

I don't understand, why alpha values are noted as a number between 0 and 1, while for colors percentages are used. They're pretty much the same, except percentages are 100 times the value and sufficed by '%'. HSL is the strangest: RGB allows you to decide, whether you use values between 0 and 255 or percentages. HSL OTOH requires a mixture of these. HSLA, as RGBA, even adds 0..1 for the alpha value--three different notations in one color definition.

Alpha values were introduced as values between 0 and 1 in the SVG 1.0 specification. CSS3 Color continues with that convention. Similarly, the rgb() color value format which takes percentages or integers 0..255 was introduced in CSS1 and CSS3 Color continues with that as well. HSL was chosen to be consistent with the proposal made by Steven Pemberton.


3.1. Foreground color: the 'color' property

The computed value for HTML4 keywords, RGB hex values and SVG color keywords is the equivalent six digit hex value. The computed value of the keyword 'transparent' is rgba(0,0,0,0).

Am I the only one to whom this looks a bit strange (always hex, but for 'transparent')? Not that there was an alternative, except introducing 4 and 8 digit hex values with transparency.

Actually, "equivalent six digit hex value" could be represented as an rgb() value internally as well. CSS3 Color does not require a particular internal representation. To clarify this, I have changed the wording in the text to say "equivalent triplet of numerical RGB values".


3.1.1. Gamma correction

I really don't see, why details for browser implementation across OSs have to be in the spec.

DW> Whilst strictly speaking they shouldn't be there, except as a
DW> non-normative appendix, this is an area that implementors are very
DW> likely to get wrong, even with it explicitly in the standard.

That is exactly why it has been in CSS ever since CSS1 (and still the implementors get it wrong).

DW> There is widespread ignorance about gamma, certainly amongst
DW> amateurs, marketing people, and programmers writing web pages (and
DW> browsers). It is possible that some professional designers are
DW> aware, but I suspect knowledge is rare there. Only really people
DW> who specialise in colourimetry really know about it; browser
DW> programmers are likely to have little technical knowledge in this
DW> area.

Yes, agreed. And because color is complicated in general, such programmers ignore it completely, even the brain-dead simple stuff like gamma correction.

DW> It is very common to find gamma 1.0 or gamma 1.45 images on
DW> commercial web sites, and most amateurs distribute images out of
DW> their camera, which often have gamma 1.0, and loss of significance
DW> on some channels (typically blue and green). On the other hand
DW> very few people seem to realise that there is anything wrong with
DW> their over-dark and poorly colour balanced images!

An image with gamma 1.0 is not over dark or poorly balanced provided it *says* it is a gamma 1.0 image.

DW> (One of the things that irritates me about image manipulation
DW> programs is their poor support of gamma; I'd like to be able to
DW> convert to gamma 1.0, adjust black and white levels, and then
DW> return to gamma 2.2, without unecessary loss of significance, but
DW> find I'm forced to to the steps individually - they really need to
DW> either accumulate a transform, or work with more colour depth than
DW> the images.)

Working with more color depth is the usual solution to this.

DW> I think every opportunity needs to be taken to stress gamma, if
DW> one is to hope for good quality images.

I agree.

DW> Incidentally, what is describe is the effect of both hardware and
DW> OS; Macs have gamma 1.45 because of their hardware, not their
DW> software.

Yes, agreed.


3.4. The 'rendering-intent' property

Hm, all the other baby-blue tables have more details than just the property name.

I have double checked the property description table for 'rendering-intent' and it seems to show the values, initial value, media etc. just like the other properties. Perhaps a problem with the W3C working draft style sheet and your browser?


4.1. HTML4 color keywords

The table should look like the one in 4.3.

The table was taken from HTML4.01: http://www.w3.org/TR/html401/types.html#h-6.5 and kept that way to make it clear that it was the same table.


4.2.4. HSL color values

By definition red=0=360, and the other colors are spread around the circle, so green=120, glue=240,

I've never heard of the ABC programming language before, as may others, and would prefer to see the algorithms expressed in English, although ABC is somehow close to that.

Since it sounds like ABC is acceptable to you, I prefer leaving it like that, since it is precisely defined as currently written, and I have received feedback from implementers that confirms that.

7 HSL Examples

I haven't checked why, but the color charts are all placed next to each other horizontally in my Opera 6.05.

That is a bug in Opera 6.05. According to CSS1 (and latter versions) floats don't fit horizontally next to other floats inside their containing block are supposed to be placed below (essentially, wrapped to the next "line") where they will fit. I believe this may be fixed in a newer versions.


4.3. SVG color keywords

Just wanted to express my objection against the /official/ inclusion of the mad X11 color names, again. I'd have rather seen CNS or the suggestion from http://lists.w3.org/Archives/Public/www-style/2002May/0201.html, which are more user friendly and memorable.

The /official/ inclusion of the X11 color names occurred quite some time ago in the SVG 1.0 specification which is a W3C Recommendation, and was reiterated in the SVG 1.1 specification which is also a W3C Recommendation.




4.3. SVG color keywords

Please adjust the case in the table header cells and use uppercase hexadecimal digits.

I have adjusted the case in the table header cells and hexadecimal digits as you suggested.


4.4. 'currentColor' color keyword

Nothing against it, but camelCase isn't something CSS used to use, is it? System colors use it, but with the starting letter being capital => 'CurrentColor'.

Values in CSS are case-insensitive, thus you may use any of the following:

  • currentColor
  • CurrentColor
  • currentcolor

The particular capitalization 'currentColor' is used in the spec simply because that is the same capitalization that is used for that value in the SVG specifications.


4.5. CSS System Colors

If I have

  body {background: AppWorkspace;}

and the browser has a wallpaper for the MDI background (e.g. Opera allows that), should/may this image be shown as page background or definitely just the color?

This is of course a bit out of scope of the Color Module.

The wallpaper should probably not be shown because that would be a system background-image, rather than a system background-color.

However, you have revealed the problem with the system colors, and that is that they are an extreme oversimplification of the problem of default system appearance. Even with "loosely" interpretation allowing a named "color" to represent a fill or a pattern, there are many aspects of the user interface which a simple color value is unable to represent.

Thus we are deprecating the system colors in preference to the upcoming CSS3 Basic UI appearance property.


5. Sample style sheet for HTML 4.0

Why "HTML 4.0" and not "XHTML 1", "XHTML 1.1", "XHTML 1.0", "HTML 4.01" or "HTML 4"? Well, for XHTML the first selector should presumably read "html, body".

More generally: Why is HTML4 used as normative source, e.g. for color names, instead of XHTML1?

In reverse order — you are right, HTML4 should be not used as a normative source, e.g. for color names, as this specification itself serves to define the color names and values.

XHTML1 cannot be used as a normative source for color names because it has no definition of color names. XHTML1 itself actually has very little defined meaning, and instead relies upon HTML4 for (nearly) all of its semantics.

I have updated the sample style sheet to note that it can be used for XHTML as well as you suggested.

Re: CSS3: Color From: "fantasai" <fantasai@escape.com>, Date: 17 February 2003 and Responses 1, 2, 3
# Comment Answer

None of the suggested changes to the color names made it in. How so?

Specifically, there seemed to be a consensus on www-style that X11 colors should be included *and* deprecated; this is not reflected in the draft. The first post here is representative.

Regarding the X11 colors:

From the Changes section:


Color names/values harmonized with SVG 1.0. There was substantial feedback on the previous draft that requested that CSS3 Color normatively list all the normative color names/values which are accepted by SVG 1.0. This document now contains the following additional named colors: darkgrey, darkslategrey, dimgrey, lightgray, lightslategrey, slategrey. Note that this change was also made in accordance with the TAG finding regarding Consistency of Formatting Property Names, Values, and Semantics.



The second one discusses the shortcomings of user preference color keywords, also noting objections to the system color keywords in the last Last Call Working Draft. Nothing in these sections changed, either. Why?

Regarding the message you quoted regarding user preference color keywords for hyperlink colors:


I still have the same opinion regarding user preferences for hyperlink colors, but that was my opinion, and one implementer has asked for these keywords, and there didn't seem to be much other negative feedback regarding the user preferences for hyperlink colors.

If folks think we should drop the user preferences for hyperlink colors, we could certainly do so, between last call and CR. However, my opinion alone is insufficient to do so. Additional feedback is needed.


Note: since this initial reply, there was follow up discussion where the following decisions have been made:

  • The Hyperlink colors have been removed.
  • The limited and insufficient CSS2 System Colors have been deprecated
Re: CSS3: Color From: Andrew Thompson <lordpixel@mac.com>, Date: 18 February 2003 and Response 1
# Comment Answer

Well, I was going to stay out of it this time, but since you asked... Neither current mainstream OS (Win XP or Mac OS X) is in any way adequately covered by the system colors. Both use textures, shadows, highlights etc in ways the System Colors don't capture. I don't know enough about Gnome or KDE to comment on these.

Absolutely. We even tried to extend the system colors to cover many more types of user interface elements and states etc. in a previous draft. However modern user interfaces use far more than just color (or fonts) for the appearance of OS widgets. Hence we decided to stick with the short list from before rather than extending it in a way which was still far from adequate.


Update: The system colors have been deprecated for exactly these reasons.


Well, on reading I'd assumed the utility of these keywords is to enable me to style some arbitrary element in some way such that it looks more like a hyperlink to the user - at least it uses the same colors. eg, I suppose I could have an <object> element that behaves similarly to a hyperlink when the embedded content is clicked on. I might want to style it with in the appropriate colors borders so it looks like a hyperlink to the user.

I took at look at your proposed alternate Tantek, and I'm not sure how I'd achieve something like that using your user stylesheet scheme. I'd assumed something like that was the use case for this feature.

You've missed the point(s).

The alternate that I provided is for implementers seeking to understand how to properly reflect user preferences for hyperlink colors via style rules prepended to the user style sheet.

You're speaking from the perspective of an author. Authors simply do what fantasai suggested:

That's it? This is what you're adding color names for? Why, that's easy to do even now. Just don't override the user's link colors.

And as far as borders go, border-color has the initial value of "the value of the color property" so there is again no need to set it to anything. Simply set the 'border-style' to something other than 'none' and the appropriately colored border should show up.

The "C" in CSS stands for Cascading. Using a system with a cascade means sometimes the answer is to *not* do something, to *not* interfere with the default/user-preferred style rules which are already cascading into place, rather than *doing* something, and then *doing* something else on top to fix it up. Sometimes less code works better than more. Often in fact.

Re: CSS3: Color From: Ian Hickson <ian@hixie.ch>, Date: 19 February 2003
# Comment Answer

I am still *for* dropping the CSS3 hyperlink colors.

It appears that fantasai is also for dropping them.

Does anyone else have an opinion either way?

I was one of the original proponents of the hyperlink keywords, but I retract my request for them, as you have since then convinced me that simply using user stylesheets is the better solution for prefs, and 'appearance' is the better solution for applications built with CSS.

Note, though, that some properties still depend on prefs for the actual values of their keywords, for example font-size:medium, and the initial value of the 'color' and 'font' properties.

Accepted. The hyperlink keywords have been dropped.
Regarding possible error: CSS3 module: Color (W3C Working Draft 14 February 2003) From: Russ Weakley <russ@maxdesign.com.au>, Date: 14 February 2003 and Response 1
# Comment Answer

I would like to point out what looks like an error in your document:


CSS3 module: Color

W3C Working Draft 14 February 2003

The relevant section reads:

The format of an RGBA value in the functional notation is 'rgba(' followed by a comma-separated list of three numerical values (either three integer values or three percentage values), followed by an <alphavalue>, followed by ')'. The integer value 255 corresponds to 100%, rgb(255,255,255,0.8) = rgb(100%,100%,100%,0.8). Whitespace characters are allowed around the numerical values.

It looks like the two "RGB" examples should be "RGBA". So the wording would be:

rgba(255,255,255,0.8) = rgba(100%,100%,100%,0.8)

yes, correct. thank you.

Re: CSS3: Color From: Etan Wexler <ewexler@stickdog.comgt;, Date: 21 February 2003
# Comment Answer
If folks think we should drop the user preferences for hyperlink colors, we could certainly do so, between last call and CR. However, my opinion alone is insufficient to do so. Additional feedback is needed.

Count me in agreement with Tantek. This is a "me too" message because Tantek stated the case so well originally.


RE: CSS3 module: Color From: Jonathan Stanley <jon@asciigrackle.eclipse.co.uk>, Date: 26 February 2003 and Responses 1, 2, 3


Had a good little read from a users point of view, and quite excited about some of the things it'll bring (though how soon browsers support it is a slightly different matter :( )

Anyway, I see within the RGB(A) model, the valid ranges are defined in section 4.2.2:

em { color: rgb(255,0,0) }      /* integer range 0 - 255 */
em { color: rgba(255,0,0,1)     /* the same, with explicit opacity of 1 */
em { color: rgb(100%,0%,0%) }   /* float range 0.0% - 100.0% */
em { color: rgba(100%,0%,0%,1) } /* the same, with explicit opacity of 1 */

If R, G and B can have values from 0.0% to 100.0% percent, then why is A, alpha, so limited within the bounds of 0.0 to 1.0, equivanlent to 0% to 100% in 10% steps. So perhaps a range from 0.00 to 1.00? Or alternatively, why aren't percentages used for that (alpha) value too?

The precision is not limited to 10% steps. It can be any value, for example 0.123456


As already indicated, there are uncountably infinite possible values, as it is a real number.

I think the reasons for the differences are historical. The values for R, G, and B were adapted from the deprecated HTML attributes for colour and these were invented by people commercialising HTML for an unsophisticated market, and used values that were probably in the API they used and reflect hardware engineering considerations. Alpha has come from a more sophisticated graphics tradition, which is not tied to DAC register sizes. You will also find that colours in PostScript are in the inteval [0, 1].

The % values are probably an attempt to regain normalised colours, allowing that the simple [0,1] range was taken.


Should opacity keywords be available? eg:

transparent: alpha = 0
very-transparent: alpha = 0.25
semi-transparent(/semi-opaque?): alpha = 0.5
very-opaque: alpha = 0.75
opaque: alpha = 1

The specification does include the keyword 'transparent' as was defined originally in CSS1 for the background-color property, and extended in CSS2 to the the <border-color> value type, and the 'color' property in OEB1.0.1. However, the specification does not add any more opacity/alpha keywords (for the moment). We may reconsider doing so in the future if there is sufficient demand for them (and some set of symbolic keywords which might serve as handy mnemonics for authors).


There also isn't bounds for values when using the HSL(A) colour model, other than definition of hue, that 0 = 360, no definition of how negative values are handled, eg:

* { color: hsl(-240, 100%, 50%) }

... or going round "more than once" in the colour wheel:

* { color: hsl(840, 100%, 50%) }

I agree that this aspect should be more clearly specified. It seems obvious that hue is a wraparound value but for consistency of implementation, it should be explicitly stated.


Then the "currentColor" property which is treated as "inherit" at parse time, would be better hypenated? That is: "current-color"

There is an issue with hyphens in names, to do with scripting. In response to a request from the DOm working group, SVG WG changed all the names that it had to camelCase, except for existing CSS names that we did not control.

Since the currentColor value comes from SVG, that is why it uses camelCase.

It has been in SVG since 1999 and is implemented in 15 or so different implementations.

CSS3 module: Color From: Susan Lesch <lesch@w3.org>, Date: 27 February 2003 and Response 1

These are minor editorial comments for your "CSS3 module: Color" Last Call Working Draft [1]. Overall it is beautiful.

The justified text is a little choppy. It sometimes slows down reading, see screen shot [3]. It makes the clipboard crazy in Mac IE 5.1.6. Can you get by without text-align: justify in [4]?

The profile tables could use a few pixels of padding. Also in the profile tables, some td's contain p's, some don't. The td's will look more similar if they all don't.

As Simon Jessey reported for CSS3 Text, the property column in the Property Index is cut off on the left. I am looking in IE 5.1.6, Mac OS 9.2.1.

I hope that when the CSS3 modules reach late maturity levels that they will all use US English capitalization. W3C uses en-US. W3C entities should match capitalization in the W3C Process Document [2]. Those corrections are included below except for headings.

Typos, some global:

s/CSS3 module: Color/CSS3 Module: Color/
s/Status of this document/Status of This Document/
s/working draft/Working Draft/
s/working group/Working Group/
s/style activity/Style Activity/
s/candidate recommendation/Candidate Recommendation/
s/Table of contents/Table of Contents/
s/UAs/user agent (UA)/ (spell out every time, or show both for the 
first occurrence)
s/user-agent/user agent/
s/by International Color Consortium/by the International Color Consortium/
s/Whitespace/White space/
s/must NOT/must <em>not</em>/
s/System Colors/system colors/ (or the other way around)
s/camel-case/CamelCase/ (some people prefer camelCase)

[1] http://www.w3.org/TR/2003/WD-css3-color-20030214/
[2] http://www.w3.org/Consortium/Process/
[3] http://www.w3.org/2003/02/26-CSS3-Color-MacIE.PNG
[4] http://www.w3.org/TR/2003/WD-css3-color-20030214/default.css

I believe we can get by without text-align:justify. I have passed your request to Bert, who is maintaining that style sheet.

I have removed the <p>'s from inside the profile tables and added 2px of padding to their table cells, but not all browsers seem to support the padding property on table cells.

I have made the editorial changes as you requested. Thanks for the finds.

Re: CSS3 module: Color From: Boris Zbarsky <bzbarsky@MIT.EDU>, Date: 27 February 2003

Chris Lilley wrote:

JS> * { color: hsl(840, 100%, 50%) }

I agree that this aspect should be more clearly specified. It seems obvious that hue is a wraparound value but for consistency of implementation, it should be explicitly stated.

Oh, yes indeed. Because it was not at all obvious to me, and my current implementation in fact does _not_ treat it as a wraparound value (I kept meaning to send mail asking for clarification about that, but never to around to it....).

Further, the matter of whether the hue is an integer or a float should also be clarified (eg for rgb() the non-percentage values are integers and it's easy to assume the same will hold for hsl(); not sure what the intent here is).

As noted above, the detail about the wrapround value has been specified.

You are right that whether the hue is an integer or a float should be made clear, and the spec defines it syntactically as a <number> which is according to CSS2 4.3.1:

A <number> can either be an <integer>, or it can be zero or more digits followed by a dot (.) followed by one or more digits. Both integers and real numbers may be preceded by a "-" or "+" to indicate the sign.
WD-css3-color-20030214 comments From: Etan Wexler <ewexler@stickdog.com>, Date: 28 February 2003 and Response 1

This message contains an edited copy of the CSS3 color specification found at <http://www.w3.org/TR/2003/WD-css3-color-20030214>. The edited copy is HTML, just like the original.

Changes are for the most part marked with 'del' and 'ins' elements. Substantive changes are in the class substance while the class ednit is used for minor editorial suggestions.

Commentary is marked with 'div' and 'span' elements. Substantive commentary is in the class comment while the class editorial is used for minor editorial suggestions.

Added markup for elements of types 'a' and 'abbr' is employed without the use of 'del' or 'ins' elements. These newly marked elements are in the ednit class.

Writing and using a style sheet to highlight changes is left as an exercise for the reader. (There wasn't enough time.)

I read through the your edited copy, trying to find your suggestions.

Most of the suggestions/changes I found I accepted and have made the respective edits to the draft.

There were too many small/incompatible markup edits for me to take them all. For example, for the moment I have ignored all the additional <abbr> markup.

For future reference, this is a very poor way to provide feedback on a W3C draft, as I'm sure it was non-trivial to write in this fashion (as edits to the document), and it is certainly non-trivial for the editors to attempt to find your suggestions and evaluate them, especially when many of them are duplicates of what was already reported, and have already been addressed by in progress editing.