- From: Alan Gresley <alan@css-class.com>
- Date: Tue, 10 Jun 2008 18:39:31 +1000
- To: Brad Kemper <brkemper@comcast.net>
- CC: www-style@w3.org
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