HierMenus CENTRAL: HierMenus In Progress. HierMenus 5.2 Release Notes (3/6)

[previous] [next]

Keep In Window--NOT

By default, HierMenus will automatically reposition both called top level (i.e., menus that are spawned as a result of the onmouseover handler of an in-page HTML link) and all child level menus (with the exception of position-under menus) such that the entire menu appears within the visible portion of the user's browser window, if possible. Menus that don't fit vertically within the page will be made scrollable (so long as the HM_xx_ScrollEnabled parameter is set to true). In the great majority of HierMenus configurations, this is the exact behavior that is desired, as it allows users to see menus that might otherwise be "invisible" because they are configured to pop-up outside the viewable area of the browser.

There are, however, situations where this default "Keep In Window" behavior is undesirable, and in fact can be quite annoying to site visitors. One of the more common scenarios where this behavior is problematic can be seen in the following example of a fictitious site (opens in a new window):

MySite.com--before Keep In Window overrides

On this page, a masthead graphic describes the site and drop down menus are attached to graphical navigational links just below the header. These drop down menus are quite tall, and even though they're positioned to appear beneath the header:

HM_Array1 = [
[,200,115,,,,,,,0,0,0,0,0,0,,,,0,0,0],

the height of the menus forces HM to reposition them upwards such that as much of the menu as possible is displayed within the browser window. The result is a frustrating phenomenon: when rolling over the Features link, both it and the Demos link are hidden by the newly repositioned Features drop down menu! Since the menus automatically appear--and are automatically repositioned--when the user rolls over the graphical links, the graphical links themselves cannot be clicked, and getting to a link that is now hidden requires the user to wait until the initial menu is itself removed. Clearly this is not a desirable or friendly situation for your site visitors.

Beginning with version 5.2 of HierMenus, you can now override the Keep In Window behavior for all or specific top level menus. The new parameters that enable this override are documented below.

 HM_GL_TopKeepInWindowX and HM_PG_TopKeepInWindowX

Description:

Indicates whether or not HM should horizontally (left/right) reposition called top level menus such that as much of the menu as possible is displayed within the viewable portion of the user's browser window. If true, menus will be repositioned horizontally; if false, they will be displayed based on the initial positioning coordinates (i.e. where they would normally be displayed, regardless of whether the menu is visible in the user's browser window or not).

Value:

Boolean (true/false,1/0) or any expression that evaluates to a true/false value.

Comments:

In addition to being a Global or Page specific parameter setting, TopKeepInWindowX can also be applied specifically to a menu tree, as the 22nd entry in the first array of each top level menu entry in HM_Arrays.js. This option applies only to top level called menus. Child menus will continue to follow the default keep in window behavior, and to remain consistent with prior versions of HM both permanently-visible top level menus and position-under child menus are not automatically repositioned when they are displayed.

Examples:

Top level menus are automatically repositioned horizontally if necessary:

HM_GL_TopKeepInWindowX = true;

When it is popped up, the top level menu in menu tree 6 is not automatically repositioned horizontally, but is repositioned vertically:

HM_Array6 = [
[,200,115,,,,,,,0,0,0,0,0,0,,,,0,0,0,0,1],

Default:

True. By default HM will attempt to reposition top level menus horizontally so that the majority of the menu appears within the viewable portion of the user's browser window.

 HM_GL_TopKeepInWindowY and HM_PG_TopKeepInWindowY

Description:

Indicates whether or not HM should vertically (up/down) reposition called top level menus such that as much of the menu as possible is displayed within the viewable portion of the user's browser window. If true, menus will be repositioned vertically; if false, they will be displayed based on the initial positioning coordinates (i.e. where they would normally be displayed, regardless of whether the menu is visible in the user's browser window or not).

Value:

Boolean (true/false,1/0) or any expression that evaluates to a true/false value.

Comments:

In addition to being a Global or Page specific parameter setting, TopKeepInWindowY can also be applied specifically to a menu tree, as the 23rd entry in the first array of each top level menu entry in HM_Arrays.js. This option applies only to top level called menus. Child menus will continue to follow the default keep in window behavior, and to remain consistent with prior versions of HM both permanently-visible top level menus and position-under child menus are not automatically repositioned when they are displayed.

Whether or not scroll bars are applied to a vertical menu depends on the HM_xx_ScrollEnabled parameter, and the resulting position of the menu on the screen. If the lower portion of the menu overlaps the bottom border of the screen and HM_xx_ScrollEnabled is set to true, then scrollbars will be applied.

Examples:

Top level menus are automatically repositioned vertically if necessary:

HM_GL_TopKeepInWindowY = true;

When it is popped up, the top level menu in menu tree 6 is not automatically repositioned vertically, but is repositioned horizontally:

HM_Array6 = [
[,200,115,,,,,,,0,0,0,0,0,0,,,,0,0,0,1,0],

Default:

True. By default HM will attempt to reposition top level menus vertically so that the majority of the menu appears within the viewable portion of the user's browser window.

Let's now have a look at the example link above, only this time we'll set HM_PG_TopKeepInWindowX to true, and HM_PG_TopKeepInWindowY to false:

MySite.com--after Keep In Window overrides

The result is a cleaner menu display that will decrease confusion for site visitors.

In addition to these enhancements, a few corrections also made their way into HierMenus 5.2, many of them centered around some sticky situations involving Opera 7 in cross-frames implementations.

[previous] [next]