home / documentation / setup / applying menus / cross frames primer

Cross Frames Primer

Our cross frames primer provides general information applicable to all cross frames HierMenus implementations, as well as the advantages and disadvantages of each of the two cross frame implementation methods.

Do You Really Mean Cross Frames?

When we discuss cross frames support for HierMenus, we are discussing the use of menus in this context: defining a set of links in one frame that, when clicked or rolled over, spawn popup menus in another frame. If you need to launch a page from a menu item in a different frame (but the menus themselves are all contained in a single frame--both the menus and the links that will spawn them) then you do not need to implement "cross frames" functionality, as this feature can be accomplished using javascript: URLs. See FAQ #3 for further information.

Permanent Menus Displayed in Content Frame

Before we discuss the differing methods of implementing HierMenus in a cross frames fashion on your site, note this important point which effects both of the methods described below.

You can use permanently visible menus (a feature originally introduced in HM4) in a cross frames implementation. The menus themselves, however, (including the permanently visible portion) will be displayed in the content frame, and not the navigation frame. Therefore, to popup menus in the content frame from the navigation frame you must define "hotspots" by attaching onmouseover and onmouseout handlers to HTML links within the navigation frame (this is explained fully in step 3 of the setup instructions).

In most cases, this will be the preferred setup method for users anyway, as defining hotspots allows the main links of the navigation page to always be present and available to users--even if they are using an unsupported browser or have JavaScript disabled.

Standard Cross Frames

Our standard cross frames implementation method was introduced in HierMenus version 5 (and in fact, was the only cross frames implementation method available in version 5). The main point--and feature--of the standard cross frames implementation method is that the necessary modifications to support HierMenus are applied to the framesets and the navigation page. Little to no changes are necessary to your content pages.

The one exception to this rule has to do with HM 6's new support for style sheet class names. If you are using the special HM class name configuration parameters in a standard cross frames implementation, then your style sheet rules (where you actually define the classes) must exist in the content pages--i.e., the pages the menus will appear within. For more information on the use of class names in HM, have a look at our Using Classes Mini-Tutorial.

While elegant and easy to implement, the standard cross frames implementation method does suffer from some inadequacies:

Content and Navigation in same frameset

The content frame and the navigation frame (i.e., the page in which the scripts and popup links will be loaded) must exist within the same frameset tag of the page. It is not required that the two pages be adjacent to one another, though we suspect this will be the most common arrangement. It is not possible, using the standard cross frames implementation method, to dynamically subdivide your content frame (by loading a page in the content frame that has its own frameset).

Multiple Navigation Frames Not Allowed

You cannot have more than one navigation frame with links that spawn menus in the content frame. For example, you cannot have links in two navigation frames, which border the content page on the right and the left, both of which popup menus in the content frame.

In a similar vein, you cannot load both a cross frames and a stand alone HM implementation in a single frame simultaneously. That is to say, if you have a two frame setup, with HM loaded in the Navigation Frame and producing menus in the Content Frame, you cannot also then have a stand-alone HM version loaded directly within the content frame at the same time. (In other words, you cannot spawn menus from links within the content frame in addition to the links that spawn menus from the navigation page.)

Opera and History

When using the standard cross frames implementation in Opera, you may find that the menus occasionally stop working when you return to a historical page (using the back button). We included several updates to the code throughout the version 5 release cycle to address this problem and in general our support is very good. Nonetheless, the problem does still occur, though it's fairly rare.

Alternate Cross Frames

In the alternate cross frames implementation method, both split content frames and multiple navigation frames are allowed in cross frame implementations. Additionally, the Opera history problems should be moot (we're crossing our fingers). So what's the catch?

The catch is that in the alternate cross frames implementation method, both the navigation frame pages and the content frame pages must be modified to include scripts. In fact, the content frame pages will be modified in almost an identical method to stand alone (non-framed) HierMenus implementations. And the navigation pages must include a brief script to facilitate the necessary cross frames communication for the menu displays.

Cross Domain Scripting and the Same-Origin Policy

Finally, before we leave this cross frames primer, note one important issue that effects both of the cross frames implementation methods, and that you must understand before you attempt to install a cross frames implementation of HierMenus on your site.

All modern browsers implement security restrictions such that pages loaded into one frame cannot manipulate pages loaded into a second frame unless both pages were retrieved from exactly the same domain. This "Same-Origin Policy" exists to protect surfers from frame "spoofing," setting up a frameset that loads scripts in one frame that could potentially read and write sensitive data from a second frame that contains a page loaded from an entirely different site (such as a credit card order form, for example). HM cannot override this security restriction (nor can any DHTML script), therefore if pages are loaded in the content frame of the site from a different domain from that of the frameset and the navigation page, then no popup menus will be displayed in those pages.

JavaScript provides the document.domain property allowing cooperating sites to remove this restriction for their particular Web sites, i.e., pages which specifically set the document.domain property can override (to an extent) the Same-Origin policy to allow scripts such as HM to read and write values across frames as if both pages did come from the same domain.

As this restriction applies to all JavaScript code, the use of document.domain is somewhat out of the scope of our typical HM documentation. However, if you should need it, be aware of two important limitations to its use:

1. The domain name set in document.domain must itself be a suffix of the actual domain that the page came from in the first place. For example, if you retrieve a page from "mySite.myDomain.com", then you can set document.domain="myDomain.com" but you cannot set it to document.domain="microsoft.com" or even document.domain="www.myDomain.com"
2. When using document.domain we've found that it's necessary to include it in all pages of the site that will be loaded into the frames; including the framesets and the navigation pages themselves. I.E., if document.domain is set in any one page of the frameset, it must be set in the frameset and the navigation frame, as well.