CSSnewbie

Bug Fix: IE Double Margin Float Bug

The double-margin float bug has been a source of irritation for CSS-loving web designers for years. The bug first became a major problem in IE5, when CSS started to become increasingly popular, and persisted through IE6. And, while an easy (if mysterious) fix has been known for quite some time now, it occurs to me that perhaps not everyone knows about it. So I thought it couldn’t hurt to toss another explanation out there.

So what is the double-margin float bug? It’s an Internet Explorer-exclusive bug wherein an element that is floated – and given a margin in the same direction as the float – ends up with twice the specified margin size. In other words, if you were to float an element to the left and give it a 20-pixel left margin, in IE the margin would actually be 40 pixels wide. It only happens when the margin is in the same direction as the float, but it happens to both left and right floats. At least IE is consistent in its inconsistency.

Obviously, this can be a pretty annoying problem. If, for example, you use floats to create columns (as I tend to do), this little bug can throw off your entire layout in Internet Explorer. Let’s say you create a wrapper div 800px wide, and then create two columns inside. You decide to float your columns left to get them next to one another, and then you give your leftmost column a margin to push it away from the edge of the wrapper. Assuming you’ve done your math right, this should work perfectly in every browser but IE. The ol’ blue beast, however, has doubled your left margin and thrown your columns completely out of whack.

Happily, the fix is extremely simple. All you have to do is apply a display: inline rule to your floated element. Seriously: that’s it. So you simply go from something like this:

#content {
	float: left;
	width: 500px;
	padding: 10px 15px;
	margin-left: 20px; }

To something like this:

#content {
	float: left;
	width: 500px;
	padding: 10px 15px;
	margin-left: 20px;
	display: inline; }

And why does a display property fix our margin problem? Really, your guess is as good as mine. In all truthfulness, applying a display property to a float should do exactly nothing (unless it’s display: none, that is). Floats are by definition block-level elements, and cannot become inline elements. And even IE knows this – after you apply this rule all browsers including Internet Explorer will continue to treat your floats like block-level elements. But now IE will also start behaving itself when it comes to your margins.

However, that’s also what makes this fix so nice: you can apply it to your element and not have to worry about what other problems that might cause down the line. Floats can’t be inline elements, so the property does nothing harmful.

As I said previously, this fix has really been around for some time. You can read more about it at Position Is Everything, which also gives a bit of the history of the bug and some of the old-school workarounds web designers used before this little fix was discovered.

Find Deprecated Elements with Diagnostic CSS Highlighting

I have to admit that I’m a bit of a code purist. In my heart of hearts, I’d really like to think that every developer out there that this site helps will turn around and produce clean, semantic XHTML to which to apply their lovely, efficient CSS. But that isn’t always the case. Sometimes people write code that isn’t quite semantic, whether they’re in a rush or just don’t know any better. Or sometimes designers are charged with redesigning a website that was first built during the Neolithic period.

Any way you slice it, there’s still a lot old-skool code floating around out there, and it can be a bear to dig through all that HTML to find the bits that could use a good refreshing. So once again, CSS comes to the rescue! The technique I’m talking about today is sometimes called “CSS Diagnostics.” Basically, you’re just using CSS to highlight specific elements and attributes – specifically, the ones that shouldn’t even be there in the first place.

Our first order of business is to decide what elements you’d like to weed out of your code. You could create a list of every single deprecated tag out there, but most developers didn’t use every tag out there. For our purposes, I’m going to look for the <font>, <center>, <s> (strikethrough), <u> (underline), <b> (bold), and <i> (italic) tags, which probably make up around 80% of the still-common deprecated tags out there. If I want to see where those tags are used in any website, all I need to do is apply some CSS to make them stand out:

font, center, s, u, b, i {
	color: #000;
	font-weight: bold;
	background-color: #f99;
	border: 3px solid #c00; }

And just like that, all of our deprecated tags are boldfaced on a light red background with a nice, wide dark red border. And assuming that wasn’t your previous design of choice (please tell me that wasn’t your previous design of choice), they should stand out on your website like the big, red sores that they are. :)

And that takes care of our tags, but what about all those deprecated attributes out there that might be applied to perfectly legitimate tags? For that, we’ll use the magic of CSS attribute selectors (more on those here). So for example, if I knew that the previous developer of the site I’d just inherited was fond of applying margins to their body tags using “rightmargin,” “leftmargin,” and so on, and also loved to scatter “bgcolor” and “background” attributes like so many apple seeds, I could just write a rule like this to weed them out:

body[bottommargin], body[leftmargin],
body[rightmargin], body[topmargin],
*[background], *[bgcolor] {
	color: #000;
	font-weight: bold;
	background-color: #fc6;
	border: 2px solid #c60; }

Here I’m using attribute selectors to highlight elements with particularly unsavory attributes. I’m also using the universal selector (*) to find all instances of attributes that can apply to multiple types of elements (like backgrounds). That way, I don’t have to write out every possible combination of element and attribute under the sun. And just like that, I’ll be able to hunt down all sorts of problem bits of code! You can see our examples from above in action here.

A few words of caution: when you’re doing this sort of styling, it’s important to apply these styles after all of your other CSS has been applied. That way, you don’t accidentally overwrite parts of your diagnostic CSS with other rules later on down the line. To do that, either put your diagnostic rules at the bottom of your CSS files, or create a whole new file for your diagnostic rules and <link> them after your main CSS file, or just copy and paste them into a <style> tag if you’re only diagnosing a page or two.

Also, as mentioned in the last article about attribute selectors, IE6 doesn’t recognize them. Of course, since this are purely diagnostic rules, that shouldn’t be much of a problem… just be sure to view your website in a modern browser (Firefox, Opera, Safari, IE7 (if you must), etc) when checking it for problems. And really, if you’re still using IE6 for all of your web design work, you’ve bigger issues to work through than just a deprecated tag or two here and there. :)

And finally, this build-your-own-diagnostic method is great if you know what to look for, but if you’d prefer a more one-size-fits-all solution to your diagnostic woes, I’d suggest downloading a full diagnostics stylesheet, like the one Neal Grosskopf offers here. However, be aware that his solution will highlight elements and attributes that are technically deprecated but still commonly used to good ends – such as the “height” and “width” attributes on images. I may be a code purist, but I still find those attributes mighty useful!

Fixing the IE6 Whitespace Bug

Sometimes, when I’m building a vertical navigation menu (like the one pictured above), Internet Explorer 6 will fight with me in a fairly annoying way: it adds a bunch of white space between the list items (specifically, I think it’s adding space below each list item). This space isn’t a margin, and it isn’t padding… it’s just empty, un-selectable space. So what’s going on, and how do we fix it?

The “what’s going on” part is simultaneously simple and perplexing: IE6 is treating all the empty space inside of your HTML lists – that is, the stuff between your closing </li> and next opening <li> tag — as real space. That’s the simple part. The confusing part is, why would it choose to interpret this space as “real,” when it ignores all of the other space between tags in pretty much every other situation out there? Well, that’s just IE6 for you, and that’s the perplexing bit.

Luckily, there is a really easy solution to this problem. Actually, truth be told, there are several solutions. Depending on your situation, each might be the right fix for you.

Fix #1: Remove All Whitespace

This is the most arcane of all the solutions, but to be honest, it’s the one I’ve used most often in the past – because I didn’t know about the other solutions! If you remove the white space from your code, this prevents IE from having anything to screw up. Specifically, if you remove the white space between your closing list item and the next opening list item, and your last closing list item and the end of your list, this will fix the problem. So you just need to turn this:

<ul>
	<li><a href="#">First Item</a></li>
	<li><a href="#">Second Item</a></li>
	<li><a href="#">Third One!</a></li>
</ul>

Into this:

<ul>
	<li><a href="#">First Item</a></li><li>
	<a href="#">Second Item</a></li><li>
	<a href="#">Third One!</a></li></ul>

Like I said, this isn’t exactly an elegant solution. But it does work, and it can be useful in places when CSS isn’t entirely reliable (like in HTML emails).

Fix #2: Float the Anchor Tags

Jon Hicks popularized this fix years ago. Basically, you float the anchor tags left, and then clear them left as well, like so:

ul a {
	display: block;
	float: left;
	clear: left; }

This causes your links to behave like floated elements, which naturally don’t have any space between them. Unfortunately, it also prevents your links from filling all the horizontal space available, which would make a mess of the example I used above, because I’m relying on that width to create a background color and a border. However, if your links don’t have any fancy hover states or borders, this solution would work just fine.

Fix #3: Apply a Bottom Border

Another useful solution is to apply a border to your list item. Why does this work? I have no idea. Does a border just anywhere work? Nope. It has to be applied to the bottom of the list item (or to all four sides, as long as the bottom is included):

ul li {
	border-bottom: 1px solid #666; }

I suppose the logic on this one is that the space is on the bottom of the element, so specifying a definitive edge to the box causes IE6 to recognize the “real” end of the element. Whatever the reasoning, it works, and it’s a good solution if you don’t mind a pixel of extra space in between your elements in return for getting rid of the great swaths of space IE had introduced. And sometimes it even works in the design. In the image above, for example, the border between the items could just as easily be applied to the list item instead of the anchor (which is where I had placed it initially).

Fix #4: Use Display: Inline

In my experience, the most useful solution of the four is to force your list items to display inline, instead of as a block-level element (which they are by default):

ul li {
	display: inline; }

As far as I can tell, this technique was first popularized by Andy Budd waaay back in 2003 (of course, he was dealing with IE5 back then). I like this solution because it seems to do the least harm to my lists. It doesn’t add any additional space that I need to account for. It also doesn’t harm the size of my anchor tags: if I apply a “display: block” to my anchors, like I’ve done in the image above, my anchor will stretch out the “inline” list item to its standard size.

Any of these solutions will remove the extra space from between list items in IE6. The key is simply to pick the fix that works best with your particular design.