A
HTML construct, invented by
Netscape to allow a HTML page to be split into frames (window panes) that can be filled with content separately.
Frames are specified in the 'container' page, which is a HTML page that employs
two special HTML tags: <FRAMESET> to specify the number of frames and conditions on their placement, and <FRAME> to specify the name of each frame and the URL of the document initially to be placed within it. Other HTML elements that allow URL attributes, such as <A;> now have optional TARGET attributes to specify the placement of the URL content within a specific frame.
There are fundamental problems with this design.
First, there is no way to address a given collection of frames with a URL. All you can address is the URL of HTML documents with framesets, and these framesets only list the initial content of the frameset. As soon as the content of a frame is replaced with the content of a given URL, the resulting combination is no longer addressable.
Second, there is no way to address an individual frame as a frame with a URL. There is no way to indicate within a URL whether or not a document is used as a frame within a frameset. It is not even possible to indicate this within the content of the document. But this information is very important for the page composer: the content of a document usually depends highly on whether or not it is being used as a frame within another document, and if so, which frame.
As a result of the second problem, there is no way to address frames in a safe way. In order to specify a link that is supposed to replace, say, the left menu frame, you have to specify its frame name as the link's TARGET attribute; but the correctness of the TARGET value depends on the frame names as specified in the frameset document, and the document containing the link has no way of knowing what that frameset is, or whether it is part of a frameset at all.
Given the intended functionality (being able to replace the contents of frames within a page rather than the whole page) and the design constraints (HTML must work from a passive medium, such as a flat filesystem, and make no assumptions on constraints that such media place on the form of URLs, such as a 8.3 filename limitation) the chosen implementation with FRAME and FRAMESET is reasonable.
But the resulting limitations are a pain for authors.
There are three ways to overcome these limitations:
- use Javascript, which can analyse the frame structure at page viewing time
- use home-made conventions for URL use by which individual frames can be addressed as the part of the frameset they are, and by which arbitrary combinations of frames can be addressed as well, and implement them in the authoring tools or process
- generate all HTML, including frames, from original document source that is specified in a different format, probably databased, in which no such limitations exist
The latter is a cure-all to most of the problems with HTML, proving that HTML really isn't suitable as a
document specification language, and is best thought of as a
device independent rendering specification for rendering engines, a characterization it shares with
PostScript.