CSS 2.1 draft comments and editorial problems

Some comments on the CSS 2.1 draft rooted at
http://www.w3.org/TR/2006/WD-CSS21-20060411/


* Section 15.7 guides UAs to use font sizes "small" (2) and "xx-small"
   (1) for heading levels h5 and h6.

   That seems much too small.  Why should any headings be _smaller_
   than regular text (text that defaults to "font-size: medium")?

   Note how making the heading smaller than "medium" causes the same
   problem described "The Wrong Size Fonts" at
   http://www.xs4all.nl/~sbpoley/webmatters/fontsize.html

   Note that that guideline seems to assume that UAs need to use only
   font sizing to differentiate heading levels.  Can't they also use
   font weight, underlining, small capitals, etc.?




* Section 9.9.1 says:

     Boxes with greater stack levels are always formatted in front of
     boxes with lower stack levels. ... Boxes with the same stack level
     in a stacking context are stacked bottom-to-top according to document
     tree order.

   The second quoted sentence should say "back-to-front" instead of
   "bottom-to-top," to avoid confusion with the vertical dimension, and
   to be consistent with the first quoted sentence's use of "in front of."

   (Additionally, should "stack level" be "stacking level" instead?  The
   wording "X's stack level" sound more like the height (the level) of X's
   stack rather than X's level within a stack.  "X's stacking level"
   sounds a lot more like X's level (position) with the stacking of
   things.)


* Section 5.8.3 says:

     To match a subset of "class" values, each value must be preceded by
     a ".", in any order.

   As written, that wording makes no sense--"in any order" contradicts
   "preceded."

   The real problem is apparently that "in any order" was meant to apply
   to something that didn't make it into the text.


* Section 5.11.4 says:

     It is recommended, that documents and protocols indicate language
     using ...

   That comma should not be there.


* Section 6.4.3 says:

     ... if the selector is a 'style' attribute rather than a selector ...

   The wording needs to be adjusted.  (How can the selector be something
   other than a selector?)  Maybe the first "selector" should be something
   roughly like "virtual selector" or "effective selector" and/or the
   second "selector" should be something roughly like "actual selector."


* Section 10.8.1 says:

     This applies to empty boxes as well, as if the empty box contained
     an infinitesimally narrow letter."

   Is that a double negative (meaning the opposite of what is intended)?

   "Infinitesimally wide" would mean wide "in an infinitesimal degree"
   (per http://www.onelook.com/?other=web1913&w=Infinitesimally), meaning
   very narrow.  Since narrowness is an inverse of width, inverting the
   above phrase to "infinitesimally narrow" would invert its meaning to
   "very wide."

   Coming from another direction, given that "infinitely narrow" means
   very narrow, inverting that to "infinitesimally narrow" would also
   invert to "very wide."

   Therefore, the quoted text should probably say "infinitesimally wide"
   or "infinitely narrow" (or simply "zero-width"?).


* Section 12.4 says:

     The following example will increment the 'chapter' counter with 3 ...

   That "increment ... with 3 ..." should be "increment ... by 3..."


* Section 12.5 says:

     They do not allow authors to specify distinct style (colors,
     fonts, alignment, etc.) for the list marker or adjust its position
     with respect to the principal box, these may be derived from the
     principal box.

   The last comma should be a semicolon.


* Section 16.6.1 says:

     Any text that is directly contained inside a block (not inside an
     inline) should be ...

   An inline what?  ("Inline" isn't a noun.)

   That should probably read:

     Any text that is directly contained inside a block element (not inside
     an inline element) should be ...

   It also says:

     For each inline (including anonymous inlines), the following ...

   which should be

     For each inline element (including anonymous inline elements), the
     following ...


* Section C.2.6 says:

     ... and then 'right' (or 'left') is solved.

   That should be:

     ... and then 'right' (or 'left') is solved for.

   (or some other construction).



Thanks,
Daniel Barclay

Received on Wednesday, 26 April 2006 17:16:01 UTC