frames and framesets
In the beginning… a browser was only able to display a single document with its “source” file’s name showing in the browser’s address bar. At this early date, browsing through documents was then a sequential process, e.g., first page 1, then page 2, and so on. Then came the Netscape people with the frameset concept; the same people who – 2 versions later – would create NN 4 :-)
In my opinion, they made a mistake right at the start by naming their new feature a “FrameSet” instead of a “windowset”.
Because frames and windows are synonyms, the average user has a hard time understanding that a frameset is not one window displaying a "page" but multiple windows within one browser window rendering multiple document sources at once [each frame acting like a separate browser window].
As such, a set of windows can behave in unexpected ways simply because more than one document is being displayed, such as:
- Bookmarking an interesting page actually bookmarks the frameset document, not the frameset state,
- Reloading a frameset document [which is different than "refreshing" the window] brings the default frameset layout, hence you are moved away from your page of interest!
- Moving out of sequence through the browser's history [when using the browser’s back/forward function],
- Accessing a source code that doesn't correspond to the page displayed in the browser window [in other words, if you use VIEW | Source, you will see the source of the frameset page, not of the content document displayed in the browser window],
- Displaying a static Title while browsing different documents [since it’s the frameset title that is being shown in the browser’s title bar],
- Displaying a static URL in the address bar while browsing different documents [for the same reason as above],
Scrolling, Printing, Searching and using Keyboard Shortcuts are also tricky because these functions rely on focus and it is not always obvious for the user which frame [window] has focus.
Section 6 of this tutorial discusses these issues.
Moreover, most designers of frames-based-layout neglect the
noscript elements which leads to none or poor alternative content. They also have the tendency to focus more on layout than on information structure.
I think frames should be implemented into a design only when the benefits of using them justify the sacrifices in term of usability and accessibility. This means that it is incumbent on you to familiarize yourself with the price that you will pay for selecting this design method before you make the commitment to frames. Unfortunately, many web designers are not aware of the many issues that come with frames...
I hope that the following pages will help you to learn [or to better understand] the pros and cons related to frames and that you will find some of the scripting techniques explained in these pages interesting.
Mark Fletcher [VTC Dreamweaver Fundamentals] pointed me to a W3C document on Xframes [an XML application that could replace HTML frames]. This draft is not a Recommendation yet, but it is a good read.
Inline-frames [aka I-frames or Floating frames] are another way to display more than one document at once. Iframe elements are embedded in other HTML documents - I do not discuss them in these pages.