Welcome to WebmasterWorld Guest from

Forum Moderators: not2easy

Message Too Old, No Replies

Son of Suckerfish: Correct in Firefox, wrong in IE

Drop down is block in Firefox but inline in IE?



6:49 pm on Feb 20, 2008 (gmt 0)

10+ Year Member


I have tried to figure this out for a few days but its not working. I am using the Son of Suckerfish model for a drop down menu. The correct version should be displayed block style and that works in Firefox. However, it shows inline in IE(6). Anyone have a clue as to what's causing this? Probably real obvious.

Here is my relevant code:

#navBar {
height: 45px;
width: 799px;
margin: 10px 0 0 0;
background: url(images/nav-bar.gif) center no-repeat;

ul.navLinks {
padding: 12px 0 0 60px;

* html ul.navLinks {
padding: 27px 0 0 25px;

ul.navLinks li {
display: inline;
list-style-type: none;
position: relative;
float: left;

li.mainLink {
padding: 0px 30px 7px 30px;

ul.navLinks a {
font: 16px verdana, arial;
color: #000;
text-decoration: none;
word-spacing: 4px;
padding: 0 0 2px 0;

ul.drop {
padding: 0;
margin: 0;
list-style: none;

li ul {
display: none;
position: absolute;
padding: 0;
top: 26px;
left: 0;
background: url(images/dropback.gif) bottom left no-repeat;
border-right: solid 1px #665032;

li > ul {
top: auto;
left: auto;

li:hover ul, li.over ul {
display: block;

ul.navLinks a:hover {
font: 16px verdana, arial;
border-bottom: solid 2px #BAB658;

ul.drop a, ul.drop a:hover {
font: 12px verdana, arial;
margin: 15px 25px 15px 25px;

ul.drop li {
padding: 10px 0 5px 0;

<script type="text/javascript"><!--//--><![CDATA[//><!--

startList = function() {
if (document.all&&document.getElementById) {
navRoot = document.getElementById("nav");
for (i=0; i<navRoot.childNodes.length; i++) {
node = navRoot.childNodes[i];
if (node.nodeName=="LI") {
node.onmouseover=function() {
this.className+=" over";
node.onmouseout=function() {
this.className=this.className.replace(" over", "");


<div id="everthingWrapper">
<div id="header"><img src="images/head_03.gif"/></div>
<div id="bodyWrapper">
<!-- Begin Navigation Bar-->
<div id="navBar">
<ul id="nav" class="navLinks">
<li class="mainLink"><a href="index.htm">Home</a></li>
<li class="mainLink"><a href="poetry.htm">Poetry</a>
<ul id="nav" class="drop">
<li><a href="">Departed</a></li>
<li><a href="">Consolation</a></li>
<li><a href="">Loss of Pet</a></li>
<li class="mainLink"><a href="policies.htm">Payment and Shipping Policies</a></li>
<li class="mainLink"><a href="contact.htm">Contacts</a></li>


8:54 pm on Feb 20, 2008 (gmt 0)

5+ Year Member

I tried Son of Suckerfish too and had all kinds of alignment issues as well. I ended up switching to another css based nav system and had similar alignment issues. After much research, I believe I had to add display:inline; to the top div container class to correct the rendering issue in IE. Once the menu was displaying the same in both Firefox and IE (left aligned) I could then adjust the positioning for both easily at the same time.

Here's the top bit of my nav.css - hope it helps:

.menu {width:745px; height:22px; font-size:0.85em; position:relative; left:27px; z-index:100;/*border-right:0px solid #000;*/display:inline; }
/* hack to correct IE5.5 faulty box model */
* html .menu {width:746px; w\idth:745px; }
/* remove all the bullets, borders and padding from the default list styling */
.menu ul {padding:0;margin:0;list-style-type:none; }
.menu ul ul {width:149px;}
/* float the list to make it horizontal and a relative positon so that you can control the dropdown menu positon */
.menu li {float:left;width:149px;position:relative;}
/* style the links for the top level */
.menu a, .menu a:visited {display:block;font-size:12px; font-weight:bold; text-decoration:none; color:#7d0606; width:138px; height:20px; /*border:1px solid #000; border-width:1px 0 1px 1px;*/ background:#c58f59; padding-left:10px; line-height:19px;}
/* a hack so that IE5.5 faulty box model is corrected */
* html .menu a, * html .menu a:visited {width:149px; w\idth:138px;}


8:56 pm on Feb 20, 2008 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Hi Cienwen,

not only is it wrong in IE it's a differing "wrong" between IE6/IE7 :o

I have it fixed in 7, but can't quite narrow it for 6 yet, I'm not really a SF whizz as I prefer using other methods to get the hover functionality working for IE, but I know a lot of people use it, taking your code at face value it's quite hard to give a simple fix anyway.


li > ul
should go ;) basically every browser except IE (including 7**) needs the top/left values to be "auto" so those values should go in the main rule, then the IE values should be fed to to IE via a conditional comment
** this is one of the cases where IE7 is NOT fixed!

The way that this particular SF hack was set up is not future compatible, and this particular example shows why.. IE7 now reads that rule, but it still actually needs the older IE co-ordinates!

making that right appears to fix 7, but I tried a few things so there may be more to it. (will let you know)

I'm not sure about a definitive answer for IE6 yet.. hold that thought.. just has a lightbulb while typing this


9:52 pm on Feb 20, 2008 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

well this one is just yuk.. I finally figured out what was up with IE6, then IE7 blew up

Ok the IE6 problem is related to the fact that you're not using widths on the dropdown ul (understandable request!) so that ul is actually expanding widthways to contain all the floats - the OLD IE expanding box problem

on correcting that - I applied a width of 1% to the drop ul for versions less than 7, previously width was like min-width for IE, but as IE7 now takes that literally it has to be shown to only pre IE7.

However now I've got Peekaboo! on the first list item of the dropdown for IE7

there are other issues like the way you're spacing the links and the margins not collapsing in IE too. but those can be gotten around

the solution of display: inline on the container does not work in this case unfortunately, but thanks tygrfsh for your suggestions (and Welcome to WebmasterWorld!)

actually I have a vague recollection of this first item in list bug being unique to IE7..

Cienwen would you be able to put a width on those drop lists or do you want them "shrinkwwrapped"?


2:17 pm on Feb 21, 2008 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

OK, had to go back to one of my own posts: :hover - ghosts, gaps and peekaboo in IE7 [webmasterworld.com] to help remember the intracicies of IE7's foibles, while that post is a bit of ramble it does show that there are many different combinations layout on the <a>, <li> :hover elements which can cause weirdness - I think I have a fairly robust solution which should cover both lists with widths and those without (width is hasLayout trigger that's why it has a bearing on the combination of dropdown menu display errors) and both horizontal and vertical.

btw.. if you haven't already guessed, this is not specific to Suckerfish, so if you've been looking for another drop menu you might be seeing the same thing if you're structuring your CSS similarly. The suckerfish JS is only one method of activating the missing

functionality for
. there's a behaviour file, csshover.htc and also you can use a behaviour expression directly in the IE css file, which I have used in my testing.

The IE6 fix was as I said previously, down to expanding box problems, so a width of 1% set on the drop ul, and

white-space: nowrap
on the drop li's should fix it. That fix needs to be hidden from everyone else including IE7

IE7 simply did not like the "auto" values for the positioning co-ordinates and it didn't handle positioning the same as IE6 if top/bottom padding was used on the the li's so when I changed that I was able to use a set of co-ordinates that keeps everyone happy (top: 100%; left: 0;} this meant that no filter was needed for IE and that the drops can be offset top and let using margins instead. The fix was to use line-height instead of top./bottom padding although that subsequently got fixed using the aforementioned co-ordinate system... round robin ;) so you can use line-height or padding whatever your preference.

The rest was based on just knowing something might happen, like ghosts, and that disappearing first item and I just put in the things I know to be fixes even though I can't always remember why..

e.g. putting

position: relative
on the
instead of the
, also putting *ANY* hasLayout triggering property that is on the initially hidden
onto the
li:hover ul
rule instead.

the 'ghosts' usually only appear after more complex (3 level) drops so that is not not vital in your case. Note that with your widthless lists menu you couldn't really have another drop level (you would need to give your ul/li's width for that) - you'll see from the colors : but I think it's best to get used to this foible and make it a habit thing to look for as we will be dealing with IE7 for quite a while! - anyway this time I think I've documented this well enough to cover most scenarios

If you take the CSS below, all comments are in the CSS, it includes more or less every possibility that could occur, so while some of the CSS may be unnecessary for you - I've tried to put in a comment as to why it's there. It may be that your particular menu doesn't need all of these points addressed but it *shouldn't* do any harm to leave them.. let me know if it does

I removed the classes and used selector specificity instead as that can be easier to follow and should apply to anyone's menu so even if you do want to add the classes try to keep the element count in the selector the same for specificity reasons

<style type="text/css" media="screen">
#nav {
height: 45px; /* setting line-height of the first #nav ul to same as this ensures it fills the height without guessing at padding */
width: 799px;
margin: 10px 0 0 0;
background: #dad; /* purple */
font-family: verdana, arial, sans-serif;

/* use line-height instead of top/bottom padding, avoided parts of the IE positioning problem */
/* however using the positioning co-ordinates as now shown below now negates this, and padding could optionally be used */
#nav ul {list-style: none; margin: 0; padding: 0 20px 0 60px; line-height: 45px;}
#nav ul ul {padding: 0; line-height: 1.8em; background: #ff0;}

#nav ul li {
background: #abc; /* blue */
float: left;
padding: 0 30px; /* pad left/right the list item for spacing between links */
font-size: 16px;

#nav ul li li {
background: #ffe; /* pale yellow */
padding: 0 15px; /* pad left/right the list item for spacing at sides of links */
white-space: nowrap; /* forces link text not to wrap for IE6's width problem */
font-size: 12px;

#nav ul li a {
color: #000;
text-decoration: none;
padding-bottom: 4px; /* make this = to the padding+border value of the hover state below to avoid jumpy links */

#nav ul li a:hover {
border-bottom: 2px solid #777;
padding-bottom: 2px;

#nav ul ul {
display: none;
padding: 0;
border-right: solid 1px #665032;
/* if IE 7 has auto values it displays inline! */
/* using the percent method takes care of both line-height and padding used for height */
top: 100%; /* using this value means IE doesn't need separate values */
left: 0; /* using this value means IE doesn't need separate values */
margin-top: -5px; /* optional - adjust this to create any overlap required */
margin-left: 30px; /* optional - adjust this to create any left offset, can be negative too */

IE prefers an :hover rule before extending that rule to a child of a hover
and because we only need the hovered list positioned I put the relative position rule in here
to satisfy that quirk, although putting the position in here with a z-index value also helps
bring drops atop other drops - (again IE) but should do no harm
#nav ul li:hover,
#nav ul li.over {
position: relative;
z-index: 1;

#nav ul li:hover ul,
#nav ul li.over ul {
display: block;
position: absolute;
/* IE has problems with hasLayout if a trigger (which AP is) is on the main rule I think that's why I was seeing disappearing menu items but anyway it causes "ghosts" so it's best here */
/* if you had a width on the ul it would also need to go in here, because it too is a hasLayout trigger */

#nav ul li:hover ul li:hover ul,
#nav ul li.over ul li.over ul {display: block; }

<!--[if lte IE 6]>
<style type="text/css" media="screen">

/* for IE5/6 only*/
#nav ul ul {
width: 1%; /* width needs to be restrained *if* there is no width specified, to compensate for expanding box
this was the equivalent of min-width previously
though if using this because there is no real width on the ul in the main code, you will likely need white-space: nowrap; set on the child li's

/* quick IE hover code or put script in below */
#nav li {
behavior: expression(
this.onmouseover = new Function("this.className += ' over'"),
this.onmouseout = new Function("this.className = this.className.replace(' over','')"),
this.style.behavior = null

<!--<script> would go in here</script>-->

This based on your HTML (without the classes) and is centered on you not wanting widths.. if you try it and change to widths.. let me know what happens I'm going to try and see if this can be templated in a copy/paste way.



7:33 pm on Feb 21, 2008 (gmt 0)

10+ Year Member

Oh my stinkin' goodness!

You are amazing! The amount of time you have put into this is just so above and beyond what I was expecting. I soooooo appreciate what you have done with this.

Thank you so much!

I have no problem throwing some widths into my CSS. In fact I added a width to the ul.drop and that fixed everything. It even took care of a little weirdness in Opera.

But, the widthless options you have proposed here are very interesting. When I have a little free time I'm going to play with that for another project. I'm going to copy and paste this discussion into a Word Doc and save it forever as a reference!

Just out of curiosity, I am very interested in the non-Javascript :hover correction. Has it been your experience that one method is better than another?

Thank you again.


8:47 pm on Feb 23, 2008 (gmt 0)

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

You're welcome, your question came at the time I was already looking into some other IE7 foibles with drop menus so the research I was able to with a real world example, your widthless variation, gave me something else to test ;)

I am very interested in the non-Javascript :hover correction. Has it been your experience that one method is better than another?

all methods actually rely on javascript to work, put I prefer using the csshover.htc behaviour file [whatever:hover] [xs4all.nl] - (Version 1.42.060206 (:hover and :active))

using that you do not need to add extra classes to your CSS (e.g. the .sfhover or .over) you code the CSS how it should be (well nearly because we can't yet use child selectors).. you upload the file to the same directory as your CSS file and simply add

body { behavior:url("csshover.htc");}

to the IE6 conditional or in an IE specific stylesheet, I just like it because it keeps the main CSS clutter free and files IE6 away ;) Also as it applies the :hover functionality to everything not just a list with a single ID (like SF) you can have more than one hover effect on the page. NOTE: IE's behaviours still require javascript in order to work so preference would be whatever you're comfy with I guess.



12:59 pm on Feb 24, 2008 (gmt 0)

5+ Year Member

All of the above IE stuff aside, I found while dicking with Suckerfish that if I didn't set a width (I was playing with someone else's version and he only had some padding: 0 .5em on the first li), I too had the subs displayed inline instead of block. Crusty Old Guy got around this by saying that the sub li's are float: none

#nav li li {

While setting a width somehow meant I didn't have to specifically say float: none. Sometimes you just can't get away with using a width on the li, esp with text that goes from "aansprakelijkheidsverzekeringen" to "contact" : ) Luckily, the width: 1%; works because IE6 lets content expand heights and widths of things : )

[edited by: Stomme_poes at 1:01 pm (utc) on Feb. 24, 2008]


Featured Threads

Hot Threads This Week

Hot Threads This Month