If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

for #navbar ul I suggest using absolute instead of relative, with relative it will affect the content under the navbar.
add #navbar ul ul li and set the float to none, this is what is causing them to stack horizontally instead of vertically.

UPDATED JSFIDDLE http://jsfiddle.net/yPHPW/2/
Great, that worked however now the black background which was 100% of the width of the page is gone. How would I go about getting that back without the use of a background image?

Why are you absolute positioning the DIV... and the outer UL. <enus are usually a flow item, why are you APo'ing them? Only thing that should be getting aPo is the dropdowns.

You're using the display:none method of hiding it, which has accessibiltity issues as screen readers like JAWS won't let users get at them. I'd probably swap that out for overflow:hidden on the LI. Crazy as it sounds it works perfect. It doesn't have the accessibiltiy failings of display:none, and isn't as complicated/buggy as the "left:-999em" method.

The biggest problem is the lack of gaps means a lot of floats... the outermost container I would therein just float and set to 100% width (since you can't set float wrapping with overflow as it would break the menu.) -- again, no clue why you are absolute positioning the wrapper, unless you're doing something silly like absolute positioning the entire layout for no reason.

Oh, on 'custom buttons' you have your </a> and </li> reversed. I didn't even notice until I was testing in IE7.

I use a lot of re-declarations (see the three background-color hover sections) because the child-selector ">" isn't available on legacy IE. You throw a .htc file at it like Peterned's whatever :hover and you can have the menu work all the way back to IE 5.5 windows or 5.2 Mac.

... is wide open for easy access to the gooey bits and pieces. Also it's been tested working perfect in 6, 7, 8, 9, 10 and 11, Real Opera (12.17) and Chropera Next, and latest each of Firefox, Safari and Chrome... and it's been tested in IE 5.5 which only has a problem with the 'padding' thing being a bit off. Naturally legacy IE doesn't have rounded corners either, oh noes, not that...

I switched the fonts and padding to all EM based, so it properly dynamically scales... this could have been a problem with the top position with the PX border, but if you pad the top of the child UL equal to the border width (top and bottom) we can mix metrics. It's actually nice doing it that way as there's then a few PX of overlap with the dropdown UL, preventing IE positioning bugs from making the menu hard to use.

One issue that deathshadow's excellent code does not deal with is using dropdowns on mobiles which may not be able to trigger them! So what I've done is add the facility to toggle between hover and click activation:
- Click on an item in the top level menu, and the dropdown appears (if not already) and stays visible in click mode.
- Click on an item in the second level menu and the menu toggles back to hover activation (if not already).

One issue that deathshadow's excellent code does not deal with is using dropdowns on mobiles which may not be able to trigger them!

Which is why I'd hide the dropdowns and instead have sub-navigation on the sub-pages, which should be there ANYWAYS regardless of how you do a dropdown.

NOT that I'd have dropdowns on a site where I actually care about mobile -- MOST of the tricks for doing it just annoy the hell out of me on mobile devices -- see the train wreck of scripttard nonsense now where people are turning entire icons into battery and bandwidth wasting messes that are HARDER to use on dropdowns than just trying to use the desktop versions.

Originally Posted by jedaisoul

So what I've done is add the facility to toggle between hover and click activation:
- Click on an item in the top level menu, and the dropdown appears (if not already) and stays visible in click mode.
- Click on an item in the second level menu and the menu toggles back to hover activation (if not already).

a) The code uses PHP, so the file needs to:

Again, looks like a job for :target if there's only one level of dropdown... then you don't need a page refresh or PHP to do it.

Though again, I wouldn't bother making the dropdowns work, or even having dropdowns in the first place if I was designing for mobile.

But :target isn't supported, at least, not as far as I'm aware? And I'm trying to get away from the idea of "designing for mobile(s)". Designs should work for phones, tablets and PCs. So if you want to have dropdowns for PCs you either have to hide them for mobiles and provide alternative navigation (duplicating the code), or make it work for mobiles.

Perhaps I did not make it clear, I was envisaging a scenario where clicking on the top level did not just lock the sub-menu, it took you to the start of the relevant section. So a page refresh would be needed anyway. In this demo there are no sections to link to, so I've just linked back to the same page, to make the demo usable.

In effect, I'm simply adding hover activation (where appropriate) to an otherwise conventional click operated menu. Which, if the design spec says dropdowns are a required feature of the look-and-feel of the site, seems to me to offer the best of both worlds?

All modern browsers, and IE9/newer. Legacy versions of IE I'd make the sub-menus visible via a selector bug.

Originally Posted by jedaisoul

And I'm trying to get away from the idea of "designing for mobile(s)". Designs should work for phones, tablets and PCs. So if you want to have dropdowns for PCs you either have to hide them for mobiles and provide alternative navigation (duplicating the code), or make it work for mobiles.

Thing is, I do to -- I tend to think design for "everything" as well. By designing for everything, and designing for accessibility, I came to the conclusion that dropdown menus are bad accessibility. They don't work well for keyboard navigation, they don't work well on mobile, they don't work well for many desktop users who have bad aim unless you script their fade-out to be delayed... they can cause 'link overload' where you are presenting the user with too many options -- at which point much like a number of other design concepts I started lumping them in the "not viable for web deployment" pile.

Originally Posted by jedaisoul

Which, if the design spec says dropdowns are a required feature of the look-and-feel of the site, seems to me to offer the best of both worlds?

Honestly, someone comes to me with a "design spec" before we have document structure, semantic markup (which would say if a dropdown is warranted or not) and so forth, they'd probably be introduced to my boot, it's mass, and it's acceleration right into their crotch.

You seem to believe that function is the dominant priority, and, as a developer, that is correct. But that is an unrealistic view of the development process as a whole. Functionality is not, and never has been, an end in itself. It serves a purpose: meeting the client's business objectives. There are exceptions (informational sites spring to mind), but for many commercial sites, aesthetics play a role in the business objecives. As such, they form part of the design objectives so, naturally, precede and inform the functional design. It is as simple as that.