· <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.

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.

3.1.1. Gamma correction

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

3.4. The 'rendering-intent' property

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

4.1. HTML4 color keywords

The table should look like the one in 4.3.

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,

:-D

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.

4.2.4.1. HSL Examples

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

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.

4.3. SVG color keywords

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

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'.

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.

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?

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.

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?

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.

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.

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.

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

http://www.w3.org/TR/2003/WD-css3-color-20030214/

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)

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.

Hi

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?

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

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%) }

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

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/glue=240/blue=240/
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

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).

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.)