Re: [CSS21] 10.6.1, 10.6.3 and 10.6.7 - editorial issues

Issue 4:

10.6.3 (Block-level non-replaced elements in normal flow when 'overflow'
computes to 'visible') says:

   # If it has block-level children, the height is the distance between
   # the top border-edge of the topmost block-level child box that does
   # not have margins collapsed through it and the bottom border-edge of
   # the bottommost block-level child box that does not have margins
   # collapsed through it. However, if the element has a non-zero top
   # padding and/or top border, or is the root element, then the content
   # starts at the top margin edge of the topmost child. (The first case
   # expresses the fact that the top and bottom margins of the element
   # collapse with those of the topmost and bottommost children, while in
   # the second case the presence of the padding/border prevents the top
   # margins from collapsing.) Similarly, if the bottom margin of the
   # block does not collapse with the bottom margin of its last in-flow
   # child, then the content ends at the bottom margin edge of the
   # bottommost child.

The second sentence explains how to calculate content area height when
top margin collapsing between parent and child is prevented by certain
means.  The second clause of the third (parenthetical) sentence explains
the same thing, but with reference to even more restricted means.  The
fourth sentence invokes "similarly" but goes on to explain how to
calculate content area height when bottom margin collapsing between
parent and child is prevented by /all/ means.

This paragraph needs editing so that it treats the top margin collapsing
case in the same way as the bottom margin collapsing case, namely by
simply referring to the general situation in which parent–child top
margin collapsing is prevented.

Without this edit the spec is wrong – specifically, in the second
sentence – since the parent element in question might have a first child
with overflow other than visible (for example) and a positive top margin
height.

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

Received on Monday, 9 August 2010 11:07:23 UTC