"Tables prompt eye-gouging hissyfits among accessibility advocates and Web designers of all stripes, whether oldschool or avant-garde. Both sides are saddled with myths and both argue in large part from ideology. Let’s do a reality check, shall we?"
cite: Joe Clark's Building Accessible Websites
http://joeclark.org/book/sashay/serialization/Chapter10.html
OK. Have you done that reality check? Good, then we may proceed...
Many people try to use table elements and its descendants for page layout, for two reasons. The first is historical: tables have been around longer than CSS. Second, tables offer a quick way to create a grid-based page layout. The prevalence of table-based layouts leads to the main gripe some have against CSS (aside from sketchy support in certain browsers): replacing table-based layout with pure CSS is often seen as a difficult task.
Advantages CSS can have over tables:
Advantages tables can have over CSS:
Tables were created to provide structure to data. By "providing structure to data", I mean something along these lines:
| ID | Name | Date | ICQ no. |
| 0123 | John | 19/12/2002 | 11223344 |
| 2365 | Mark | 01/12/2002 | 23453534 |
| 5486 | Lisa | 12/11/2002 | 78642656 |
| 7894 | Sara | 01/02/2001 | 12347784 |
This is the intended use of tables.
When we use tables for creating a layout, we lose the semantic nature of the page. If a page follows this semantic order:
Title of Page Primary Navigation Content Secondary Navigation Copyright Notice
But is marked up this way:
<table>
<tr>
<td colspan="2"> Title </td>
</tr>
<tr>
<td width="20%">
Navigation
item
item
item
item
</td>
<td>
Primary content
---
Secondary Navigation
</td>
</tr>
<tr>
<td> </td>
<td>(c) 2002</td>
</tr>
</table>
All semantic meaning is lost. Speech or text-only browsers would not enjoy this layout very much. Switching to CSS can be the perfect way to turn that jumble into an accessible, easy to decipher page.
Some argue that CSS posesses no replacement for table-based layout. However, it can be easy (if the browsers get their act together!) to create a simple layout.
If we take the previous structure:
Title of Page Primary Navigation Content Secondary Navigation Copyright Notice
and then implement the following HTML in the <body>:
<h1 id="top">Title</h1> <ul id="navigation"> <li>item</li> <li>item</li> <li>item</li> <li>item</li> </ul> <div id="main"> The main content <div id="secondary"> secondary navigation </div> </div> <div id="copy"> © Foo, 2003 </div>
h1
{
border: 1px solid black;
}
#navigation
{
float: left;
width: 20%;
padding: 5px;
border: 1px solid black;
}
#copy
{
border: 1px solid black;
}
This creates a simple and easy to change layout. You will never need to modify every page, as you would with tables. Adding extra sections is very easy.
As stated earlier in this document, tabular data is the purpose of tables. And in a perfect world, all sites fall into the Page Title, Navigation, Content, Secondary Navigation, Footer theory. I know this doesn't always work, and is most often limiting in time and energy and abouding in stress / multiple hacks when supporting several platforms and browsers.
So, setting aside the utopian CSS 1.0 Standard concepts, lets work on a CSS / table compromise.
The real problem with using tables for structure is the complex and (sometimes incredibly insane) nested tables (mostly generated by awful commerical WYSIWYG graphic and HTML editors). Some least compromising table and CSS marriage would contain one simple table with three rows and two columns with everything else falling into the style sheet category.
marked up this way:
<table summary="Layout table starting with header row,
followed by navigation left, content right and ended
with a row of legal stuff." id="layout">
<tr>
<th colspan="2"> Header </th>
</tr>
<tr>
<td> Navigation </td>
<td> Content and Secondary Navigation </td>
</tr>
<tr>
<td colspan="2"> Footer </td>
</tr>
</table>
Keep the header elements (h1 through h6) in mind when creating a site that has a text-to-speech audience. Most of them include a site hierarchy based on these tags. It doesn't matter what kind of tables you are forced to use, h1 will always appear at the top of the hierarchy.
Use Lynx or Opera 7's [small screen rendering] to test how your tables look when linearized.
If you are using Internet Explorer, consider installing the Accessible Info Solutions Web Accessibility Toolbar. Among its many features is a function that will linearize the content of the currently displayed page (Document Structure | Linearize (Remove Tables):
http://www.nils.org.au/ais/web/resources/toolbar/
The example above seems like a bit of a straw man argument. My experience is that tables are not used to lay out simple textual content with simple semantic meanings. Rather, they are used to lay out complex sliced graphics that need precise pixel alignment in order to hold together. I've yet to see that done with divs and CSS. Even making a simple 3 column layout with divs and CSS seems to be a subject that spawns pages of technical argument. Let's see someone replace a real-world, complex, sliced image table that has multiple row spans and col spans with a few divs and CSS. That would be much more impressive and probably convince more people to switch from tables to div/CSS layout.
I think divs have the upper hand... look a site like http://www.protopage.com/v2 try to imagine that with tables...I suppose you could give each <td> and <tr> attributes but obviously it easier to position things with relative absolutes inside each "virtual window" and then these relative positions can be defined in one css file which is globally applicable and inheritable etc. With tables its a much more difficult process to alter your design... you have to go into the code that writes out the html... where as with css the designer can just modify the CSS file and change the layout to whatever they even in very complex layout situation such as that of protopage…