If you’re getting started with semantic HTML coding, you’ve probably thought about using an unordered list (ul) for a list of navigation elements. Consider, for example, the navigation items on the left side of this page — they were created with just such a list (well, several consecutive list, in any case). And, it makes sense to code them that way since a group of links is fundamentally a list of related elements (which is the semantic definition of an unordered list).
There’s not much to it — or, there shouldn’t be. You’d probably start out by setting margin-left and padding-left to 0em on both the ul and the li elements with the list, in order to remove the margins and padding that browsers apply to unordered lists by default. And, the remaining step should be just a matter of setting list-style-type to “none” on your li elements.
So far, so good. You might then set anchor tags within that list to display:block. As block-level elements inherently have 100% width, this serves to widen the “click area” of each of the links to the full width of the unordered list (as opposed to merely on top of the linked words themselves).
If you tried all of that, you’d see that it works just as you thought it would: you get an unordered list without padding or bullets. Well, it works in Standards Compliant Browsers, anyway (Firefox, Safari, and so on). But IE doesn’t cooperate; rather, IE insists on applying extra padding underneath each li element. This is not a subtle side-effect — you’d know it if you saw it, as it ends up adding around 1.0em blank space underneath each li element.
This one took me a little while to debug but I did find a solution (though not a reason why this solution works). I first tried forcing margin-top/padding-top and margin-bottom/padding-bottom on the relevant list items to 0em. But, that didn’t help. On a hunch, I tried setting the list elements to display:inline — and that took care of it. IE now behaved and I also confirmed that other browsers weren’t affected (Firefox, Safari and IE/Mac still worked fine).
The only minor downside to this technique is that it technically goes against the spec. Per the spec, block level elements may contain inline elements (such as a p element containing a strong element) but inline elements aren’t allowed to contain block-level elements. And, in our scenario, the list items (which are set to inline) end up containing the anchor tags (which are set as block-level elements).
In short, here’s how some code could look for an unordered list with its inherent list attributes (padding and so on) removed:
div#secondary-nav ul,
div#secondary-nav li
{
margin-left: 0em;
margin-right: 0em;
padding-left: 0em;
padding-right: 0em;
}
div#secondary-nav li
{
list-style-type: none;
display: inline;
}
div#secondary-nav ul li a
{
display: block;
}
Well, apparently it’s too subtle for me; I don’t see the padding underneath these li’s. I’m using Win IE6SP1
What am I missing?
Jeremy: The example you mentioned — from the excellent Listutorial — doesn’t set the anchors to display:block. Setting them that way allows for a wider click-area but it causes IE to become confused (unless the fix is applied).
You’re right of course. I should have followed along making code with your discussion.
Please consider reporting this issue to PPK’s Bug Report: Bug Report.
Thanks so much for the tip! The extra padding underneath my li’s has been driving me CRAZY. I’ve forced every top and bottom margin and padding to zero throughout my CSS and couldn’t figure it out.
Thanks again!
Alex, this has been driving me insane. Thanks for the nice write-up.