Re: [CSS21] line boxes, line-height and zero height floats

On 16/01/2012 03:37, Alan Gresley wrote:
> In a recent thread (which I need to reply to some messages) [1], I
> stated this to Anton.
>
> | It's possible to have line-height: 0 which shows no
> | leading and overlapping line boxes. The overlap is
> | roughly 80% of the height of the line box (the one
> | I conceptualized).
>
> This was based on a test case that Anton had put in the message that I
> replied too and just testing in Firefox 9.
>
> In another part of this thread, I had stated that when line boxes
> (whatever the are) have a line-height applied, this line-height value
> determines if a line box can flow beside a float of equal height
> (noticed in this test case [2]).

You still seem to be mixing up line boxes with inline-level boxes!  Line 
boxes don't have a line-height applied; their height is determined by 
the inline-level boxes they contain (including a strut) based on the 
line-height (and vertical-align) set on these inline-level boxes.  The 
UA bug you noticed concerned the flowing of inline-level boxes next to 
floats and was not related to line boxes per se.

> I have somewhat contradicted myself it seems because both statements can
> not be true. After working on a interactive test case as a reply to
> Gérard list message (still in the works), I have come across something
> which I have never tested or observed before (I dare say that Anton and
> Bruno may have knowledge of this).
>
> Below is a test case that is testing three type of line boxes flowing
> beside a zero height float.
>
> 1. anonymous inline element.
> 2. inline element (inline-level)
> 2. block element (block-level)

Seriously, none of the above things are line boxes.  The first two are 
inline-level boxes.  The third is a block-level box.

> http://css-class.com/test/css/text/linebox-line-height-012.html
>
> When 'line-height: 0' is selected for all test, I expected to see in all
> browsers what I observe in IE9 and WebKit and that is where the two
> longer floats are touching (since the shorter float has zero height) and
> the line box or content box has it's upper half leading over the top
> longer float and it's lower half leading over the bottom longer float.

I've already explained the inline formatting model a couple of times. 
Still, let me do so again to describe the correct behaviour for the 
first two tests is the following.  The line-height on the div which is 
the parent of the floats and the inline-level box is zero.  As per 
10.8.1, this specifies the minimal height of the line boxes within the 
div (through creating a strut of this height within each line box that's 
created).  The div also has a font-size of 100px and so the inline-level 
box has a content area height is around 100px.  (The exact content area 
height is explicitly undefined.)  The vertical-align of the inline-level 
box is the initial value, namely 'baseline'.  Hence the baseline of the 
100px-high text aligns with the baseline of the (zero-height) strut. 
Now, the "height" of the inline-level box is zero (despite its content 
area height being around 100px).  There is equal half-leading placed 
above and below content area box of the inline-level box to vertically 
centre the content area "within" the inline-level box.  (In this case, 
the leading is negative). It's difficult to imagine this, and so as I've 
mentioned various times it's easier to imagine that each inline-level 
box has an associated guide box; in this case, the guide box is zero 
height and it's vertically centred within the content area box of the 
inline-level box.

The line box height is defined in 10.8 to be the distance between the 
uppermost inline-level box top and the lowermost inline-level box 
bottom.  Here, "top" and "bottom" refer to the "height" of the 
inline-level box; the spec does not define a term to describe the edges 
to which they refer, but note that they're nothing to do with margin-, 
border-, padding- or content-edges.  Again, this is why I introduce the 
concept of guide boxes.  The spec is saying that the line height is the 
distance between the uppermost guide box top and the lowermost guide box 
bottom.  This is around 50px high, since the zero-height guide box for 
the strut sits on the baseline and the zero-height guide box for the 
inline-level box is vertically centred within the content area box of 
the inline-level box.

> In Firefox 9, I also observe something different. The first two test
> 'anonymous inline element' and 'inline element (inline-level)' shows the
> two longer floats separated by a gap
[...]
> As the line height is reduced, the line box or content box is only bleeding
> upwards over the top longer float and the gap when is it minimum (based
> on the x-height) is always the vertical height of the distance between
> the baseline and the vertical midway line (guide line ?) of the
> line-height box (to use a term).

This seems correct, visually.  (It's easy to tweak the test case so that 
Firefox no longer renders correctly though.)

> In Firefox 9, the last test 'block element (block-level)' renders the
> same as IE9 and WebKit where the two longer floats are touching and the
> line box or content box has it's upper half leading over the top longer
> float and it's lower half leading over the bottom longer float.

This is incorrect. The underlying issue here is that Firefox gets the 
following test case wrong:

<!DOCTYPE html>
<div style="line-height:0>text</div>

It thinks the used height of the div is zero (or at least, that's what 
Firebug tells me).  This is wrong, as explained above.

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

Received on Monday, 16 January 2012 23:27:41 UTC