Why avoiding tables (for layout) is important

On Scripting News on February 13, 2002, Dave Winer asks why avoiding tables is so important in web-design and points here. This is an attempt to answer that question. Thanks for the link and conversation, Dave!

I want to make clear that I’m not saying you should never use tables. Tables are in HTML, and when you want to display tabular data, you should use them. But for layout, there are other options.


Tables are slow
Tables can be inflexible
Accessibility issues are easier with CSS
Tables don’t degrade
Tables don’t print as well
Other Resources


Tables are slow

In almost every browser out there, unless table widths are specified explicitly, all the text in the table needs to be rendered before the browser can figure out how wide to make the various table cells. This means that pages load slowly. Note that using CSS for layout doesn’t necessarily help here, since there’s the same problem if the widths aren’t specified explicity. I’m guilty of this myself. Take a look at my quotes page (which doesn’t need to be a table, as a list with a floating element to the right of each list-item for the link would do just fine) or my list of CDs. Notice how slowly they load. Both pages use a table to line up the data.

Tables don’t have to be slow (as Todd Hoff points out) if you put each row in a separate table, but then you lose the alignment between rows. For a blog, that may not be much of a problem, but for data that actually wants to be in tabular form, it’s still a problem.


Tables can be inflexible

One of the common tricks to make tables load more quickly is to specify the widths for all the table columns. This means that the table renders pretty quickly, and the user can see your text right away. The problem is that you’ve just specified the width for the page. Again, note that you can have this exact same problem with CSS if you specify all the widths explicitly.


Accessibility issues are easier with CSS

Thanks to Harold Levin for the question about accessibility (see the followups). Tables also mean you have to present the information in the same order you want it displayed. You have to present data in the left column before the columns to the right. Using CSS for layout, you can present the data in a logical order and use CSS to control the appearance. For example, in a three-column layout using tables, you’ll see left-column then center column then right column in that order. Using CSS, you can put whichever of the three columns is most important first, and keep the layout separate (which is the whole point of CSS). A real important point that I missed on the first pass. I don’t know what I was thinking.


Tables don’t degrade

The most important reason why using tables for layout is that they don’t degrade gracefully. For a good example of this, take a look at any page on this site. If your browser window is wide enough, you get a nice, two-column layout, just the way I intended. But if you’re using a narrower browser window, or a web TV (I still preview all my pages with the WebTV Viewer to make sure they look reasonable there), the page falls down to a single column with what used to be on the right down below the more important part of the page (or at least what I think is more important to most people). Tables don’t let the page degrade gracefully, and that’s their biggest problem.


Tables don’t print as well

A huge problem with tables (pointed out by a reader, this is another one I missed on the first pass) is that they don’t print terribly well. With CSS, you can use a print style sheet to give another look to the page. This style sheet can also include page-breaks that are under your control. You can also have elements that only show up when rendered to a screen, but not to a printer (headers and footers, for example). Or elements that show up when printed, but not to a screen (useful for expanding links so they’re visible when printed). Take a look at How to use valid code to make your life easier for a swell example. Now look at it using Print Preview if your browser supports that.



Scripting News uses tables to do layout. Dave’s Picks uses CSS. Here are images showing how they degrade. The view in Internet Explorer (5.1 Mac) is on the left and was shrunk to 25% of its original size. The view in WebTV Viewer (2.0 Mac) is on the right and was shrunk to 33% of its original size.

Scripting News

scripting news viewed in explorer scripting news viewed in webtv

Notice how the center column, containing the important information, gets scrunched so the text is very narrow.

Dave’s Picks

daves picks viewed in explorer daves picks viewed in webtv

Notice how the left column, containing the important information, expands to fill the whole width, keeping it readable.



Dave Winer writes:

Here’s Dave P’s weblog. I have a scaled-down rendering of Scripting News that I think is more readable than his, and doesn’t compromise the reader experience for people who have reasonably modern machines with a graphic Web browser.

My response is that having two separate renderings is an option. Having a single rendering that degrades gracefully is another option. Both are ways to have content that anyone can read, which is my goal. I think it’s Dave’s goal, too. We just have different ideas about how to get there. I’ve been thinking about making a separate version of Dave’s Picks for cell-phones and other "crippled" browsers for a while, but I don’t think it’s worth it in my case. Much of the daily blog stuff links to newspaper articles that don’t have a good fallback, so I don’t want to imply that I point to low-bandwidth things.

The other thing about my approach using CSS is that all the information is still there. While I sacrifice the layout, all the links that used to be on the right are still visible to the user. They’re just at the bottom of the page, instead of on the right. Dave’s scaled-down rendering actually has less information available to the reader. I think that’s a good choice if you’re aiming at someone reading on a cell-phone. I don’t know if it’s a good choice for someone who’s got the browser window set to 500 pixels wide (I don’t think it’s unreasonable to want to have two browser windows side-by-side on a 1024x768 display - I don’t design for that, but I’d like things to still be readable).

Dave Winer again:

Finally, those of us who use tables are part of a mass of people who learned to develop websites that way. It’s impossible to get us to change.

I learned to develop websites that way, too. But I’ve kept learning since then.

Harold Levin asks:

One issue that public institutions face with web sites is complying with the Americans with Disablities Act. There is standard advice for use of tables and the ADA: make the left-to-right top-to-bottom order of text in tables meaningful so that screen readers (aids for visually impaired) will present the text in the way intended.
How do your CSS techniques interact with this consideration?

Quite well, I think. The only real trick is presenting the divisions (the <div> tag is my friend) in an order that makes sense. If you look at the source for Dave’s Picks, you’ll see that I’m careful to present the stuff on the right last. And an added benefit is that if I want the links on the left, I can change the CSS and accomplish that. Let’s see you do that with a table!

Ryan Tate asks:

i tried that 3 column liquid layout page, and when i scaled in my browser window, it simply hid one of the columns outside the window (on the side) and added a horiz scroll bar at the bottom. isn’t that exactly what an HTML table will do if you specify a min width for the main cell?

I don’t know about the 3 column liquid. I could never get a 3-column, CSS-based layout to degrade the way I thought it should. But I haven’t had time to investigate that layout yet, either. Horizontal scroll bars are just evil, and I try very hard to avoid them at all costs. That’s one of the reasons Dave’s Picks only has two columns. The liquid, three-column layout I cite below has a horizontal scroll bar for me in Mac IE 5, so it’s not an option for me.

Craig Saila points out:

A horizontal scrollbar appears because the layout is designed to "freeze" near 640 pixels (unlike those at glish.com and bluerobot.com) so that the columns don’t overlap at lower browser widths. The layout is liquid above 640, though.

By adjusting the width values in the layout’s CSS you can reduce or increase the minimum width of the layout, but the templates purpose is such that it will always have a minimum width. If that behaviour is not desired, it’s best if you use Al Sparber’s (of PVII) template at: http://www.projectseven.com/whims/cssp_3box/3boxnoscript.htm

Thanks, Craig! But Al’s layout still shows a horizontal scroll bar in Mac IE 5.1 for any window width up to 1024 pixels. Sigh. It’s a box-model problem in IE, I think, but it’s still darned annoying.

Ryan Tate:

your argument seems to be that you want pages that’ll degrade gracefully on, say WebTV. but as the article at http://www.alistapart.com/stories/tohell/index.html makes clear, the pages don’t degrade gracefully on older browsers like netscape 4. i like tables because they work for people with older browsers, and, if i set them up right, degrade just fine in, say, Lynx.

Actually, Dave’s Picks (to use the example I’m most familiar with) degrades pretty well in NS 4, NS 3.x, NS 1.1N, as well as lynx. I’ve got about a dozen browsers on three computers that I test things against every once in a while. I don’t do it very often, but I also don’t make drastic changes to my page template very often.

Dave Winer has more comments about CSS. I’ll address ’em one in order:

  1. I didn’t know CSS a couple years back. I learned. I’m not the only one. HTML on its own is lacking enough that there’s an incentive for people to learn.
  2. CSS is complex, and there need to be better tutorials. I wish I had the time to write one.
  3. Browsers are going to have to support tables one way or another. Red Herring.
  4. CSS isn’t that weak. See css/edge.
  5. I agree. Buggy browser support is a major problem. Even Mac IE, which aims to have the best CSS2 support still gets some things wrong. But as I wrote in The Problem with Standards, having a validator available for the pages is a darned good start.

Other Resources

Copyright 2009, Dave Polaschek. Last updated on Mon, 15 Feb 2010 14:08:56.