home / bulletins / 12 / page 2

[previous]

Using UponDisplay and UponHide with Rollovers

You may recall from one of our previous bulletins that the UponDisplay (or evaluate_upon_tree_show, as it is called within a menu array) and UponHide (or evaluate_upon_tree_hide) parameters allow us to execute any JavaScript expression each time a menu tree is displayed or hidden. As these parameters automatically fire only when each individual menu tree is displayed/hidden (and not refired with every display and hide of child menus of the tree) they are exactly what we need to synchronize our menu displays with our top level link rollover behavior.

On the previous page, we demonstrated one possible configuration of links for use in a HierMenus pop-up design. Let's have another look at the onmouseover setting for one of these particular links:

...
onmouseover="HM_f_SwapImage('developer',
                   'developer_but_on.gif'); 
             HM_f_PopUp('HM_Menu83',event)"
...

This is simple enough; the image rollover code (which we've defined as HM_f_SwapImage) comes first, followed by the HM code to pop-up the desired menu for this link.

When synchronizing the rollovers with the HM menu display, the first step is to move the image rollover code into the menu array definition itself. Specifically, the code to display the "on" image goes in the array's evaluate_upon_tree_show parameter, and the code to redisplay the "off" image goes in the array's evaluate_upon_tree_hide parameter. Continuing with the above example, the menu array for HM_Menu83 might begin something like this:

HM_Array83 = [
[,                      // menu width
 "mouse_x_position+10", // left position
 ,                      // top position
 ,                      // font color
 ,                      // mouseover font color
 ,                      // background color
 ,                      // mouseover background color
 ,                      // border color
 ,                      // separator color
 ,                      // top is permanent
 ,                      // top is horizontal
 ,                      // tree is horizontal
 ,                      // position under
 ,                      // top more images visible
 ,                      // tree more images visible
 "HM_f_SwapImage('developer','developer_but_on.gif')",
                        // evalute upon tree show
 "HM_f_SwapImage('developer','developer_but_off.gif')"],
                        // evalute upon tree hide
...

Now that HierMenus is controlling the image rollovers, it's important to remove the rollover code from the actual links themselves; otherwise both the links and HM will attempt to swap the images--with undesirable results. Our new link definitions now look something like the following:

...
onmouseover="HM_f_PopUp('HM_Menu83',event)"
onmouseover="HM_f_PopDown('HM_Menu83')"
...

Or, in other words, they'd look just like a standard HM pop-up implementation.

The result? Pop-up menus with external links that "remember" the state of the image rollover when the user rolls over the child menus. Have a look for yourself:

Rollovers in Older Browsers

Though it effects a very, very small subset of browsers, there remains one minor problem with our solution. A browser that does not support HierMenus--but does support basic image rollovers--will not display rollovers on the top level links. If you think about this, the reason is obvious: the rollover code for the links is handled by the HierMenus UponDisplay and UponHide mechanism; thus, if HierMenus is not loaded, that mechanism is not in place. In this case, the rollovers don't function.

As we mentioned, active browsers that will support image rollovers but will not support HierMenus is an extremely small number; small enough that most WebMasters will simply allow those older browsers to not receive image rollovers and not even bother with the following instructions. But for those who want their rollovers to be synchronized with their HierMenus and still be applied to the widest possible variety of browsers, the following JavaScript sleight of hand will do the trick.

When implementing a pop-up based design, four "dummy" functions are defined on each page:

function HM_f_PopUp(){return false};
function HM_f_PopDown(){return false};
popUp = HM_f_PopUp;
popDown = HM_f_PopDown;

These functions will prevent browsers from triggering errors in the event that a pop-up link is rolled over before the HierMenus scripts have been loaded, or in browsers that don't support the HierMenus scripts at all. (See our setup instructions if you are unfamiliar with these functions and their declaration.) Typically, they are defined as do-nothing functions, as in the above. But there's no rule that says they must be dormant!

Instead of do-nothing functions, let's modify the above code somewhat so that our "dummy" copies of HM_f_PopUp and HM_f_PopDown actually do something useful--namely, execute our image rollover code. Continuing with the internet.com example from earlier on this page, here's what the new versions might look like:

function HM_f_PopUp(menuName,e,imgName,imgSrc){
   HM_f_SwapImage(imgName,imgSrc);
   return false;
};
function HM_f_PopDown(menuName,imgName,imgSrc){
   HM_f_SwapImage(imgName,imgSrc);
   return false;
};

And then, in our links, the new onmouseover code looks like this:

...
onmouseover="HM_f_PopUp('HM_Menu83',event,
       'developer','developer_but_on.gif')"
onmouseout="HM_f_PopDown('HM_Menu83',
       'developer','developer_but_off.gif')"
...

Until the HM code is loaded, these functions will take the HM_f_PopUp calls from the image links and simply pass the additional information (the name of the image and its new source location) to the image swap routine. Once (and if) the HM code is loaded, HM will automatically redefine HM_f_PopUp and HM_f_PopDown to its own internal versions, which will quietly ignore the additional information and instead control the rollovers via the evaluate_upon_tree_show parameters. Of course, this discussion assumes that your swapping routine is compatible with the older browsers that will execute your new versions of HM_f_PopUp and HM_f_PopDown; you'll need to test that behavior out yourself for best possible results.

Update (6/14/2004): On this last point, that of supporting basic rollover behaviors in older browsers that don't support HM, there is one error and one necessary clarification that have been brought to my attention.

First, the error. In HierMenus 4, 5, and 6 the "dummy" HM_f_PopUp and HM_f_PopDown functions are automatically redefined in the HM_Loader.js. Thus, if you follow the steps above, you will find that in some cases (specifically, those cases where the HM_Loader.js file is loaded, but further browser sniffing excludes the browsers from running HierMenus), the above image swap will not work; since the dummy definitions in the HM_Loader.js will override those that you manually adjusted within your page. To get around this, simply comment out the dummy function definitions in HM_Loader.js; i.e., change this:

function HM_f_PopUp(){return false};
function HM_f_PopDown(){return false};

to this:

// function HM_f_PopUp(){return false};
// function HM_f_PopDown(){return false};

And the clarification: In HierMenus 6, the above approach will not work as described, because this statement: "...which will quietly ignore the additional information and instead control the rollovers ..." is no longer true. Specifically, the HierMenus 6 HM_f_PopUp does, in some cases, expect and utilize parameters in addition to the MenuID and event parameter. Thus, you should not use the above example directly in HM 6 implementations.

Conceptually, however, you can arrive at the same result in HM6 by simply using different code (that does not rely on additional parameters passed to HM_f_PopUp). For example, one possibility is to simply define your rollover routine such that it examines the MenuID and selects the appropriate image rollover; i.e.

function HM_f_PopUp(menuName,e){
   var imgName,imgSrc;
   if(menuName=="hm_m_developer") {
      imgName="developer_img";
      imgSrc="developer_but_on.gif";
   } 
   else if (menuName=="hm_m_devx") {
      imgName="devx_img";
      imgSrc="devx_but_on.gif";
   } 
   else if (menuName=="hm_m_earthweb") {
      imgName="earthweb_img";
      imgSrc="earthweb_but_on.gif";
   }
// etc.
   HM_f_SwapImage(imgName,imgSrc);
   return false;
};

That's a bit crude (with some creative image naming you could do away with the if/then block entirely, for example) but it should give you an idea as to how to approach the problem. Again, the concept is the same: build your rollover logic into the dummy HM_f_PopUp and HM_f_PopDown routines so that if HM isn't loaded, the rollovers still happen.

Click the link below (opens in a new window) for an example of this technique, including an HM6-based configuration file:

HierMenus 6 Synchronized Rollovers Example

Conclusion

With a small amount of code and configuring, we've turned our disjointed top level rollovers into a professional menu display that allows the rollovers to "follow" the state of the displayed menus themselves. Feel free to adjust the code in this tutorial to your own liking; and remember that the evaluate_upon_tree_show and evaluate_upon_tree_hide parameters will accept practically any string-formatted JavaScript expression.

[previous]