- From: Alan Gresley <alan@css-class.com>
- Date: Wed, 18 Jun 2008 11:07:37 +1000
- To: Brad Kemper <brkemper@comcast.net>, Arron Eicholz <Arron.Eicholz@microsoft.com>, Alex Mogilevsky <alexmog@exchange.microsoft.com>
- CC: www-style@w3.org
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