• Choose a category
• All
• Classic-Fiction

Problems with frames

Frames were a feature of the early versions of HTML. They allowed you to break a page into several segments. Each segment was filled with a different page from the server. You could change pages independently of each other, to make a very flexible system. You could also specify the width and height of each frame.

At first glance, frames sound like an ideal solution to layout problems. In practice, they had a lot of disadvantages, such as

♦ Complexity: If you had a master page with four segments, you had to keep track of five Web pages. A master page kept track of the relative positions of each section but had no content of its own. Each of the other pages had content but no built-in awareness of the other pages.

♦ Linking issues: The default link action caused content to pop up in the same frame as the original link, which isn’t usually what you want. Often, you’d put a menu in one frame and have the results of that menu pop up in another frame. This meant most anchors had to be modified to make them act properly.

♦ Backup nightmares: If the user navigated to a page with frames and then caused one of the frames to change, what should the backup button do? Should it return to the previous state (with only the one segment returned to its previous state) or was the user’s intent to move entirely off the master page to what came before? There are good arguments for either and no good way to determine the user’s intention. Nobody ever came up with a reasonable compromise for this problem.

♦ Ugliness: Although it’s possible to make frames harder to see, they did become obvious when the user changed the screen size and scroll bars would automatically pop up.

♦ Search engine problems: Search engines had a lot of problems with frame-based pages. The search engine might only index part of a frame-based site, and the visitor might get incomplete Web sites missing navigation or sidebars.

For all these reasons, frames aren’t allowed in XHTML Strict documents. The layout techniques you read about in this chapter more than compensate for the loss of frames as layout tools. Read how to integrate content from other pages on the server with AJAX in Book VIII, Chapter 5.

Problems with tables

When it became clear that frames weren’t the answer, Web designers turned to tables. HTML has a flexible and powerful table tool, and it’s possible to do all kinds of creative things with that tool to create layouts. Many HTML developers still do this, but you’ll see that flow-based layout is cleaner and easier. Tables are meant for tabular data, not as a layout tool. When you use tables to set up the visual layout of your site, you’ll encounter these problems:

♦ Complexity: Although table syntax isn’t that difficult, a lot of nested tags are in a typical table definition. To get exactly the look you want, you probably won’t use an ordinary table but tricks, like rowspan and colspan, special spacer images, and tables inside tables. It doesn’t take long for the code to become bulky and confusing.

♦ Content and display merging: Using a table for layout violates the principle of separating content from display. If your content is buried inside a complicated mess of table tags, it’ll be difficult to move and update.

♦ Inflexibility: If you create a table-based layout and then decide you don’t like it, you basically have to redesign the entire page from scratch. It’s no simple matter to move a menu from the left to the top in a table-based design, for example.

Tables are great for displaying tabular data. Avoid using them for layout because you have better tools available.

Problems with huge images

Some designers skip HTML altogether and create Web pages as huge images. Tools, like Photoshop, include features for creating links in a large image. Again, this seems ideal because a skilled artist can have control over exactly what is displayed. Like the other techniques, this has some major drawbacks, such as

♦ Size and shape limitations: