W3C home > Mailing lists > Public > www-style@w3.org > January 2011

[CSS21] WD 9.2.1.1: anon block box issues

From: Peter Moulder <peter.moulder@monash.edu>
Date: Mon, 10 Jan 2011 04:43:40 +1100
To: www-style@w3.org
Message-id: <20110109174340.GA23949@bowman.infotech.monash.edu.au>
9.2.1.1 says:

  # if a block container box ... has a block-level box inside it ...,
  # then we force it to have only block-level boxes inside it.

but doesn't say how we force it to have only block-level boxes other than
in the case that an inline box (after being split per 9.4.2 for
determining what's in the line box) contains a block-level box.

Another problem is that "has a block-level box inside it" is unclear:
it isn't clear whether this means as a child, as an ancestor, or
geometrically inside.  Whereas in fact I believe we want none of those,
because I believe we also want to restrict the test to in-flow
block-level boxes.

The text also doesn't say what to do when an inline box contains two
block-level boxes, and the most obvious interpretation differs from what
most existing user agents do, when there are two or more *consecutive*
block-level boxes: I believe the most obvious interpretation of the "even
if either side is empty" rule would result in an anonymous block box
(containing an empty inline box that "still [has] margins, padding,
borders and a line height") between the two block-level boxes, whereas
common existing user agents treat the sequence of consecutive block-level
boxes as if it were a single block-level box; and this seems like
desirable rendering behaviour.

I'm uncomfortable with this section mentioning line boxes, and believe
this to be an error: it introduces circularity, in that it makes
anonymous block box generation depend on line breaking, which of course
depends on anonymous block box generation.  I believe it unnecessary to
mention line boxes in this section, and it seems easier to understand
without this circularity.

Another form of circularity in the existing text is the definition in
terms of an existing box tree, leaving us with what resembles a paradox
as to whether the inline box does or doesn't contain a block-level box.
Possibly this can be resolved by clearly distinguishing the input and
output of anonymous block box processing.

(My impression is that most other box tree manipulations within CSS2.1
(run-in, anon table object creation, inside marker insertion) can be
considered to entirely "precede", i.e. form the input to, anonymous block
processing; though that involves some assumptions about run-in that may
be simply errors in the current text.)

pjrm.
Received on Sunday, 9 January 2011 17:44:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:35 GMT