W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: [css3-color] XSL FO SG comments on "CSS Color Module Level 3" WD

From: Chris Lilley <chris@w3.org>
Date: Wed, 29 Sep 2010 20:02:50 +0200
Message-ID: <83816141.20100929200250@w3.org>
To: www-style@w3.org
CC: Tony Graham <Tony.Graham@MenteithConsulting.com>, Liam Quin <liam@w3.org>
Hello www-style,

The XSL FO Subgroup reviewed the CSS Color Module Level 3 WD
(http://www.w3.org/TR/2008/WD-css3-color-20080721) some time ago, and sent editorial comments.

I just realized that, while edits have been made to the spec in response, there was no email followup to the comments. Here then is a list of those comments which have been accepted, which were rejected and why.

If the XSL-FO subgroup could respond (to www-style) indicating which of these responses are acceptable, which are not, and any formal objections, that would be very helpful. Sorry for the delay in responding to the comments.

The current editors draft of CSS3-color is at

These comments are being tracked as issue 17

>  - The capitalisation of the titles of sections, 4.5, 
> 4.5.1, 8, and 9 is inconsistent with the majority of the titles.

We agree.
Thanks, fixed

>  - "color related properties" should be "color-related properties".

We agree.
Thanks, fixed

>  - In the 'interoperable' definition, "must one or more" should 
> be "must be one or more".

We agree, although that text no longer appears in the specification.

> - The links to other CSS3 modules don't work when the spec 
> is printed.

We agree, although we no longer have dependencies on other CSS3 modules.

>  - The two uses of "color:inherit" (the other is in section 4.4) 
>  are the only declarations that do not have a space after 
> 'color:'.  While allowed by CSS syntax, this is inconsistent 
> with the other examples.

We agree.
Thanks, fixed

> - There is no Example I or Example II.

We know, but chose to retain the numbering since this is a stable specification and we did not want to break references to particular examples. Therefore we have chosen not to renumber the examples.

>  - How to set gamma correction on different operating systems 
> should be in a note or in an informative appendix.

- How to populate a lookup table should be in a note.

We agree, other commentors also pointed out problems with this section and it (old section 3.3.1) has been removed from the specification.

> - "thought of conceptually" is a tautology.

We agree, it now simply says "thought of"

> Should the document be consistent and use either only uppercase 
> or only lowercase for A-F (or a-f) in numerical color
> specifications?

Since both are syntactically legal in CSS, we chose to leave the examples as they were.

>  - Using 'new' in "specify new effects that are now possible 
> with the new rgba() notation" will be incorrect when CSS3 is 
> no longer new.   (Also in section

We agree, and the mention of 'new' is removed.

> There should be a reference to where to find the 'CSS 
> forward  compatibility parsing rules'.

We agree, a reference to ([CSS21], Chapter 4) has been added.

> There should be a comma after "rgba(0,0,0,0)".

We agree, the comma has been added.

> What is the "something similar" in "internalizing how to 
> translate hue, saturation and lightness, or something similar"?

It is a reference to the various ways in which colour appearance has been parameterized by various authors - hue or chroma, lightness or 'value', saturation or colourfulness, and so on. We did not want to give the impression that hue, saturation and lightness were the only parameters by which colour appearance has been characterized. Thus "or similar' is a nod to other systems, while mentioning explicitly only those terms which are in fact standardized in this specification.

We have chosen therefore to retain the wording.

> "[0,360)" indicates a range exclusive of 360.  The notation is 
> not commonplace and should be explained.  Also, the notations 
> for this range and for the "0..1" range used later in the 
> section (and the "0..255" ranges in section 4.2.1) are 
> not consistent.

We agree, and have clarified the wording inline to explain the [) notation.

> - There is a parenthesis missing in "((x mod 360) + 360) mod 360)".

We agree, fixed

> - How to populate a lookup table should be in a note.

The algorithm given is not how to populate a lookup table. It is how to convert from HSL to RGB, in general. That algorithm happens to have been used to construct the tabular examples below, which demonstrates that it works, but 'filling a lookup table' is not its intent.

> - It is not clear why an inverted exclamation mark is being 
> used to represent degrees.  (It was also not clear that they 
> were inverted exclamation marks until I looked at the page 
> source.)

We agree, this was an encoding issue and has now been fixed. A Unicode degree sign is used instead.

>  - "‘flood-color’, ‘lighting-color’" should be "‘flood-color’, 
> and ‘lighting-color’" (or "‘flood-color’ and 
> ‘lighting-color’", depending on how you feel about commas).

We agree, fixed

>  - The only content is in section 4.5.1.  This title should 
> be removed, and section 4.5.1 should become section 4.5.

While sympathetic to this position, we did not want to change section numbering (and thus break cross references from other specifications) unnecessarily, and so have decided to retain the current numbering.

> - "pre-defined" should be "predefined".

We agree, although due to another comment the word predefined no longer appears in the current specification.

(There was one more comment about system colors, which is being tracked as a separate issue as it was non-editorial and did result in a change. That comment will be the subject of a separate email).

Thanks once again for your useful editorial review of the specification, sorry it took so long to close the loop on these comments.

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Wednesday, 29 September 2010 18:03:43 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:51 UTC