A List Apart: Comments on: Suckerfish Dropdowns

Posted by: tim

2012-01-31T13:00:49+00:00

nice.

Posted by: Michael Ward

2012-01-31T13:00:49+00:00

A nice example of drop down menus - probably the most semantically correct bug free version yet. But it still has it's bugs... Ah, for a world where we didn't have to work around the bugs of useless browsers! Might just consider this for one of my future projects - and it's certainly better than any of the javascript/dhtml versions.

Posted by: Seb Duggan

2012-01-31T13:00:49+00:00

...works fine. At least, it does in version 1.1 (comes with OS X 10.3). I agree that it's broken in version 1.0. The good news is that this means Apple are addressing all these incompatibilities that are being reported...

Posted by: Jim S.

2012-01-31T13:00:49+00:00

I still have 10.2.8 on my work system and as such Safari 1.0 and the drop down menus appear in the upper left hand corner of the screen. On my other system I upgraded to Panther and it has a newer version of Safari which works perfectly. I wonder if we need to keep an older version of Safari for testing purposes as some people may not upgrade immediately? The more the merrier as far as browsers is great but just makes our jobs as designers a little tougher.

Posted by: Andy A.

2012-01-31T13:00:49+00:00

As we learned in the previous issue, display: none effectively hides the content from the screen readers. So is this TRULY accessible or are the screen readers only going to get the top level items and not the secondary items?

Posted by: Blakems

2012-01-31T13:00:49+00:00

Finally a dropdown that looks great and works great. Good article on the technique. Is there any way to go and create decendent lists from the child list?

Posted by: Stephen Sample

2012-01-31T13:00:49+00:00

Darn! Why wasn't this published a month ago? I ended up coming up with a similar method for a redesign project at work, though I used mouseover methods on the URLs rather than DOM coding. This is cleaner, though. Hmm. May be time for me to recode. ;-) If IE/Win is your only concern (and not Opera or IE5/Mac, say), and you aren't a Javascript language purist, you can do a slightly simpler script with conditional comments and DHTML behaviors. But of course, that doesn't get you compatibility with as many browsers.

Posted by: Dan Webb

2012-01-31T13:00:49+00:00

As Blakems just mentioned above we are working on getting further nested levels in the dropdowns now and have gone most of the way to making this work. The javascript patch for IE is simple enough, it just needs to recurse through any child nodes to attach the behaviour. However, the CSS is another thing... We'll keep you posted. Any ideas greatly appriecated.

Posted by: Stephen Sample

2012-01-31T13:00:49+00:00

Andy, as I understand it (and I don't have much experience with screen readers, so I may be wrong here), the submenu items probably won't be accessible as-is. If any of the screen readers support Javascript, you could also add an onfocus handler to the script code, which would allow the menus to expand on tab selection as well. The HI of that is a little odd, but it seems possible. Of course, I don't know that any screen readers would support this in any case. Joe? But at least on the sites I've worked on, dropdown menus are frills. They save you a step in your navigation, but if your top-level categories are intelligently designed, that's all they get you--the top-level category you need is hopefully obvious, and when you follow the top-level link, the subnavigation will probably appear early on the index page anyway. So I don't know. I'm something of an accessibility (and standards) advocate, but I'm also a pragmatist. And I'd rather have pretty-good accessibility than none, particularly if the differential is small, and perfection is unattainable. Of course, since I'm arguing that dropdowns are optional, it might be more equitable to have *no-one* get to have dropdowns, since after all, they aren't really necessary. I guess my question becomes "is the utility of dropdown menus for your audience such that it's acceptable to offer them to only part of that audience?" And I can't answer that for you. ...It might be the client's call in a lot of cases, anyway.

Posted by: Dan Webb

2012-01-31T13:00:49+00:00

Actually, We experimented using onfocus and onblur to enable mouseless use but I found this was not going to work easily as you cannot attach onfocus and onblur methods to list elements. But yes, as you said above Stephen, the objective was to create a simple but effective solution to the problem with the minimum amount of code. I also have always used dropdowns as an optional quick route in to deeper content that is always backed up by traditional navigation and this was designed to do that at the minimum of disruption and extra page weight. In my opinion, adding a few extra CSS rules and a few lines of JavaScript does mean that giving an optional extra navigation feature to users that can (and want) to use it comes at a much more acceptable cost. And yes, clients love this kind of thing..what can you do?

Posted by: Justin Cone

2012-01-31T13:00:49+00:00

I just tested the bare-bones version in JAWS 4.5, and it worked beautifully. JAWS read the menus as normal lists and sublists. The links were also available via the List Links command (Insert + F7), commonly used by users to cut to the chase. I see no problems with this drop-down menu approach and JAWS 4.5.

Posted by: Marek Moehling

2012-01-31T13:00:49+00:00

The fallback option for non-css browsers is clear: plain HTML. What about IE with JS deactivated? That's 13-15% of all users, a group too large to get served plain HTML.

Posted by: Patrick Griffiths

2012-01-31T13:00:49+00:00

Making the dropdown titles link to a certain section will mean those users won't get the full multi-level functionality of the dropdown menus but they will have single-level navigational menu. If they are used as an extra navigational tool (as discussed), they can simply be seen as a bonus to those with scripting capabilities rather than a detriment to those without.

Posted by: David Ondrik

2012-01-31T13:00:49+00:00

When I went to the pretty example, with the OSX like drop downs with the latest IE6 on XP, the menus "flash" as I mouse between options. What happens is that the background (the light gray lines) disapears and then reloads. It's really annoying. I checked in Opera and it was (predictably) smooth, so is there any idea why this is happening for IE6?

Posted by: Jon B

2012-01-31T13:00:49+00:00

I have seen this display bug a lot in old versions of mozilla and netscape 7, but never in IE although I have seen many others. In netscape/moz the problem was always to do with using 'visibility:hidden' or 'display:none' to hide menus with anchor tags. The solution was to position the menu 'off-stage' when in it's off state - simply done by changing the positioning value to something like 'top:-100px'. In this way you never need to change the visibility or display states so it works around the bug. I have IE6 on XP and I see no problem whatsoever by the way, but if you think it is a problem then try my suggestion as a bug fix.

Posted by: Julian Rickards

2012-01-31T13:00:49+00:00

I don't see anything happening in Opera 7.21 but in Moz1.5 I do (Win2k).

Posted by: Doug Baker

2012-01-31T13:00:49+00:00

Thanks for a clearly written article with clean, compact standards-compliant code. Very well done.

Posted by: John Colby

2012-01-31T13:00:49+00:00

Dan Many congratulations on producing this and circumventing some of the bugs in browsers. I'm going to test it on JAWS next week when I can (Thursday or Friday) so that we can prove its accessibility with users who need this technology. Must remember to take biscuits for his guide dog.

Posted by: Aleksandar Vaci&#263;

2012-01-31T13:00:49+00:00

Dan, Patrick, congratulations on the good work. I'm working on the same thing, and have got pretty far. You can check it out at - http://www.aplus.co.yu/Sparks/ADxMenu/ - it might give you some ideas while you work on nested levels code. At first, I was thinking on doing similar to what you did, using CSS at fullest and then compensating for IE's lack of :hover support. I gave that up because of real world usability problems (I'm developing the menu and use it at the same time at the client web site). I reverted to larger Javascript use to be able to accomodate problems like: - large menu list goes off the visible screen area - icon support (item icon and submenu arrow) - problems with menu being used in the pos:relative and float:left or right layouts, when in IE you have all kinds of overlapping. - easy switch between vertical and horizontal use Part of these problems and how I solved them can be seen in the three posts I have at the address above. I plan to add another post with some new tweaks I dealt with, this weekend. Also, as the menu is used on the bookmaker's web wite with lots of forms, I added the code that deals with windowed controls punching through the menu layers. Feel free to use any of the code in your future work (which I assume is GPL or CC based), as I will certainly review my code based on what you two published here and possibly simplify it.

Posted by: Patrick Griffiths

2012-01-31T13:00:49+00:00

Some of the problems you mention could actually be solved with CSS: icon support by using backgound images, IE problem with position and float with the the li > ul bit mentioned in the article, horizontal display using position or display properties.

Posted by: Elmo

2012-01-31T13:00:49+00:00

No workie in Opera. Elmo sad :(

Posted by: Patrick Griffiths

2012-01-31T13:00:49+00:00

I tested it in Opera and it worked fine. It was the latest version (7.2 I think). Maybe it messes up in earlier versions. Is it the examples that don't work? What happens?

Posted by: LazyJim

2012-01-31T13:00:49+00:00

I havn't tested it but if "display: none;" causes the content to be hidden from some text-readers, maybe a "overflow: hidden;" and "clip: rect(0,0,0,0);" could be used to hide the sub-menus, and then set "overflow: visible;" to show it for the hover state.

Posted by: Patrick Griffiths

2012-01-31T13:00:49+00:00

LazyJim I played around with overflow and clip and came up with http://www.htmldog.com/articles/suckerfish/bones/bones2.html which does the overflow thing, but sets height to zero rather than using clip. It seems to work in IE 6 Win, Mozilla 1.5 and Opera 7.2. I would be really interested to find out what the results are of this overflow method compared to the display method in screen readers, which I unfortunately don't have access to right now.

Posted by: Jean-Fran�ois Bastien

2012-01-31T13:00:49+00:00

As previously stated, it's not working in Opera 7.20. Javascript is enabled, there are no javascript errors, I'm on the normal page's stylesheet. Version 7.20 Build 3144 Platform Win32 System Windows XP

Posted by: Elmo

2012-01-31T13:00:49+00:00

Same here, Opera 7.20, xp, build 3144, javascript enabled, still doesn't work. Elmo still sad :(

Posted by: Michael Czepiel

2012-01-31T13:00:49+00:00

First of all thank you very much for this solution. Unfortunately, I'm still at that stage were I'm not sure if it's me or the browser when it comes to quirks. I'm scripting my student government website and have been waiting to ditch the milonic menu system (an abysmal piece of dhtml hackery). Anyway, it seems to be working fine in Moz 1.5, Firebird .7 perfectly. I've hit a minor snag in safari 1.1 where leaving the menu doesn't hide the dropped menus. But I'll chalk that up to safari seeing as it's lagging simply refreshing simply color change hover events in the menu. Moz 1.6a works fine for the most part but only the first few options within the dropped menus are selectable, mousing further down the list causes it to hide as if you intended to leave the menu. Again I'm chalking this one up to the browser and the alpha status. As far as IE 6 it begins by not showing the drop downs If I use the selector #nav li ul { /* for second-level lists */ or ul#nav li ul { /* second-level lists */ I can't afford to simply use li ul as I do have other sub lists and I figured this was the easiest way to get around applying style to other innocent elements. Additionally, IE seems to be adding a margin or a border to each li item in the sub list if I do use the general li ul selector where it will work. I'm really desperate for some help as sadly I've had to do this site form scratch by myself with some help from one of my friends back home, troubleshooting these things is becoming tedious (not that you're strangers to that). If anybody has any suggestions for this scenario I'd love to hear them. Additionally, if you happen to notice any other problems that'd be cool to.

Posted by: David House

2012-01-31T13:00:49+00:00

Isn't there a much easier way of doing this? ul li a { display: block; width: 100%} ul li a:hover ul { display: block} Works in my experience.

Posted by: Patrick Griffiths

2012-01-31T13:00:49+00:00

'Fraid not. You can't nest a list within an anchor element.

Posted by: Louis St-Amour

2012-01-31T13:00:49+00:00

Great technique. Just what I was looking for. As for the Opera comments, I'm using the still unoffical build 3221 (version 7.22 on WinXP) and it works fine...

Posted by: Julian Rickards

2012-01-31T13:00:49+00:00

It didn't work on Opera 7.20 at work but on 7.21 at home (haven't upgraded my copy at work yet). Maybe a bug in 7.20.

Posted by: Aleksandar Vacic

2012-01-31T13:00:49+00:00

> Some of the problems you mention could > actually be solved with CSS... I do use CSS as much as possible - DOM is used purely to position elements where needed. I don't see how to control whether is menu going off the visible screen area, using CSS. You need to know how large your menu is, what is available client width etc. As for multiple levels, I always wanted as simple code as possible, but as soon as I got into advanced features, I inevitably enter the realm of heavy DOM use. If one have multiple nested lists, using li:hover ul { display: block; } will show all of them, not just first sub-level. You can't use li:hover > ul { display: block; } either, because UL is not the first child (it's plain text node or A element). > IE problem with position and float with the > the li > ul bit mentioned in the article I'm not sure what you mean? I'm speaking about the problem explained here: http://www.aplus.co.yu/Techs/24/ - not sure whether li > ul can help to overcome that problem... I have finished, clean script that solves all the problems (except accessibility :( ) and I will publish it on my web site, but I'm not as nearly satisfied as I want to be. It requires each list item to be A element. I find that too restrictive, so I'm working on revised code, partially using the code you published here.

Posted by: Patrick Griffiths

2012-01-31T13:00:49+00:00

I agree that there is a disadvantage of the Suckerfish method in that it can not tell if a sub-menu goes off screen. I'm not a big fan of multi-level dropdowns, but it is certainly possible with CSS and Dan and myself intend to tackle it in the near future. It would involve something like displaying the next level (li ul) lists on hover, but explicitly not displaying third level (li ul ul) lists. For example, something like: li:hover ul {display: block} li:hover ul ul {display: none} On your other note, the li>ul bit in the article works because IE has a philosophy that children shouldn't be seen or heard. Everything within the li>ul selector is ignored by IE Win. So, the top and left properties are set initially to fix the IE float / position problem and then are reset with the li>ul selector.

Posted by: Toni

2012-01-31T13:00:49+00:00

I am sorry for not having read the entire discussion, but here's my bit I developed yesterday without even knowing anyone has been working on it... Unfortunately... no way to know weather we are offscreen... The multi-nested dropdown UL that works in Moz, Opera and ** (thou shalt not swear). Unfortunately I have to use some browser sniffing for Opera, as it has a rather nasty bug with no workaround...*(It's stupid, but if you nest an UL inside LI and then set CSS so that UL tries to align with {top: 0} of the parrent, opera will align UL with top of parent's parent - not LI's, but UL's... Really stupid.) Also, I have some freakish fancy things done with borders, as it seems, that {border: 1px} confuses the aligns... Other than that I use **'s native

A List Apart: Comments on: Suckerfish Dropdowns

Posted by: tim

Posted by: Michael Ward

Posted by: Seb Duggan

Posted by: Jim S.

Posted by: Andy A.

Posted by: Blakems

Posted by: Stephen Sample

Posted by: Dan Webb

Posted by: Stephen Sample

Posted by: Dan Webb

Posted by: Justin Cone

Posted by: Marek Moehling

Posted by: Patrick Griffiths

Posted by: David Ondrik

Posted by: Jon B

Posted by: Julian Rickards

Posted by: Doug Baker

Posted by: John Colby

Posted by: Aleksandar Vaci&amp;#263;

Posted by: Patrick Griffiths

Posted by: Elmo

Posted by: Patrick Griffiths

Posted by: LazyJim

Posted by: Patrick Griffiths

Posted by: Jean-Fran�ois Bastien

Posted by: Elmo

Posted by: Michael Czepiel

Posted by: David House

Posted by: Patrick Griffiths

Posted by: Louis St-Amour

Posted by: Julian Rickards

Posted by: Aleksandar Vacic

Posted by: Patrick Griffiths

Posted by: Toni

Posted by: Aleksandar Vacić