Practical Web Design - Frames and Frame Usage Explained

Ah, frames. We hated them when Netscape first offered them up around 1995; we deplored them when they became all the rage for a few short years; we wish they would go away and never darken our displays again. Well, maybe.

The debate on frame usage has been raging for eight years now, and while most experts come down solidly against their use in most instances, I won't continue the debate here. I will say that in my experience on the Web, 90% of the sites that still use frames don't use them well; I'm still a bit surprised when I find a site that works better with a frame than not.

Most people who have come late to Web design or are just learning it now get told, "Frames? Forget 'em! You won't design a page in frames, they're hard to get right, and it's a waste of time for you to learn them." Now, there's plenty of truth in this statement. It's not a necessity to learn frame design: many professional Web designers have designed hundreds of elegant, functional sites without a single frame and will go right on designing without giving frames a thought. The percentage of framed sites out there is dropping steadily, especially now that more and more designers are moving towards CSS-based design, which essentially renders the entire concept of frames irrelevant. Note that while HTML 4 includes frames as part of the official code, HTML 4.01 Strict does not support frames, relying instead on style sheets.

For a nice compilation of the pros and cons of frames, see Tom Chaplin's SitePoint article on the subject. It's a few years old, but still pertinent.

There are times when a knowledge of frame design is necessary, however. Perhaps your business site uses frames and you're constrained to operate within company parameters. Perhaps you've got a client, or an aunt, who is mad for frames and insists you use a frame-based design. Or maybe you've come up with a concept for a design that actually works better in a frame (unlikely as that sounds, it does happen).

Frames have their uses, infrequent though they are. So I've decided to provide some info on frame design for the novice or intermediate Web designer -- some how-tos, along with some observations, caveats and warnings along the way. Frame technique is not that hard, though it's tricky, and it is worth learning if for no other reason that you'll know what all the fuss is about.

Basic Design

Frames disrupt the entire fundamental concept for the Web: a large collection of individual pages, linked together with hypertext. ...Frames violate too many accepted Web standards to be a worthy information delivery system. -- Ross Shannon

Frames: just say no. -- Jakob Nielsen

It’s hard to argue with those statements. Frames do disrupt the flow of the Web. Ideally, the idea is to surf unencumbered from site to site and page to page without any problem navigating from one location to another. Point, click, peruse the content, point, click, go somewhere else.

The Web is inherently fluid in nature; frames disrupt that paradigm by adding static structure to Web pages. The fluid paradigm shifts the moment you enter a framed page. Content is displayed inside a "corral" of frames, locked inside a barricade of code. Navigation is disrupted; the usual "click in, click out" methodology no longer works. In some older browsers like Netscape 2, even the BACK button didn't always get you out of a framed page. Thankfully, that little irritant is no longer a factor, since browsers that don't handle frames well have all but disappeared from the pool of browsers currently in use, with the notable exception of Lynx, which displays the content of the NOFRAMES page and provides labeled links to the framed content.

Bookmarking doesn't always work; instead of marking the specific URL of the framed content, you've just bookmarked the frameset, which may have a different URL and may not contain the same content upon your return. Copying a frame's URL for use as a hyperlink in another page may not send a visitor to the proper page, since the framed page's URL doesn't display; only the frameset URL displays. Printing a framed page doesn't always work well. Cookies don't track frameset pages well. Framed content displays quite poorly on smaller screens such as notebooks and handhelds.

Probably the biggest irritant of frames is the occasional framed page that won't let you out once you've entered; it insists (whether because of poor design or intent) on displaying every other page you go to within its own frameset. This last is a technically defensible choice for some commercial sites that want to keep their own navigational setup or advertising content always in front of visitors, but it's not a good choice. Trapping visitors within your site’s frames is the best way to aggravate them into leaving your site as quickly as possible -- even if that includes closing the browser completely and starting to surf from scratch.

There are also the considerations of additional server load and page maintenance. A framed page often takes up more server space than a non-framed alternative, and those frames also add load time to the page. A bunch of framed pages can be more difficult and time-consuming to modify. And when you create a new frameset, you'll have a minimum of two (with just one frame -- more if you have more frames) hits to the server from a single visit. With more framesets, you generate more hits to the server without generating additional page views. This can cause problems if you can accept a limited amount of traffic to your site; it can also can play havoc with your attempt to keep track of site visitations.