Dreamweaver 8 Design and Construction (OReilly Digital Studio)

4.5. Choosing a Layout Strategy

When you construct your layout in Dreamweaver, you have your choice of two strategies: building with tables or building with layers. In both cases, you break the web page into rectangular sections, just like the areas in your sketch, and fill them with the corresponding content. More often than not, the results are indistinguishable. So which method should you use? This section helps you to make the right choice for your particular site.

4.5.1. Building with Tables

A table is an HTML structure for organizing rows and columns of data. In the early days of the Web, when scientists and mathematicians were the only people building web sites, the table was a convenient method for displaying the results of some experiment or other. But in what was perhaps the greatest act of subversion since postmodern literary theory, visually oriented people realized that the table could be "borrowed" to mark off the areas of a graphic design, resulting in far more sophisticated page layouts on the Web than Al Gore had ever dreamed possible. As a direct result, the Web became interesting to people who had never heard of hypotenuses, stock prices soared, and art majors found their degrees in welcome demand.

The problem wasand still isthat the specifications of HTML are very clear: you identify elements according to what they are, not according to what you want them to look like. Standards organizations like the World Wide Web Consortium (W3C) argue with great conviction that the table element, regardless of how it looks in the browser, is specifically for marking up rows and columns of data. It has no business defining the layout of a web page, because that isn't its purpose. This may seem like a trivial point, but the technology of the Web turns on this principle.

When the browser sees a table in an HTML document, it assumes rows and columns of data, not a page layout. To most visitors, this doesn't matter. They don't care if they're looking at what the browser thinks is a table. They're more interested in the content inside it. But what about those visitors who can't see your layout? When a non-visual browsing device like a screen reader comes along, it also assumes rows and columns of data, and it reads them out as such. While your web page may make good visual sense, it might not translate logically in table form, and the screen reader can very easily take the areas of your design out of order. The navigation area might come after the content area, and who wants to sit through paragraph after paragraph of unwanted content just to get to the links?

Despite the accessibility drawbacks and the continued protests of the W3C, tables have one major advantage in that they are completely and utterly stable. Tables-based designs look much the same in IE as they do in Firefox or Opera or any other browser, so your visitors receive the same experience, no matter which browser they prefer. Tables are also hard to break, in that you can push their limits without your layout coming apart at the seams, especially when you nest tables and add spacer images (more on that in Chapter 9).

If stability is your overriding concern, as it is if you're designing a site for your business, then building with tables is the better option. You won't win many friends in the W3C, but at least you'll be in good company, as most of the Web comes courtesy of tables.

4.5.2. Building with Layers

You know that a table is rows and columns of data, which many designers just happen to use for divisions of page content instead. But a layer or div is precisely that. It's a division of contenta section of the pagejust like the areas in your design sketch.

No strict rows-and-columns-of-data formulation here. When you mark up a section of your page as a layer, you're telling the browser that this group of content belongs together. The browser doesn't have to perceive the layer in the context of the graphic design to understand this, either, because you've translated the purely visual divisions in your design into logical, structural divisions in the HTML code. What the human brain does for visual groups, the layer does for logical groups. Not even the W3C can object to that.

In fact, layers are so logical that you can arrange them in any order in the HTML codethe order in which a screen reader should read them out, for instancewithout affecting their visual placement in your design. But layers aren't all about the code. They come with a wide variety of formatting options and effects. Tables are locked into a grid of rows and columns, but layers know no such limitations. You can position them anywhere on the page. You can animate them or make them draggable with the mouse. They can overlap. You can even make them invisible.

At least that's how it works in theory. In practice, browsers don't support layers as well as they should. Layers-based designs tend to vary from browser to browser in odd ways, so that when you get the layout looking the way you want it in IE, you find annoying inconsistencies in Firefox, or the other way around. Sometimes the browser completely misinterprets your intentions, and the layout breaks down.

Nevertheless, layers are very much on the cutting edge for all the right reasons. A layers-based design is forward-thinking, standards-compliant, and more accessible. Layers are the future of web design. If you can afford to lose a little in the way of stability, and if you can live with a lean and straightforward visual style, then a layers-based design is an astute choice.

For your consideration, Table 4-4 summarizes the pros and cons of tables and layers. If, after carefully reviewing the arguments, you're still not sure which to use for your site, tables is the safer beta crime, perhaps, but a crime of convenience.