HierMenus CENTRAL: HierMenus In Progress. Controlling Rollovers from HierMenus (1/2)

[next]

Synchronized Link Rollovers

D.M Ragle, January 29, 2004

Version 4 of HierMenus introduced, for the first time, permanently visible menus; that is, menus which were created and displayed when the page loads without requiring a specific link rollover for activation. These types of menus quickly became (and still remain) popular, since they allow all of the menu creation logic and configuration--including the configuration parameters for the topmost menu--to be controlled by HierMenus without requiring separate HTML on the page.

Such an implementation is not without drawbacks, however. First, earlier HierMenus versions did not support embedded image rollovers. Though you could create the top level menu so that it was completely image based (using image tags embedded in the item descriptions--see FAQ #2 if you are unfamiliar with this capability) there was no way to specify image rollovers for those top level menu items. This first drawback was corrected with the release of HierMenus 5.3, which introduced support for embedded image rollovers.

The second, and more serious of the permanently visible menu drawbacks still remains. If a user hits a page with a JavaScript disabled browser, or an older browser that HM doesn't support, the permanently visible menus will not be displayed. As HierMenus is entirely JavaScript based, it can't offer a built in defense for this possibility, so we recommend that users opt for pop-up based menus in their page designs whenever possible. With a pop-up based menu design, JavaScript disabled browsers will still at least be able to visit your top level of links (namely, the ones that would pop-up the menus in an HM supported browser) even though they cannot see the pop-up menus themselves.

Pop Up Designs and Rollovers

A minor problem with pop-up menu designs arises when developers attempt to use image rollovers for their top level menu links. Consider the following menu design, which we borrowed from our parent site internet.com and have slightly adapted for clarity in this tutorial:

The above is a typical implementation of HierMenus. Rollover behaviors affect the look of the top level options, which are defined as standard in-page HTML links. The menus, in turn, pop-up from additional statements embedded within the mouseover handlers. In this example, a typical link looks like this (line wrapped for better display):

<a onmouseover="HM_f_SwapImage2('developer','developer_but_on.gif'); 
                HM_f_PopUp('HM_Menu83',event)"
   onmouseout="HM_f_SwapImage2('developer','developer_but_off.gif'); 
               HM_f_PopDown('HM_Menu83')" 
   href="https://www.internet.com/sections/webdev.html">
   <img src="developer_but_off.gif" width="161" height="20" 
        border="0" name="developer" alt="Developer" /></a>

(Note that there are many, many ways to define and implement image rollovers; a full discussion of the topic is outside the scope of this article. For our purposes here, we've chosen a name-based image identification method for compatibility with older browsers that do not support image IDs, and for easier integration with the HierMenus code, which we will be discussing momentarily.)

While the above configuration works well enough, you may have already noticed one visual weakness in our design. When the user rolls over a link, the image swaps as desired, and the appropriate menu is displayed next to the mouse pointer, as we intended. But when the user rolls over the menu itself, the top level rollover image reverts to its old "off" state. This is because the HTML page itself has no way of knowing that the menu is "a part of" the top level link, and that the rollover image should therefore remain "on."

So what can be done about this annoyance? Fortunately, HierMenus provides a means whereby you can synchronize the top level link rollovers with the actual display/hiding of the menus themselves.

[next]