Frames: just say no!

Some questions come up all the time. If it isn’t “How can I force…” (the answer, always, is “You can’t”) it’s something to do with frames. There’s something about frames that makes the heart sink. The simple answer to the question is always “No, frames aren’t a good idea.”

Netscape invented frames with Netscape 2, and the concept is instantly appealing: have part of the page, a nav frame, say, always right there when the user wants it; it won’t scroll out of sight no matter how long the main content is. Fixed navigation, scrolling content — it sounds good.

The trouble is this appealing and apparently simple concept comes with a load of problems. For starters, there’s the increased load time. Without frames, one page equals one HTML file. With frames, the minimum is three HTML files to one “page” of on-screen content: one file with the frameset information, and two files with the content for two frames. Three files always take longer to download than one.

The good news was that this extra download time was only a problem for the first “page”, because once that was loaded the frameset was there and the nav frame was there, so clicking internal links only replaced the content frame — since this was only part of the browser window rather than all of it subsequent pages would actually load faster than an equivalent page done without frames.

That was the idea, anyway. There are other problems with frames, some of them actually caused by using them in this way. The basic one from the user’s viewpoint, the one which more than anything else made frames very unpopular with many users, is that the simplicity of following a link to a page and being able to bookmark (or send to a friend) the URL of the new page is completely lost. Try to do it, or even just hit refresh, and you are likely to end up back at the original state of the frameset. As Jakob Nielsen put it: With frames, the user’s view of information on the screen is now determined by a sequence of navigation actions rather than a single navigation action.

The only simple way to get around this is to load a complete new frameset with each new page of content. With that you of course lose the advantage of speed from only loading the content frame — in fact, it’s worse than that because now every page is more sluggish to load than the equivalent frameless page would be. But if you just have to use frames, this is the best approach in most circumstances because users need to be able easily to find their way back to pages of interest.

The problems don’t stop with sluggish loading and losing the correlation between URL and what is one the screen. Framed documents need one HTML file for the frameset and one for each frame. All links need to target the correct frame — it is no longer a question of simply putting in <a href="file.html">a link</a>. As a site gets larger, the extra complexity of frames makes it much more likely that mistakes will happen.

The sorts of mistakes I mean happen all the time: a mistake with one filename leaving a frame empty; or clicking a link only for the new page to load into the navigation frame rather than the content frame; or perhaps having the whole frameset load again (and again…) within either the nav or the content frames. If you surf the Web for any length of time, you’ll see sites broken like this. It is always deeply unimpressive to the user and does not incline anyone to put their trust in a site.

If you think having a new frameset for each new page of content fixes all the problems, think again. Unless you provide new menu frame content each time round as well, all the links are always there — including the link to the current page. Having a live link to the current page is a very bad idea, but the only way to avoid it is to load a new nav frame as well as a new content frame every time a link is clicked — the entire page is being replaced now, and as it’s in a frameset it takes longer to load than a single file would. If you keep the same nav file for each page, it’s cached and that part of the page reloads more rapidly — but you have a live link to the current page.

Whichever solution you pick, you’re trading off pluses and minuses. There is no all-win solution. This is always the case with frames. You need to keep clearly in your head all the time the fact that using frames is a choice you make, it is not a necessity. Almost always, using an approach other than frames would make life a lot easier.

Let’s summarise the problems frames cause.

Problems for the user

The address bar URL is no longer a guide to the location within the site. Bookmarking/reloading may bookmark/reload the frameset (and its initial contents) rather than the page of content the user is looking at.
Framesets take longer to load than an equivalent frame-free page.
Links are present which reload the current page.
Frames take up screen space. On smaller monitors/lower resolutions, the fixed space devoted to one or more other frames may leave only a tiny area for the content.
Users following a link from elsewhere may end up on a content page with no links to the rest of the site (and no indication the page is meant to be part of a frameset).
Mistakes may lead to documents opening in the wrong frames or the frameset opening again within one of its frames.
If the designer is foolish enough to disable scrolling, users with small displays/lower resolutions may not be able to access all the menu options.
The effect of hitting the back button varies from browser to browser.
Some browsers have problems with printing pages within frames.

Problems for the author

Each frameset needs a minimum of three HTML files; this means that sites quickly grow very complicated, mistakes are more likely, and the work necessary to maintain the site increases.
Use of framesets requires the careful targetting of links to avoid documents opening in the wrong frame and to avoid accidentally incorporating other web sites within the frameset.
All sites vary in appearance from browser to browser, but the variation can be more troublesome with framesets — ugly scrollbars appearing in some browsers, for example.
There are browsers which don’t support frames, and browsers where support for frames can be disabled. The author can provide content for such browsers using <noframes> but this can double the work involved in putting a site together.
It is not possible to link from outside a frameset to an anchor within a frame of the frameset. (It is possible to do this with scripting, but of course this does not work if scripting is not supported; also, if this approach is taken, creating links becomes even more intricate and error-prone.)
Search engines ignore framesets.

Problems for other webmasters

Framesets make it easy for the unscrupulous to grab other sites’ pages and incorporate them within their own web sites. Sometimes this happens accidentally because the author of a frameset forgets to put TARGET="_top" in an external link, but sometimes it is deliberately done. (In some countries, this is treated as a breach of copyright.)

Frames have their supporters

There are people who like frames. They tend to be people who produce sites which use frames, rarely those who visit such sites. Some of them get quite aggressive in the defence of their choice to use frames. This point of view is articulated well by David Chan [archived at WaybackMachine], and less offensively than some other frame supporters would put it :

Many critics condemn web designers for using frames, but few ask the people who use old or obscure browsers why they don’t switch. It must be frustrating for these people to be “turned away” frequently by web sites.

This is completely wrong-headed (and overlooks the point that if you ignore users who can’t see frames, you are also ignoring search engines). It’s nothing to do with users of “old or obscure’ browsers. There are many browsers which allow the user to decide whether or not frames are used. Lynx, the text-only browser, is no more an “old’ browser than Internet Explorer or Netscape. People use text-mode browsers or disable frames for their own reasons which are, frankly, none of the author’s business.

Chan doesn’t stop there. He goes on:

If these lesser-equipped people belong to our intended audience, we’d have added a HTML 2.0-compliant version between NOFRAME tags. We’re not dumb.

This is such a ridiculous argument. If users choose not to enable frames, that does not mean they are in any way “lesser-equipped”. There is also no reason why NOFRAMES (not NOFRAME) content should be restricted to HTML 2 or any other outdated version of the language. (The argument advanced is an instance of the HTML straw man arguments described by Alan Flavell.) If anyone actually believes this rubbish, they are dumb.

If you can’t see frames, sod off!

Unfortunately many of those who are dumb enough to believe this rubbish are also arrogant enough to be incredibly rude to their sites’ visitors. You don’t have to have a browser which can’t handle frames to see this. Search engines ignore framesets — but if NOFRAMES content is present that is indexed. Search for something on Google and it displays the page title and the beginning of the page’s content. Quite frequently, that content is something like this:

Browser ERROR: Your browser is unable to display frames. Please access this page using a browser such as Netscape Navigator or Microsoft Internet Explorer. ...

Browser error? I don’t think so. In the first place, I may be using Internet Explorer but have chosen not to see frames. If I am using Lynx, it doesn’t display frames — that’s not an error. The only error here is in the design. And, to repeat, it isn’t the author’s business to tell visitors what browser to use.

Some pages are a bit less rude. This item also appeared in a Google search:

Sabrina's Pregnancy Page - Frames
... Sabrina's Pregnancy Page If you are seeing this text, your browser lacks the ability to read frames. Please click here for the no frames version: Index Page.

This is slightly better, but it still makes unwarranted assumptions (it doesn’t follow that my browser can’t read frames — for one thing, I could be looking at a search engine). Also, the creators of Sabrina’s Pregnancy Page have provided content for those who can’t see frames — that puts them ahead of the average frame-happy “designer”.

However, It still isn’t all that good. I don’t know what the content of the “no frames version” is but I’d happily bet that it is more relevant to the site than “if you are seeing this text, your browser lacks the ability to read frames’. It would be much better if the NOFRAMES content of the frameset was the “no frames version” index page. Actually having some content on pregnancy (which, I’d guess, is what the site is about) would be a lot better than stuff about frames.

How to use `<noframes>`

One of the bad points of frames is that, unlike most HTML constructs, they do not degrade to a usable state. With most tags, if a browser does not recognise them it ignores them. Well, if a browser doesn’t recognise <frameset> it ignores it all right — the problem is, there isn’t anything else there:

The FRAMESET and FRAME elements do not have textual content. A browser that does not support frames will simply skip over these tags. But as there is nothing else to show, this browser would display nothing in place!

As I’ve indicated, NOFRAMES makes content available for these browsers (and search engines) but there is a big drawback:

The NOFRAMES element allows an author to specify content for such a browser, but this often means that the author has to do double work.

How many people do you think are going to do almost double the work for less than half their audience? That’s one reason why you get the rude messages for frames-free users on a lot of sites.

Really, NOFRAMES should include equivalent content to that presented to frames users. That also needs to include navigation, of course: you can’t get away with simply taking what’s in the content frame and sticking it between <noframes> and </noframes>.

This is, as we’ve noted, a lot of work. At the end of it, if it is done well, you have a page with content and navigation which looks good. The thought will (or should) occur to you: why not just dump frames and make the site this way — if I don’t do frames, I lose about half the work and everyone can see the site!

If, though, you are still determined to use frames but you’re too lazy to put a full page in the NOFRAMES element, at least make the NOFRAMES content useful. Give an idea of what your site is about and provide links to your content. Remember, if all you talk about is frames and browsers, that’s what will show up in search engines.

Some people think “If I use frames I should have NOFRAMES content” and then insert something insane like this:

<noframes>
     <body bgcolor="#FFFFFF">

     </body>
</noframes>

I haven’t just made this up, there really are pages out there with precisely this code, which does nothing but ensure that a user who has disabled frames sees nothing but a completely blank, white page. If you can’t be bothered providing actual content, don’t put in NOFRAMES at all.

The final word about NOFRAMES remains: don’t be rude to users who come to your site with browsers which don’t display frames. If you do that, you’re the loser. As they say in Germany, “No one has ever won an argument with a customer.”

Are frames ever necessary?

Necessary? I thought we’d already covered that. Frames are never necessary: they are a choice. There are, though, some times — some very few times — when frames are possibly the best solution to a particular problem.

Take, for example, a diary of events for a social club. (This is based on a real site I created a while ago.) The list of events could be be very, very long, some months containing up to six weeks’ events.

To make it easy for the user to find what’s happening on any particular date, a nav frame can be used to contain the month’s dates, each of which links to an anchor within the diary frame. If there were more than one page of events — say, one page per month — then each new page would have its own frameset, preserving the link between URL and location. For users with frames, this, as the example shows, is much the most usable presentation.

This type of situation — lengthy content with hyperlinks to anchors within it from the main navigation — is the only one where I can see a good argument for using frames.

Philosophical objections

I’ve left this to now because most people don’t care about theory. But there are strong arguments against the use of frames even ignoring the practical problems they cause. If you’re thinking He’s going to start talking about structure and presentation again, you’re dead right.

HTML, as I’ve said many times, is not designed to describe the layout or appearance of a web page. The function of HTML is to describe the logical structure of a page.

However, the tags used in a frameset document are wholly presentational: this amount of space to be used for a frame here, that amount of space for a frame there. There is no structural information in a frameset at all:

The HTML markup language is designed to be a platform-independent way to indicate the meaning of the contents. This way, each browser can render the document on whatever platform it is running on. Frames violate this principle; everything is designed to accomodate [sic] only browsers running on big-screen graphical displays.

The future

There are theoretical objections to frames, and problems for both user and author in their use. There is a little light at the end of the tunnel, though.

If you are looking at this page with a fairly CSS-compliant graphical browser (that specifically excludes Netscape 4), you will see a page like this:

[Image: this page in MSIE5.5/Win] [Image: this page in Mozilla]

This page in MSIE 5.5 (left) and Mozilla 0.9.1 (right)

With a lot of browsers, scrolling down will take the nav bar (blue, on the right) up and out of sight. However, if you are using a very standards-compliant browser (Mozilla, Opera) then you can scroll down the page but the nav bar remains in place:

[Image: nav bar has scrolled out of sight in MSIE] [Image: page has scrolled but nav bar remains fixed in Mozilla]

Scrolling in MSIE takes the nav bar up and out of sight, but in Mozilla it stays fixed as the rest of the page scrolls.

As CSS support improves, we can have the functionality of frames without the problems of frames. It can't come too soon.

This article has probably provoked more feedback than any other. Apart from those agreeing with it, most of the responses seem to be from people who haven’t grasped the points made here. For example, those who read it and then said something like, “Well, then, how would you make a site like X without using frames? You need frames for that!”

The fundamental point about designing Web sites — most of the time — is that you try to present the information the user needs as effectively as possible. That means that, usually, fixating on a particular “look” from the start isn’t the way to approach it; and frames are rarely the most effective way to give the user the information she needs. If frames were so good, don’t you think the big sites like Amazon would use them?

Besides, the question was at least partly answered in the article: if you want a fixed section of a page while the rest is scrollable, CSS can do that. Not in MSIE for Windows yet, no, but in Gecko-based browsers (Firefox, Mozilla, etc.) and Opera — and browser stats recently show a lot of people are using these browsers. If what you want is to include other documents in a given page, the only way to do it using plain HTML is frames (or iframe), but there are other and better techniques to do that.

You don’t need to use frames. Ever. If you choose to, it’s up to you — but don’t expect your site’s visitors to like it.