HTML 4.0 (the predecessor of 4.01) introduced something called frames, which split the browser's viewport up into different sections, each displaying a different webpage.

It was a good idea in concept, but the execution left a few things to be desired. Amongst the litany of woes:
  • Using the back button on a browser in frames tended to be unpredictable, depending on what frame was loaded when.
  • You could not bookmark a specific set of pages in the frameset's, only the default set.
  • Accessibility for the disabled was severely compromised.
  • Printing frames could also wasteful, as you might find yourself printing all pages displayed in the browser.
  • Viewers would have to download multiple pages: the page defining the frames, and all pages displayed by the frames.
  • Not all browsers during frames' heyday supported frames, so you had to code a no-frames version of your webpage.

So why were they ever used?

  • If you had a part of a webpage (usually the navigation) that you used over and over again, a frameset allowed you to put that code in its own webpage and display it apart from everything else. While server-side processing—explained in Server-Side Scripting—also was used for this, in many cases (such as website hosts at the time and websites that come on a CD, like this one), that simply wasn't available.
  • Speaking of navigation lists, they could be quite long, and frames allowed the list and the page proper to scroll seperately.
  • They were a means of arranging a page before CSS really came into its own.
  • For someone unused to programming, frames (which are HTML) were easier to work with than server-side scripts, which (for the most part) require some knowledge of a programming language.
Reasonably accurate?