Why I think divs are better than tables

From CSS Discuss

Jump to: navigation, search

"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...

Yes, that reality check can basically be boiled down to "Before stylesheets were invented the spec said layout tables were OK (and lets not mention that the spec also said they could cause problems in the very next sentence)", "WCAG doesn't forbid it! (Because it was out of scope for the project)", and "Data tables are hard and everyone uses tables for layout, so it must be OK (you lemmings you)!".

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:

  • smaller page size, quicker to load
  • future flexibility
  • search-engine-friendly

Advantages tables can have over CSS:

  • Broadly similar layout in ancient graphical browsers

Contents

Why we shouldn't use tables

Tables were created to provide structure to data. By "providing structure to data", I mean something along these lines:

ID Name Date ICQ no.
0123John19/12/200211223344
2365Mark01/12/200223453534
5486Lisa12/11/200278642656
7894Sara01/02/200112347784

This is the intended use of tables.

This is not so clear-cut, the earliest HTML standard I've found with <table> is 3.2 (search for the text "HTML 3.2 includes a widely deployed subset" which starts the section on <table>), which states tables "can be used to markup tabular material or for layout purposes". The 3.0 draft also mentions them, and includes layout as an intended purpose; however, the language in the draft clearly indicates the structural/semantic use is preferred. I think the matter has been recently (dare I use 'modern' to contrast with 8 years ago, even in Internet time?) settled by the widespread (and hopefully the to-be-wider-spread) adherence and support of CSS. Still, this is nothing new, the table support draft for HTML states "The wisdom of past experience encourages us to separate the structural information in documents from rendering information. Mixing them together ends up causing increased cost of ownership for maintaining documents, and reduced portability between applications and media." -- Roger Pate

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.

What can we do instead?

Some argue that CSS possesses 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.

Lets Compromise

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 abounding 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 Site Structure Compromise

The real problem with using tables for structure is the complex and (sometimes incredibly insane) nested tables (mostly generated by awful commercial 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>

Tips and Tricks for a compromise

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/

Real World Use of Tables?

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.

counter to Real world tables:

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…

Personal tools