|
home / bulletins / 13 / page 2
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]
|
