HierMenus CENTRAL: HierMenus In Progress. Status Report: HM6 Preview (2/4)

[previous] [next]

Support for Older Browsers

HierMenus version 6 offers continued support for Internet Explorer 4 (Windows only) and Netscape 4. All capabilities currently supported in version 5.3.1 of HierMenus will continue to be supported in Netscape 4 and Internet Explorer 4 in version 6 of HierMenus.

Most of the newer features of HM6, however, will not be implemented for these older browsers. Our reasons for this are twofold. First, many of the new features are simply not supported in these older browsers, making them impossible to implement (at least in any plausible way). Netscape 4, for example, provides no direct method to support opacity settings. Second, continuing to develop the independent scripts for these older, non-DOM compliant browsers is no longer cost-effective for us. We continue to provide support for these browsers because some of our clients have specifically asked about them. However, we cannot continue to agressively develop independent scripts for browsers with such a dwindling (and it will only get worse) market share.

Finally, we want to inform you about one browser fatality in HierMenus 6: Internet Explorer 5 on the Macintosh. Despite our best efforts, we continue to uncover menuing problems in this browser (see our Known Issues page for those we know of) for which we can discover no graceful workarounds. This, combined with Microsoft's decision to produce no new versions of Internet Explorer for Mac led us to our decision to drop support for Mac IE 5 entirely in HierMenus version 6.

Alternate Cross-Frame Methodology Provides Enhanced Cross-Frame Capabilities

Our HM cross frames support, as introduced in HM5, allows for the creation of frame based sites with navigation page links that, when rolled over, popup menus in the content frame of the site. Our original design allowed for all configuration changes in a cross frames site to be required only in the navigation page and the frameset itself; the actual content pages did not require modification. While elegant and efficient to implement, such a design was not perfect and did result in some inadequacies. The content frame (the frame in which the menus were to be displayed) was required to be defined in the same frameset block that defined the navigation frame (the content frame could not be later subdivided into two or more or more frames itself by a newly loaded page). And only one navigation frame was supported in a frame set; all the menu spawning links must exist within this one navigation frame, and no menu spawning links could be present in other navigation pages--or even the content frame itself.

Our standard cross-frames implementation works well for most framed sites that use it, so we'll continue to offer and support it in HM6. Additionally, we'll introduce a new cross-frames implementation methodology that remedies each of the above limitations: subdivided content pages and multiple navigation section framesets. The catch? Unlike our traditional cross frames approach, the new methodology will require that all content pages of the frameset include the HM Script itself. i.e., All content pages will require modification to appear as if they are, in fact, standalone HM pages. In addition, the navigation frameset(s) must also be modified to include a small "stub" script that enables the cross-frame communication between the links and the content page. While not as efficient as the standard cross-frames implementation, this new methodology will, (at the very least), provide HM implementors with a choice where there previously was none. And don't forget that HM uses external JavaScript file loads to pull in its scripts; once the user has downloaded the script once from your site further page loads will typically retrieve the cached version of the script, making the difference in overall download impact between the two implementations negligible.

New Menu Positioning Options

New menu positioning options in HM6 provide site designers with increased control over the exact location at which individual menus are displayed.

HM6 continues to support the positioning of menus based on x/y coordinates and the parameters that control these positions allow for both numbers (pixel-based x/y locations) as well as JavaScript expressions that return the exact x/y location that the developer desires. In addition, new keywords and included JavaScript functions allow these x/y positions to be retrieved based on the existing page dimensions and or existing elements already on the page.

• New Keywords. HM5 offered the mouse_x_position and mouse_y_position keywords for use in menu x/y placement. In HM6, these keywords will be changed to HM_default_x_position and HM_default_y_position, which we will explain further in a moment. In addition to these existing keywords, the new keywords HM_window_left_edge, HM_window_right_edge, HM_window_top_edge, and HM_window_bottom_edge have been added, allowing you to position menus based on current browser window dimensions (such as HM_window_top_edge+20).

  The new HM_default_x_position and HM_default_y_position keywords offer a new degree of control specifically over the placement of child menus when they appear. While these keywords still allow for the placement of popup menus based on the current location of the mouse (i.e., for popup menus the default position is the mouse position), they also allow you to pinpoint the location of child menus based on an offset from where HM would typically put them. For example, if you specify PositionUnder menus for a horizontal menu, you may decide you don't care for the exact location HM places them in; preferring instead that they be slightly offset to the left. In previous HM releases this was not possible; since HM completely controlled the placement of child menus when so designated. In HM6, however, you can accomplish your goal with two simple parameters, one on the parent item and one on the child menu itself:

  PositionChild:"below",ChildMenuX:"HM_default_x_position-10"

• New Functions. As part of the HM5 release cycle, we introduced the HM_f_GetMenuDimension routine, which site implementors could plug into their menu configurations, allowing them to base their menu positioning on the right or bottom edges of the menus themselves. This routine is now included by default in HM's loader file for easy access (and those that don't need it can always delete it to reduce the total download size of the HM files).

  Additionally, a new function is included in the loader file that allows implementors to retrieve the x/y location of an existing image or link within the HTML page (in later browsers, it will retrieve the x/y of virtually any in-page element). This position can then be applied to the position of an individual menu, either precisely or as a target location from which the menu should be offset a fixed distance.

  Unfortunately, the implementation of this particular function is not nearly as foolproof as we had hoped; and the fact is that nearly all browsers exhibit some quirks when using it. IE6, for example, will not retrieve the x/y position of relatively positioned elements properly; and Netscape 6.x has trouble locating elements that themselves have inherited border widths, or inline border widths specified with length units other than pixels, just to name a few.

  Nonetheless, we feel the new x/y retrieval routine will still be useful in the majority of cases (and many of the "quirks" cases we know of can be corrected by specifying alternate HTML in the creation of your target elements), and therefore we will include it with the loader file for your experimentation.

In addition to the above menu positioning extensions, HM will also now support fixed and follow-scroll menus. Fixed menus are currently supported in a limited selection of later version browsers, and provides the ability to "plant" a menu at a specified location of the browser window such that it remains there when the horizontal or vertical scrollbars of the page are changed. Fixed position menus exhibit no extraneous movement when the page is scrolled. In those browsers that do not support fixed menus, "Follow-scroll" menus are supported, allowing the menu to "follow" the scrolling of the page, gracefully sliding into their new positions just after the page is scrolled. Fixed menus are implemented in HM6 for only Gecko based browsers and Safari; while follow scroll menus are implemented for all browsers other then Netscape 6.0 and Netscape 6.01 (Netscape 6.0 and 6.01 support neither fixed, or follow scroll menus; but Netscape 6.1 and later do).

The latest browsers include display support for advanced object display characteristics such as filters and transitions. On the next page, we'll see how HM6 will allow you to apply these types of effects to your own menus.

[previous] [next]