Re: [CSS21] When line boxes are or are not present is not really defined

Boris Zbarsky wrote:
> Section 17.5.3 has this to say:
> 
>     The baseline of a cell is the baseline of the first in-flow line
>     box in the cell, or the first in-flow table-row in the cell,
>     whichever comes first. If there is no such line box or table-row,
>     the baseline is the bottom of content edge of the cell box.
> 
> However nothing defines when line boxes are or are not present.  If a 
> block contains only non-preserved whitespace, does it have any line 
> boxes?  The end of section 9.4.2 suggests yes[1], but Gecko and Webkit 
> seem to think the answer is "no"[2].  Opera seems to think that even an 
> empty block which has no child boxes at all has a line box.
> 
> It would be good to get this clarified, since this affects vertical 
> alignment of both table cells and inline-block elements and currently we 
> seem to not have very good interop here.
> 
> -Boris
> 
> [1] "Line boxes that contain no text, no preserved white space, no
>      inline elements with non-zero margins, padding, or borders, and
>      no other in-flow content (such as images, inline blocks or
>      inline tables), and do not end with a line feed must be treated
>      as zero-height line boxes." though this really does beg the
>      question of whether said line boxes exist at all; they just
>      have to be treated as 0-height if they do exist?
> 
> [2]  Testcase:
> 
>   <div style="display:table">
>     <div style="display:table-row">
>       <div style="display:table-cell;background:red">
>        <div style="width:150px;height:150px;background:blue"> </div>
>       </div>
>       <div style="display:table-cell;background:green">a<br/>b</div>
>     </div>
>   </div>

When I was examining the inline formatting model in [3], I was certainly
working with the assumption that 9.4.2 expects that an empty, zero-width
line box exists in a non-empty block that contains only non-preserved
whitespace.  I'd have to think about it some more before commenting on
whether this has an impact on anything other than vertical alignment of
table cells and inline-block elements.

Given the following "transitions" of the blue-background div in Boris'
example, discontinuities exist in Gecko and Opera at the points marked 'D':

    | div contains | div contains | div is | div contains block- |
    |     'a'      |     ' '      | empty  | level replaced el   |
-----------------------------------------------------------------
Gk                D
Op                                        D

Somehow, Opera's discontinuity doesn't feel very natural to me, but I
can't quite explain why.

In both browsers, I'm happy from an author perspective that there's no
discontinuity between the non-empty block that contains only
non-preserved whitespace and the empty block.  Which I guess means that
I prefer Gecko's behaviour.

Note that the same discontinuities exist for inline-block.  (I find
Opera's layout here more objectionable than in the table case. I think
this has something to do with the fact that, to my mind, table cells in
a given row are "equals" when it comes to vertical alignment whereas
inline-blocks are lesser than text in a given line box and generally
occur in line boxes where at least some text is present, which leads me
to certain expectations about how they should align to keep the text
runs looking nice in the admittedly contrived situation of the
inline-block containing no positive-width line boxes or replaced content.)

So I suppose I'm voting against the existence of line boxes in 9.4.2 in
the circumstances required.  I wonder if they were originally desirable
because they functioned a bit like "struts" for the purposes of 10.8.1
before struts were actually introduced.

[3] http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html

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

Received on Monday, 31 May 2010 21:29:09 UTC