[CSS2.1] Visual formatting model: Boxes, BIDI, and Normal Flow

S9.2.1 Block-level elements and block boxes: Anonymous block boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous-block-level

# The properties of anonymous boxes are inherited from the enclosing
# non-anonymous box (in the example: the one for DIV).

There's no DIV in the example. (It would make sense for the example
a few paragraphs up, but that's not in range of this sentence.)

# Properties set on elements that are turned into anonymous block boxes
# still apply to the content of the element. For example, if a border
# had been set on the BODY element in the above example, the border
# would be drawn around C1 and C2.

Would the border be drawn as a block border around C1 and another around
C2, or would the border be drawn as an inline border around C1 and another
around C2?

Would the border split where the block occurs? I.e. if it's a block border,
would the bottom border not exist for C1/if it's an inline border, would
the last border not exist for C1?

If it's a block border, then what happens with:
   <p>There's an <em>interesting <span class="block">formatting</span>
      effect</em> in this paragraph.</p>

   em { border: solid }
   .block { display: block }

?

S9.2.2 Inline-level elements and inline boxes: Anonymous inline boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous

# The <p> generates a block box, with several inline boxes inside it...
# ...they don't have an associated inline-level element.

No mention of the conditions for creating an anonymous inline.

S9.2.3: Run-in boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#run-in

# 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.

I don't think the intention is to have last-child run-ins combine with
their parents' next-siblings, so change that to "a sibling block box".

Also, see http://lists.w3.org/Archives/Public/www-style/2000May/0010.html

S9.2.4 The 'display' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#display-prop

# and the element itself is formatted as a replaced element on the line.
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
   as an inline replaced element.

S9.3.1 Choosing a positioning scheme: 'position' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position
> In the case of the print media type, the box is fixed with respect to
> the page

If it repeats on every page, then that should be mentioned here.

S9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position

It seems like the property definitions for top, right, left, and bottom
could be combined into one table+description+note. Other than the name
of the side, the text is exactly the same.

# The offset is a percentage of the containing block's box width
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
   containing block's width

# See the sections on the width and height of absolutely positioned,
# non-replaced elements for details

Strike out "non-replaced".

S9.4.1 Block formatting context
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
# 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). This is true even in the presence of floats (although a
# box's line boxes may shrink due to the floats).

What about clearance?

S9.10 Text direction: the 'direction' and 'unicode-bidi' properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#direction

# For the 'direction' property to have any effect on inline-level
# elements...                  ^^^^^^^^^^^^^^^^^^

change to
   For the 'direction' property affect reordering in inline-level
   elements...

~fantasai

Received on Tuesday, 21 October 2003 04:23:28 UTC