« South by Southwest Web Design Awards.....brought to you by Style Master! | Main | Floated layout »

February 09, 2005


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;


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.


Would playing with the line height make any difference?


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:


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).


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

(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.


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.


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)

..)(li)Item 1(/li
..)(li)Item 2(/li
..)(li)Item 3(/li
..)(li)Item 4(/li
(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.


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.


The comments to this entry are closed.