Open Bug 895989 Opened 11 years ago Updated 2 years ago

Shrink-wrap width of element containing a float and a block formatting context is not wide enough for them to be side by side

Categories

(Core :: Layout, defect)

22 Branch
x86_64
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: christopherbuenaventura, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: DUPEME)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.22 Safari/537.36

Steps to reproduce:

I have an element with display: inline-block; that has two children. The first child has float set to either left or right. The second child, which has text, has overflow: hidden; to create a new block formatting context.


Actual results:

The text from the second child wraps prematurely. http://jsfiddle.net/8a6F3/1/ This seems to be a version issue as this was not occurring before (though I cannot pinpoint the version that it was working in).


Expected results:

The text should stay all on one line, as it does in other browsers.
Component: Untriaged → Layout
Product: Firefox → Core
For what it's worth, per spec this is a perfectly reasonable (and arguably correct) behavior...

Consider the slightly modified fiddle at http://jsfiddle.net/nTgHz/ in which the "rest" is not a BFC.  In that case, we have identical layout: the text wraps.  WebKit matches us in that case as well, as far as I can tell.  But changing the overflow of the child should not affect its preferred width and hence its contribution to the parent's preferred width!

In contrast, Presto has the text _not_ wrapping in both cases, which is also arguably correct per-spec behavior.
Summary: Premature line wrapping on inline-blocks with multiple block formatting contexts → Shrink-wrap width of element containing a float and a block formatting context is not wide enough for them to be side by side
Whiteboard: DUPEME
Interesting to know - perhaps then it's been a bug in both Webkit and FF this whole time, but FF recently had the proper fix. Don't know if that makes me any happier, haha.

--

Though not originally part of my report/fiddle, I should mention that my intended usage was to include a max-width on the "container" element, or an even parent element even further above "container".

http://jsfiddle.net/8a6F3/2/

In my example, setting width or max-width to 210px, at 100% zoom, should only drop "here." to the next line in other browsers.

In FF, setting the max-width will give the same exact result ("displayed here." dropped to the next line), but setting width (instead of max-width) will do what I was expecting (only "here.").
Basically the same as bug 396821, although I won't mark as a duplicate because this one has the variation that the block is overflow:hidden and thus establishes a block formatting context.  (That currently doesn't make a difference, although I suppose it's possible it could.)
Depends on: 396821
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.