frequal.com

HTML Frames -- Bane or Blessing?

Frames began as Netscape-specific extensions to HTML 2.0, and have since been approved by the W3C in HTML 3.2. Frames allow the display area of a single browser window to be segmented into multiple rectangular areas, each of which can scroll independently. Frames can be named, allowing links using enhanced syntax to update specific frames.

Several site designs are permitted by frames that aren't easily created using frameless techniques. A table of contents can be displayed alongside a content pane. Headings atop a page can be continuously displayed to allow toggling between different topics. Contact information can be displayed in a short frame at the bottom of your site, keeping it always visible while the user navigates in the main frame. Advertisements can be displayed in a frame, automatically updating using a META tag.

The Good

Independent scrolling of frames is a major benefit. In fact, this is a major benefit of electronic displays over paper media. Tables of contents cannot be reproduced on every page of a book. While looking at a given page, the reader must break away from what they are reading to return to the table of contents (TOC). To return to their place, they must clumsily mark it with either a flag or a finger. When the TOC can be displayed next to the content, the users don't have to risk losing their place to look at the table of contents. Plus, highlighting of visited links reminds them what they have read.

Maintaining content on a frames-based site is easier than on one that tries to emulate frames by embedding headers, footers, and navigational aids on each page. The TOC needs only exist in one page. Other pages can be kept simple, containing only the content described in their title. Contrast this with the difficulty of maintaining a table of contents on each page of a site.

The Bad

Frame handling by browsers is atrocious. In early (pre-3.0) versions of Navigator and Internet Explorer, the forward and back button would navigate between top-level frames only. Users navigating within frames by following links were greatly confused when the back button returned them to a page that was several navigations back in their browsing history, instead of the most recent navigation they were accustomed to on non-frame sites.

While back and forward navigation has been corrected in more recent browser versions, they still fail to bookmark frame-based sites adequately. They bookmark the top-level frame currently being viewed. When returning to the bookmark, the contents of subframes do not reflect any navigation done in subframes at the time of bookmarking. In other words, what the user sees when returning to the bookmark is not what they saw when they added the bookmark!

The history feature in most browsers also fails to adequately allow reverse navigation. Like the back button, it tends to show only top-level frames in the history list. Since the back button moves one level back in history, it is likely that a fix to the underlying mechanism will fix both features.

Printing of frames is also problematic. I am sorry to say that (at least in the 4.0 versions) printing frames is handled better by Internet Explorer that Navigator. Hopefully Navigator 4.5 and beyond have improved frame printing.

The Summary

To me, the benefits of frames-based sites outweigh the difficulties presented by certain browsers. I think as more sites use frames, browser vendors will receive pressure to improve their frame handling. The open competition in the browser market should help this. Although I despise sites that require one browser over another, it doesn't seem outrageous to warn users that printing or bookmarking will work better in one than another. Perhaps with a bug feedback mailto link to prod developers of a deficient browser.