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) 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 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 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. It is surprising to see unobjectionable reporting, fox, cnn…. could get lessons from this article. I too use tables (for my header and footer layout) and css (for the main content in order to put the content before tthe side column). Great article keep up the good work.

  2. Rarely do I get a chance to read one of these articles that is not one side bashing the other. Thank you for that. I use both tables and css floats. It has the advantage of cross browser support, easily editable, w3c validated and was a breeze to design.

  3. Print layouts can be done purely with php. Just query the database and echo the results on a blank printable page. No CSS required.

  4. It’s hard for me to make a practical comparison between the difficulty of working with CSS and that of working with tables for layout; I exclusively develop sites using CSS, and have never done anything else. I imagine that I must do the ‘mental work’ you describe; but for me it’s really just part of the way I think while setting up a layout.

    As to whether tables to a better job to present sections of data – well, for many types of data, tables are absolutely the best way to layout data. That’s their purpose, after all: laying out data.

  5. Joe, I think I agree with you regarding the use of only tables for layout, it would definitely be a bad practice to layout a complete website using only tables now that I think about it.

    The only thing that definitely bothers me about CSS is all the mental work you have to do to calculate the real size of the “text area” inside a div styled with CSS, don’t you think there could be another way that combined the ease of defining tables regarding widths, margins, etc, with the flexibility and capabilities of CSS regarding background imaging and floating?

    Maybe its a stupid comment but when I started using CSS I was a little disappointed since everything fell out of place if widths in pixels or percentages were not quite precise in my design. What I’m trying to say is that CSS is not as easy as it could be and tables do a better job sometimes to present sections of data.

  6. Well, you find doing a layout with CSS to be tricky; I find layouts with tables to be completely unmanageable. It has everything to do with personal experience and knowledge. Learn any system well enough, and you’ll have little trouble with it.

    I would say that there are never web applications or web sites where all you need is tables — there are certainly web applications where the data is best presented in a table, without question – but there’s always use for CSS. CSS and tables aren’t an “either/or” dilemma; the question is when and where to use tables appropriately.

    If you’re not using CSS on a project, I’m inclined to think you’re taking the wrong direction to begin with.

  7. Maybe it’s my lack of knowledge on CSS, but trying to create a layout with CSS can be tricky since you need to be calculating continously the box size minus margin minus padding minus border width, specially for nested divs. Also line height vs text size among other things. My opinion is that there are web apps where CSS can do a great job, others where tables is all you need and some others (specially web apps and not websites) need a combination of both.

    Regards from Mexico. Antonio.

  8. Thanks for the analysis. I use W3C validated tables for my website and it works perfectly fine in all major browsers. Tables can be used only if one REALLY knows how and when to use them. RG.

  9. That’s probably true. I tried to align the idea of arbitrarily numerous tables in any manner as generic “bad coding,” but this isn’t really a clean case separation. To be fair, it could potentially even divide to five cases: CSS can unnecessary code depth as well. How to define excessively nested CSS is, of course, a bit more difficult to specify.

    The separation would allow the ability to characterize the advantages/disadvantages of different CSS implementations, as well.

    Further yet, the different methods of CSS layout could be characterized: relative positioning, absolute positioning, floats, natural order, etc. These all have different ultimate results when applied across various user-agents or browser dimensions.

    Yeah, finding a valid nested-table site sounds like a challenge I don’t want to take up. If such a thing even exists…

    I’ll definitely consider going through the analysis again with those additional instances in mind – would be interesting.

  10. I think you should rerun your analysis against four cases, not two: One table for layout, arbitrarily numerous nested tables for layout, arbitrarily numerous sequential tables for layout, and CSS.

    And, ideally, check typical invalid-HTML vs. valid-HTML versions, though it will be next to impossible to find a nested-table site with valid HTML.

  11. I’m inclined to agree with you, Mike. The reason I discarded semantics and “content-appropriateness” is that many of those developers who evangelize the use of tables for layout also consider the idea of web semantics to be an academic illusion. Thus, it’s an ineffective argument.

    One argument which really surprised me (in the Cre8asite thread) was somebody who argued that adding semantic table elements to a layout table made the table appropriately semantic — as if using the element was what creates meaning, rather than helping to define an already existing meaning.

    Thus, from the perspective of creating accessible, SEO-friendly sites with CSS is infinitely easier and simplified. In my opinion.

    Mine, too.

  12. Nice article Joe. A well-reasoned argument. My opinions:

    With CSS layouts there is a smaller amount of required mark-up than that required as a minimum with tables. If one wants to make proper tables that is.

    Based on my own experiences it seems most CSS layouts do load the page more quickly, but it’s not the speed I seem to notice as much as how the page loads. On a tables-based site there does seem to be a lot of last minute building going on during load. I can hear the hammering, sawing, and the break truck going ding-dong, ding-dong.

    My number one concern with tables is the fact that the content of tables is supposed to be tabular form and have meaning when done this way. It has certain elements that are required to make this tabular data understood by all users. But with tables-based layouts I think most of these elements simply aren’t used — table head, caption, summary, etc. Thus, I think retaining the markup’s inherent accessibility with a CSS layout is a LOT easier, and it requires a ton of extra mark-up and skill to make the same thing happen with tables. Thus, from the perspective of creating accessible, SEO-friendly sites with CSS is infinitely easier and simplified. In my opinion.

  13. This is gonna get lengthy… πŸ˜‰

    Responding to Stevie D:

    1) Ease of maintenance, etc.

    The situation you’ve described is what I’d consider “bad code” – that’s an example of use tables in such a manner as to make maintenance a severe burden. I certainly agree that such a use is a major problem. However, I’m trying to make a fair analysis, discarding poor use of code in either respect:

    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 divs or tables. Twenty-eight layers of nested anything is bad news.

    I’ve also worked on standards-based, div driven sites where maintenance and adjustment was a major chore because everything used absolute positioning and numerous layers of nested elements. That’s not a problem unique to tables.

    Maintenance also has a lot to do with workflow – many larger businesses actually do the bulk of their site maintenance through content management systems. How much does the practical coding of their site actually effect day to day maintenance?

    2) Adaptability to screen widths.

    I agree. CSS is generally superior in this area.

    3) Easier to learn and use.

    Tricky one, isn’t it? I certainly don’t find tables easier. The problems that crop up with table organization (missing cells; etc.) are just different from the problems with CSS (complicated floats). The reason I just can’t accept the argument either direction is that it’s completely a matter of opinion — each person has their own way of learning and their own design style.

    4) Centering, etc.

    Surprising, isn’t it? I think a “shrinkwrap” option would be fantastic.

    5) Print Stylesheets

    Actually, print stylesheets can be used with table-based layouts. It’s more difficult, certainly, but you can use the print stylesheet to remove various chunks of advertising, images, other extraneous information. I’ll grant you, however, that with a fully CSS-driven layout, print stylesheets are FAR more powerful.

    Thanks, Stevie D!

  14. I say all this as someone who loves CSS, hates layout tables, and nearly had a coronary when I read DeCloak.

    I don’t accept ease of maintenance of development as being relevant. These are personal opinions and personal choices.

    For a personal site, that may be fair enough. For a commercial site, it isn’t acceptable. With my current job I took on responsibility for maintaining a website that my predecessor had created. It was table-based. All I wanted to do was add one item to the menu – it was quicker to rewrite the whole damn thing in HTML+CSS than figure out how to line the right bits of the table up with each other.

    Adaptability with variable browser widths.

    CSS has far more options for this than tables do. At the end of the day, it should be possible in any decent browser to remove all styles and linearise the page, which will allow any screen, no matter how small, to display the page in a sensible way – to do the same with tables requires the user-agent to do a lot of guesswork and is less likely to get it right.

    Easier to learn and use.

    Tables are easier to use if you start with a presentational attitude and a “WYSIWYG” editor. A lot of people say that tables are easier because that’s what they know, forgetting that’s only because they have had more practice.

    Basic-to-middling CSS layouts are not difficult, no more complicated than table-based layouts and often less (especially if you start from a semantic/content attitude), and it’s only because so many people are habituated into using tables that they find CSS difficult.

    the lack of ability to specify that a block level element is centered without specifying that the text within is centered.

    That ought to be easy to do. It must be. Surely! Hmmm … apparently it isn’t.

    Why does CSS not offer a ‘shrinkwrap’ option, where a containing block is only as wide as it needs to be?

    But to me, one of the biggest advantages to CSS is print stylesheets. Pressing the Print button on most table-based webpages gives you loads and loads of adverts, sidebars, navigation menus, and 85% of the text. The remaining 15% disappears irretrievably off the right-hand side of the page. When even someone as technophobic as my dad has figured out to copy-and-paste the text into Word to get it to print, you know there is a serious impediment to usability. Print stylesheets allow changes to layout, graphics, content and typography that table-based layouts could never even dream of.

  15. There are quite a few solutions to the full-length column issue; all with their own tricks and difficulties. Regardless of the presence of a solution, it remains more difficult.

    I just think that refusing to use CSS because columns are difficult is rather lazy… πŸ˜‰

  16. @Jermayn: Yes, it was absolutely worth the effort. I don’t think I said anything or made any serious attempt to demonstrate that CSS was superior — that wasn’t the point. The point of the exercise was to define the qualities of each approach and ascertain, for myself, whether my own preferences are justified.

    Ultimately, with outside contributions, I’d also hope to identify some defining characteristics of tables which I can point to as a specific and universal reason not to use them for layout. No bets on that at this point, however.

  17. Yes good analysis Joe but was it really worth the effort?? Knowing these dinosaurs who use tables still (I work with one). Know matter what you say and proove with CSS or even validation etc, they still wont do it…

  18. Yes, you’ve pretty much hit it there. The fundamental failing of CSS is it’s inability to create grids. The existence of floats is also a massive strength – since they are a means to create fantastic flexibility – but the corresponding absence of an abstract grid mechanism is, from a design perspective, a major lack.

    What I’d really like to see (and I don’t know how realistic this is) would be a grid structure where the interdependencies of the grid were variable. A structure where a grid element could be assigned a position in the grid through CSS, which could be changed independently of other grid elements. This is one of the weaknesses of tables — all grid elements are thoroughly dependent on other grid elements.

    Ah, dreams…maybe the CSS working group will come up with something like that in 25 years or so. That means only 50 years until browser implementation!

  19. Joe,

    Great analysis. I think there is one idea I want to add to your analysis: tables are inherently easier to use to create grid-based layouts. This is important because a lot of people think in grids. The columns on newspaper page, road signs, flow charts, etc, all look off if they somehow don’t fit on an invisible grid.

    With that said, I think the W3C missed a huge opportunity to create a non-table-tags grid-based layout mechanism. Instead they create the CSS box model with floats. We can argue which one is technically superior forever, but at the end of the day, IMHO one truth stands out: people don’t think in floats, which makes the whole CSS thing a failure; just look at how much code Yahoo! had to produce to create a CSS grid. However, it is easily fixed with a new set of layout-specific declarations that really ought to make it into CSS3.

    In short: grids are why people are using table-based layouts. It’s what they (the customers, if you will) want. It’s what the W3C should deliver. Till that happens, the debate will continue.

    Incidentally, grid-based layout has been around for ages. Tcl/Tk, GTK, even Visual Basic, all have grid-based layout engines.

    Pierre