Why Tables Are Bad (For Layout*) Compared to Semantic HTML + CSS

  1. Tables are usually more bytes of markup. (Longer to download, and more bytes of traffic for the host.)
  2. Tables usually prevent incremental rendering. (Takes longer for the user to see anything on the page.)
  3. Tables may require you to chop single, logical images into multiple ones. (This makes redesigns total hell, and also increases page load time [more http requests and more total bytes].)
  4. Tables break text copying on some browsers. (That's annoying to the user.)
  5. Tables prevent certain layouts from working within them (like height:100% for child elements of <td>). (They limit what you can actually do in terms of layout.)
  6. Once you know CSS, table-based layouts usually take more time to implement. (A little effort up-front learning CSS pays off heavily in the end.)
  7. Tables are semantically incorrect markup for layout. (They describe the presentation, not the content.)
  8. Tables make life hell for those using screen readers. (Not only do you get the other benefits of CSS, you're also helping out the blind/partially-sighted. This is a Good Thing.)
  9. Tables lock you into the current design and make redesigns MUCH harder than semantic HTML+CSS. (Have you seen CSS Zen Garden?)

Tables can be Good

Tables are 100% acceptable, appropriate, and correct for use with tabular data. For example, tables are the correct markup for the content of Filterlicious.

If you can't decide if your data is appropriate for a table, see "Tables are for Tabular Data. Period".