This article is an attempt to clarify some theoretical or technical objections to the frames proposal from Netscape. It is not an attack on the concept of frame-based layout. The article is divided into two sections: at a glance and in depth.
One of the main problems is that the focus is on layout, not on the structure. The HTML markup language was designed to be a platform-independent way to indicate the meaning of the contents. This way, each browser can render the document on whatever platform it is running on. Frames violate this principle; everything is designed to accomodate only browsers running on big-screen graphical displays.
The central concept is the frameset. But as a user "clicks through" a site, there no longer is a way to store the state that the frameset is in now. This is because framesets are not addressable. The information about the position in a frameset is not present in the document in the frame. Similarly, the TARGET attribute requires that the author remembers and determines the target frame of the linked document. There is no information present in the value of TARGET.
And, most obvious, frames are totally incompatible with browsers that do not support it. The author has to provide a lot of extra work to essentially duplicate the site for users of those other browsers. This should not be necessary.
On the Web, everything can be accessed (or addressed, at least) using an Uniform Resource Locator (URL). This makes it possible to link to anything, anywhere. At least, as long as the anything in question does not use frames.
Although the first document (the one that defines the frameset) does have an URL, this URL does not change as a user navigates his way through the site. There is also no other mechanism to keep track of where the user is, so the "current location" cannot be expressed using a URL. Inventing such a mechanism is not as simple as it may seem. Not only do you have to keep track of all frameset documents used along the way, but also of the frame names that were defined, and the documents loaded in there.
This is a rather technical complaint. It does not mean that documents using frames are written for just one browser, or lack structure. The problem is that the implementation of frames itself focuses only on the layout of the various frames. A typical frameset declaration only states that the frames are rows or columns, and how wide each one should be. There is no way to determine the role of the frames being defined. This makes it impossible to create an alternative display of the frames. The best you can do is provide links to each frame separately.
A more structure-oriented model would not only define the frames as rows or columns, but also provide the role of each frame. This way the multiple documents can also be made accessible in other environments. For example, if one frame is used for the table of contents, and one for the content, the browser could also make this table of contents available as a floating toolbar, or through a special-purpose button.
The general rule for HTML is that if an element is not understood by a browser, it should be ignored. This way, a browser that does not understand the element can still show the rest of the document. The reader may miss some of the meaning of the text, or get a document that is formatted a bit strangely. Unfortunately, this is not the case with frames.
The FRAMESET and FRAME elements do not have textual content. A browser that does not support frames will simply skip over these tags. But as there is nothing else to show, this browser would display nothing in place! The NOFRAMES element allows an author to specify content for such a browser, but this often means that the author has to do double work.
