markparnell.com.au

How to use HTML Frames properly

Introduction

Much has been written on the "evils" of using frames in HTML. While I am wholeheartedly of the opinion that frames have had their day (Netscape, the company that invented frames, stopped using them on their own site after just 6 months!), I don't see the point in writing yet another article detailing the problems with them. Links to a few of these pages can be found at the bottom of this page.

My purpose in writing this article is to explain how to work around the problems with frames, partly in an attempt to show how much harder they make authoring when done properly, but also because no matter how many reasons there are not to use frames, some web developers will insist on using them regardless. I figure if they are going to use them, they might as well do it properly.

Logical names for frames

We'll start with an easy one.

Many developers simply name their frames according to their location on the screen, for example "top", "left" and "right". However, this makes no sense at all on non-graphical user agents (text browsers, aural browsers, etc).

For example, many text browsers, when they come across a page using frames, will just display a list of the available frames, and the user has to select which one to view. If the frames are simply named according to their location on the screen, the user has no way of knowing which frame is the one they want.

The solution to this is simple: name your frames according to their contents, not their location. For example, you may have "header", "navigation" and "content".

This is a simple change, but can make a big difference to the usability of your site.

Separate frameset for every page

One of the major problems with frames is that your visitors cannot bookmark a particular page on your site. They have to bookmark the home page, and then every time they come back, try and find their way through your menus to the page they actually want - if they can even remember which page it was. The same happens when they try and send the link to someone else. They have to send the link to the home page, and (if they even realise what has happened), add instructions on getting to the page they wanted to share.

My wife was looking at a site that sells tickets to sports matches, concerts etc. She sent me a link, and asked "What do you think?". However the site used frames, so instead of the link taking me to the page that she was looking at, it took me to the home page, and I had to try and guess what event she was talking about!

The solution to this is to create a separate frameset for each page on the site. Then, only link to the framesets, not the individual pages. That way every page has its own address.

Quality <noframes> content

Most developers, when working with frames, simply put "Your browser does not support frames" or something similar in the <noframes> section of the page. In fact, many so-called "web editors" do this automatically.

However, the <noframes> element is supposed to be a replacement for the content of the frames, for user agents that don't support frames.

Many developers will argue at this point that all modern user agents support frames. That is mostly true, although there are a handful that don't. One of those that doesn't is potentially your site's most important visitor - Googlebot. That's right, Googlebot does not support frames. This can be demonstrated by a simple test. Go to Google, and search for "Your browser does not support frames". There are literally millions of results. Why? Because that is what Google can read on those pages.

So how to work around this problem? The content of the <noframes> element should be a duplicate of the actual page, plus navigation. In other words, it should basically be what the page would look like if you never used frames in the first place.

Robots.txt

If Google does somehow manage to index your framed pages (which does sometimes happen), we run into another problem. Anyone who follows a link from Google to your site will almost always end up on a page outside of its frames - usually meaning no navigation.

Many framed sites implement some Javascript that detects if a page has loaded outside of its frameset, and if so, reloads the page inside the frameset. While this is generally a good idea, it is not enough. Many people these days surf with Javascript disabled, so a more concrete solution is needed.

Enter robots.txt. This is basically a text file that sits on your server, which search engines and other robots look for. In it you can enter instructions for the robots, such as which pages not to index.

To prevent people ending up on your pages without the frames, you need to instruct the search engine robots not to index any pages except the framesets. With your <noframes> content, they will still be ranked just as highly, and when someone follows the link to your site, they won't end up on an orphaned page.

For more information on robots.txt, see the official robots.txt web site.

Printing

In many browsers, frames make it difficult to print your pages. While some authors may consider this beneficial, if your visitor wants to print the page, who are you to say otherwise? This is particularly a problem on sites that are mostly informational. If visitors can't print the page, they lose one of their main tools.

To my knowledge, there is no proper work around for this. I believe it is possible to implement some Javascript that will allow printing of particular frames, but as mentioned previously, many people surf with Javascript disabled or unavailable, so this is not a complete solution.

Summary

Frames have a lot of inherent problems. Doing a site properly, to avoid these problems, creates a lot of additional work, and ultimately not all of them can be worked around. Personally, I don't think it is worth the effort, but ultimately that decision is up to you.