Why not tables? Is CSS really better?

August 23, 2007

Topics: Accessibility, Semantics.

At Cre8asite Forums this week, a lengthy discussion on the ultimate value of pure CSS (Cascading Style Sheets) (Cascading Style Sheets) based layout over the use of tables has been taking place. Sometimes, living in the sheltered world of accessible and standards-based design, I can lose touch with the fact that many people out there simply don’t accept some of the same guidelines I work with every day — and that this does not, in any way, mean that they haven’t given the subject a fair shot. Very good arguments have been made to defend each side.

On the whole, I think this discussion is an old, worn-out subject: those who won’t use tables generally don’t use them out of principle, and those who do use them out of pragmatism and a justified awareness that principles don’t build websites. I want to review the question once more, however, ignoring the entire question of principle.

The Argument Before Us

The question at hand in this forum discussion has been whether tables have a fundamental, universal flaw which should make them unacceptable. Many arguments have been offered, but don’t satisfy the true question.

Answering the question is actually very difficult. It needs to be an inherent characteristic of tables, rather than a factor which depends on a specific use of tables or a facetious argument about which one is “easier” to use or maintain.

I’m opposed to using tables for layout — but now I want to look very closely at why. I want to find a reason outside of my own biases and beliefs, which can be simply stated and demonstrated.

Is it possible to use tables for layout and provide an equally usable and accessible web site?

For the best analysis, we have to assume that these tables are being used in a respectable manner. Bad code is bad code, whether it’s applied to <div>s or <table>s. Twenty-eight layers of nested anything is bad news.

So, there are three rules which must be met in order to be a definitive advantage:

  1. I’m not willing to accept minor design limitations as meaningful for either option. Whether there are certain design choices which you don’t have open to you with tables or with CSS-based layouts is irrelevant to me: you choose a tool, and work with the capabilities of that tool.
  2. I don’t accept ease of maintenance of development as being relevant. These are personal opinions and personal choices.
  3. I’m not going to consider semantics except as it may effect the user experience. A context in which the use of tables for layout causes problems because the device assumes any table is purely tabular data is a problem; the argument that tables are “wrong” for layout is functionally meaningless.

The only acceptable argument is whether there are ways in which the use of a table for layout inevitably damages the user’s experience with that site.

Examples of perceived weaknesses of tables

Speed of rendering. Unless table widths are specified explicitly, the entire content of the table must be rendered fully before the browser can completely render the page. This slows down the overall loading time of the page.
This does not fulfill the requirements. First, this is also true of CSS based websites. Second, it’s avoidable.
In order to provide an accessible website order, you have to arrange your data cells very carefully, due to table linearization.
Partial pass. The only real difference is that with tables, whatever will appear on the left MUST be before what appears in the center. Of course, there are easy workarounds for it. There are, in addition, many other ways of navigating around a page which make the whole concept somewhat irrelevant — it doesn’t ultimately matter that much whether your navigation appears before your content, if you’ve made effective use of other key structural elements or skip links.
Adaptability with variable browser widths
Tables can only become as narrow as the content they contain, even if they are constructed using percentage widths, etc. Div based layouts can re-flow content, so that sidebars slip to the bottom as the screen width narrows. The question is: which behavior is worse? Would you rather have to scroll to the bottom to see sidebar or navigation content, or scroll horizontally for the same? I’d rather not ever do horizontal scrolling, but this isn’t a clear pass.
Compatibility with mobile devices.
Technically, the same problem as above. However, many modern devices don’t really have this problem. There are four basic methods of rendering sites in mobile devices: linearizing, zoom, rewrite, and “try and interpret the standard styles on a tiny screen.” The 4th method is the only one which is likely to really run into problems with tables — and it’s fundamentally identical to the previous described problem.
Ability to accomplish radical redesign without altering HTML (HyperText Markup Language) code.
Depending on your definition of radical, this is a total winner for CSS layouts. Tables fix the fundamental placement of elements where CSS based layouts allow those fundamental elements to be moved more or less at will. Whether this is seriously important, however, is a matter of personal opinion. Arguably, this is a question of design capabilities, and fails rule #1.

That’s all I can think of off the top of my head, although I’ll happily accept suggestions from the comments.

Before I move on, however, I want to approach this from the opposite direction. What are the advantages to using tables for layout? The same rules apply: only a situation where not using tables for layout damages the user’s experience will absolutely qualify the table as a superior method.

The main reasons people have so far espoused as benefits to using tables for layout include:

This is actually a very interesting problem, which clearly exposes some of the weaknesses in CSS: specifically the lack of ability to specify that a block level element is centered without specifying that the text within is centered. I’ve constructed an example, but it only functions in browsers which support display: table. Opera and Firefox make it fine, as does Safari — but Internet Explorer, as usual, falls short.

Easier to learn and use
Matter of opinion. Doesn’t qualify.
Easier to create a multi-column layout with full-length columns.
Yes, it’s easier. But the fact that with CSS this is quite difficult is not a huge advantage — although we ALL agree that CSS will benefit greatly from more advanced support across browsers.
Certain layouts are only possible using tables
This is extremely difficult to prove. In the Cre8asite thread, Ron Carnell suggested a specific layout which he believes is not possible to accomplish without using a table. The challenge is to present a poem with a heading where the lines of the poem are left-aligned, but the poem as a whole is centered under the heading. The poem and heading should be able to have lines of any length and still remain centered correctly. (See “flush left” sidebar.) Although CSS appears to fail this test, the test itself comes under rule #1, as well. It does not substantively effect the user experience.
Browser Compatibility
Older browsers have lousy support for CSS. This is pretty much a no-brainer. Older browsers (Pre-IE (Internet Explorer) 5.5) pretty much just have to receive style-free versions of CSS-based layouts. Still, it’s a very valid question whether providing support for Netscape 4.8, IE 4 or similar relics is actually valuable. As of today, statistics for August 2007 at theCounter show that all versions of Netscape 7 and below plus all versions of Internet Explorer version 5 and below accumulate to approximately 1% of browser market share. Versions of IE in the 5 range account for over half of that – but it’s still less than 1%. (Browser Statistics for August 2007 as of August 23rd, 2007.)

In Conclusion

The conclusion, so far, is inconclusive. Tables, when used with a high level of consciousness concerning how and when they can be used, can provide a perfectly flexible, fast, web site. Though there are definite flaws with tables and how they present information, many of these problems are paralleled by related problems when using CSS based layouts.

There don’t appear to be any serious benefits, however, to using tables for layout. Although the table may make layouts easier for certain contexts: particularly when using centering and fluid widths or establishing full-length columns, these aren’t, in my opinion, issues which are capable of selling the table as a tool for layout.

In the absence of any definitive benefit for either tool, I will choose not to use tables for layout. I am, however, interested in this argument, and would be glad to hear your own arguments for or against either method. I have little doubt that I’ve missed cogent points for both sides!

Have something to contribute?

« Read my Comment Policy

35 Comments to “Why not tables? Is CSS really better?”

  1. Hi, Bruce – Thanks for your comments! The main reason that tables are frowned upon is because, if not used correctly, they can cause significant problems for users of screen readers and other linearized content devices. As far as web browser support goes, I think it’s unlikely that future browsers will cause any significant problems with the rendering of your designs.

    With both tables and CSS (Cascading Style Sheets) layouts, the biggest problem is with poorly implemented usage; not an inherent failure in either system.

  2. It is amazing that this blog post was written 3 years ago and we are still comment. Great blog post, Joe.

    I have designed over 300 websites for 15 years and when tables came to the rescue for layout, we are very lucky. CSS (Cascading Style Sheets) was not available yet. My problem was that I became so used to designing with tables, that CSS layout was very difficult to master and the cross browser issues with CSS just made even harder and more frustrating. With table layout, you simply do not have the cross browser challenge and it still seems like an easy way to design websites.

    I still do not understand why tables are so frowned upon even when I read lots of web pages on why tables are the devil and so far, none of my table layouts have broken in any web browser yet.

    I am open to opinions, but I have been forcing myself to use CSS layout and am finally getting the hang of it, although I always feel like going back to laying out my web pages with tables. I have not designed a website with tables in about 10 websites.

    My only question is that if tables have not yet broken my layouts, will they in future releases of Firefox, Internet Explorer, etc?

  3. Hello Paul,

    On Dreamweaver, you can convert Tables to Divs and vice-versa going to “Modify -> Convert”

    Excelent article by the way.


  4. I appreciate the article as well! I am new to web design, and am using an old version of Dreamweaver 8. I don’t know how to hand code yet, but I wish there were a way to “draw” a table with cells, and then convert it automatically to CSS (Cascading Style Sheets). I know it’s lazy, but I will never be a professional, but would like to have a standards based web site.

  5. @Kevin It’s very clear that there are reasons that organizations use tables for layouts. They do provide some capabilities not readily available in other ways, and make other issues easier — semantically, however, they are still incorrect.

  6. I apologize. Target is all CSS (Cascading Style Sheets). It was another retailer.

  7. I really appreciate this article. As someone relatively new to designing web sites, I learn by studying the code behind the sites I like. More often than not, I will come across a site and ask myself, how in the world did they lay all that out with CSS (Cascading Style Sheets)? And more often than not, it is not laid out with CSS, it is tables.

    I want to note it is not just a few sites that still use tables, there almost seems to be a growing number.

    I keep hearing that tables are the Devil, but honestly, it seems to be a fairly efficient way to structure and lay out a site with a lot of images and competing content. This was just confirmed today when I saw Target’s site and wondered how they laid out the site and again it was with tables.

    If people are still dancing with the Devil, there must be a reason.

  8. “For questions having to do with ranking on Google, that’s a good place to go. However, this issue really doesn’t have anything to do with ranking — it has to do with information processing. Google talked about it in a blog post: using named anchors.”

    Excellent and very timely. Thanks so much.

  9. For questions having to do with ranking on Google, that’s a good place to go. However, this issue really doesn’t have anything to do with ranking — it has to do with information processing. Google talked about it in a blog post: using named anchors.

    They aren’t specifically using headers; but headers are the best way of delineating the anchored sections of a page discussed in the Google blog post for many reasons.

  10. Thanks for your answer, and thanks for the information on this page. It is very helpful.

    You said, “Already, Google is making use of page headers with internal anchors to provide quick access to information..” I wonder if you could point me to the source of this info? I tend to send folks who have questions on Google page ranking to http://www.google.com/support/webmasters/bin/answer.py?answer=35769#3. I’m not seeing anything in there regarding page headers or anchor tags. Is there a better source for this info?

  11. Code which semantically represents the content appropriately provides better information for machine translation: screen readers, braille readers, or other methods of information discovery. Already, Google is making use of page headers with internal anchors to provide quick access to information which is found at a greater page depth than the top of the page – this is an example of semantic discovery.

    Since all visitors are using some form of information translator to access web sites, using semantic sense in your code can provide users with a benefit.

  12. “Writing code well *might* be better for search engines, but is definitely better for visitors. I advocate the use of CSS (Cascading Style Sheets)-based layouts, on the grounds that they are semantically more appropriate for site design.”

    How does being “semantically more appropriate” help visitors?

  13. That point has pretty much been gone over, although not in this discussion — and the answer is ‘not a lot.’ There are those who might argue that CSS (Cascading Style Sheets) has a benefit due to load speed or code to content ratios, but in fact this is a specious argument — even if these ‘benefits’ did have a significant effect on SEO. Load speed and code to content ratios are really the effect of good coding practices, not your choice of layout elements.

    Writing code well *might* be better for search engines, but is definitely better for visitors. I advocate the use of CSS-based layouts, on the grounds that they are semantically more appropriate for site design.

  14. No one seems to have touched on a point that was brought up by the guy who started the forum discussion, that is, what effect to tables or CSS (Cascading Style Sheets) have on SEO. I am a business major, but specifically I am fascinated by internet marketing, and specifically SEO. Is CSS really “better” for search engines? I am just beginning to teach myself website development through YouTube tutorials and online discussions (such as this one). I would like to teach myself the best (if there is one) way to build a site for business. What are your thoughts?

  15. Hmmm. Thought-provoking, I must say. I myself use tables most of the time, I am not that familiar and comfortable with doing table-like outputs using CSS (Cascading Style Sheets). Mostly I use CSS for the style and design, but as for the actual layout, I go for the tables. I might just try to create a CSS layout in the future. Nice read, keep it up.