Re: [CSS21] 9.2 Anonymous boxes

fantasai wrote:
> On 08/01/2010 02:45 PM, Anton Prowse wrote:
>> Several issues arise concerning anonymous block boxes.
>>
>>
>> 9.2.1 (Block-level elements and block boxes) says:[1]
>>
>> # Block-level elements (except for display 'table' elements, which are
>> # described in a later chapter) generate a principal block box that
>> # contains either only block boxes or only inline boxes.
>>
>> 9.2.1.1 (Anonymous block boxes) says:[2]
>>
>> # In a document like this:
>> #
>> # <DIV>
>> # Some text
>> # <P>More text
>> # </DIV>
>> #
>> # (and assuming the DIV and the P both have 'display: block'), the DIV
>> # appears to have both inline content and block content. To make it
>> # easier to define the formatting, we assume that there is an
>> # anonymous block box around "Some text".
>> #
>> # In other words: if a block box (such as that generated for the DIV
>> # above) has another block box or run-in box inside it (such as the P
>> # above), then we force it to have only block boxes and run-in boxes
>> # inside it.
>>
>> OK. But we also have the following from 16.6.1 (The 'white-space'
>> processing model)[3] (which will likely be moved to Ch.9; see [4]):
>>
>> 16.6.1:
>> # Any text that is directly contained inside a block element (not
>> # inside an inline element) should be treated as an anonymous inline
>> # element.
>>
>> Issue 1:
>>
>> Does that mean that there's an anonymous inline box around "Some text"
>> or that there's one around "Some text <P>More text" (which would mean
>> that the rules for breaking an inline box around a block then come into
>> play)? In fact it doesn't matter, since we end up with an anonymous
>> block containing an anonymous inline containing "Some text" in both
>> interpretations. But what if it were
>> "Some text <SPAN>More text</SPAN> End text"? In this case the two
>> interpretations – anonymous inline boxes around "Some text" and "End
>> text" or one anonymous inline box around everything – yield different
>> results.
>>
>> I think the sentence from 16.6.1 says that it's the first
>> interpretation, in each case. I'd be grateful for confirmation of that!
> 
> In both cases the first interpretation is correct. I think that's
> pretty clear from the text you quoted. The <p> is not text that
> is directly contained inside a block, therefore it does not get
> wrapped in an anonymous inline. (Its contents, however, are, so
> they do get wrapped in an anonymous inline -- a different one.)

Yeah, the P example doesn't really cause confusion.  It was rather the
SPAN example that had a glimmer of ambiguity: do both chunks of loose
content ("Some text" and "End text") get wrapped in the /same/ anonymous
inline box (which would thus also contain anything in between) or does
each get their own?  Your confirmation that it's the latter option
doesn't come as a great surprise though!

> BTW, why would the two interpretations yield different results?

Not different renderings, but different box subtree structure.


>> Issue 3:
>>
>> What /does/ happen when an inline box contains a float? Does the run of
>> inlines+floats in which it sits get wrapped in an anonymous block box
>> which becomes the sibling of the floats? If so, this needs stating.
> 
> I don't understand. What case exactly are you talking about?

<div>start <span style="float:left">middle</span> end</div>

The float is taken out of the flow, but the div is a block box and can
only contain all inline-level or all block-level content.  Under the
assumption that the div _contains_ the block box of the float, then we
either need to ensure that the div's inline content is wrapped in an
anonymous block-level box, or that the float is ignored for the purposes
of enforcing block container box behaviour on the div.

Thinking on this further, however, I think that "out of flow" probably
means that the float box isn't "contained" by the div box, in which case
things already hold together correctly.  This might be worth clarifying
in the spec, though.


>> Issue 4:
>>
>> Is it the case that, with the exception of an anonymous table box, an
>> anonymous block box contains either only block boxes or only inline
>> boxes, much like a principal block box? (This is essentially the same
>> question I'm asking in [5] as part of the great box cleanup; we'll need
>> to ensure we get the same answer!)
> 
> Both anonymous block boxes and principal block boxes are block boxes.
> So yes, it contains only block*-level* boxes or only inline*-level*
> boxes.

Good to know.  This needs stating in the current spec, which plucks the
term "block box" out of thin air without defining its behaviour.  Or
preferably, the great box cleanup[5] will be enlisted instead.

(Yeah, sorry for the lack of "-level"s; I just copy-pasted from 9.2.1
(Principal block boxes) without bothering to merge in the clean-ups in [5].)


>> 9.2.1.1:
>> # This model would apply in the following example if the following
>> # rules:
>> #
>> # body { display: inline }
>> # p { display: block }
>> #
>> # were used with this HTML document:
>> #
>> # <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
>> # <HEAD>
>> # <TITLE>Anonymous text interrupted by a block</TITLE>
>> # </HEAD>
>> # <BODY>
>> # This is anonymous text before the P.
>> # <P>This is the content of P.</P>
>> # This is anonymous text after the P.
>> # </BODY>
>> #
>> # The BODY element contains a chunk (C1) of anonymous text followed by
>> # a block-level element followed by another chunk (C2) of anonymous
>> # text. The resulting boxes would be an anonymous block box around the
>> # BODY, containing an anonymous block box around C1, the P block box,
>> # and another anonymous block box around C2.
>>
>> Issue 5:
>>
>> Why would there be an anonymous block box around the BODY? Surely the
>> principal block box of the (implied[6]) HTML is what surrounds the
>> anonymous block box around C1, the principal block box of the P, and the
>> anonymous block box around C2.
> 
> Good point. Assuming "display: none" for the <head> and "display: block"
> for <html>, the example here is wrong.

Yep.  And just to be clear here, had HTML been display:inline, we'd have
ended up with the three block boxes as the "top level" boxes of the
canvas, since there's no "initial box" or similar concept, right?
(There's an initial containing block, but this is a region, not a box.)


> [5] http://lists.w3.org/Archives/Public/www-style/2010Aug/0004.html

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

Received on Tuesday, 3 August 2010 18:06:46 UTC