A requirement of a site that I am currently developing is that the main horizontal nav bar at the top is repeated again in the page footer with different styling.

The menus will always be the same as one another, so the smooth way to do it seemed to be to create 1 Drupal menu, 2 Nice Menus, assign each Nice Menu to the same Drupal menu, show one in the header and show one in the footer. It works, it looks great, and the separate container DIVs allow me to style them differently with CSS. Perfect.

...except for one thing: Each menu item gets its own ID, and of course IDs need to be unique per page.

<li id="menu-425" class="menu-path-node-4"><a href=...

appears once in each menu, causing the HTML to be invalid.

I'm pretty sure that without using Nice Menus, there really is no way to render the same menu twice on the same page (okay, maybe with Panels or something). Perhaps it is just simply bad practice to display the same menu twice. Opinions?

My solution (since this has to be done, like, now) is likely to be to just create another Drupal menu with the same menu items so the menu items get unique IDs, which creates some duplicate effort in maintainability and introduces more potential for human error. Maybe this is a corner case, but I see a lot of sites that repeat their navigation at the bottom (although I understand that the way more common use case is that the bottom nav has different/additional links.. I'm also pretty sure that the client hasn't really thought it through and will eventually want to add more links to the bottom nav: think TOS, Privacy Policy, RSS links, "Advertise with Us", and so on..).

Feel free to "won't fix" it if you think its just a bad idea, but a possible solution would be for Nice Menus to prepend the Nice Menu ID on the menu item ID. In the example above you would get <li id="nice-menu-1-menu-425"... and <li id="nice-menu-2-menu-425"... for the header and footer navigation, respectively. Thoughts?

Cheers,
Jim

CommentFileSizeAuthor
#4 nice_menus-class-not-id-363366-4.patch1.49 KBadd1sun

Comments

add1sun’s picture

Version: 6.x-1.3 » 6.x-2.x-dev
Category: feature » bug

Yep, I'd consider this a bug. Most of the time there isn't a need to ID everything and classes are better, especially for "small" things, (straight from the mouth of Dave Shea ;-)) so moving this to a bug to be fixed.

diond’s picture

This would be a great change to see that could help prevent possible id conflicts in complex layouts. Thanks add1sun!

add1sun’s picture

Status: Active » Needs review

Patch to move the id to the class. We'll need to document this in the upgrade docs as well for folks that have CSS relying on this.

add1sun’s picture

StatusFileSize
new1.49 KB

ugh, didn't attach the patch....

add1sun’s picture

Status: Needs review » Fixed

Committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.