[drupal-devel] [feature] Make navigation menu expandable

nedjo drupal-devel at drupal.org
Tue Sep 6 18:28:25 UTC 2005

Issue status update for 
Post a follow up: 

 Project:      Drupal
 Version:      cvs
 Component:    menu system
 Category:     feature requests
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  nedjo
 Updated by:   nedjo
-Status:       active
+Status:       patch (code needs review)
 Attachment:   http://drupal.org/files/issues/expandable_menu2.patch (5.53 KB)

Thanks for the comments.

This patch adds a "dynamic menus" option to theme configuration
(disabled by default), available for individual themes if it's
registered as one of the theme's or its engines' features.  Initially,
I've added this feature to PHPTemplate.

If a theme's dynamic menus option is selected, the standard navigation
menu becomes a clickable tree menu.  This is done almost entirely
through css; the two-line javascript function serves only to toggle css
classes.  The "trick" is that an invisible image is positioned over the
navigation list-style-image.  It's this hidden element that receives
the onclick event.

The patch requires two additional files to be added to the misc/
folder, which I'll attach in a bit.

Client-side navigation (expandable menu trees) might seem like a frill.
 But, for dial-up users, it's a real usability gain, as it avoids
considerable delays.

Yes, this adds a bit (albeit only a few lines) to core.  But is there
another way to make this sort of functionality generally available,
rather than only in a single theme?

I've implemented expandable trees for the navigation menu, but of
course it could readily be added for other navigation blocks, e.g.,
book navigation.


Previous comments:

Wed, 24 Aug 2005 15:43:24 +0000 : nedjo

Attachment: http://drupal.org/files/issues/expandable_menu.patch (2.16 KB)

One or more unneeded page loads are often required to bring up the
desired page through the navigation menu (e.g., administer > settings >
content types).

Using CSS, this patch introduces automatically expanding menu options. 
E.g., holding the mouse over "create content" will dynamically expand
the menu, revealing the available options ("page", "story", etc.).

Issues & questions:

* Is this a desired behaviour?
* Page loads are slightly larger, since they include hidden menu
* Not supported by, e.g., Internet Explorer due to CSS bugs. 
Downgrades cleanly, but means that functionality is not uniform across
browsers.  A js IE fix is available, see e.g.,
http://www.alistapart.com/articles/dropdowns/ but it's a big ugly.
* Display is a bit jumpy.  Slideouts or slowed transitions might be
nice, but would I assume require javascript.
* Introduced as the default behaviour, not as an option.  Should this
be a configuration option instead?

The approach is based on suggestions and code [1] for the
taxonomy_context module by eferraiuolo [2].
[1] http://drupal.org/node/29074
[2] http://drupal.org/user/24218\" title=\"View user profile.


Wed, 24 Aug 2005 16:45:37 +0000 : ica

I might be wrong beause of my lack of knowledge coding but zirafa's
example here with togglediv might be the solution for Auto-expand
navigation instead alistapart's?


(Altough alistapart of a site/coders who practice elegancy with fine
coding to high standard to inspire -imho)


Wed, 24 Aug 2005 17:00:50 +0000 : m3avrck

If we are going to include a script, I would recommend this one:


Uses no additional markup and only requires the use of one extra class
for the effect to work in IE. Requires a small, 12 line JS file to
work in IE. Works perfectly, super easy, clean, and standards


Wed, 24 Aug 2005 17:28:25 +0000 : fajerstarter

Altough I think it's a really good idea and really could improve the
navigation (this is one thing that's always bugging me, 4 clicks just
to change that little thing), it's not that good for usability.

If just css had a delay effect...

Try for example to go from top to down to click the administrator link.
Impossible I would say; you have to go from bottom up or else it

I think for this to be really useful we need some kind of javascript.
And then this gets much more complicated (and debated).


Wed, 24 Aug 2005 17:31:06 +0000 : m3avrck

That's why I suggested this other method for creating the XHTML and then
the additional JS for IE. It works great, and with the proper tweaking
of the CSS (e.g., padding mainly) it works almost flawlessly. I'm using
it in a current project with 3 layers of menus with no usability


Wed, 24 Aug 2005 17:42:07 +0000 : fajerstarter

With the chance that I've misunderstood: Suckerfish et al. for me is
menus that pop-up and shows a new "layer", either downwards or
left/right. This patch makes the menu expand and pushes the content
below down, as the current menus work, and IMO this is how it should

Have you tried the patch?


Wed, 24 Aug 2005 18:22:40 +0000 : m3avrck

Well I haven't had a chance to try that patch yet. However, the ALA code
is for a menu popup "layer" as well. However, I do agree, "pushing" the
content downwards is a much better aproach. And with that, I present a
much better (and related!) JS code approach:
http://www.danwebb.net/lab/archives/000018.html  ... this would make
navigating those menus much easier and it can auto-expand to whatever
Drupal has labeled as "current" too. This would be very slick. Hmm,
need some time to play around but I would recommend this approach.


Wed, 24 Aug 2005 20:57:09 +0000 : Crell

I would much prefer the danwebb approach on simple usability and
accessibility reasons.  On-hover menu appearance is very bad, from a
usability perspective, and the deeper the menu the worse it is.  Even
assuming all of the position detection is working perfectly, the user
still has to then be very careful in how he moves his mouse.  One
slight slip off track and the menus all close and shift and change on
him.  That pisses me off to no end when dealing with Start Menu-type
menus. :-)  If a person doesn't have very good fine motor control in
their hands, then slipping off track is almost guaranteed.  

In contrast, the danwebb approach is click-based.  It doesn't matter
how you move the mouse to get there, just the click itself.  That's
much more user-friendly and accessible.  It also means the new menu
items persist for as long as the user wants them.  If I'm just browsing
through various options, that's much easier as I don't need to keep
perfect balance on my mouse hand, and can even switch away to an IM
window or similar without losing my place.


Wed, 24 Aug 2005 21:10:14 +0000 : Tobias Maier

""If a person doesn't have very good fine motor control in their hands,
then slipping off track is almost guaranteed."

he's absolutely right. Think about not everyone is a web geek. the most
dont even know a "browser" or how to minimize a window or to move a
some (mainly older) people are not very good at moving the mouse
(sometimes have even problems to understand what this "thing" does)
the won't realise why the menu closes or opens. they get confused and
maybe leave the page :(

look at
or your grandmother surfing ;) (sometimes an unexperienced mother/dad
or wife/husband is enough)


Wed, 24 Aug 2005 21:30:05 +0000 : nedjo

Yes, clicked selectors rather than mouseover effects are easier to use. 
In our case, we would need to have the graphic (e.g., folder, or our
existing "expanded" or "collapsed" bullet) clickable, because the text
links themselves (e.g., 'administer') need to load a new page.  And, of
course, we'd need clean, GPL code to use/adapt.



Wed, 24 Aug 2005 22:08:55 +0000 : Tobias Maier

what I dont understand is why must this be included in HEAD?
is there not any way to do it with a module or a theme?
theming theme_menu_item(), theme_menu_item_link() and theme_menu_tree()
as example?

I in my case dont need it really...
there are a lot of other things which are much more important in my
bugfixing and integrating/testing/coding more important


Sat, 27 Aug 2005 03:58:49 +0000 : nedjo

Setting this to active as it would need a different approach (likely a
tree menu).

I consider this a desireable usability enhancement, though hardly
pressing.  It's true that this could be done through a theme, but then
of course it would be available only in that theme.


Sun, 28 Aug 2005 10:01:22 +0000 : Bèr Kessels

A +1 for your css class system. I prefer that above the current $leaf=
TRUE system, for its flexibility in theming AND its ease of use.
A -1 for the class li:hover, ad the extra LIs in core. IE does not
support the :hover on other things then the A, and such advanced
themeing things definately do not belong in drupal.css. If you really
need that, make a theme that has such expading divs, but not in core.


Mon, 29 Aug 2005 14:15:56 +0000 : deepesh

I would like to add this functionality, But I am NOOB can anybody guide
me step by step how to get it working.

More information about the drupal-devel mailing list