Zoom bug in IE7/8 and Firefox caused by border
UPDATE: As of Jan 2009, this bug is still appearing in the latest release of Firefox 3.5.7 The bug was fixed at some point in Firefox 3, but it has reappeared ![]()
After ranting on twitter for the last few hours, I realized it might be more helpful for the web development community to write a more thorough explanation of the bug that I've recently discovered.
This bug relates to both Internet Explorer 7/8 and Firefox 3.
The bug in action:
http://markasunread.com/examples/zoombug.html
If you have a fixed width element containing floated elements that take up 100% of the that container's width, and any of those elements have a border, zooming below 100% will cause the floats to break or wrap below the adjacent floated element. A small border will trigger the break quicker than a larger border.
Why nitpick?
This could actually cause a website to be unusable when zoomed down. If you have a sidebar with navigation floated and that sidebar has a 1 pixel border... ouch. Your navigation will probably wrap underneath your main area... probably below the wrap. Site navigation gone.
The HTML:
This is the first set of divs. Just a container "a" with floated "b" and "c" inside of it.
<div class="a">
<div class="b">div b</div>
<div class="c">div c</div>
</div>
In the second set of divs, I've added a wrapper of "border" so that I can add a border to it and reduce its width (for proper box-model width total) with the CSS.
<!--add a "border" div to set .b border and reduce its width-->
<div id="border">
<div class="a">
<div class="b">div b</div>
<div class="c">div c</div>
</div>
</div>
The CSS:
.a {
width:200px;
}
.b {
float:left;
width: 100px;
background:#FCC;
}
.c {
float:right;
width:100px;
background:#9FC;
}
#border .b{
width:98px;
border: 1px solid black;
}
Below is a screenshot of how the code renders at 100% zoom in IE7/8 as well as Firefox 3:

Code rendered at 100% zoom in IE7/8 and Firefox (acutally... all modern browsers)
Now, here is what it looks like if you zoom down to anything below 100% (I'm using 99% here just so you can easily see the elements, but the results are similar for all zoom percentages below 100%)

Code rendered at 99% zoom and below. The floated div wraps. This is the bug
This is the simplest example I could think of. I spent hours working math on paddings/margins/borders trying to understand why my pages were breaking when zoomed down. I finally narrowed it down to the border. Can anyone confirm if this is a noted bug?
The Results
Here is the link again for you to test the bug.
http://markasunread.com/examples/zoombug.html
It's worth noting that the bug is not present in Opera, Chrome, or Safari. Also worth noting... zoom feature sucks anyway. Why won't they trash it?
Is there a fix?
Unfortunately, my only suggestion is to not set the inside elements to exactly the width of their container. Give em some breathn' room. If the page breaks at 25% zoom, I really don't care. But it should be able to at least zoom down 1 time
Tags: bugs, css, web development
August 27th, 2009 at 6:21 pm
I ran into the same bug in Firefox 3.5. So if it was fixed in 3.0, then it came back in Firefox 3.5. Anyways, in my particular setup I only had a one pixel left border and that caused issues when I zoomed out by one notch. Then, when I changed it to a 2 pixel border (again, only on the left), it didn't have an issue until I zoomed out the page by 6 notches.
My solution will be to get rid of the left border and replace it with a faux border using a background image.
October 21st, 2009 at 3:02 am
I have had the same problem as this and stumbled onto your blog in my search to solve this problem, though nothing came up but your blog post. I have eventually found a solution, not very pretty but what you need to do is set a negative margin-right on div C (large enough value to stop it from breaking the box) and that should stop div C breaking onto a new line.
February 28th, 2010 at 9:35 pm
Wow, thanks so much for this. This issue has been driving me crazy. At least now I know what it is so I can go about finding a way around this bug. Thanks again for the work.