|
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:
- 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"
- 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.
|
