Working with Frames

These days, it's a rare novelty to see someone using frames to create web pages. The reasons are numerous, including these fun facts:

  • Frames modify the browser interface, which results in no consistency in how operating systems and individual browsers display the results.
  • Frames are difficult for both blind and mobility-impaired users. Screen reader software has a hard time managing the altered interface. Mobility-impaired users also encounter difficulty moving from frame to frame.
  • In older browsers, frame pages were difficult to bookmark. Bookmarking is improved in most modern browsers, but the user still has to know where to dig up this feature within the browser interface.
  • Frames consume more server and client resources, for two reasons: First, frames-based designs rely on multiple documents just to build one page, so a server has to send each of these documents when each frame page is assembled. Second, browsers and the user's operating system have to work harder to manage them.
  • Because multiple documents must be created for each single-frame page result, managing frames is an arduous, unhappy task when you're trying to manage, update, and modify a frame-based site.

So if frames aren't all that and a bag of chips, why on Earth would you want to learn them? I have two very specific reasons I want you to know about them:

  1. Frames are a unique part of HTML. I want you to understand what you're looking at if you see frames and to also have them in your toolbox if you ever need them.
  2. Frames can occasionally be exactly the right choice for a specific approach. Let's say you want to develop an application in which data loads into another location directly within the same interface. Frames can help you accomplish that kind of functionality; if you need it, you'll know how.

Finally, although iframes are not the same thing as conventional frames, they are in use. You might well want to tap into their unique functionality at some point.