Re: [CSS21] Another ambiguity in the definition of "containing block"

2009/9/27 Boris Zbarsky <bzbarsky@mit.edu>:
> On 9/27/09 4:45 PM, Giovanni Campagna wrote:
>>
>> Even if it used the anonymous box (which includes "Text" and "More
>> text"), the float should have been half the height of that box
>
> No, it should have had a computed height of 50% of the computed height of
> that box.  The computed height of the anonymous box is auto, and percentages
> of auto compute to auto.

Rigth. Maybe putting some content inside the float could clarify
what's happening (not rendered, 0px height, auto height with no
content)

>> In any case, imo the interpretation "the box generated by the nearest
>> block-level ancestor element" is the correct one
>
> There are multiple boxes generated here, so "the box" is nonsensical.

If you ignore paging and multicolumn layout, one block element creates
one explicit (not anonymous) box. Other block-level may create more (a
marker box for list-item, for example), but it should be unambiguous
what's intended.

>> the anonymous one is generated by its content.
>
> I believe in CSS each box is generated by a specific element.  But I could
> be wrong; Bert's pointed out cases where I was wrong about box generation
> before.  I wish it were defined somewhere outside Bert's brain.  ;)

As I read it, element create "explicit" boxes, while "anonymous" boxes
are created by the interaction of other boxes: an inline box, sibling
of a block box, inside another block box, is wrapped by an anonymous
block box; a table-cell box, inside a table-row-group box, is wrapped,
with all its adiacent sibling table-cell boxes (which may be
anonymous) in a table-row box

>>> I still think that all of 10.1 is ambiguous in any but the most trivial
>>> cases that fall under item 2; this is just another example....
>>
>> Well, replacing "ancestor" with "ancestor's" may solve it, I think.
>
> Not really, no.

Not in any case, but it works for block-level elements. Table-cells
may be treated differently, if we wish to preserve compatibility (and
to choose the most sensible approach, imho). Inline-blocks have no
problems, because they're never inferred from other boxes.

> -Boris
>

Giovanni

Received on Tuesday, 29 September 2009 16:15:05 UTC