Re: [CSS2.1] Inline-block and inline-table and floats

Brad Kemper wrote:

>> [...]
>>> The Opera way is what I would have expected. If the inline block was 
>>> instead just inline, then they would all start at the same place, to 
>>> the right of the green box.
>>
>>
>> Not quite since you can give a width to an display:inline-block element
>> but not a display:inline element.
> 
> I meant, if that block was just a span of text, it looks like it would 
> fit there, and that is where it would start. I didn't think it was the 
> width that was pushing it down lower. Wouldn't the same thing happen if 
> it was narrower?


Now having the *real* Gecko 1.9 to test with I now remember that Gecko
1.9 and Safari 3 did indeed show the same in these test cases (now many 
months old). I had a discussion with Philippe Whittenbergh last year in 
which he said that the Gecko 1.9 and WebKit behavior is a bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=25888


Hixie writes in this bug report, "Line boxes should never overlap floats
that are in their formatting context."


This bug also happens with inline elements or the display properties
'inline', 'inline-block' and 'inline-table'.

I have updated my test cases.


http://css-class.com/test/css/visformatting/floats-with-inline-block-width.htm
http://css-class.com/test/css/visformatting/floats-with-inline-table-width.htm
http://css-class.com/test/css/visformatting/floats-with-inline-block.htm
http://css-class.com/test/css/visformatting/floats-with-inline-table.htm


There are two test each for each display property, one with a declared
width (to fit beside the float) and one without. Each test has
three parts.

  1. A box with no given height.
  2. A box with no given height and content greater than the space
     beside the float.
  3. A box with a given height.


Only Opera 9.10+ and I think IE8b1 (can someone please confirm this) 
will render these test cases correctly since both implementations use 
the bottom edge of the line box instead`of the top edge of the line box 
to calculate if any inline formatting context will overlap the second float.


>> http://www.w3.org/TR/CSS21/visuren.html#inline-formatting
>>
>> # When an inline box exceeds the width of a line box, it is
>> # split into several boxes and these boxes are distributed
>> # across several line boxes. If an inline box cannot be split,
>> # then the inline box overflows the line box.
>>
>>
>> But that in not how a inline-block or inline-table should behave, 
>> there should be no splitting.
> 
> You're right, I think. From what I see in FireFox and Webkit, it looks 
> like it is overflowing vertically. Should it just make the line-box 
> taller, or does the line-height prevent that? I imagine that is what 
> Opera is doing.


Opera is rendering it correctly. The vertical overflowing behavior
happens with boxes with display:table, display:table-cell,
display:table-row, display:auto and display:hidden.

What I find interesting is some of the properties and values establish a
'new block formatting context'. The spec has.

http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float

  # The border box of a table, a block-level replaced element,
  # or an element in the normal flow that establishes a new
  # block formatting context (such as an element with 'overflow'
  # other than 'visible') must not overlap any floats in the same
  # block formatting context as the element itself. If necessary,
  # implementations should clear the said element by placing it
  # below any preceding floats, but may place it adjacent to such
  # floats if there is sufficient space.


But this is only true with these constructions if the element that
establishes a new block formatting context comes after a float. This is
not true if a float appears after the said element in the source, thus
we can observe this overflowing of the second float. This would indicate 
that this part of the spec should be looked into.

  # If necessary,
  # implementations should clear the said element by placing it
  # below any preceding floats


http://css-class.com/test/css/visformatting/floats-with-block-elements.htm
http://css-class.com/test/css/visformatting/floats-with-block-elements2.htm


Another observation is that the tested elements themselves (the 
background) will appear under the second float but the line boxes will 
appear over the second float in the display:table, display:table-cell, 
display:table-row, display:auto and display:hidden cases but only in 
Opera 9.10+ and Gecko 1.9.

Safari shows some unexpected rendering with display:table-cell and
table-row which seems to force down the second float. When I was able
to test IE8b1 I found that that there was unexpected behavior with all
test cases. To memory this was with each tested element clearing the
second float. This would mean that IE8b1 is following this part of the 
spec to the letter.

  # If necessary,
  # implementations should clear the said element by placing it
  # below any preceding floats


Alex and Arron, is this what is happening with IE8b1?


Alan

Received on Wednesday, 18 June 2008 01:08:28 UTC