[drupal-devel] [feature] Make navigation menu expandable
whoey
drupal-devel at drupal.org
Sat Sep 17 13:13:02 UTC 2005
Issue status update for
http://drupal.org/node/29551
Post a follow up:
http://drupal.org/project/comments/add/29551
Project: Drupal
Version: cvs
Component: menu system
Category: feature requests
Priority: normal
Assigned to: nedjo
Reported by: nedjo
Updated by: whoey
Status: patch (code needs review)
While this would greatly help with a problem on a site I have, why does
expandable_menu3.patch want to patch line 169 of misc/drupal.js ? (I
don't seem to have this file...)
whoey
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
portions.
* 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?
http://www.drupalart.org/togglediv
(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:
http://www.htmldog.com/articles/suckerfish/dropdowns/
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
compliant.
------------------------------------------------------------------------
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
dissapears.
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
problems.
------------------------------------------------------------------------
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
work.
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
file.
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
http://www.useit.com/
http://www.useit.com/alertbox/20020428.html
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.
Candidates?
------------------------------------------------------------------------
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
opinion
bugfixing and integrating/testing/coding more important
features........
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Tue, 06 Sep 2005 16:48:19 +0000 : nedjo
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.
------------------------------------------------------------------------
Tue, 06 Sep 2005 16:51:14 +0000 : nedjo
Attachment: http://drupal.org/files/issues/menu.js (140 bytes)
menu.js file. Note that the function is only two lines long:
function toggleMenuItem(elt) {
var item = elt.parentNode;
item.className = (item.className == "collapsed") ? "expanded" :
"collapsed";
}
------------------------------------------------------------------------
Tue, 06 Sep 2005 16:55:46 +0000 : nedjo
Attachment: http://drupal.org/files/issues/blank.png (116 bytes)
blank.png This file needs to be added (like menu.js) to the misc/
directory.
Using a transparent image like this feels like a bit of a hack, but I
couldn't get other element types (I tried, e.g., div) to position
correctly and receive the onclick event.
------------------------------------------------------------------------
Tue, 06 Sep 2005 20:07:58 +0000 : m3avrck
For the JS, is that really needed? Did you check out this function
toggleClass(node, className) in misc/drupal.js? If you modify your code
so that *only* one class is used, say for example, only 'expanded', then
you can make use of this function and avoid the redunancy that your JS
introduces :)
Also, I couldn't figure out a way to get this patch to apply to the
default Drupal install. Is there a way to do this? If not, I think we
should modify it so that it can be included in the default install and
might even make sense to turn it 'on' as well, since it does improve
usability and out of the box, this works with all current themes. It
could then be turned 'off' by themers as they make use of it. Much
better implementation in my view.
------------------------------------------------------------------------
Tue, 06 Sep 2005 20:18:46 +0000 : m3avrck
Ok searched through the code, didn't realize this was a 'theme' setting
congifuration, anyways got this working great on WinXP FF, Opera8 and
IE6.
One note, the 'clickable' area is pretty tight, if you move the mouse
around you can see not all areas of the triangle are clickable,
probably need to adjust the the height/width of the image being use and
it's placement in regards to margin/padding/etc.
Also, I would add a title='Expand' or title='Collapse' to the image as
you click it, since it isn't clear if clicking on that bullet will
expand the selection or goto that main link.
Those fixes, along with eliminating the redundant JS file and I'll give
this a +1.
------------------------------------------------------------------------
Tue, 06 Sep 2005 20:31:30 +0000 : Bèr Kessels
please not opt-out, but opt-ni. javascript can break. and thus will
break peoples sites.
------------------------------------------------------------------------
Tue, 06 Sep 2005 20:44:54 +0000 : Crell
@Ber: Proper DOM scripting starts with a page that has no JS on it, and
then, via JS, adds the JS hooks only if the browser is determined to
have the necessary support for it. Think of it as an "automated
opt-in"; the browser itself opts-in only if it supports it. That's the
proper way to do any modern Javascripting.
I've not checked this patch to see if that's what it's actually doing,
but that's how it should be doing it. :-)
------------------------------------------------------------------------
Thu, 08 Sep 2005 12:53:45 +0000 : ax
hm - isn't this issue a duplicate of DHTML expandable menu links [3]?
[3] http://drupal.org/node/5943
------------------------------------------------------------------------
Sun, 11 Sep 2005 02:17:43 +0000 : nedjo
Attachment: http://drupal.org/files/issues/expandable_menu3.patch (6.47 KB)
Here's an updated patch addressing issues.
* Uses a single CSS class setting via addClass(). This is, however,
possibly confusing, as it means that a collapsed li has class="expanded
collapsed".
* Now implemented the way we do js in Drupal (calls added dynamically
on page load). I've also put added the cursor CSS at this point, so
that non-javascript browsers won't show the area as clickable. Js file
to follow.
* Title tooltips "+" (when collapsed) and "-" (when expanded). This is
preferable to the suggested text as it should be clear in various
languages.
To implement this, I've suggested adding a switchTitle() function to
drupal.js, on the theory that switching between two different titles
might be used elsewhere. But maybe this should be done straight in the
menu js file.
The reported display problem (clickable area isn't exactly over list
item image) seems to be a quirk in Internet Explorer and possible other
browsers: image is above text level rather than being aligned. I
haven't found a good fix for this.
"hm - isn't this issue a duplicate of DHTML expandable menu links?
"
Yep, you're right, thanks, I hadn't seen that issue. Should I move
this patch there, or would it be okay to move that issue here? This
patch, I'm thinking, more or less picks up where that discussion left
off.
------------------------------------------------------------------------
Sun, 11 Sep 2005 02:21:11 +0000 : nedjo
Attachment: http://drupal.org/files/issues/activemenu.js (472 bytes)
Revised javascript file, to be put in /misc. Also still requires
http://drupal.org/files/issues/blank.png in /misc.
More information about the drupal-devel
mailing list