Help on a CSS drop down menu to suit this site

I am currently developing the following site http://positivepsychologytraining.co.uk/

I am wanting to put a simple CSS drop down menu for the ‘Positive Psychology’ and ‘Services’ links and to keep with the style of of the current menu I want the drop down menus just to be a box below its respective link (either ‘Positive Psychology’ and ‘Services’). Though I have become a bit stuck and just can’t get any existing menu or one I try to make cross browser compatible (i.e. IE 6 & 7!). Any help would be appreciated.

Thanks,
Aaron.

Jason, your gonna have to relax at some point and realize that demos are not final drafts. They are just examples to get started by.

  1. don’t use EM on a menu over a fixed width header - it just breaks when large fonts auto-enlarges it…
    I was using the OP’s font-settings and the menu sits in the wrapper between the header and the content on the original page.
  1. 1.3 what? Yes, it DOES make a difference since it changes FF’s rounding.
    When a unit is not set it just becomes a simple multiplier that can be inherited without any problems. That has been explained to you before. If you set it in ems you open up a can of worms with scaling problems. I don’t use px font sizes either.
  1. don’t waste his time throwing CSS3 at it since that’s not real world deployable yet and has NO *** business on a production website.
    That is the OP’s code too, no need to point fingers at rayzur. Besides that, your not going to stop the www from using it so save yourself from the stress it gives you.
  1. ALWAYS declare a line-height when you change size on body, even when that size is default. Default line-height CANNOT be trusted cross-browser. (since the specification doesn’t even SAY)
    Yeah, I hear you on that. In a final working site I would have that addressed. I’m not always going to have a full blown launch ready stylesheet on a simple demo.
  1. Include at least ‘normal’ when condensed or IE will screw up font size inheritance.
    Same as above
  1. Might as well use a reset - does he have a reset on the original?
  1. Position:relative on the outermost UL will fix many of FF’s inline-block issues.
    It won’t fix the AP child bug for FF2, that has been documented and the suggested workaround is a mess.
  1. the float on the anchor is needlessly complicating matters.
    The floated anchor works fine when the LI is set as Inline-block, it cascades down to the sub li and kills IE whitespace bugs.
  1. It’s a menu, should it really have a :visited state? Should the keyboard state REALLY be different from the hover state?
    Feel free to give your thoughts on how it should be.
  1. margins on the LI are collapsing in some browsers but not others - this is why you use PADDING instead.
    No, I have told you before that paddings are not a substitute for margins. We both know that padding is placed on the inside and margins create space on the outside. When you want space on the outside you need to use margins.

If your talking about IE6/7 that is because they do not have native support for inline block and there are no whitespace nodes present .

Be specific about which browsers are different since I don’t see anything collapsing, I have no vertical margins anyway.

Oh, cute trick though to make all browsers position the &raquo consistently, never seen that one before though I personally wouldn’t bother with an indicator (or if I did it would be image based)
Yeah, it’s a demo. I would use an image too on a working site. :slight_smile:

Except it doesn’t work right in IE6 going back to default line-height, and WORSE exacerbates the problems with gecko’s already half-assed rounding methods. (So instead of 1 to 2px difference, you get 3-5px - JOY!)… Taking the time to add two characters to say “EM” isn’t going to kill you. (though I like to keep my metrics the same, so if I say % font-size, I say % line-height for simplicity sake)

That and I THINK it also ends up working as PX in IE5, and only IE’s minimum height of an element being the font-size stops that from completely shtupping the page - though really who gives a flying fig about IE5 at this point.

Though the question becomes WHICH IE5… Kind of like IE6 on Win98 and IE6 on XP having radically different behaviors. (go consistency!)

They do - on inline-level elements, though that’s just exploiting an IE bug - as all inline-level elements have inline-block’s behavior in the first place. This is why the hack to fix the behavior in IE7/earlier is to declare display:inline on it.

Opera and IE8, you’re only getting collapsed margin and not full, incorrect behavior for the floats.

Or you pad the parent, or a wrapping element you are not/should not be applying visual styling to in the first place… like say, an LI

The thing is I don’t see any of these problems you mention and I suspect it is because you are a 120dpi user.

This goes back to our debate about the sticky footers. You do bring up a good point though and I am hearing you. :wink:

So tell me this, what percentage of users would you say are at 120dpi

Quite possibly.

Well, given the number of people over on MSDN who were *****ing about IE8’s ‘new’ handling of the DPI setting I’d say a decent number. (You can make it revert to the old ‘only make text bigger’ behavior).

That with Vista they stopped hiding it under advanced and moved it to where it can easily be accessed, and made it even more prominent in Win7… (Personalize > display, what’s the FIRST thing it shows you?) Add in more and more displays shoving 1920+ width at 24" or smaller I certainly wouldn’t be surprised if it were up to 10% or more. I’m really looking forward to the proposed next-gen resolution jump, increasing the current desktop screen resolutions 50% or more - no more jaggies, even sharper text at smaller sizes, and legacy support through Win7’s new application level DPI scaling. Crank Win7 up to 150% or more to see what I mean. It’s great for turning Win7 into a ‘ten foot UI’ on a 1080p 40" screen without any extra UI changes.

Be a fun thing to pull some usage stats for… but in any case it’s something one should test; which is another reason I test legacy IE, Opera and FF inside VirtualBox - my host Win7 is set to 120dpi (win7 calls that medium now, 150%/144dpi is the new ‘large fonts’)

M$ is really gearing up support of actually setting the physical DPI or increasing it for comfort use. I know I certainly enjoy it since I can sit back at a comfortable three feet instead of pressing my nose right up to my screens.

Rayzur –

  1. don’t use EM on a menu over a fixed width header - it just breaks when large fonts auto-enlarges it…

  2. 1.3 what? Yes, it DOES make a difference since it changes FF’s rounding.

  3. don’t waste his time throwing CSS3 at it since that’s not real world deployable yet and has NO *** business on a production website.

  4. ALWAYS declare a line-height when you change size on body, even when that size is default. Default line-height CANNOT be trusted cross-browser. (since the specification doesn’t even SAY)

  5. Include at least ‘normal’ when condensed or IE will screw up font size inheritance.

  6. Might as well use a reset - does he have a reset on the original?

  7. Position:relative on the outermost UL will fix many of FF’s inline-block issues.

  8. the float on the anchor is needlessly complicating matters.

  9. It’s a menu, should it really have a :visited state? Should the keyboard state REALLY be different from the hover state?

  10. margins on the LI are collapsing in some browsers but not others - this is why you use PADDING instead.

Oh, cute trick though to make all browsers position the &raquo consistently, never seen that one before though I personally wouldn’t bother with an indicator (or if I did it would be image based)

Let’s see… if I were to do that I’d axe the sfHover nonsense as there’s no sense sending 1k of crap hidden behind conditional comments sent to EVERYONE when less than 15% of people need it… so PeterNed’s csshover3.htc gets the nod. You lose the floats most of the firefox fixes aren’t needed, even for FF2… ESPECIALLY if you use ‘left’ instead of ‘margin-left’ - I’ve been seeing a LOT of people doing that lately - is there some reason for it apart from “let’s make it MORE complicated”? We’d need the display state change so IE7 doesn’t ‘stick’ open in one state… position:relative on the topmost menu item should prevent needing to screw with z-index… and we’d probably need a 1k or smaller image to do away with the CSS3 nonsense so it’s real world deployable.

@Aaron:

My approach do doing a menu like that comes out something like this:
http://www.cutcodedown.com/for_others/aaron118/tempate.html

as with all my examples the directory:
http://www.cutcodedown.com/for_others/aaron118

is unlocked so you can grab the gooey bits and pieces. Valid XHTML 1.0 Strict, would be valid CSS 2.1 if not for the browser specific values, tested working just fine in IE 6, 7 & 8, Opera 9.6 and 10.53, Firefox 2 and 3.6 and the latest flavors each of safari and chrome.

Uses csshover3.htc for the hover states in IE.
http://www.xs4all.nl/~peterned/csshover.html

… and is even usable all the way back to IE 5.x (though the incorrect padding behavior makes the menu items offset/incorrectly placed, it’s still functional).

Uses a sliding doors type effect for the hover backgrounds (hence the extra span) using a single 627 byte image.
http://www.cutcodedown.com/for_others/aaron118/images/mainMenu.png

Oh, and I remastered the body background image shaving 700 bytes off it.
http://www.cutcodedown.com/for_others/aaron118/images/bodyBackground.png

Meaning on image sizes it breaks even. Gains a bit of markup and a whole bunch of CSS, but small price to have it work in the most recent RECOMMENDATION version of the specification instead of the not ready for primetime DRAFT CSS3.

Though admittedly the CSS used for the image backgrounds and hover states for them is one big specificity mess.

Nice and thx again from me! :slight_smile:

@ChrisXPPro,
Glad you found it helpful :slight_smile:
It’s a shame about the FF2 AP bug, but I don’t think that would be enough to keep me from using Inline-Block. FF users are well known for staying upgraded.

@aaron118,
I went ahead and polished up that “rough version” I posted above. I got the IE6/7 Inline-Block fixes and IE6 Hover Script in place.

Inline-Block Dropdown

Hope that helps! :wink:

Rayzur … some most useful bits of info - thx from me.

Hi Aaron,

The concept behind a dropdown is pretty simple in and of itself. It just involves nesting a UL in the respective list item that gets the sublist.

[URL=“http://www.css-lab.com/demos/navbar/easy-dropdown.html”]Simple Dropdown Navbar

In your case the html would look like this -

<ul id="nav-menu">
    <li><a href="index.html">Home</a></li>
    <li><a href="about.html">About</a></li>
    [B]<li>[/B]<a href="#">Positive Psychology</a>
        [B]<ul>[/B]
            <li><a href="#">Drop1</a></li>
            <li><a href="#">Drop2</a></li>
            <li><a href="#">Drop3</a></li>
        [B]</ul>[/B]
    [B]</li>[/B]
    [B]<li>[/B]<a href="#">Services</a>
        [B]<ul>[/B]
            <li><a href="#">Drop1</a></li>
            <li><a href="#">Drop2</a></li>
            <li><a href="#">Drop3</a></li>
        [B]</ul>[/B]    
    [B]</li>[/B]
    <li><a href="courses.html">Courses &amp; Workshops</a></li>
    <li><a href="resources.html">Resources</a></li>
    <li><a href="publications.html">Publications</a></li>
    <li><a href="contact.html">Contact</a></li>
</ul>

Now things get a little trickier and this is where the CSS comes in to hide and reveal the sub UL on hover. That is done by using li:hover on the parent list items which in turn poses a problem for IE6 since it only supports a:hover. We will get into that later.

As for hiding the sub UL with the CSS that is best done by setting the sub UL as position:absolute then hiding it with a large negative margin. Then it is revelaed by setting margin:0 on the parent li:hover ul


/* ------ Sub UL Drop Down ------ */
#nav-menu ul {
    position:absolute;
    width:180px;
    left:0;
    top:100&#37;;
    [B]margin-left:-999em;/* hide the sub ul */[/B]
    background:#CCC;
    text-align:left; 
}
#nav-menu ul li,
#nav-menu ul li a {
    float:left;
    width:172px;
    margin:0;
    padding:2px 4px; 
}
#nav-menu li:hover ul {
    [B]margin-left:0;/* reveal the sub ul on li:hover */[/B]
}

You bring it all together and it would look something like the code below. I used display:inline-block on the parent LI but it will cause some problems cross browser. I did something like this once before and FF2 chokes on it, probably not a big concern these days though.

Here is a rough version -


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Simple Dropnav</title>

<style type="text/css">
body {
    font-family: Arial, Helvetica, sans-serif;
    font-size: 85%;
    color: #000;
}
ul {
    margin:0;
    padding:0;
    list-style: none;
}
ul#nav-menu { 
    font-family:Arial, Georgia, "Times New Roman", Times, serif; 
    font-size: 1.2em;
    text-align: center;
}
#nav-menu li {  
    margin: 0 6px;
    display: inline-block;/*needs X-browser fix*/
    position: relative;
}
#nav-menu li a {
    float:left;
    padding:2px 4px; 
}

#nav-menu li:hover { background: #bedced; }

#nav-menu li:hover,
#nav-menu ul { -webkit-border-radius: 5px; -moz-border-radius: 5px; border-radius: 5px; }

#nav-menu a:link,
#nav-menu a:visited,
#nav-menu a:active { 
    text-decoration: none; 
    color: #000; 
    padding: 4px; 
}
/* ------ Sub UL Drop Down ------ */
#nav-menu ul {
    position:absolute;
    width:180px;
    left:0;
    top:100%;
    margin-left:-999em;/* hide the sub ul */
    background:#CCC;
    text-align:left; 
}
#nav-menu ul li,
#nav-menu ul li a {
    float:left;
    width:172px;
    margin:0;
    padding:2px 4px; 
}
#nav-menu li:hover ul {
    margin-left:0;/* reveal the sub ul on li:hover */
}

</style>
</head>
<body>

<ul id="nav-menu">
    <li><a href="index.html">Home</a></li>
    <li><a href="about.html">About</a></li>
    <li><a href="#">Positive Psychology</a>
        <ul>
            <li><a href="#">Drop1</a></li>
            <li><a href="#">Drop2</a></li>
            <li><a href="#">Drop3</a></li>
        </ul>
    </li>
    <li><a href="#">Services</a>
        <ul>
            <li><a href="#">Drop1</a></li>
            <li><a href="#">Drop2</a></li>
            <li><a href="#">Drop3</a></li>
        </ul>    
    </li>
    <li><a href="courses.html">Courses &amp; Workshops</a></li>
    <li><a href="resources.html">Resources</a></li>
    <li><a href="publications.html">Publications</a></li>
    <li><a href="contact.html">Contact</a></li>
</ul>

</body>
</html>

What I am seeing from the site that you linked to is that your main list items are centered. You have them centered via text-align:center on the UL with display:inline; on your LI.

There is another way of centering the LI by using centered widthless floats.
http://www.pmob.co.uk/pob/centred-float.htm

That is probably the best way to do it if you want full cross browser support. Each method will have it’s pros and cons though.

Here is another dropdown using that centered float method with the IE6 sfhover script in place. As far as I know it works fine in all browsers.
http://www.css-lab.com/demos/navbar/cntr-float-drpdwn.html