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

Brad Kemper wrote:

> FWIW, Webkit nightly 5525.18 and FireFox 3 RC1 both show it the same.


Here's a rambling message. :-)


Brad, the same in which way? I have WebKit nightly 5525.17 and Firefox 3 
RD1. I now find that when I launch Firefox 3 RD1, it's reporting itself 
as FF2.0.0.14 (profile corruption, I guess). It was working correctly a 
few week ago. This could mean that what I have seen over the last few 
days is not correct when quoting Gecko 1.9. :-(


What does Firefox 3 RD1 and WebKit nightly 5525.18 do?


1. Inline block and inline table top left corner sitting against the top
left corner of the container.

2. Inline block and inline table sitting to the right of the green float.


Is this what WebKit nightly 5525.18 is now doing? I am seeing changes 
with behaviors between different versions of WebKit betas and Gecko 1.9 
betas. The shifting sands. :-)


> 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.


> Opera seems to be pushing it down because as an 
> inline block it doesn't fit there. I don't know why that wouldn't be 
> correct.


Take a look at this test case.


http://css-class.com/test/css/visformatting/inline-block1.htm


Gecko 1.8: Shows the red box as a block element.


Safari 3.1, WebKit nightly 5525.17 and Opera 9.10~9.50: Shows the red
box shrink-wrapping the line box as a inline element (display:inline) does.

I don't know what IE8b does here. Any clues? What does WebKit nightly
5525.18 do? Or any version of Gecko 1.9?


I see in the specs this:

http://www.w3.org/TR/CSS21/visuren.html#display-prop

# inline-block: This value causes an element to generate a block
# box, which itself is flowed as a single inline box, similar to
# a replaced element. The inside of an inline-block is formatted
# as a block box, and the element itself is formatted as an
# inline replaced element.


This would indicate that Gecko 1.8 is generating a block box and
thus following the spec more closely (as I see above).


WebKit and Opera are treating the box as display:inline for formatting 
so if there is enough room beside the green float in this test case.


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


then both WebKit and Opera will place the display:inline-block element
beside the green float but if the height of the box exceeds the height
of that little space (beside the float), Opera will clear the second
yellow float.


I guess it how we understand this part in inline formatting

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.


I have updated both my mass test cases, the first with a width on the
tested elements

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


and the second with no declared width on the tested elements

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


In some of these test the tested element will show under the float but 
the inline boxes will show above the float. Gecko 1.7~1.9, Safari 3 and 
Opera 9.10~9.50 render display:table this way.


What is supposed to happen, I don't know. All I know is that different 
implementations (current, betas a RC) show different behaviors and I 
having trouble testing all implementations (like IE8b1) and now relying 
on memory alone.


This can all wait until I get another computer and wide screen monitor 
but I would prefer to see this resolved since all implementations are 
currently in betas apart from FF3 RC1.


Alan

Received on Tuesday, 10 June 2008 08:40:31 UTC