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: Anonymous Reported by: nedjo Updated by: ica Status: patch (code needs review) 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) ica 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.

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: Anonymous Reported by: nedjo Updated by: fajerstarter Status: patch (code needs review) 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). fajerstarter 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.

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: Anonymous Reported by: nedjo Updated by: fajerstarter Status: patch (code needs review) 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? fajerstarter 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.

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: Anonymous Reported by: nedjo Updated by: Crell Status: patch (code needs review) 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. Crell 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.

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: Anonymous Reported by: nedjo Updated by: nedjo Status: patch (code needs review) 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? nedjo 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)

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: Anonymous +Assigned to: nedjo Reported by: nedjo Updated by: nedjo Status: patch (code needs review) 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. nedjo 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"; }

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: Anonymous Reported by: nedjo Updated by: nedjo Status: patch (code needs review) 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"; } nedjo 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.

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: m3avrck Status: patch (code needs review) 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. m3avrck 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.

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: Crell Status: patch (code needs review) @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. :-) Crell 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.

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: nedjo Status: patch (code needs review) 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. nedjo 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

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.