Update: After being fixed in WebKit, this bug has resurfaced in Blink. Read the follow up post.
I found a pretty big bug in WebKit today. It seems like such a basic scenario that I can hardly believe that no one found it before… and maybe they have but I couldn’t find an open issue on the WebKit bug tracker that described it.
Scenario
The bug involves a floated div containing an inline element (a span in this case, but I confirmed this also for label and input) and another floated div. The inner floated div breaks to the next line, even though it shouldn’t.
This is the HTML markup for this bug scenario:
<div class="outer"> <span>Breaking</span> <div class="inner">Float</div> </div>
This is the stylesheet:
.outer {
float: left;
}
.inner {
float: left;
margin: 0 8px 0 0;
}
This is the expected result:
Float Breaking
This is the actual result:
Breaking Float
I have to say I was a bit surprised by this bug. I consider WebKit a very strong browser with excellent standards compliance, being on the cutting edge of web standards. WebKit was one of (if not the) first browsers to pass the Acid3 test for example. So for such a basic scenario to fail is a bit of a disappointment.
Suggested fix
It seems this bug can be fixed by changing the inline element to a block level element, but this has to be done in markup, just a CSS rule display: block won’t help. Another possible fix is removing the float: left rule from the outer container and replacing it with display: inline or display: inline-block.
Repro and bug report
I have created a demonstration page on my personal webspace that demonstrates this bug and reported it on the WebKit bug tracker. I hope they will fix it soon because it makes for yet another of those browser inconsistencies that makes our lives as web developers difficult.
Stijn de Witt 
Thanks for bringing this to my attention on T.net. Is this the same as I’m experiencing here?
http://gathering.tweakers.net/forum/list_messages/1452439
http://stackoverflow.com/questions/5600390/html-css-whats-causing-this-difference-in-rendering-between-webkit-and-gecko
https://bugs.webkit.org/show_bug.cgi?id=57441
If this is the same bug, then perhaps we can confirm eachothers bugreport and maybe gain some attention for this problem.
Doesn’t this have more to do with the implied width of .outer?
FWIW: IE6 & IE7 display the same behavior as the Webkit browsers.
@James: As .outer is a block-level element it has an implied width of 100%… So I don’t see how that could explain the behaviour.
@Gert: Yes you are right I could also confirm that. IE 8 and 9 treat it correctly, but IE 6 & 7 do it wrong in the same way as WebKit. So probably this was introduced in WebKit in the past to improve compatibility with sites that relied on this behaviour and were only tested in IE…
@Martijn: I have looked at your issue. They definitely seem related.
First of all I edited your example to minimize it further to isolate the migitating factors. The results of my edits are here:
http://jsfiddle.net/gFevt/19/
Looking at that example there is one style rule I cannot remove without breaking the example (apart from the obvious ones like float left/right, display:inline etc that make the example in the first place). This rule is:
#topmenu li {
margin-left: 20px;
}
Removing this or setting it to 0 makes the word ‘helpdesk’ stay on the same line, where you would expect it. This makes me think that maybe the margin makes the last word extend beyond the right side of the page, making it break to the next line. I tried padding-left or margin-right or padding-right but they all have the same effect.
Likewise, from the markup, I am unable to remove the span element around ‘over’ in ‘over ons’. If I remove that span then wham! the problem disappears… Also if I place the word ‘ons’ inside the span then also the problem disappears. The same for the anchors (links), I cannot remove them without making the problem go away.
Interesting find you have here. I am now pretty convinced this is a bug as a span element is not supposed to have such an impact on the layout afaik.
@Martijn: I was able to reduce the problem even further. I removed the list, because these contain all kinds of complex rules (like bullets, indents for bullets etc) and replaced the list items with simple spans. Continuing this reasoning of removing elements with (more) complex rules associated with them, I removed the anchors. I found I could keep the problem by just nesting two inline elements in the first span. I chose b and i for this as they are short and sweet.
The results are here:
http://jsfiddle.net/gFevt/21/
This is now a staggeringly small example of the problem:
* A floated block element containing inline elements with a margin-left of 20px
* One inline element has nested sub inline elements
Thanks, that illustrates the problem more clearly then my own example.
I also responded to your report on the Webkit bugzilla, hopefully it will gain some attention.
[…] Traa from Mindcontrolled.nl brought to my attention a bug in WebKit that seems to be related to the WebKit Breaking Float Bug I blogged about […]
I hacked on it some more. I found it interesting enough to warrant it’s own Blog post:
https://stijndewitt.wordpress.com/2011/04/13/webkit-overflowed-float-bug/
Coming back to the original topic of this post. It took a bit of time but it seems now the WebKit people have been very busy on this. They have a patch ready, I am having trouble figuring out what version it will be in though…
SEE https://bugs.webkit.org/show_bug.cgi?id=45274
So it’s now march 2nd 2012. I was optimistic there would be a fix soon as in may of 2011 it seemed like it was imminent to arrive as there was a patch ready. Unfortunately though it seems that patch caused a couple of tests to fail and it was never committed. And then the devs seemed to have lost interest…
So it is now April 2013 and Chrome 26.0.1410.43 m still has this bug…
The article above, from stijndewitt, help me: I had an img and a div in the same parent div. The div has span elements inside (but no margin/padding), and I floated it to the right. Adding a float: left on the image solved the problem.
Hi PhiLho. Great to hear my post helped you. That motivates me to write more of them. 🙂
About the progress being slow… It sure is, but these kind of bugs can be *very* hard to fix. So anything you can do to help them would be great. For example if you have a different scenario that exhibits the same issue, you could make a test case for them and attach it to the bug. That may help them in analyzing what is happening. Also you can vote for the bug / follow it. If they see a lot of people are tracking a bug that will be a motivator for them to keep pounding on it until they get it right.
So please visit the bug tracker and add a comment. But keep it positive, because nothing can demotivate people as bad as trying hard to help a community project just to get bashed for it. I hope to see you here again under better circumstances, for example when you finish the great stuff you are building and show it to us! 🙂
[…] in september of 2010 I wrote a blog post about the Breaking Float rendering bug I found in WebKit, the rendering engine backing the Safari, Chrome and Opera […]