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.
Reply With Quote
Bookmarks