I first sent this to Marcus via email and he has requested it be added to the forum so others can benefit from the answers.

Marcus's Answer:

Looks like it's moving nicely along!

The extended menu.

It looks like the stacking order (z-index) of the module info bar and the main menu are conflicting. You can see that it actually works if move your mouse downward along the extreme right of the extra buttons just outside the info bar.

Open up menus.css and remove the duplicate "z-index: 10;" entry from .main_menu. Leaving in just the "z-index: 250;" will make it rise above the module info bar (that has z-index 200) and remove the problem.


The module menu.

Open up skin_menus.php and edit $skin['module_menu_unit'] — make it read:

<li id="module_menu_[[MODULE_IDENT]]_[[MODMENU_NUM]]_container" class="module_menu_container [[SELECTED]]"><a href="[[MODMENU_LINK]]" id="module_menu_[[MODMENU_NUM]]_[[MODMENU_NUM]]_link" class="[[SELECTED]]">[[MODMENU_NAME]]</a></li>

Thanks Marcus.  That did it.

I was wondering - was that a bug?  I was wondering because I had similar issue modifying the Main Menus, where the spacing seemed to go off.

Specifically, when moving your cursor over the main menu, in the default template and also in mine, when you move your cursor over the side of a menu item, the background changes before the link is active.  This happens, as I see it, because the background change includes the left and right side table column blocks and the link is in the center td.  

I believe this presents a problem, to me a somewhat significant one from the perspective of usability, as someone moving their cursor over the side of a nav button and seeing the change of state would assume it is now active, but it is not (until the cursor moved more to center and the text color changes).  Users would invariably get frustrated with the fact that the navigation buttons are not working, or seem to sometimes not work because they would likely just be acting unconciously to standard input.

I wanted to solve this problem with my own design which did not need the left and right td backgrounds by simply changing the width of each td on the sides (classes top_button_right and top_button_left) to 0, (and a right border 1px for the border between menu items applied to the link tag), but the result was some unexpected spacing that threw it off in a wierd way - this time in Safari (Mac) and Explorer (PC testing).  It seemed that the background highlight change per link was set off to the right by something like 6 to 12 pixels.  

Not a big deal as I worked it out in another way, but I don't love the solution because I am still stuck with navigation that works in the way I explained up front with this, that a cursor over the button causes a state change before the link is actually active. (I figure I could change the code so that the state change does not include the right and left table cells, but that seemed like more code to keep track of on updates and would also cause the the highlight states per menu item not to be right up against each other, which I don't love aesthetically at all.

So I thought to ask if there was something easy that you knew of to make that work better?

Thanks,

OOPS!  I take it back - there does seem to be an issue that came up.  When I made the change above per the Module Menu topic above, the empty tabs inserted the code [[MODMENU NAME]] into the empty tabs for that module, which were empty before.  Obviously one way to fix this is to remove the empty boxes per Modules > Menu Builder > Sites - but I thought you might have a slight change in the code to fix it so those empty tabs don't do that?

FYI - In that file, I swapped out the code you gave me above for the whole line 115, leaving in place before it on line 114:

$skin['module_menu_unit'] = <<

and after it on line 116:

WIC;

...as I was not completely clear on what to edit.

screenshots added below.  You can view site now here: http://174.132.77.99/~rispoli/community/index.php?module=site

Before changing the skin_menus.php

After Change:

also in section headers (I think here the {{MODULE_NAME]] shows up when the module that was initially specified for this was deactivated, at which point I would guess it would normally default to a blank space...:

Not sure if it is helpful for more examples or overkill, but hopefully just helpful - example in another context - created a blog and tried to create another one (I see a hint at understanding the "Parent" setting in the Module Masks, I understand that) - not pointing out the actual warning, just the fact that is presented with the [[CPARENT]] instead of what was supposed to be there:

To get rid of the [[MODMENU NAME]] code that now appears, simply remove the spacers (marked "x|" as the name) in Admin CP > Menu Builder > Module Menu. If you want to keep the spaces but want to get rid of the unparsed tag, open up class_templates.php #1974, and replace the following:

            $tmp['module_menu_name'] = "";
            $tmp['module_menu_link'] = "";

With this:

            $tmp['modmenu_name'] = "";
            $tmp['modmenu_link'] = "";

The above is a bug that has been fixed for the next release.

--

I notice that the [[CPARENT]] language tag (that should translate into "Blog" — "cparent" as in "capitalized parent") doesn't get parsed properly. Flagged for investigation and fixing.

In general, these are unparsed language tags, and where they still exist, I will need to check the core to see where they are parsed and why the language strings don't get parsed in as expected.