The most mysterious IE6 bug.......ever

I've spent the larger part of the day tweaking a collection of navbars that ultimately get used for the navbar wizard in Style Master. For this new version I wanted to add a few new ones, as well as fix up a few issues with the existing ones. We've got two types of navbars, horizontal and vertical. It's with the vertical navbars that I have found the weirdest and most inexplicable bug I have ever seen in IE6. And gee whiz, as everyone knows, that's a long and distinguished list.

The HTML for all the navbars is a beautiful, semantically correct list:

<div id="navbar">
	<ul>
		<li><a href="#" class="current">home</a></li>
		<li><a href="#">products</a></li>
		<li><a href="#">services</a></li>
		<li><a href="#">about us</a></li>
		<li><a href="#">contact</a></li>
	</ul>
</div>

To take care of any potential quirks mode issues, I've also included an XHTML Strict Doctype.

A problem of extra space between the list items in the vertical navbars became apparant in IE6. I put 0 margins and paddings on everything: no joy. That 1 pixel space stayed put. So, I went back to my inspiration at Listamatic and did a compare and contrast, because the navbars there were not showing this problem. The only difference I could find was that at Listamatic the font-family property was being applied to #navbar, while I was applying it to #navbar ul, something which should make no difference whatsoever to anything in this situation.

Me

#navbar {
width: 175px;
font-weight: bold;
}
#navbar ul {
margin: 0px;
padding: 0px;
list-style-type: none;
font-family: Verdana, Helvetica, Arial, sans-serif;
}

Check this out in IE6 - mind the gap!

Listamatic

#navbar {
width: 175px;
font-family: Verdana, Helvetica, Arial, sans-serif;
font-weight: bold;
}
#navbar ul {
margin: 0px;
padding: 0px;
list-style-type: none;
}

Check this out in IE6 - gap gone

And sure enough, when I changed the CSS to be like listamatic, the 1 pixel gap disappeared and all was right with the world.

Now, for mine, that's mysterious and weird enough. However, I've since discovred that it is even more particualr. It only happens when you specify font-family using sans-serif fonts. That's right. If you specify instead using a standard collection of serif fonts, there is no gap.

For example

#navbar ul {
margin: 0px;
padding: 0px;
list-style-type: none;
font-family: Times, "Times New Roman", serif;
}

Check this out in IE6 - gap not there now either, even though it should be because font-family is being applied to #navbar ul not #navbar.

The moral is computers are evil: never dismiss any avenue of investigation as too ridiculous when trying to track down a pesky extra pixel gap problem in IE6.

Comments

[Jens Brueckmann]

This is really weird.
I tested this on IE6 and found that the gap seems to be font-dependent.
Using Arial or only the generic font-family sans-serif no gap appears.
If however, Verdana or Tahoma is chosen, the gap is there.

By the way, should the last example not read

#navbar ul {
font-family: Times, "Times New Roman", serif;
margin: 0px;
padding: 0px;
list-style-type: none;
}

[Maxine]

Thanks for checking that out for me Jens - I had a feeling that's how it would pan out. So, it's even more specific: if you're having problem with a mysterious gap in IE6 in a navbar, check to see if you're using Verdana or Tahoma anywhere.
Oh, and yes, thx for picking up on the error - fixed now.

[Olly]

Would playing with the line height make any difference?

[Philippe]

It can be even more fun with Japanese.... Include first a Mac font, and then a Windoze fonts, and that 'browser' goes beserk. Do the opposite, and it falls back into place.
(note, I haven't tested with your particular setup, just noticed the same maddening behaviour in nearly similar situations.)

[Jens Brueckmann]

"Would playing with the line height make any difference?"

The gap disappears when the following values for line-height are used:

Tahoma: >= 1.1em
Verdana: >= 1.04em

[Brett Merkey]

I've found lots more like this. Yes, all bizarre. The key factor is putting IE6 into strict mode with doctype switching. For that reason, I avoid strict mode when I can. For x-browser coding, it is still possible to keep other browsers to strict while killing that mode for IE.

[Ron Pringle]

I would hazard a guess that this is probably another example of a browser rounding error. You don't say what unit of measure you use for the font size, but I'm going to guess its ems or percentage.

It'd be interesting to see a methodical test of this issue using various units of measurement for fonts, line-height, etc.

I've discovered some rounding error induced funkiness with table captions as well. My test page for that is:
http://www.aurora-il.org/testsite/table_test.htm

[Björn]

Hmm. Could you perhaps make screenshots and post them? Pretty please?

I am behind a computer with Win98 right now, and looking at those pages with IE6 doesn't look any different from K-Meleon (which uses the gecko engine).

[Tom]

I think I know this one, try putting all the LI tags on the same line.

So:
(li)products(/li)
(li)services(/li)
(li)about us(/li)

Would be:

(li)products(/li)(li)services(/li)(li)about us(/li)

For long lists you might end up with really long unreadable lines but hey it worked for me, oh and sorry for the () your comment form was throwing all sorts of errors at me. eek!

[Chris Hester]

Opera 7 shows a gap on all tests here, but only under the first list item, which is also a different shade of green.

I found with the Listamatic demos, they also need the space between list items in the HTML taking out to work in Opera.

[Alex]

Another means around this, when setting anchor tags within list items to display:block, is to set the list items to display:inline (and you may also need position:relative on the unordered list's parent element).

[Andrew K]

This is a hasLayout bug. Applying the Holly hack to the list items will also solve it, regardless of font choice.

[dclayton]

The HTML specification is fundamentally flawed with how it treats whitespace, and IE has its own share of problems. When I want my html code to be indented, but not contain parseable whitespace, I use the following trick: (due to formatting limitations of this blog, the periods represent space characters, and the parentheses represent brackets - I apologize, I know this is hard to read, but this blog is limited)

(ul
..)(li)Item 1(/li
..)(li)Item 2(/li
..)(li)Item 3(/li
..)(li)Item 4(/li
)(/ul)
(p)I don't want my (a title="Extremely Long Tags"
)Extremely Long Tags(/a) to have parseable whitespace in them when I
split them amongst lines.(/p)

This has the advantage of allowing you to keep your indentations without introducing parseable whitespace into the tagged content.

[tshirts]

It’s as though game-designers are making these things up, putting in little backdoor cheats and odd characters that can only be accessed if you type in the right code. Perhaps if we search long enough we’ll discover that a secret Bill Gates has been encoded that pops up if you set things up just right, sticks his tongue out at you and says in a quite impish voice: “ha ha, tricked you into buying it again, didn’t I?” Which is a humorous way of saying, why do we let MS tie us into knots as we do? Yes, I know all browsers have bugs, but IE has many more than most. And yes, I know it’s used by the majority of the general public, making it seem as though we must take it into account if we are going to satisfy that public, but what would happen if every programmer decided to simply ignore IE because of its renowned temperamental nature? I for one, would be interested to see.

[Eric O'Brien]

I will note that as of September 2007, Using IE 7, or the Nightly Build of WebKit, this is still broken. A carriage return IN THE CODE (between list items) is still RENDERED in browsers as a space!

Often, this will not be noticed. Unless, perhaps, you happen to be using lists as display: inline, for horizontal navigation menus, perhaps. Umm?

Good Grief! Is there anybody out there testing this stuff, or are you all working 9 to 5?

I will note that the wacky, ugly suggestion [no offense intended] from "Andrew K" DOES work.

Sheesh.