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)
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.
Reporter | ||
Updated•11 years ago
|
Component: Untriaged → Layout
Product: Firefox → Core
Comment 1•11 years ago
|
||
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
Reporter | ||
Comment 2•11 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•