SilverDisc Articles

Self Referencing Framesets

Published by Alan Perkins on 25th January 2010

Frames offer added flexibilty to the Web designer, such as the ability to ensure that branding and navigation are always on screen. Frames are therefore often seen as a "good thing" in the Web design community. However, without careful forethought frames present several problems, chiefly in the Web marketing arena. Before proceeding to consider those problems, let's define a few frames-related terms:

  • Frameset page (or "container") Page that contains the <FRAMESET>. The content of this page is not displayed by a frames-capable browser.
  • Framed page (or "pane") Page referred to by a <FRAME> in a frameset page.
  • Framed site Site (or subsite) whose home page is a frameset page.
  • Self-referencing frameset Frameset page that contains a frame referring to itself. (This article describes why and how to create a self-referencing frameset)

Now let's set the scene to show the problems. Let's suppose we have a simple little Web site consisting of five HTML files:

  • Index.htm Frameset page containing a three frame frameset: branding.htm, nav.htm and content.htm
  • Branding.htm Framed page containing branding
  • Nav.htm Framed page containing navigation - links to content.htm and sales.htm
  • Content.htm Framed page containing body copy for the home page
  • Sales.htm Framed page containing body copy to sell something

Functionally, index.htm (the home page of the site) initially displays like this:

branding.htm - contains header graphic
nav.htm (Links to content.htm and sales.htm)Body copy from content.htm

Consider what happens when a visitor to this site clicks the "Sales" link in the Navigation frame. Their view will change to show this:

branding.htm - contains header graphic
nav.htm (Links to content.htm and sales.htm)Body copy from sales.htm

Suppose that the visitor wants to create a link to the page they are now looking at (a mix of branding.htm, nav.htm and sales.htm). They can't, because the page does not exist. There are only five HTML files on this Web site, and none of them define the view that includes branding, navigation and sales. The problem with framed sites, therefore, is that you can only link to frameset pages on those sites, not framed pages. Linking to framed pages results in those pages being seen outside their container frameset, i.e. out of context - branding and navigation will be lost. Let's just spell out that problem explicitly by looking at three ways in which the problem manifests itself - the current URL, bookmarking and hyperlinking.

  • Current URL: The browser's current URL indicator (variously called the Address, Location or URL by different browsers) will always give the URL of the frameset document. It gives no indication of which content pages the user is currently viewing. This can reduce viral marketing opportunities, as visitors cannot refer their friends directly to the content they like - they have to say something like "go to the home page and click on the sales button you see on the left hand side, wait for that page to load then click on the Windows 2000 option"
  • Bookmarking: When the visitor sets a bookmark (or "Favorite") within a framed site it is the frameset page that is bookmarked, not the currently viewed set of framed pages. This (a) causes confusion to repeat visitors and (b) reduces bookmarking opportunities (only one bookmark per framed site), both of which can lower site traffic.
  • Hyperlinking: In many ways the essence of the Web is that other users should find your pages interesting and include links to them from their own pages. This is effectively impossible within a framed site: only the frameset page can be linked to with any meaning. Thus, hyperlinking opportunities are reduced.

All online marketing can be distilled down to the simple process of creating links to your pages from locations that have traffic interested in your proposition. By making linking and bookmarking more difficult, frames can reduce the effectiveness of online marketing.

However, some visitors will create links to the framed pages within a framed site. Most notable of these visitors are search engine spiders.

Links from search engines are, functionally, no different to links from any other site. That is to say that if other sites have trouble linking to framed pages on a Web site, then so will search engines. Search engine spiders have two choices when they encounter a <FRAMESET>

  • Do not crawl the frames in the frameset - in this case, entire framed sites will be excluded from the search engine's index unless there is a frameless version of the site.
  • Crawl the frames in the frameset - in this case, the search engine will create links to the framed pages, and they will be seen out of context (e.g. without branding and navigation) which can result in confusion for visitors from search engines.

Many techniques have been proposed for dealing with the issues surrounding rebuilding the framed context. Two such techniques are:

TECHNIQUEPROBLEM
Use JavaScript to automatically redirect back to the frameset pageAn auto-redirect to the frameset page will often mean that information that the searcher is looking for is not on the page they are redirected to. This is akin to spam.
Put a link on the framed page back to the frameset page for people to followA link on the framed page to the frameset page will appear even when the page is displayed in the frameset.

In other words, these techniques are problematic. They can result in confusion for visitors to the site.

A further problem with framed sites and search engines is link popularity. This factor is being used more and more by search engines (notably Google) to evaluate the relevancy of a page. With framed sites, links can only be made to the frameset page, which can give great link popularity to that page. But the frameset page often contains very little text to take advantage of that link popularity, hence it does not do too well in searches. It is the framed pages that contain the text, but their link popularity is much lower than the frameset page they inherit it from, so they do not do too well in searches either!

So, we want a technique that solves all the problems we have listed:

  • Lists the URL of the current content frame, increasing viral marketing opportunities
  • Allows bookmarking of any content frame on the framed site, increasing bookmarking opportunities
  • Allows hyperlinking to any content frame on the framed site, increasing traffic from other sites and (through increased link popularity) search engines

We have developed such a technique - we call it the self-referencing frameset.

The self-referencing frameset is a technique designed to allow frames to be used for branding, navigation and content, and to overcome the problems of hyperlinking, reduced link popularity, bookmarking and determination of location that frames present to Webmasters and Web users.

The technique involves making a framed page responsible for writing out its own frameset - a frameset that includes itself - if it detects that it is about to be displayed out of context. The framed page uses JavaScript to achieve this. JavaScript and Frames are very closely bound - the assumption is made that if JavaScript is available, frames are also available. If JavaScript is not available, the page is still usable, with all branding and navigation, but not in a frameset. This means it can be accessed by a wide browser park, including search engine spiders. All of the following criteria are fulfilled:

  • Lists the URL of the framed page in the Location/Address/URL field of the browser display, increasing viral marketing opportunities
  • Allows bookmarking of the framed page, increasing bookmarking opportunities
  • Allows hyperlinking to the framed page, increasing traffic from other sites and (through increased link popularity) search engines

To show the self-referencing frameset in action, let's return to our original example. We had a five page Web site:

  • Index.htm Frameset page containing a three frame frameset: branding.htm, nav.htm and content.htm
  • Branding.htm Framed page containing branding
  • Nav.htm Framed page containing navigation - links to content.htm and sales.htm
  • Content.htm Framed page containing body copy for the home page
  • Sales.htm Framed page containing body copy to sell something

Because we are now using a self-referencing frameset, we do not need a page just to define a frameset - the index page can now contain its body copy as well as the frameset, so we only need four pages:

  • Index.htm Self-referencing frameset containing body copy for the home page
  • Branding.htm Framed page containing branding
  • Nav.htm Framed page containing navigation - links to content.htm and sales.htm
  • Sales.htm Self-referencing frameset containing body copy to sell something

So, there are two self-referencing framesets, index.htm and sales.htm. Let's examine the code that writes the self-referencing frameset. In fact, it is just one line:

<SCRIPT LANGUAGE="JavaScript" SRC="writefs.js"></SCRIPT>

This line is placed between the HEAD and BODY sections in the index.htm and sales.htm documents.

writefs.js is responsible for two things:

  • Detecting whether the frameset needs writing out
  • Writing the frameset if necessary

The need to write the frameset is detected as follows:

var str = location.search; var writeFrames = (str.indexOf("nowritefs")) && (top.window.length == 0);

This gives a hint of what is to come. The self-referencing frameset works by writing a frameset reference to itself and passing a parameter of "nowritefs". [This is done to avoid infinite loops caused by some versions of JavaScript using the cached parsed copy of the page - but that's another story].

So the self-referencing frameset document is accessed using two different URLs - one of which does not contain "nowritefs" in the parameters, and one that does. The version that does not contain "nowritefs" in the parameters writes the frameset, and the version that contains "nowritefs" in the parameters does not write the frameset.

We now know whether we need to write the frameset. If we don't need to write it, we're done. Let's look at what we do if we need to write it. Firstly, we need to work out the URL of the frame we are writing. This is the same URL as the current document, but with a "nowritefs" parameter added:

if (str == "")
{ var bodyFrame = window.location + "?nowritefs"; }
else
{ var bodyFrame = window.location + "&nowritefs"; }

Finally, we are ready to write the frameset. For our simple frameset this is straightforward, so let's just look at all the code together. Here is the full source of writefs.js:

var str = location.search;
var writeFrames = (str.indexOf("nowritefs")) && (top.window.length == 0);
if (writeFrames) {
if (str == "") { var bodyFrame = window.location + "?nowritefs"; }
else
{ var bodyFrame = window.location + "&nowritefs"; }
document.write('<FRAMESET FRAMEBORDER="1" ROWS="100, *">', '<FRAME SRC="branding.htm" NAME="brand">',
'<FRAMESET FRAMEBORDER="1" COLS="200, *">', '<FRAME SRC="nav.htm" NAME="nav">',
'<FRAME SRC="', bodyFrame, '" NAME="bodyframe">', '</FRAMESET>', '</FRAMESET>'); }

Having written out the frameset in JavaScript, let's now consider what happens to both non-JavaScript and JavaScript compliant browsers.

Non-JavaScript compliant browsers

For non-JavaScript compliant browsers (such as search engine spiders, or users behind corporate firewalls) the frameset will not be written, so only the <BODY> content of the self-referencing frameset will be seen. This is fine - but what about the branding and navigation contained in the frameset? No problem - simply repeat the branding and navigation in the <BODY> section, using <NOSCRIPT> tags (consider using SSI or ASP to achieve this site-wide). So if nav.htm (the navigation frame) looks like this:

<HTML>
<HEAD>
<TITLE>Navigation Frame</TITLE>
<BASE TARGET="bodyFrame">
</HEAD>
<BODY>
<A HREF="index.htm">Home Page</A><BR>
<A HREF="sales.htm">Sales Page</A><BR>
</BODY>
</HTML> 

then put this code somewhere into the <BODY>s of the self-referencing framesets (index.htm and sales.htm):

<NOSCRIPT><A HREF="index.htm">Home Page</A> | <A HREF="sales.htm">Sales Page</A></NOSCRIPT>

You can do likewise with the branding:

<NOSCRIPT><IMG SRC="logo.gif" ALT="Branding logo"></NOSCRIPT>

JavaScript compliant browsers

JavaScript compliant-browsers will write the frameset. The extra branding and navigation information will not be displayed since it is within <NOSCRIPT> tags.

Once the frameset is written, a decision has to be made on targetting. Hyperlinks can be targeted to two possible locations:

  • The body content frame <BASE TARGET="bodyFrame"> This has the advantage that only the body content frame is redrawn - branding and navigation remains on screen at all times. The disadvantage is that browsers don't report the current URL correctly after navigation has been performed, which can cause confusion to visitors.
  • The top frame <BASE TARGET="_top"> This time the entire frameset is redrawn each time a hyperlink is followed. This doesn't usually take long because most of the frames are cached. The huge advantage is that browsers report the URL correctly so normal visitors won't be confused. As described earlier in this article, this will improve the marketing of the page. This is the targetting method we prefer.

No matter which targetting method you choose, add or modify the appropriate <BASE TARGET...> tag to both the navigation and body content frames.

Summary

  • Decide upon pages that are to be self-referencing framesets
  • Add JavaScript include code to turn them into self-referencing framesets
  • Add <NOSCRIPT> HTML to maintain branding and navigation for scriptless browsers and search engine spiders
  • Add or modify <BASE TARGET...> tags to all self-referencing framesets and the pages that may end up being displayed in the self-referencing framesets
  • You will then benefit from the visual benefits of frames and the marketing and usability benefits of frameless sites

If you have any questions, e-mail [email protected].