Kimler Sidebar Menu

Kimler Adventure Pages: Journal Entries

random top 40

Die Tables Die

Filed in:XHTML
The Web

Die Tables Die

February 2nd, 2007  · stk

Don't web designers now know NOT TO USE TABLES FOR PAGE LAYOUT? I thought so, but an email, received from the President of a web media company, says otherwise

Tables for tabular data ONLY ... NOT for LAYOUT!!

tableless designs

Last night, I had an interesting e-mail exchange, in which someone was using an datalist to display three PZ3 images in a row. They were having problems with IE. (No surprise there). :p

First, I know very little about, but I asked the fellow for a copy of the page (X)HTML and CSS and said I'd look into the problem.

It was a basic page, nothing too odd (though I did notice a bunch of bloat). I quickly found the problem: the fellow was using a table to contain the single row of three PZ3 images, each in their own cell (browsers often fail to correctly interpret CSS directives inside table cells).

I haven't used tables for layout in years and assumed that (by now) the message to do so, would've gotten out. Obviously not.

I wrote back and said, "Using a table to hold the three images is semantically incorrect (because no tabular data are being displayed) and the root of your problem. To fix it, just take the three images out of the table." I even provided some XHTML-valid code that would accomplish what he wanted (semantically correct and more succinct).

The response I got back, floored me.

I am displaying data from a [sic] XML file that display files. Those images are in each cell, so yes I am displaying tabular data. (emphasis mine)


Maybe what he's trying to say is that "he can't get rid of the table", but if so, it's because of a limitation in the language he's using and not because it's semantically incorrect to do so. At the end of the day, it doesn't matter how stores/retrieves/interprets the image data, what does matter is:

Displaying three images in a row, is NOT a display of "tabular data".

To top it off, this fellow isn't just anyone, he's the President of a web media company. He should KNOW BETTER!

The exchange bothered me enough that I thought I'd write my own version of "What I think should be tacitly understood anyone writing HTML code".

To find out why tables are bad (should be used for displaying tabular data, NOT FOR LAYOUT) and what is "tabular data" anyway? .... read on.


Why Tables are BAD-BAd-Bad-bad

Never use tables for layout.

Truth is, they're not bad, they're just badly abused. Tables are fine for displaying tabular data, but should never be used for page layout. The problem with tables has arisen, because they have been abused and used for page layout, by many designers.

The whole goal of using tables is to "arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells" (Source - W3C HTML Recommendation).

Furthermore, the W3C also recommends against using tables for layout. Here's what they have to say on the matter (same document):

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

Besides simply being a W3C recommendation, not using tables for layout just makes plain sense.

Why Tables for Layout Suck

  • Tables require more code.
  • Tables take longer to load.
  • Tables prevent incremental page display.
  • Tables may require image slicing.
  • Tables break text copying on some browsers.
  • Tables prevents some CSS from working within them.
  • Tables layouts are convoluted and confusing.
  • Tables are semantically incorrect for layout.
  • Tables break for screen readers.
  • Tables make redesigns/modifications difficult.


The Solution & the Backlash

The solution, of course, is to use CSS and DIVs (along with other, semantically correct, elements) to design and lay out a web-page. The benefits for designing this way are readily apparent to anyone who is doing it - flexibility, accessibility and future-proofing (among others).

Web developers are beginning to design to web standards, making semantically-correct pages. That's a good thing. The backlash, is that using tables has gotten a bad rap. Many people have interpreted "Don't use tables for layout" into "tables are bad".

Many forget that tables still have a useful and semantically correct place on a web page - for displaying tabular data.


So What ARE Tabular Data?

Tabular data are the kind of data one would expect to see in table-form, or information that has a two-dimensional relationship. Consider the following table (LOL - oh crap, now I have to make up a table, which I don't often have need to do ... and style it! :|):


Popularity Dog Names Votes
1 Rover 34,566
2 Spot 28,502
3 Fido 10,275


The above example table, which could be titled "The Three Most Popular Dog Names", has relationships in both the horizontal direction (Popularity, Dog Name & Vote) and the vertical direction (Popularity, Dog Name or Vote lists). In other words, it has two-dimensional relationships. Though it's possible to present the data some other way, it just makes sense to arrange it in columns and rows.

That's a good way of determining IF your data should be presented in a table or not, (i.e., is it tabular data?) - does it have 2-D relationships and does it make sense to display it in rows and columns?. (Could your table cells fit into Excel, or some other spreadsheet program, having a descriptive row and column titles)? If the answer is 'yes', then you're likely dealing with tabular data and should use tables. If 'no' (as in the case with three images in a row), then it's NOT tabular data and shouldn't be inside a table.



Tables are not inherently "bad", but they've been abused. Use them for displaying tabular data ... not for page layout.

I didn't think I needed to write this, but I sincerely hope it helps others. (Hopefully, the President of a certain web media company, for one.) :D


Views: 30252 views
18 Comments · GuestBook
default pin-it button
Updated: 25-Nov-2008
Web View Count: 30252 viewsLast Web Update: 25-Nov-2008

Your Two Sense:

XHTML tags allowed. URLs & such will be converted to links.

Subscribe to Comments

Auto convert line breaks to <br />

1.flag Jonathan Kemp Comment
Very good post about using css for layout and tables for tabular data. I totally agree and build all of our web sites that way. It is still surprising how many webmasters do not do this or know about standards.
2.flag stk Comment

Thanks for the kind words.

I had a quick look at your site and enjoyed the article - about ColorZilla. I'll have to look into that.

Right now, I use a free utility called Pixel Probe, which (basically) does the same thing ... minus the selector bit.


3.flag Glenn Comment
Ya that dumb ass. lol
4.flag stk Comment
5.flag EdB Comment
I used tables recently for non-tabular data. After seeing what my CSS did in IE I found it much easier to throw the content into a table than to work the CSS to do what I wanted. Understand this was for a site that thinks the phpbb forum is THE site and everything else is extra... phpbb is table-city :(

Anyway I totally agree with you. I *like* being table-free in my own domain. What's that domain you might ask? Why it's (not that I'm sucking link-love off you with that shameless self-promotion ;) )
6.flag stk Comment
One good turn, deserves another, eh Ed? :D
7.flag DontheCat Comment
Scott, thanks to you I shifted from tables to CSS layouts totally.

Yeah, I use them still for displaying MySQl data. Easier to populate and repeat :-)
8.flag Ed Comment
Just spent about a week making a new template for my companys newsletter. Guess what? CSS is hardly supported by email clients, both on and offline. Notably gmail, which has nearly no support at all.
So I have to redesign the whole thing in tables. AAAAAAARRRGHHH!!!
So there are times when tables still have to be used.

'Die Tables Die' indeed!
9.flag stk Comment
Ed - I'm sorry to hear about your frustrations and pain (try to write to web standards and end up having to do it the old way). :(

Not using tables for layout is a WEB standards movement and because email clients are not "the web", they're way behind in standards support. I don't envy your task of making an HTML newsletter for email client, knowing that some people have text-only email support, use a non-HTML mode or don't allow graphics ... so any HTML-based presentation (tables or otherwise) and perhaps the message itself, may not get even get through.

Anyone making such email newsletters might find this article interesting, as it talks about the present difficulties in creating an HTML document for email clients.

At the end of the article, is a good reading list of resources on CSS support in a variety of mail clients. One I found intriguing, was this one.

Hopefully, web standards will universally supported by email clients, both local and web-based, in the future.

10.flag Jonathan Comment
Funny stuff. :) I just happened across this blog when looking for a good XHTML table resource that describes the good and bad of tables. I'm learning XHTML in school right now, and ironically, one of the exercises I'm working through involves putting three images in one row of a table (and nothing else). :P I'm glad I cam across this, though, because I might have been tempted to use tables in such a manner in the future.

11.flag A. Boulley Comment

In your zeal to slam the guy with long buzzwords, you gloss over what he was actually trying to do. Hence, you totally miss the point and fail to provide a viable solution to the real-world problem he's trying to solve with tables. Furthermore, you incorrectly assume he's spelling XHTML wrong, as evidenced by your insertion of "[sic]" into the quote of his response to your self-righteous suggestion.

In my opinion, this person is using a table in a legitimate manner - the images are the data and an XML file is the source. Many situations call for an XML file to hold filenames so a portion of a web page becomes easily customizable. This method is especially useful when combined with Flash; for instance, a slideshow that a third party can alter simply by uploading new image files and updating the XML data source.

Whether you believe it or not, a single row of data is still data. And as such, if a person wants to display that data in a tabular fashion, they are perfectly within their rights to use a table. You could have tried to help the guy with his markup instead of telling him unspecifically to change how he's doing something. Your aptitude to behave zealously shouldn't get in the way of answering a simple question.
12.flag A. Boulley Comment
Hey stk,

I meant the previous post for you. Address what it says instead of the address.
13.flag stk Comment
A. Boulley - LOL @ your apology for calling me 'Jonathan'. :p
14.flag stk Comment
A. Boulley - My article obviously hit a nerve with you. Since you think that the intent was to "slam the guy with long buzzwords", you're the one missing the point. Let me address some of your assumptions and errors:

1) "you incorrectly assume he's spelling XHTML wrong, as evidenced by your insertion of "[sic]" into the quote of his response to your self-righteous suggestion." - Wrong. The [sic] follows the 'a' because it should be 'an XML', rather than 'a XML'. You'll note the acronym is "eXtensible Mark-up Language", not "eXtensible Hyper-Text Mark-up Language". ;)

2) "you gloss over what he was actually trying to do" - Nope, I only glossed over how he got there. That he is using an XML file to store image filenames is of little consequence when the end result is an XHTML file.

3) "In my opinion, this person is using a table in a legitimate manner - the images are the data and an XML file is the source." - It may be your opinion that he's using tables in a legit manner, but using tables for layout is not recommended by the W3C for the reasons I outlined. (Putting three images into a table row is using tables to layout the images on the page).

4) "Whether you believe it or not, a single row of data is still data" - I do believe "single row of data is still data". However, it's not necessarily tabular data, and that's really the test that should be applied. (Characters are data, should each be placed in a table-cell?)

5) "You could have tried to help the guy with his markup instead of telling him unspecifically to change how he's doing something. Your aptitude to behave zealously shouldn't get in the way of answering a simple question." - I don't blindly answer questions without thinking about them first. If someone asked me, "How do I put cement down my toilet?" I'm going to ask first, "Why do you want to put cement down your toilet?" Same applies here. "How do I get PZ3 working inside a table?" is going to beg the question, "Why are you using a table?"

The fact is, there are lots of people that use tables for layout and other things they shouldn't. I'm simply spreading the word that it's not ideal and pointing folks to solutions: using tables for tabular data; using DIVs, CSS and other semantically correct tags for layout.

15.flag Paul Comment
Tables bad-bad-bad? Calm down, It is just a tag, a useful one for what it does: displaying data or breaking the page into pieces. DIV's are fine, too, but they still suffer from many (many) browser implementation issues.

Do a DIV-three-column Layout, middle column always centered, with a sticky(!) footer and non-clipping backgroundtiles, displays the same on FireFox, IE, Safari, Opera, etc. ... it is IMPOSSIBLE if what you want is clean and fast code. You would need a thousand CSS hacks and probably Javascript fixes. Yet with a table all you need are three TD's and that is it.

Comes to my mind my old programming teacher in school who would rather have four nested loops to avoid ONE "goto" - and why? Because someone told him it's "bad-bad-bad." My philosophy is: use what makes most sense.
16.flag Paul Comment
Btw, reading through your code underlines my point.

<!--[if IE]>
<!--[if IE6]>
<!--[if IE7]>
<!--[if ...]>

Non-Standard Browser checks in so-called "standard-code," this is the real evil - but nonethelss a sad reality, worse than ANY table could ever be.

As a web-developer, if I had to choose between a table or bag of ugly tricks - it would for sure take the lesser evil.
17.flag stk Comment
Paul - Non-recommended use of browser tags and browser support for web standards are two completely separate issues. I'll try to address your comments to both.

At the end of the day, you have only to account to yourself. If you find that a more practical solution for layout can be achieved through the non-recommended use of table tags, by all means, go that route.

The fact is, however, that table tags were designed to display tabular data and not as a tool for "breaking the page into pieces". Unfortunately, many people (and WYSIWYG web-authoring programs) default to using tables for that purpose, without even considering using div tags instead.

There's a difference between choosing tables over divs for a reason and blindly using tables without first considering divs.

Regarding browser support and the use of IE conditional comments. Yes, I agree it's a travesty that browser companies (notably Microsoft) don't do a better job of supporting web standards. I wouldn't characterize any of this as "evil", just unfortunate.

My preference, as a web-developer, is to write semantically correct mark-up and clean, standards-based code. Unfortunately, this conflicts with my - more important - goal of providing a good visitor experience, so I use IE conditionals. (There are other other ways of browser sniffing - i.e., it could be done server-side and would keep such "ugly tricks" from showing in the code. Would this be any different really? Not to my way of thinking).

BTW ... I happen to think conditionals are one of the things Microsoft did correctly, since IE isn't alone in their failure to fully support web standards.) ;)
18.flag Paul Comment
You are right and I agree.

But recommendations do not necessarily reflect the real world and they are just that: recommendations. The W3C writes its recommendations out of a futuristic (some might say utopic) viewpoint in which brosers actually respect standards, which currently they do not.

There is a very old truth: "Rules are meant to be broken"
Another one says "Rules protect the small man but are a burden to him who wants to grow" ;)