@djpaul
I’ve been working on this over here http://tempsg.com/
I was doing it with a if ( is_nav_menu( ‘BuddyPress’ ) )
show menu
else
show the hard coded links
edit// 
ok scrub that modemlooper has sorted it.
I’ll take a look in the morning, the new menus have a draw back at the moment in not doing nested dropdowms so not sure how you’ve forced that behavior, I implemented them in pcwriters plugin using a top level li element as exists for adminbar elements.
Issues with the way the nav is floated right and drop downs going off the edge. You might have to rethink the top nav to the left. This is really apparent when you double nest.
no ‘display:none;’ please, left:-999em; / left:0;
What are intending on doing for users having to still use IE6 ?
I only messed with it yesterday as I wanted to add drop downs to my themes. I thought BP wasn’t going to work with IE6 anymore. Also that css is the 2010 with id’s edited. So why would BP fix IE bugs when 2010 does not? Fixed to accommodate out dated and broken IE6
If twentyten doesn’t work with IE6 then I don’t see why BP Default should work with IE6 either. But if it mostly does, so should we.
I’m not against moving the nav menu to the left of the screen, but we’d need a really really good reason to do that.
@modemlooper Looks cool! Let me know how you get on
No biggie for the IE6 display:none bug. I changed it per @hnla‘s suggestion.
@djpaul an issue: when creating a menu link thats not a page just a straight url link to say /activity it doesn’t add the class to make the tab look selected.
check it by clicking activity and then another tab http://tempsg.com/
I’ll take a look after work. Not sure if we can do anything about it.
Had intended on looking in detail at new menu arrangement but have had a really problematic time running 1.3 on a clean relatively fresh and mainly unused WP 3.0.1, not sure what the issues are at this moment but not feeling the love for these new page approaches to the main components as they hang around – obviously – despite reverting to 1.2.6.
May I suggest we have a consistent hover over colour just from a usability point of view? Even a hover and current would be the ideal I would go that stage further. I totally agree the top and sub / drop menus should both have a hover colour but it should also be the same. I also would lean to the menus actually being the same colour not the different white. My reason would be 2 fold: contrast / visual and usability.
Rather than doing a 2 cents with another version and creating a too many cooks situation I reckon seems sensible to add to the version you’ve come so far with @Modemlooper? May I suggest some possible enhancements as a result of this thinking?
I’m thinking we could perhaps add the following possible enhancements:
1. Hover / current styling
2. Darker consistent to top menu styling
3. Bottom border rounding on the drop down perhaps to match the top rounding on the top menus?
The current nav tabs has no hover state only a current. So are we adding one? If so suggest colors 
I played with a rounded bottom, not really a fan of the way it looks when you have a third ul but if everyone wants it then we should add it.
Well logic would dictate to some extent simply replicating the adminbar styling more or less.
the opportunity should be taken though of getting rid of the graphics and replacing them with versions that aren’t 1×1 and if adding hover it should also be matched with :focus
I would suggest ignoring the admin bar as it is likely to change to the new admin bar present in WP 3.1. I think it just needs to remain internally consistent with BP-Default.
+1 for BP-Default Menu bar same styling maybe hover a few shades up to highlight hover.
I can try haven’t used Tortoise to create patch before. You agree though, on the depth param?
@modemlooper the cause for custom link nav items not getting the style for the “selected” page is as a result of _wp_menu_item_classes_by_context() in WP Core, which is doing what it’s meant to do.
There’s no good hooks or filters we can use. We’re going to need to style ul#nav li.current-menu-item the same as ul#nav li.current_page_item. We can change the selector on line 150 of the CSS file. Anyone see any problems with styling current-menu-item?
@hnla I’ve replied to the trac
Current_menu_item would be my preference to be honest as a styling option.
It doesn’t add .current-menu-item to those types of links. That’s what I meant before. Only pages add that class as well as .current_page_item to a menu li.
li id=”menu-item-91″ class=”menu-item menu-item-type-post_type menu-item-91″>Activity
li id=”menu-item-104″ class=”menu-item menu-item-type-post_type current-menu-item page_item page-item-102 current_page_item menu-item-104″>Forums
How are you implementing the tabs? Will users need to create these tabs via pages? Or will it be pre-populated? If somebody creates custom links for the tabs then .current-menu-item does not get added to them. This seems like WP is missing something. So it will look funky if some tabs have current states and others do not. I’m sure the custom links option is mainly for external links but seems like a WP failing here
The new menus have oversights, out of interest do we know what if any changes may be implemented for nav menus in 3.1 if there are it would make sense to add that patch to the mix for testing – given that 1.3 will release after 3.1?
@modemlooper Components in BP 1.3 will exists as Pages in WordPress. The Pages will be created as part of a new Setup procedure.
@modemlooper, if I create a custom link item to “example.com/activity”, and then click on that link, it loads the correct page and applies the ‘current-menu-item’ class to the li element. I’m testing this on BP trunk and WP 3.0.1.
If I put a Page into my menu, it gives it the class ‘current_page_item’ as it recognises it is part of the WordPress object hierarchy.
