- From: Peter Moulder <peter.moulder@monash.edu>
- Date: Mon, 10 Jan 2011 04:43:40 +1100
- To: www-style@w3.org
§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 UTC