Dropdowns (horizontal) or flyout (vertical) menus abound on websites and come in many different flavours. They are also put together in a number of different ways, some done with javascript, some with ‘pure’ CSS and some a mixture of both.
They also have varying degrees of usability and accessibility. Some are completely inaccessible to those who can’t use a mouse (i.e., use their keyboard to navigate), for some only the top level menu items are accessible and others give you keyboard access to the whole menu.
Then there are ones that either won’t work at all or provide limited functionality if javascript is disabled.
So which is the ideal dropdown menu system to use on your website and why?
In an attempt to answer this question, I’ve put together a list of some of the menu systems I’ve come across and made some comments as to their different features. I only say ‘attempt’ because I don’t actually believe there exists a dropdown menu that doesn’t fall down in some way, that won’t restrict a certain section of users under certain conditions.
I’m mainly concerned with the menus usability, so the criteria I’ve used to assess them are:
- Semantic code – no unnecessary markup. By this I mean that, from a semantic point of view, extra markup required to achieve functionality has nothing really to do with describing the content.
- Keyboard accessibility – being able to access the submenu items without a mouse.
- Will work with javascript disabled.
Although in some cases I’ve highlighted things like code weight, ease of implementation and price, in most cases they don’t affect a user’s experience, so those factors don’t really have a bearing on my personal view that the ‘perfect’ dropdown doesn’t really exist.
If anyone has examples of other dropdown menus that they know of, feel free to mention them in the comments.
Also, please note that the number of ‘pros’ or ‘cons’ listed with each menu does not constitute a rating of how good the menu is or how it compares with the other menus on the list. Neither does the order in which they appear below. The only determining factor affecting the order really is that the free ones are first, followed by the semi-free ones and the paid ones last.
While this article may appear to advocate some menus over the others, my aim was more to present a list of options alongside a checklist of the sort of things you should look for when choosing a menu. The rest, of course, is up to you and I hope people will take the time to check out the examples and read a bit about them before making a choice.
-
Sons of Suckerfish
Originally published on A List Apart, and then updated on HTML Dog, Suckerfish dropdowns are widely used, due in part to their relatively easy implementation.
Pros
- Free.
- No unnecessary markup.
- Dropdowns work if javascript is disabled*.
- Easy to set up and customise.
- Commonly used so if you run into trouble, you’ll find lots of people able to help with problems.
Cons
- Submenu items are inaccessible to keyboard-only users.
- *The dropdowns also won’t work in IE<=6 with javascript disabled due to their inability to handle
:hoveron non-pseudo elements.
-
PIE’s Deluxe CSS Dropdowns and Flyouts
This is similar to the Suckerfish menu but introduces
“sticky hovering zones”
which ensure that the submenus stay open when moving between different levels (something which can sometimes be an issue with the Suckerfish menu). The trade-off is more (and from the point of view of pure semantics) unnecessary markup and slightly more complex CSS.Pros
- Free.
- Dropdowns work if javascript is disabled*.
- Better ‘stickiness’ of menus (submenus won’t disappear before you have time to mouse over them).
Cons
- Unnecessary markup.
- *The same problems that affect Suckerfish with regards keyboard access and javascript being disabled apply here too. This menu does provide a better
noscriptfallback than Suckerfish though – all submenus become expanded in IE<=6/Win and IE5/Mac which depending on the complexity of your menu, may not actually be desirable.
-
Keyboard Accessible Suckerfish
As pointed out by Helena Boylen in the comments, Matthew Carroll has developed a modification of the Suckerfish menu which makes the submenus keyboard accessible.
With javascript off, standards compliant browsers still have keyboard access to the submenus, but only the currently focused menu item and any sub-menu beneath it are shown. IE7 will let you tab through the submenu items, but there are no visual cues as with other modern browsers.
IE<=6 still behaves the same as the original Suckerfish.
Pros
- Free.
- No unnecessary markup.
- Dropdowns work in non-IE browsers if javascript is disabled.
- Submenu items are keyboard accessible.
- Easy to set up and customise.
Cons
- Very slight display discrepancy in most modern browsers if javascript is off.
- The dropdowns won’t work in IE<=6 with javascript disabled.
-
Sons of Ursidae
Another variant of the Suckerfish menu whose main point of difference appears to be that you can easily switch from a horizontal to a vertical menu by just un/commenting a small set of the rules (rather than having to write a lot of new code as in the original Suckerfish). Also, by removing the width from the <ul> and <li> elements you can have different widths for the top level items without needing to attach classes or IDs to them.
Keyboard access of the submenus is only available in Mozilla and Firefox and IE5.5 up to 7 and when tabbing through the menus, they become separated from their parent menu item which makes it a bit confusing to work out where you are in the menu.
Pros
- Free.
- No unnecessary markup.
- Dropdowns work in non-IE browsers if javascript is disabled.
- Easy to switch between horizontal and vertical menus.
- Easily create different width menus.
Cons
- Submenus only keyboard accessible (with some limitations) in Firefox, Mozilla and IE5.5-7.
- The dropdowns won’t work in IE<=6 with javascript disabled.
-
FatFish
Alexander Farkas has come up with another keyboard accessible Suckerfish variant which uses jQuery for some added javascript effects like fading in and out.
The menu also works for both mouse and keyboard with javascript off in modern browsers. Using the keyboard, only the submenu item you’re currently on is displayed on screen when javascript is off, rather than the whole submenu being shown. This can make it a bit difficult to tell exactly what level you’re at as the links are separated from their parental context, but it’s better than no on-screen display at all.
The menu also works in IE6 for keyboard users with javascript off in the same way and there is an alternative fallback for IE6 which lets you expand the submenu fully on screen instead.
Alexander is German so the description of the menu in English is quite brief (the German version is more comprehensive) and there were a couple of things I was unsure about, like why each submenu item has
<span class="sbh">. </span>in the code (which is hidden from the screen).Pros
- Free.
- Dropdowns work if javascript is disabled.
- Submenu items are keyboard accessible.
- Easy to implement.
Cons
- Display of submenu items for keyboard users when javascript is off could be a bit confusing.
- Some additional (perhaps unnecessary) markup.
- The majority of the description and comments are in German.
-
Superfish
Another menu that combines jQuery with Suckerfish, Superfish by Joel Birch, currently at version 1.3.3, features time delay on mouseout to be more forgiving of mouse-piloting errors, animation of submenus and is keyboard accessible (when javascript is enabled).
The examples include horizontal and vertical variants and a horizontal menu with horiztonal submenus. There’s also a built-in fix for the dropdowns falling over select elements in IE6 and the ability to have the submenus that show the path to your current page remain open while the menu is idle.
Pros
- Free.
- Dropdowns work if javascript is disabled (except in IE<=6).
- Submenu items are keyboard accessible.
- Easy to implement.
Cons
- Submenu items aren’t displayed on screen when tabbed into with javascript off.
- The dropdowns won’t work in IE<=6 with javascript disabled.
-
Project VII CSS Express Drop-Down Menus
Project VII provide this free menu on their site which has pretty much the same functionality as the Suckerfish menu.
See below for commercial examples with better keyboard accessibility features.
Pros
- Free.
- No unnecessary markup.
- Dropdowns work if javascript is disabled*.
- Easy to set up and customise.
Cons
- Submenu items are inaccessible to keyboard-only users.
- *The dropdowns also won’t work in IE<=6 with javascript disabled due to their inability to handle
:hoveron non-pseudo elements.
-
CSS Play dropdowns
Stu Nicholls has worked on numerous examples of his CSS-only menus over the last year or so (the most recent one linked above). Their main advantage is that they require no javascript to work in IE<=6 which means that these dropdowns will always function when javascript is disabled.
The downside is that to do so, the HTML makes use of IE conditional comments and table tags. The dropdowns are also not keyboard accessible.
Pros
- You don’t have to pay for it, although permission must be obtained for commercial use and a donation is welcomed.
- A variety of different configurations.
- Dropdowns work if javascript is disabled.*
Cons
- Unnecessary markup.
- *Although no javascript is required, a mix of IE conditional comments and table tags is.
- Submenu items are inaccessible to keyboard-only users.
-
FreeStyle Menus
As pointed out by John Lascurettes in the comments, FreeStyle Menus is a keyboard accessible menu with added javascript animated fade effects.
Using javascript instead of
:hoverfor controlling the submenus means that they are more usable and won’t disappear as easily when moving around the menus.While it does have better accessibility features than the original Suckerfish with javascript on, with it off, however, it actually becomes less accessible because you can’t access the submenus via keyboard or mouse in any browser. (With javascript off, the menu falls back to CSS for presentation.)
Pros
- Free, although a donation is requested if you want to remove the credit link.
- No unnecessary markup.
- Dropdowns are generally more usable without menus disappearing too soon.
- Submenu items are keyboard accessible.
- Javascript fading effects.
- Will work in older (v4+) browsers.
Cons
- The dropdowns won’t work in any browser with javascript disabled.
- CSS and javascript may be complicated to customise although the download files are well commented.
-
TJKDesign’s Pure CSS Dropdown Menus
Thierry Koblenz has updated his menu to give it a better ‘look’ while also improving its usability accessibility aspects.
There are two versions: horizontal and vertical. Both menus are actually horizontal in that the top level menu items display horizontally, but the difference is the orientation of the submenus. The menus work slightly differently as they are designed to address different issues which are mentioned in the article.
The vertical menu has better keyboard support in that you don’t have to tab through all the submenu links before reaching the next top level menu item (except for the submenu items of the top level list item of the page you’re currently on).
The dropdowns will work for a mouse user with javascript disabled, but not for keyboard users (except, again, of the list item of the current page you’re on).
The dropdowns also won’t work in IE<=6 if javascript is disabled but Thierry has instituted a clever fallback whereby the menu reverts to having the submenus display horizontally below the top level nav.
Pros
- You don’t have to pay for it, although the Creative Commons licence it uses states it cannot be used commercially.
- No unnecessary markup.
- Keyboard navigable using the
tabkey. - Care has been taken to ensure menus don’t disappear too quickly when moving between levels.
- Dropdowns work if javascript is disabled*.
Cons
- Quite complicated CSS.
- *Dropdowns won’t work in IE<=6 with javascript off, but there is a workable fallback.
-
Menu Déroulant Accessible - Partie 2
Aurélien Levy brings us part 2 of his dropdown menu. The behaviour of this menu is driven completely by javascript. If javascript is disabled, the whole menu is completely expanded, so some care would need to be taken with your design to make allowances for this. The submenus also appear completely expanded for an instant on first load of the page.
The submenu links can be accessed via the keyboard and when first tabbing into the submenu, a hidden skip link appears which enables you to bypass that submenu and move along to the next top level link.
The menu doesn’t work quite the same in IE with you having to hit
tabtwice on each top level link to get to the submenu.Please note that the article accompanying this example is in French.
Pros
- Free.
- No unnecessary markup.
- Keyboard navigable using the
tabkey. - Skip link added to each submenu so you don’t have to tab through all the links if you don’t want to.
Cons
- CSS contains quite a lot of hacks for IE5+ browsers which probably would be better moved to conditional comments.
- Submenus appear completely expanded for an instant on page load.
- You need to hit
tabtwice on the top level links to access submenus in IE. - Dropdowns won’t work with javascript off, but there is a workable fallback.
-
Easymenu
This has similar functionality to the one above but with much less complicated CSS and javascript. Implementation seems to fairly easy.
The site doesn’t appear to have been updated in a while because its list of supported browsers ends at IE6 and Opera 7.11 but the menu does work in Firefox 2.0, IE7 and Opera 9.02.
Pros
- Free (if you don’t mind linking back otherwise a donation is requested).
- No unnecessary markup.
- Submenu items are keyboard accessible.
Cons
- Submenus won’t work with javascript disabled, however, with javascript off, the whole menu is expanded and you can provide different styles for javascript on or off.
-
Keyboard Accessible Dropdown Menu, Part Deux
Another fairly straightforward implementation that uses javascript to provide a little extra useability with a mouse delay which means you can slip off the menu momentarily without losing your place.
Pros
- Free.
- No unnecessary markup.
- Submenu items are keyboard accessible.
- You can have an infinite level of submenus (a change is required to the IE6 stylesheet).
- Care has been taken to ensure menus don’t disappear too quickly when moving between levels.
Cons
- Submenus are still accessible by keyboard if javascript is turned off but highlighting varies between browers. In IE6 and 7 there is no highlighting, in IE8, Firefox and Opera only the current item is highlighted (Opera exhibits this behaviour with javascript on too). Firefox will also expand the contents of all child submenus when first tabbing into a parent, before reverting to only showing the currently selected submenu item.
-
Project VII’s Pop Menu Magic
The difference between this menu and the previous PVII example is that this one makes much more use of javascript which means it is accessible to keyboard users, can detect the edge of the window and reposition submenus accordingly and provides fade in/out effects.
The downside is, of course, that without javascript, the menu actually becomes less usable then the previous example.
Update: As Al Sparber has pointed out in the comments, there is an article on their site outlining how to to build an accessible site around this menu.
Pros
- No unnecessary markup.
- Submenu items are keyboard accessible.
- Other javascript enhanced effects like window detection, submenus fading in and out.
Cons
- Not free.
- Dropdowns don’t work with the mouse without javascript. The submenu items are still accessible via the keyboard, but like the UDM4 example, on the status bar gives you an indication of where you are.
-
Smartmenus
Smartmenus appears to be fairly new on the scene (judging by the fact that their ‘Online Samples’ page is still under construction) and combines the functionality of Easymenu and PVII’s Pop Menu Magic.
The menu is accessible via the keyboard using the
tabkey and interestingly, works in IE with javascript disabled. I say interestingly because in Firefox with javascript off the menu behaves like the Easymenu example and becomes completely expanded. There also doesn’t appear to be any documentation as to whether this expanded form can be styled in any way.Pros
- No unnecessary markup.
- Submenu items are keyboard accessible.
- Menu works in IE with javascript disabled.*
- Other javascript enhanced effects like window detection and repositioning of submenus.
Cons
- Not free.
- *Menu loses all styling and structure with javascript disabled in other browsers like Firefox and Opera.
-
Ultimate Drop Down Menu
This menu is probably about the best there is when it comes to advanced usability and accessibility features including keyboard navigation. Not only can you
tabinto all links, but you can use the up and down arrow keys to move between items on the same level and use left and right to keys to move between levels.This menu claims WAI Triple-A and Section 508 conformance and boasts impressive browser support.
Pros
- The best keyboard support of any menu I looked at.
- Also seems to be able to lay claim to being the most accessible dropdown menu available.
Cons
- Not free.
- Dropdowns don’t work with the mouse without javascript. You can, however, still access them using the
tabkey although there are no visual cues apart from the URL in the status bar to indicate which link you’re on.
-
Milonic
Milonic menus are old school DTHML menus, in other words, completely javascript-driven. This means that links don’t actually appear in the HTML which creates problems for search engines spidering your site and for people using assistive technologies who may not be able to access any of the links. They are keyboard accessible but if javascript is disabled, you get nothing unless adding a
noscriptfallback to your page which ultimately leads to greater code weight.Pros
- Free unless for commercial use.
- Submenus are keyboard accessible.
Cons
- No HTML markup.
- Completely javascript-driven.
- Menu disappears with javascript disabled unless
noscriptfallback is provided.
-
Sothink
More javascript-only menus but without the keyboard accessibility although they do seem to have more javascript effects than Milonic. Again, no menus at all without javascript.
Pros
- Different effects like scrolling within submenus.
Cons
- Not free.
- No HTML markup.
- Where HTML is used it appears to be table-based and largely invalid.
- Completely javascript-driven.
- Submenus inaccessible by the keyboard.
- Menu disappears with javascript disabled unless
noscriptfallback is provided.
-
AllWebMenus
AllWebMenus feature some very snazzy examples (including a replica of Windows Start menu) but from a usability point of view, they’re almost identical to those of Sothink and Xtreeme.
Pros
- Different javascript effects.
Cons
- Not free.
- No HTML markup.
- Completely javascript-driven.
- Submenus inaccessible by the keyboard.
- Menu disappears in most cases with javascript disabled.
-
Xtreeme
Another javascript-driven menu but this one mixes javascript and tabled-based HTML markup (which does mean that the menu is still viewable if javascript is turned off).
Pros
- More javascript effects like transparency and fading.
Cons
- Not free.
- Table-based markup.
- HTML and javascript mixed.
- Submenus inaccessible by the keyboard.
- Submenus won’t work without javascript.
-
Apycom
Apycom’s menus are Java driven which means from an animation point of view, they can do more than any CSS or javascript solution. Of course, not everyone has Java installed and the same problems with regards there being no HTML in the page also applies although these menus will still function if javascript is off.
Pros
- A variety of animation effects.
Cons
- Not free.
- No HTML markup.
- Completely Java-driven.
- Submenus inaccessible by the keyboard.
-
ThinkHTML menu
Updated: 22 September 2009
This is a brand-new CSS-only menu by Timo Huovinen which doesn’t require any javascript (even for older versions of IE), and also supports tabbing via the keyboard.
Timo received some tips from Paul O’Brien via a contest held at Sitepoint after having developed an initial version of the menu and now the menu seems to meet all the criteria I laid out at the beginning of the article making it the only completely CSS dropdown menu with semantic markup.
Pros
- Free.
- Works in all browsers using only CSS without browser-specific HTML.
- Completely valid HTML/CSS (semantically correct HTML) without any IE hacks.
- Natural tabbing.
Cons
- Width of the dropdowns has to be fixed.
Excellent article John, thank you for summarising it all so well.
There is an addition to the Son of Suckerfish menu to make it keyboard accessible - I think it was by Matthew Carroll - Linky
I haven’t used them (yet) but I like the article. Curious, though, wouldn’t dropdown be the vertical one and flyout be horizontal?
There is Angus Turnbull’s Twin Helix site that has his FreeStyle Menu. I’ve used them with two clients. They’re mostly based on Suckerfish (semantic structure) but provide JavaScript animation and fade controls. The versions I used were partially keyboard accessible (but might work better today). The CSS is involved if you want to customize them, but the sky is still the limit with what can be done on the CSS for the developer. He has a support forum where he is fairly responsive to questions. The code is free with a credit line, or licensable with a donation. My experience with the Milonic Menu mentioned above is that it creates a mess of non-standards-compliant code when it renders to the client.
@Mike - my understanding was that you call them horizontal or vertical depending on the orientation of the top level list, not the submenus.
@John & Helena - thanks for the links. I’ll add them to the list.
Thanks for clearing that up, John.
Hi John,
I’d like to comment on a few things:
The two other examples are keyboard navigable too.
I don’t understand this statement. If it works better, then it should be listed with the “Pros”, not with the “Cons”
Actually, I thought you would have two entries in this article, one for each menu. Because these menus are built differently to address different issues, so each one is better than the other depending on the point of comparison (which you do not mention).
For example, do you mean better in term of tabbing navigation or search-engines indexing?
There is nothing “odd” in there. And it is not related to the first top level list item either.
This is well explained in the article:
Visit another page to see that this is related to sections and not to the first item of the list.
I kind of agree on that one, but on the other hand you forgot to mention in the “Pros” that this menu looks the same in all browsers, including IE 5 Mac OS 9. That’s the price to pay for a solution that has great browser support and degrades nicely with Javascript off.
There are no drop down menus out there that work in IE IMHO, the “[with Javascript off] there is a workable fallback” should be in the list of “Pros”
Nice Design BTW
Hi Thierry,
Thanks for your comments. The first point you raised was due to me adding other examples after I’d written about yours and forgetting that the order had changed.
In writing about your menu I perhaps glossed/skipped over some of points that might be important to understand about how the menu works, but the trouble with this kind of article is that:
a) I’m trying to just give a brief overview of each example and hopefully people will follow the links themselves to find out more about them.
b) I need to tread a fine line between describing the examples I’ve given and actually copying the work of someone else’s site.
I’ve amended the article to reflect some of your comments.
The last one about javascript being disabled though I’ve left in the ‘Con’ list because there is one example on the list which will work with javascript off and I’ve listed it as a con for all the others where it doesn’t.
IMO, that example should not belong to the list. It is not only based on table markup , but also relies on nested block-level elements in anchors.
That menu fails two out of three criteria.
I think Stu Nicholls is a genius, and when I saw that Menu a few months ago I thought it was a very clever approach, but still, this is “lab stuff”, it’s nothing serious.
IMO, justifying the presence of this menu in your list by saying it is the only one that does not rely on JS in IE dangerous because some people could think it is a “big plus” over the other solutions and could end up using it. Do you want to be responsible for that?
I’m not justifying the CSS Play menus’ presence on that point. In fact, the only justification for any of the menus being on this list is that they ‘drop down’.
There are other menus on this list that have more serious issues with regards web standards-based design than Stu’s examples.
I also think I’ve pointed out adequately the problems as I see it with those menus.
I think there may be a problem with the format of this article and the way some might read it with people looking at the number of pros/cons and deciding that that adds up to a rating of how good the menu is.
I tried to avoid giving a rating to any of the menus because I didn’t want this to be viewed as a ‘which menu is best’ list. I’ve tried to leave it up to the reader as much as possible to decide which one they should use.
A balanced article. Well done. I’d like to point to an article we’ve written that is relevant to the Pop Menu Magic system you mentioned. The article expresses our views on how to make the menu more accessible. It is, in essence, how we would deploy the menu in a real-world site.
http://www.projectseven.com/tutorials/accessibility/...
Cheers on a fine and useful article.
Al Sparber
For information here is mine, the explanation are in french here: La recette pour un menu déroulant accessible - partie 2 and the visual example.
It’s free, keyboard accessible and javascript unobstrusive.
You are right about the conditionnal comment for ie bug , for information most of them is not for the menu system itself, it because i use relative and zoomable em unit for it and ie use it differently.
For the onload problem i think it can be easy to fix it with the dean edwards onload problem solution or other equivalent technique
it´s a good drop-down overview. would be nice, if you could ad this one:
http://pfirsichmelba.de/artikel-scripts/dropdown/horizontal.html
with short explanation in english http://pfirsichmelba.de/artikel-scripts/suckerfish-accessible.html
in the demo there are two drop-downs one with fallback for ie6- without javascript enabeld and one without fallback.
keyboard accessibility is supported for all browser with/without javascript.
Thanks Alex,
I’ve updated the list. (Sorry to Aurélien - Goetsu - for not thanking him for his contribution earlier too).
thx, a lot.
the hidden spans aren’t neccessary for the script.
but the spans are good to seperate links, wich is good for screenreaders like ibm homepage reader (this screenreader doesn’t say wehre a link starts, he just modifies his voice, when reading a link. so seperation can help users to know where a link starts and where a link ends. in german text you should seperate links with “.” in english with ”|”.)
i added this because it is good to know, that you can add special markup (for example: in udm[4.5] it is not allowed to add other markup in list items than ankers.
Great list and helpful resource. I have to agree with the comments about Stu’ CSS Play stuff though. The guy is a genius and produces some amazing stuff but accessible it’s not.
I’ve noticed that with IE 7, sliding menus have problems when setting the focus to anything other than 100%. Do you know if there are any sliding menus which will work right under these conditions?
Thanks!
Could you explain a bit more about what you mean by ‘sliding menus’ and setting the focus to a width?
The submenu slides out to the right with text hyperlinks embedded in a gray square. I’ve been using pSlideOutMenus to do this. In IE7, one now has a magnifying glass with a zoom level one can set. When the zoom is set to other than 100%, the gray square slides out, but the text hyperlinks don’t remain in the square.
BTW, thanks for the response!
Here is another I didn’t see on your list that I’ve used. They are highly configurable and have been around for years with continued support.
http://www.hiermenuscentral.com/
This one does not use javascript, just images for the buttons and is free. Has gotten alot of attention - http://www.grc.com/menu2/invitro.htm
The html is rather bloaty, but usable.
Hi Sam,
Your menu looks very similar to those of Stu Nicholls (I noticed you cite him as a source). Would you be able to explain how it’s different from the menus on CSS Play?
thanks a lot
THANKS
Thank you very much for this article and time you put to write it. I wasted 12 hours of work testing various “cross browser” drop down menus yesterday.
I wish I found this article before. Thanks again, it is very helpful and time saving.
You forgot OpenCube.
I would say there is a good argument for creating a menu that doesn’t show the second levels for browsers that don’t support CSS or Javascript, e.g. most mobile phones (I’m not including blackberries!).
I mean, if i view most commercial sites using suckerfish on my mobile and I want to find the contact us button (because standards say it’ll be there on the homepage), I have to scroll and scroll and scroll and read and read until I find that little link amongst a huge long list of stuff (note the ‘skip to content’ links often don’t work, PLUS it’s a mobile and no one want sto wait for another reload)…
So if accessibility is King, then we should deliver content according to environment, and not just say ‘you must be able to access EVERYTHING’, just because…
It has to be fully css all the way. CSS is the future of web design along with server side processing. You simply cannot rely on javascript and to have a javascript solution you must have a secondary solution that can be triggered if there’s no javascript. To me, it just makes sense to make it all server side, it’s much more secure, reliable and friendly.
How exactly do you make a dropdown menu that is ‘all server side’?
Most of the menu use JS - document.getElementById(“ID_HERE_SINGLE_ONLY?”)
What if I want multiple dropdown, i.e. a dropdowns for menu, dropdowns in the footer, dropdowns in categories? How do I replace the document.getElementById(“ID_HERE_SINGLE_ONLY?”)
Ramil, it’ll depend which menu you choose but in cases like the one you’re referring to, the javascript is to enable hover support of list items in IE6. So you could either use a script that targets class names instead of IDs, or use scripts that add hover support to all elements like the whatever:hover or Dean Edwards’ IE7.
Well, using Dean’s IE7 makes my style switcher (from A List Apart) stop working in IE6.
Ramil, the purpose of this article is simply to showcase different dropdown menus, not provide implementation or troubleshooting advice for them.
If you’re having trouble with a specific implementation, I suggest you post a question in a forum like CSS Creator.
Yeah, I just giving a heads up just in case others may use both style switcher and Dean Edward’s IE7.
I have already asked this on IE7’s Google Group.
Thanks for your research. We all benefit greatly from it!
Thanks for the article! But I find that dropdown menus very often fall down on a fundamental property that you don’t seem to have addressed here. Namely, when you click or right-click to jump to a new page (possibly in a new window or new tab), does the current dropdown vanish as desired? Or does it untidily remain down (potentially still seen, or waiting to be seen if you go back)?
Even restricting my testing to just Safari 3.1.2 and Firefox 3.0, I’ve not yet seen a single example that always behaves ‘tidily’ for both types of click. As an example, Suckerfish is failing for me in Safari, with both a standard click and right-click. Actually the same goes for the fancy-sounding ‘ULTIMATE DROP DOWN MENU’ (I’ve just checked a demo), and it wasn’t tidy in Firefox either. I’ve not checked ALL the examples here, but I’m not hopeful of finding a fully tidy menu.
If you revise your article, I’d like to suggest that you also mark each menu type for tidiness, in the sense I’ve described. What I find frustrating in my web search so far, is that despite most dropdowns seeming to have failings in that regard, I’ve not yet found a single comment about it. Weird.
Hi Keith, I’m sorry, but I don’t understand the issue you’re describing (which may be why you’ve found no comments on it – maybe no-one else finds an issue with it).
Hi John. I thought I was being clear, but ok, let me have another go at describing the basic problem.
Imagine you’re using a dropdown menu. You click or right-click one of its items; maybe a submenu item, or maybe one of the top-level items. This opens a new window or tab or takes you elsewhere (er, unless maybe using a demo with annoyingly dud links!). Question: did the extended dropdown get hidden again (“tidy”), or is it still sticking out, visible on the page where you used it (“untidy”)?
I hope that helps. The only other thing I could add is that I’m using Mac OSX; I’m not on a PC. Possibly the failing is less prevalent on PCs, I currently have no idea.
If I’ve helped and you look into the matter, I’ll sure be glad to hear anything about it, because I still can’t get my menus to be fully tidy.
Sorry, Keith, but that’s not an issue I believe is worth troubling about.
Does it reduce the usability of a site or prevent access to any part of it? The answer is no, and that’s always my primary concern when considering functions of navigation.
(On a personal note, I don’t believe that effect to be that ‘untidy’ either; it just doesn’t worry me.)
The fact that, as you say, you’ve found no comments about it would suggest that perhaps others are of the same opinion.
I’m not responsible for any of the dropdowns listed in this article, so if you believe strongly enough about it that it should be rectified, you may be better off contacting one or some of the authors directly.
Although it doesn’t reduce functionality, the reason to be concerned about it is that it’s a very visible and quite ugly glitch on your page. Most users are likely to attribute that glitch to you, the designer, even if it’s actually due to some technical limitation beyond your control. To them your page is a bit broken, and the user consequently has a bit less respect for it. You may not find the glitch disturbing yourself, but isn’t it your users that should be your guiding concern? Ok I know they’re a bunch of pests we could do without, but I think they’re here to stay! Plenty of them will find it visually ugly, and also an annoyance because they have to click or mouse somewhere to get the offending dropdown to finally hide again.
As for any of the menus here getting fixed (made fully ‘tidy’), I’m not even sure that’ll be possible. I’m relatively new to site design, but perhaps there really are some current technical limitations that make it either problematic or impossible.
By mentioning the issue on your excellent round-up page here, I hope it might at least get seen and given some consideration, if it’s indeed something that has so far largely been ignored.
Is this just you projecting your view onto that of others, or do you have evidence to back up this statement?
I’ve never had any feedback that people find this effect ugly, and in the absence of such feedback, I’m disinclined to believe it’s an issue. You’re the very first person I’ve heard who has a problem with it.
I’ve not got any market research, but that’s why I just used the vague term “plenty”. How much it actually bugs people will vary of course. I find it surprising that you have so little concern on for this flaw however. At the end of the day, we’re talking about a user interface element which, in a very visible way, isn’t functioning entirely correctly (a dropdown should always retract after use), and is a potential minor annoyance or distraction to the user. To me that’s reason enough for concern.
On the positive side, if malfunctioning dropdowns are as widely accepted as you seem to imply, at least my own pages won’t be too odd-out for having the same flaw. I’m not sure that’s something I should be too happy about though! It would be interesting to hear other people’s views on this. But anyway, thanks for the response.
Regarding the issue brought up by Keith, I have noticed it and consider the only remedy to choose what effects happen on focus (and active with IE). When clicked, it still has keyboard tab focus after a backpage or backspace return. If you eliminate it altogether, you eliminate keyboard access.
Great job, would like more websites like this: complete, to the point
Thank you, this has me very helped.
Very nice list.
It seems that these days the dropdown menus are in a state that you can include them without hindering the usability of your web page too much, and some people would want them for one reason or another.
They may be really nice shortcuts if they work as expected in your browser and you can handle a pointing device with ease. Well made menus these days can be even usable by novice users that are not so proficient at pointing exactly where they want on the screen.
The menus pack more links at smaller screen space at the cost of larger pages and somewhat trickier navigation.