1 Posted by Iain on 20 April 2005 | Permalink

Apologies in advance for being the disgusting, namby-pamby fence-sitter, but I would prefer the question to be 'which is better?'
Erm, and the answer is I don't know. :) My personal inclination is towards A without repeated sub-navigation, provided the site is still accessible with the primary navigation.

2 Posted by Angus Turnbull on 20 April 2005 | Permalink

I may be biased, but I say take Diane's route with a fallback modification.

Begin with a JavaScript menu like my FreeStyle Menu (on my homepage -- please excuse self promotion, and feel free to substitute the JS menu of your choice). The important factor here is that the JS menu must use a UL/LI list in the page laid out with CSS, so it's exactly like a pure CSS menu without the :hover rules. Child menus are hidden by default.

Include the script file which activates the menu on load. The advantages here is that, coded properly, it'll run whereever JS and DOM are supported. Plus, you can use show and hide timeouts so the menus don't feel so "slippery" (something that really annoys me about pure CSS menus -- they're almost unusable unless you point with pixel precision, as they collapse as soon as your mouse pointer strays outside for a millisecond).

Finally, add a NOSCRIPT tag to your head, that contains a LINK importing a stylesheet containing the :hover rules. This means that Mozilla/Opera/Safari/etc users will get the JS menu as a first preference, and a standard CSS menu as a fallback where JS is unavailable. IE users will get the same JS menu. Other browsers and IE without JS will get just the first level menu, but to be honest with a PDA or phone that's most likely to be enough to navigate the site very effectively provided you interlink your pages well. You could always put a few more rules in your noscript sheet to expand the sublevels inline if you wanted.

Anyway, I feel that approach is the "best practice" for adding menus to a page. You get great usability and decent fallback support.

3 Posted by Vesa Piittinen on 20 April 2005 | Permalink

My answer might be E that would be choice A with a conditional commenting to JavaScript that would make Internet Explorer work. If IE7 supported :hover more widely, then the JavaScript could be limited to IE below version number 7.

4 Posted by James on 20 April 2005 | Permalink

I would vote for a pretty much PURE CSS approach but use the csshover.htc fix for IE people http://www.xs4all.nl/~peterned/csshover.html
Works wonders for me.

5 Posted by Rimantas on 20 April 2005 | Permalink

Well, drop-downs/pull-downs/foldouts on the web is bad idea to start with.
But if there is really (and I mean it) no choice left, then my vote goes for C.

6 Posted by Nelson Menezes on 20 April 2005 | Permalink

Or use IE7: http://dean.edwards.name/IE7/

7 Posted by Mark Wubben on 20 April 2005 | Permalink

I'd vote for Angus solution :) Or, you could use conditional comments to load the source for IE 5.x and IE6, but not for IE 7. Then, if it supports :hover, you're done. If not: gotta update the website.

8 Posted by Peter Siewert on 20 April 2005 | Permalink

I'll throw in a vote for Charles. I actually think Diane is wrong. If IE7 handles :hover, then a menu will be shown on mouseover and hidden on mouseout. The only difference is that both the CSS code and the javascript code will attempt to show/hide the sub-menu element. The redundant code will work, it will just do twice the work of "normal" code, however in the day and age of Ghz processors (or even MHz) this small bit of extra computation wont be noticeable to anyone.

9 Posted by John Scanlan on 20 April 2005 | Permalink

Who's right? Diane OR Charles. Their solutions provides the most general, repeatable navigation style for most browsers.

Although I'm not clear on whether something becoming a dropdown menu is a matter of behavior or presentation.

10 Posted by JD on 20 April 2005 | Permalink

I would go with option C.

Folout menus are definitely a good idea when you have lot of navigational elements. You also need to make sure that your content is accessible by search engine.

Suckerfish drop downs satisfies all requirements. The fix for IE is unobtrusive so when in future, IE support :hover, you can safely remove the onload Javascript and you have nice, accessible menus! :)

JD

11 Posted by Phil on 20 April 2005 | Permalink

Fold-out menus are a grey area for me between format and behavior. Because of this, I would prefer Charles solution, as using CSS in combination with JavaScript applies the right techs to address the ambiguity of the situation.

However, I also like Diane's, because I tend to think of this as more a behavior arena than a formatting arena, so, for me, JavaScript would probably be the best technology to address it.

And any "mainstream" site that makes life harder for IE users is asking for trouble, so I'm definitely not in favor of A for this particular site.

Basically, to sum up: Just because it CAN be done with CSS instead of script doesn't mean it SHOULD, and if your site's audience is general and mainstream, you should accommodate IE as much as you can.

12 Posted by Erik Arvidsson on 20 April 2005 | Permalink

None of the above...

...because none of these are accessible using a keyboard and using :hover for menus is a real bad way to go because menus hide too easily.

13 Posted by David on 20 April 2005 | Permalink

Adrian's suggestion is junk, because the majority of users still use IE, and anyone who wants to give the majority of their users a broken site is crazy. I hate going to sites that require me to use IE, and, if I actually prefered IE, I'd hate going to sites that required me to use something else.

Bernice's idea would work fairly well, as long as the pages are designed such that the menus don't cover anything important up when they're expanded. But most sites aren't designed like that.

Charles's idea is reasonable, as suckerfish degrades fairly well, and, as Peter Siewert points out, probably will continue to work if/when IE supports :hover.

Diane's idea discards a useful tool, out of concern of it actually being more useful in the future. Which is really bizarre logic, in my opinion. But it's certainly feasable.

So, I'd tend to stick with C.

14 Posted by Alex Lein on 20 April 2005 | Permalink

If using fold-out menus is a last resort (because I never would unless it was) then I'd go for either B or C.

B if I was in a rush, but I'd use IE specific overrides in my CSS file instead of a second file.
* html {
/* works great in IE */
}

C is probably what I'd go with if this was a major project. It's easy enough to tune in the future, and if I don't have access to the source when IE7 is out, then otehr version of IE should fail gracefully on JS, where IE7 would execute both CSS and JS commands.

15 Posted by Tom on 21 April 2005 | Permalink

Charles: Does it the proper way then brings IE along with it.

When IE finally gets :hover, support can easily be dropped, or targeted to an older version of IE.

16 Posted by copongcopong on 21 April 2005 | Permalink

C

17 Posted by Keith on 21 April 2005 | Permalink

Does your client not care about users who might want to access the web site from their web-enabled smart phone or Treo? That's my answer. :)

18 Posted by Angus Turnbull on 21 April 2005 | Permalink

@Eric: I beg to differ: a JavaScript menu can be easily keyboard accessible! Mine at least uses onfocus and onblur handlers to allow you to tab and shift+tab through the menus. Alternatively JS menus can use onkeypress event handlers to implement keyboard navigation with Tab or other custom keys... as I'm sure you're aware ;). So that's another advantage over pure CSS.

@Others: The worst-case scenario of an inactive menu is the same as the non-menu alternative: a series of normal links to site content sections. So there's little to no disadvantage in adding "extra" nested sublevels powered by JS/CSS.

19 Posted by Hungerburg on 21 April 2005 | Permalink

from experience: I once tested the way of a pure css menu with added .htc like poster #4 proposed. Pros: easy implementation. Cons: some users did not even see, that there are menus on the page at all! the menus are poorly navigable - they dont feel like the ones you get from desktop applications.

so I did e) menus were completely dropped from the design (con #1). maybe javascript menus would do away with con #2. next time this comes up, I will try d)

20 Posted by Dante on 22 April 2005 | Permalink

The choice depends on the context. If you are building a largely developer-oriented site, then A. Otherwise, I feel B is the best.

21 Posted by Jeremy French on 22 April 2005 | Permalink

d. Diane:
IMHO having a menu "pop out" is a behavioural property not a display property. Having hover on elements other than a can have many uses but I don't think popping up a menu is a good one.

22 Posted by Erik Arvidsson on 23 April 2005 | Permalink

Angus: JS menus can definately be keyboard accessible. What I'm saying is that CSS only menus (no js), using :hover cannot be keyboard accessible and the usage is really bad because there are no hide and show timers forcing the user to be really careful when moving the mouse.

A very common scenario is that the user takes /shortcuts/ with the mouse when going between menu items and menus. With a pure :hover menu system the menus are therefore hidden and the user gets confused.

23 Posted by Angus on 24 April 2005 | Permalink

Eric: Ah, we're on the same page then :). Yes, that's my feeling too -- you can implement a much more robust behaviour layer in JS, as that's really the intention of the language.

24 Posted by Steve on 26 April 2005 | Permalink

I choose D, I don't think A & B are good choices, and to argue against them not fun.

The difference between C and D is very interesting, and something I've been thinking about since I heard IE 7 is coming out before the new version of windows. I read so many cool CSS tricks built for cross-browser capability, but I get worried when they rely on IE bugs/quirks to function properly. The last one I was reading about I don't remember the particulars except it relied on IE expanding a div if it's content expanded it's boarders. I didn't use it because what if Microsoft fixes this bug with IE 7, now my whole page is squashed for 80-90% of viewers. If I write standards compliant html, with dtd, my web page should work forever.

I think some people setting themselves up for a rough time when IE 7 comes out. On the one hand, they take advantage of IE bugs to overcome browser incompatablity, but on the other hand they press MS to fix IE and make it standards compliant. What happens when IE is more standards compliant? A lot of angry fists shaken at MS when sites don't work anymore. MS can't win.

The reason I write standards compliant code is so it works across browsers. If a new version comes out and it is less compliant than the last, I have a reason to grip if my site doesn't work. If it is more compliant and my site doesn't work, I've got a hard case.

25 Posted by ppk on 27 April 2005 | Permalink

First of all, my answer is D. I've said more than once that I don't like Suckerfish Dropdowns because they divide one functionality across two layers, and I'll stick to that opinion.

The clear votes are divided as follows:
A. 1 vote; B. 1 vote; C. 8 votes; D. 5 votes

Clearly C is the option most web developers wish to follow nowadays, with D a good runner-up. Fortunately not many people go with the pure CSS solutions A and B that exclude Internet Explorer without any good reason; see also my "Three articles and one site" entry for this discussion.

John Scanlan asked the best question: Is a dropdown menu behaviour or presentation? My answer is Behaviour, because something happens when the user mouses over a menu item. All in all this was an interesting discussion.