WD-CSS21-20020802 section 9, "Visual formatting model", substantive comments

Following are substantive comments on section 9, "Visual formatting model"
(<http://www.w3.org/TR/2002/WD-CSS21-20020802/visuren.html>), of the
Cascading Style Sheets level 2.1 draft
(<http://www.w3.org/TR/2002/WD-CSS21-20020802>).



9.1.2 Containing blocks


"The root of the document tree generates a box that serves as the initial
containing block for subsequent layout."

If this is the case, what do percentage width and height mean for a root
element?  The initial containing block should be chosen before dealing with
elements, whether root or other.



9.2.1 Block-level elements and block boxes


"Several values of the 'display' property make an element block-level:
'block', 'list-item', and 'run-in' (part of the time; see run-in boxes),
and 'table'."

'Table-cell' should be listed too, yes?



9.2.3 Run-in boxes


"If a block box (that does not float and is not absolutely positioned)
follows the run-in box, the run-in box becomes the first inline box of the
block box."

This statement needs clarification.  Does the following box have to be
generated by a sibling element?



9.3.1 Choosing a positioning scheme: 'position' property


"Applies to: all elements, but not to generated content"

Why is this?



9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'


It seems to me that the four properties can be aggregated in one definition
table.



9.5 Floats


"A floated box must have an explicit width (assigned via the 'width'
property, or its intrinsic width in the case of replaced elements)."

There are several problems here.  I can be explicit but not precise:
"width: auto".  Intrinsic width is assigned by the 'width' property; it is
not a separate case.  What happens if an element is set to float but has
'auto' specified 'width'?  Does the element remain in normal flow?  Are
certain rule sets ignored?


"Any floated box becomes a block box"

Does that mean "block-level box" or "display: block"?


"When a block box overlaps, the background and borders of the block box are
rendered behind the float and are only visible where the box is
transparent."

The third word "box" refers to the float, yes?  So it should be "float",
instead.



9.5.1 Positioning the float: the 'float' property


"Applies to: all but positioned elements and generated content"

Why does 'float' not apply to generated content?  Floating ':before' could
be quite useful and handsome.


"The element generates a block box that is floated to the left. Content
flows on the right side of the box, starting at the top (subject to the
'clear' property). The 'display' is ignored, unless it has the value
'none'."

This fails to account for floated tables.  And what happens to floated list
items?


"right
Same as 'left', but content flows on the left side of the box, starting at
the top."

No, not same as 'left'; the 'right' value floats a box to the right, not to
the left.  I suggest an exact wording:

"The element generates a block box that is floated to the right. Content
flows on the left side of the box, starting at the top (subject to the
'clear' property). The 'display' is ignored, unless it has the value
'none'."


What happens to tables that flow behind floats?  Are tables allowed to flow
behind floats?



9.5.2 Controlling flow next to floats: the 'clear' property


"This property may only be specified for block-level elements (including
floats)."

This is false.  Change to "This property affects only block-level elements
(including floats)."



9.7 Relationships between 'display', 'position', and 'float'


"if 'float' has a value other than 'none', the box is floated and 'display'
is set according to this table:

Specified value                   Computed value

inline-table                      table

inline, run-in, table-row-group,
table-column, table-column-group,
table-header-group,
table-footer-group, table-row,
table-cell, table-caption,
inline-block                      block"

Specified table 'display' values should inhibit floating.  The
consequences, unless the table model is revised, are that anonymous table
objects are generated around the floated element.



9.10 Text direction: the 'direction' and 'unicode-bidi' properties


"The 'direction' property, when specified for table column elements, is not
inherited by cells in the column since columns don't exist in the document
tree."

Change "don't exist in the document tree" to "are not the ancestors of the
cells that they contain".


"Because the Unicode algorithm has a limit of 15 levels of embedding"

On last check, the limit was 62 levels.  Did I miss something?

Received on Thursday, 14 November 2002 07:12:15 UTC