Re: [CSS21] Issue 120 (again)

On 06/10/2010 18:57, Bert Bos wrote:
> http://wiki.csswg.org/spec/css2.1#issue-120
>
> The WG agreed to the definitions from Fantasai's message[1]. However,
> while looking at issue 142, I noticed that one of the changes in that
> message didn't just replace a long phrase with a shorter one, it
> actually introduced a change.
>
> Bullet 2 in section 10.1 defines the "containing block" for certain
> kinds of elements. It used to say:
>
>      [...] the containing block is formed by the content edge of the
>      nearest block-level, table cell or inline-block ancestor box.
>
> Now it uses the newly defined term "block container box" and says:
>
>      [...] the containing block is formed by the content edge of the
>      nearest block container ancestor box.
>
> (Issue 142 is about moving and explaining that word "ancestor", but that
> is not relevant now.) When checking issue 120, we all apparently
> overlooked that this misses the case of the ancestor being a table. A
> table is a block-level element, so under the old definition, the
> content edge of the table is the containing block. But under the new
> definition, the table is ignored, and instead an ancestor of the table
> provides the containing block. That is because the definition of "block
> container box" says:
>
>      Except for table boxes, which are described in a later chapter, and
>      replaced elements, a block-level box is also a block container box.
>      A block container box either contains only block-level boxes or
>      establishes an inline formatting context and thus contains only
>      inline-level boxes.
>
> Which implies that a table box is not a "block container box."
>
> I think bullet 2 of 10.1 should be amended so that a table establish a
> containing block again.

To be fair, fantasai made it clear that she preferred to keep table 
family boxes out of the core discussion on boxes (hence there was rather 
less attention paid to them in the external review).

I agree with you that there's a genuine problem in the particular case 
that you describe, but actually I suspect there may also be other cases 
that need close review to ensure that table family boxes are treated 
appropriately.  Trouble is, it's difficult to do the necessary 
inspection without access to the current Editor's Draft.  Hopefully the 
LC will arrive soon and we'll collectively be able to pick up on this 
kind of issue!

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

Received on Wednesday, 6 October 2010 20:12:41 UTC