[CSS21] Miscellaneous editorial issues - comments on Working Draft

Issue 1: 9.2.1 (Block-level elements and block boxes) currently says:

   # [...]. Some block-level elements may generate additional boxes in
   # addition to the principal box: 'list-item' elements. These
   # additional boxes are placed with respect to the principal box.

I've never liked this part.  Tables also generate an additional box. 
What's more, all block-level elements are capable of generating 
anonymous boxes, depending on their contents.


Issue 2: 9.2.1 goes on to say:

   # Except for table boxes, which are described in a later chapter, and
   # replaced elements, a block-level box is also a block container box.
   # [...] Not all block container boxes are block-level elements: [...]

s/block-level elements/block-level boxes/
since the sentence doesn't currently make sense.


Issue 3: 9.2.1.1 (Anonymous block boxes) says:

   # The properties of anonymous boxes are inherited from the enclosing
   # non-anonymous box (e.g., in the example just below the subsection
   # heading "Anonymous block boxes", the one for DIV). Non-inherited
   # properties have their initial value. For example, the font of the
   # anonymous box is inherited from the DIV, but the margins will be 0.

"(e.g., in the example just below the subsection heading "Anonymous 
block boxes", the one for DIV)"?  Seriously?  Let's give that example a 
name!


Issue 4: 9.2.4 (The 'display' property) says:

   # The computed value is the same as the specified value, except for
   # positioned and floating elements (see _Relationships between
   # 'display', 'position', and 'float'_) and for the root element. For
   # the root element, the computed value is changed as described in the
   # section on the _relationships between 'display', 'position', and
   # 'float'_.

Both links are to the same place.  Wouldn't it be better to simply add 
the root element to the first sentence and drop the second sentence 
altogether?


Issue 5: 9.3.1 (Choosing a positioning scheme: 'position' property) says:

   # User agents may treat position as 'static' on the root element.

What does this actually mean?  That the used value is 'static'?

Also, this information could ideally be repeated in 9.7 (Relationships 
between 'display', 'position', and 'float').


Issue 6: 9.4.1 (Block formatting contexts) says:

   # Vertical margins between adjacent block-level boxes in a block
   # formatting context _collapse_.

where _collapse_ links to 8.3.1.  It's not true though when those boxes 
themselves establish block formatting contexts.  (Think table wrappers, 
even if you feel there's a strong argument for saying that floats and 
absolutely positioned elements don't participate in a BFC.)

I suggest:
s/collapse/typically collapse/


Issue 7: Along the same lines, 9.4.1 goes on to say:

   # In a block formatting context, each box's left outer edge touches
   # the left edge of the containing block (for right-to-left
   # formatting, right edges touch).

s/box's/in-flow box's/


Issue 8: 9.5.1 (Positioning the float: the 'float' property) says:

   #   Applies to:   all, but see 9.7

   # This property specifies whether a box should float to the left,
   # right, or not at all. It may be set for any element, but only
   # applies to elements that generate boxes that are not absolutely
   # positioned.

However, 9.5.2 (Controlling flow next to floats: the 'clear' property)

   #   Applies to:   block-level elements

s/block-level elements/block-level elements other than absolutely 
positioned elements/

and follow the property definition with an analogous sentence for that 
for floats:

   | It may be set for any element, but only applies to block-level
   | elements that generate boxes that are not absolutely positioned.

(Note that in both cases, the "It may be set for any element" is 
superfluous and should be removed, since this is axiomatic to CSS21.)


Issue 9: In 9.5.2 (Controlling flow next to floats: the 'clear' 
property), a new Example 1 has been added – lifted word-for-word from 
[1].  This is a welcome addition, but it needs some proofreading:

   # (B1 has no children and no padding or border)

But it does have positive height, right?  Let's state this.

   # [...]: block B2 with a top margin of M2 (no padding or border, no
   # children). B2 has 'clear' set to 'both'. We also assume B2 is not
   # empty.

Really? Non-empty yet with no children?  It could be replaced, I 
suppose, but it's better to say that it has positive height.

   # [...], we are in the situation described in the spec where we need
   # to add clearance

This needs cleaning up with a proper cross-reference!

We also need to refer to the hypothetical position at some point in this 
example.

In general, the style of this example is far too informal.


Issue 10: 10.3.7, 10.3.8, 10.6.4, 10.6.5 all say:

   # [ignore the value for 'bottom/top/left/right'] and solve for that
   # value.

(Appears once per section).

s/solve for that value/solve for that property/


[1] http://lists.w3.org/Archives/Public/www-style/2009Feb/0108.html

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 7 January 2011 21:16:07 UTC