An Objective Look at Table Based vs. CSS Based Design | May 12, 2004

Over the years there have been many great articles extolling the virtues of CSS based design and bemoaning table based design. However there have been very few articles looking at things from the other side of the fence. This is probably because you really have to understand and use CSS based design before you can criticise it. Yet once converted, few (if any) people go back to the old way of coding.

In order to bring some balance back to the equation, and to have a bit of fun playing devils advocate, I’ve decided to write an article about why in some instances, traditional table based design can be as good, if not better than CSS and standards based design.

The Demonisation of Tables

Before tables came along, the web was a pretty dull place. Using tables for layout opened up the possibility of visually “designing” a page. It could be argued that table based layout was responsible for the popularity of the web and the field of web design. That’s right. Without tables, all us web designers would probably be without a job.

Yet over the last few years, table based layout has become demonised. Web purists will tell you that tables were never meant for layout so you shouldn’t use them for such. However history has shown us many examples of technologies that started out life with one purpose, only to ended up finding more practical applications as something else. The web itself was never intended to be anything other than a way of sharing research data, and yet it’s become a channel for entertainment and marketing as well as information and education.

The Comfort Factor

As web designers, we’ve been laying out pages using tables for years. It’s a skill most web designers have, and most are comfortable with. Using tables in this way leads to very predictable results. By using a few very simple hacks, such as spacer gifs, we can pretty much guarantee that our sites will look the same on the widest range of web browsers out there, from the lowliest version of Netscape 4 to modern browsers such as Safari.

Despite the fact that pioneers have been talking about web standards for a long time, the majority of web sites are still developed using tables and non standards compliant code. Because of this, user agents will be forced to handle table based layouts for many years to come. This effectively negates one of the biggest selling points for web standards. That of forward compatibility. It’s highly unlikely that in the near future, any of the big browser manufacturers (um, that’ll be Microsoft then) will release a browser that renders the majority of sites unusable.

So most web designers really don’t feel there is an overwhelming need to start developing sites using CSS based layouts and standards compliant code.

Changing the Barriers to Entry

One of the reasons the web has been so successful, is it’s low barrier to entry. HTML is a simple “language” to learn and browsers are very forgiving about poorly formed documents. This makes it incredibly easy for anybody to publish on the web. Even your 12 year old nephew could knock up a simple site using the copy of Frontpage that comes bundled with Microsoft Office.

Compare table based design to CSS based design. Sure the syntax of CSS is pretty easy. Nobody in their right mind would argue that you need too be a rocket scientist to learn CSS. However, some of the concepts can be quite tricky to grasp. On the face of it, the box model is pretty simple, yet I still get tripped up by margin collapsing on occasion. Floating and clearing can be conceptually difficult to grasp, as can positioning. In my experience, there is probably around a 6-12 month learning curve from knowing basic CSS to actually being able to develop CSS based sites competently.

Then there is the problem of browser support. Once you’ve been doing it for a while, you get to know what browsers support what, and what the common browser bugs are. However, there are so many bugs, even the “experts” find themselves spending an inordinate amount of time bug fixing. For a novice this must be extremely frustrating. Not knowing if the problem is down to your misunderstanding of CSS or some obscure browser bug. Is it any wonder why the same questions come up time and again on list like CSS-Discuss?

When the browser manufacturers finally get their act together, developing sites using CSS will get a lot easier. Still, I think most people would agree that CSS development has a much higher barrier to entry than table based design. In an odd way, I think this is one reason why CSS based design is becoming so “popular” amongst web professionals. It allows them to differentiate themselves from the amateur “FrontPage Cowboys” and take back the web for themselves. Perhaps this is why many people see web standards as “Ivory Tower” and why many web standards advocates come across as having a sense of superiority and a zealous attitude towards web design.

Some Things Are Just Easier with Tables

I’m sure we’ve all found ourselves writing fairly complicated CSS to do something that would be trivial using tables. Take form styling for example. It’s possible to lay out even very tricky forms using tables in just a few minutes. You can achieve similar results by floating elements with CSS, but it’s a lot more involved. |f you’re a CSS guru it’s all part of the fun. However if you’re a regular mortal and your boss is breathing down your neck because they don’t understand why their “simple form” is taking so long, it can be incredibly frustrating.

If you have the knowledge and patience, you can do most things using CSS that you used to do using tables. Sure it may take you longer, but you’ll get there in the end (or die trying). However there are some things which, try as you might, you just can’t seem to crack. One such thing is page footers. I regularly see posts from frustrated CSS authors trying to create page footers than “stick” to the bottom of the viewport if the content doesn’t fill the whole screen. It’s pretty easy to do using tables, but try doing this using CSS alone. Is it any wonder why web developers turn their back on CSS when even simple things are rendered so complicated when you stop using tables.

Overstating the Benefits

There are lot’s of good reasons for throwing away tables and adopting CSS based layouts instead. However in their rush to push web standards, many people have overstated the benefits. It’s true that switching a large site to a CSS based layout can save a huge amount of bandwidth. However, for most sites, this saving would be insignificant.

People want fast loading pages and many advocates have suggested that CSS helps accomplish this. For most sites, the “design” is spread evenly across the whole site. However with CSS based sites, the “design” is usually held in one or more external files. These files can be pretty complicated, and even for a simple site, can get big, fast. A recent site I designed uses 4 stylesheets weighing in at around 12k (albeit including formatting and comments). By using CSS you’re actually front loading the design, rather than spreading it evenly across the site. The means that the first page you hit can actually take longer to download than the equivalent table based page. Once the styles have been downloaded, they will usually be cached and not need downloading again. However the first page on a site is the one page that you really don’t want to see such a performance hit.

Client buy-in

The sad fact is, most clients don’t care how a site is coded. Yet for some reason web designers feel the need to “sell” web standards to their clients. One way people do this is through the carrot and stick approach. The carrot is more often than not, search engine friendliness, while the stick is accessibility.

It’s true that the search engines like semantic pages. It’s also a widely held belief that search engines like lean code. Building a site using CSS and web standards can definitely encourage the development of search engine friendly sites. However it’s no magic bullet. There are many table based sites out there that score very highly in the search engines. It’s equally possible to build a CSS based site that gets a terrible search engine ranking. The most important thing for high ranking is content and inbound links, not whether a site uses tables or CSS for layout.

More concerning is the number of people who try to sell web standards and especially CSS based design by playing on clients accessibility fears. There isn’t anything inherently inaccessible about table based design. As long as tables make sense when linearized, their content is easily accessible. Screen reader technology is pretty good these days, and most screen readers are proficient at handling table based sites. While it’s true that your site needs to be published to a recognised set of grammars to get a AA accessibility rating, tableless design is only a recommendation, not a requirement for the more stringent AAA rating.

One often mentioned benefit is that of supplier independence. In a world were everybody develops to a standard, it would be much easier to switch between developers. They’ll instantly understand how the site was put together and not have to trawl through somebody else’s tag soup. This is reliant on having a significant number of suppliers versed in web standards. Unfortunately this currently isn’t the case. While the number of skilled CSS developers is increasing, it’s still a relatively specialist field. Because of this, it could be seen as a relatively risky proposition for a large company to lock themselves into a style of coding when there is such a lack of skilled coders. In my experience an organisation will often have a single individual experienced enough to develop a site using CSS. For many organisation switching to web standards could actually increase their dependancy rather than decrease it.


Web standards and CSS based design are definitely the way forward. However in our rush to advocate these “new” techniques, we may end up believing our own hyperbole. Build something up enough and the reality will always fall short of our expectations. By taking a dogmatic approach we risk alienating the very people we are trying to convince.

Table based design will be around for a long time. To encourage developer buy-in we need to lead by example and help reduce the barriers to entry. Not create new barriers. We need to be honest and up-front about the benefits as well as the cost. Developing CSS sites can be hard and it can time consuming. In certain circumstances using tables for layout can make much more sense than CSS.

Posted at May 12, 2004 9:17 PM


Jimmy Morin said on May 12, 2004 9:40 PM

This is one of the most insightful comments about CSS i’ve seen in a long time. I’ve used CSS for basic styling for years but it wasn’t until a year or so ago I started using CSS to completely design pages.

The one thing I think makes it harder to grasp CSS are all thease hacks neccesary today to make CSS sites look good in most browsers.

Of course, you had to use some hacks when making designs using tables too, but thease worked reasonably well on most browsers. Which made the entry level for making designs using tables lower. Now, with CSS, there are more and more hacks showing up each day and for newcomers, and veterans I can imagine, it’s becoming harder and harder to keep up.

But I think many people using CSS feel compelled to use hacks since without thease hacks it’s harder to make CSS based designs excel over table based ones. But this leaves us with one important question - if most people use CSS hacks to make designs, how future proof are they and how well will they work when the most popular browsers completely compile to the standards?

Perhaps it’s a mute questions since most designs won’t last this long, but what about all the time put into making thease sites? I for one try to avoid using hacks and designs sites using only CSS which I know works well in browsers with at least a basic CSS compilance.

Dave S. said on May 12, 2004 9:40 PM

Yes! Agreed. Completely.

There are a lot of cases where one simple structural table (stripped of presentational junk, mind you) is going to get the job done way quicker, way easier, and way better than mucking around with floats. Form styling is one BIG area where tables shine.

My personal take on the matter: the more the complex a site, the more unknowns involved, and perhaps most importantly the more complex the development and mangement processes behind the site (including number of people involved in both), the more justification there is for a table.

A simple 10 page brochure-ware site should never need a table, you’re designing for rigid and known conditions. A 400-page CMS-driven site that could potentially see large images dropped in the content area, multiple hands involved in creating markup (including those that are markup-illiterate), and a variety of conditions beyond your direct control could become a strong case for a strucutral table.

Not that that’s permission to go wild. One table should almost always suffice, and for god’s sake don’t go back to nesting. But those that detract from structural tables under any and all circumstances are simply too plugged into the ideal to understand the practical reality of learning curves and browser support.

Jeremy Flint said on May 12, 2004 11:05 PM

I agree with Dave on this one.

Tables still have a place in CSS based layouts. Forms is a great example. On a recent project, i coded out a template for forms using all CSS, and it took a while to get everything right. Problem is, I was handing the template off to our programmer to duplicate into other forms, some of which had different content. So in the end, I spent even more time trying to show him how I did everything using CSS when just using a table would have saved us both a huge amount of time.

You also have to base your table vs. css decisions on your audience. If you can see from site stats that there is a significant percentage of users on older browsers (Netscape 4, IE 4) for whatever reason, then that would be a good time to use a hybrid layout, using tables for structure and CSS for all other aspects of visual control.

Jeff Croft said on May 12, 2004 11:14 PM

Jimmy said it perfectly: This one of the most insightful pieces I’ve read in a long time. Kudos, Andy.

The bottom line is the same as it’s always been. We need to use the best tool for the job. Period. Whether we’re arguing Mac vs. PC, Illustrator vs. Fireworks, Trebuchet vs. Verdana, #333 vs. #000, or tables vs CSS-layout, the answer is always the same: use what works best for the job.

It really is that simple. Seriously.

Craig said on May 12, 2004 11:51 PM

I’ve been evangelizing standards at my place of work for many months (since reading Zeldman’s New Testament some time in the fall) and the counter-argument I’ve heard most often is “why change what works?” So of course I run through all the benefits of CSS-based design (leaner code, faster loading, easier to maintain, flexible design, etc, you know em all) and after my sermon they say “those are all good, but why change what works?” As long as nested tables and font tags still get the job done, designers will continue to use them.

I have slowly won over some converts through demonstrations and examples (thanks for the garden, Dave), and we’re beginning a very slow transition to cleaner markup, but I’m still met with resistance because they just can’t see why it’s worth all the trouble. We need a pocket-sized edition of DWWS that we can pass out like the Gideons.

Tom Werner said on May 13, 2004 1:54 AM

Well, we all use CSS so we can switch from Trebuchet to Arial in one fell swoop. Just kidding!

Switching from a table based layout to a CSS layout for the NU Protest zine made it much easier to add each new month’s articles. Plus, the semantic coding makes it a lot simpler for people that don’t know HTML very well to enter information into the templates. They don’t have to deal with any table related cruft strewn about.

I think a lot of us feel that in order for CSS and Standards to be implemented in browsers properly, we need to go hard-core. We’re setting an example that we hope will be followed in years to come. And sometimes that means biting the bullet and using floats when a table would make it all so much easier. Is it cost effective to do so? Probably not. But it makes us feel good, dammit!

Jeff Croft said on May 13, 2004 1:59 AM

Wow, sorry about the multiple posts! I kept getting server errors and thought they weren’t working, but apparently they were! My apologies, Andy!

Shaun Inman said on May 13, 2004 4:16 AM

Frighteningly well put, Andy. Having 3-4 large CSS produced sites in the queue for launch at work (all 100-180 content managed pages) we are in a pretty good position to analyze the cost verse benefits—and it’s not looking so hot.

The learning curve and debugging are significant problems, increasing production time by what appears to be 50%. While there are small personally triumphs in hacking IE PC into submission those don’t translate into dollar signs and new opportunities when projects go way over budget.

I’m not advocating the bowing down to the holy dollar or a return to table-based design but this disconnect between the ideal and reality is hard to ignore—especially when, as you say, “your boss is breathing down your neck.”

Jason Santa Maria said on May 13, 2004 5:01 AM

Agreed Andy.

At the end of the day we are designers (at least speaking for my ilk). The web is just the medium we communicate our message with; the CSS and Markup, valid or sloppy, are just the tools we have in the medium. It stands to reason that the web, like all design and communication mediums, should use the method which suits the message best. It also stands to reason that as the proponents and message-carriers we seek out the most efficient means of conveyance to best utilize our time and energies. If it means using a table here or there, fine. But by now you should know how to use them intelligently. Mature tables. I am not in favor of Ironman Standards, nor am I in favor of Table Gobbledegook. I am in favor of delivering the message in the best form I can, and for sake of my own sanity, the most intelligent way I can muster. I’m with you on this one Andy, css and tables can get together from time to time and serve the greater good, assuming the message you have gives it the thumbs up.

Keith said on May 13, 2004 6:25 AM

As usual — very well written and well argued. You know me, I’m all about real world benefits and I can say that while there are many, many real world benefits to going with CSS instead of tables some of them might not be worth the effort to get to for many designers and developers.

And that’s ok. CSS is hard. For many reasons. My hope and belief is that it’ll get easier. For now there is a larger learning curve than many people advertise. I get CSS questions all the time and many times I’m just plain stumped. You can spend hours trying to sort out a small browser display problem. I’m sure we’ve all been there.

I do think, no I know, that down the road is where the real benefits will be reaped by the worker bees.

I just now starting to see some benefits on my sites that I was wondering if I’d ever see. Planning on writing about that soon.

Still, having said all of that, and having sung the praises of CSS many times, I still think there is a place for tables, like you said. Not only that but there are times when you are simply forced to go old school. Legacy or third party code, for example.

Tables. The ultimate CSS hack.

Georg said on May 13, 2004 6:39 AM

The best, and most complete, comment I’ve seen on the subject.

Tables are not the enemy here, and is / should be a tool in the toolbox when creating CSS-based designs.

The only good reason for not using tables at all, is that you don’t really need them in a given design. Tables are not deprecated, and no one should feel that they have to leave tables out in order to keep their coding-method clean.

Quoting you: “There isn?t anything inherently inaccessible about table based design. As long as tables make sense when linearized, their content is easily accessible.” I’ve found that to be very true, and that tables can actually improve on accessibility when used correctly in a CSS-based design, because they keep content in the right order. Why on earth should it be better to use “display: table” or float-trickery, when the real thing is at hand?

When asked what method I use for layout, my answer is (and will always be): every available method that works, in whatever order that makes sense for the end result. Tables are rarely needed unless some content should be tabulated(!), but tables are a valid option along with everything else.

Even presentational use of tables is valid, and can improve the end-users experience while keeping accessibility at the highest level. Let’s keep the tables, and make sure that everyone new to CSS learn how to use them.

Isofarro said on May 13, 2004 9:12 AM

Good article Andy, and some excellent comments too.

Forms: Tables are for tabular data. Forms are tabular in nature, since they consist of headers, columns and rows (albeit one row of data). Take a database table with one row, rotate it 90 degrees anti-clockwise and you have the structure of a form. Ergo - tables used to structure forms are correct - the layout side-effect is a bonus for using descriptive structure.

Learning curves: The point about CSS being a learning curve is a non-sequitur - everything you don’t know involves learning. Even at the beginning people had to learn how to hack and abuse tables into last-century websites. There was a learning curve there to.

Browser support: Browser support is also a non-sequitur. Techniques used yesterday to hack tables into a layout didn’t consistently work in last century browsers. No difference there.

The difficulty in remaining with table-heavy presentation is that there’s no reason for browsers to improve, no reason for websites to improve, no reason for web designers to improve. If you believe the web has reached its peak potential - then there’s good reason not to learn new techniques. However, if you believe the web could and should be offering a better experience, then forward looking and thinking is an inevitable requirement. Not fighting against advancements in design certainly would be beneficial.

I don’t think the web has reached its potential yet. A foundation of well structured content alongside accessibility are the building blocks of an improved web. What we see now on the web is the equivalent to the television coverage of the 1969 moon landings - awe inspiring but grainy snapshot of progress.

Patrick Griffiths said on May 13, 2004 10:57 AM

I agree with Isofarro that the learning curve point shouldn’t matter. And I don’t agree that CSS layout is more difficult than table layout.

The reason why experienced web designers see it as more difficult is because they’ve got tables ingrained on the brain. They’ve been breast fed on it. Moving from one comfortable method that ‘works’ to something new is never going to be easy, but what if we all started out on CSS layout?

CSS layout is actually easier in my opinion (“get this chunk, shove it over there” etc.). It’s one of the philosophies behind HTML Dog to teach web standards from the outset (rather than teaching the old hack way first and then teaching this ‘special’ way), which should make it as easy to learn as any other method.

I’ve had plenty of positive comments from beginners who have managed CSS layout and clearly haven’t even thought that you might be able to do something like that with tables.

Dan Webb said on May 13, 2004 11:03 AM

I think it’s good to take a step back from the situation to avoid turning into preachers but really for me the article failed to address the single most important reason for using CSS.

The seperation of content and presentation. No matter how lean your layout table code is it still is very prescriptive of what layout the page will be in. With CSS (one day…:)), we hope to be able to make our HTML content device independent. As long as people keep hacking pages together with presentational code in them we are never going to see this.

What would you say to that argument? (In devil’s advocate mode) Because at the moment I’m not quite convinced on this crazy tables idea….

Nina Meiers said on May 13, 2004 11:21 AM

What a fantastic overview and comment on the virtues /facts of the great css. I think in future years, we’ll be looking at this and wondering what all the fuss is about.

Until then, I suspect the best designed all round sites that are managable from various aspects may still be combination of CSS & Tables.

I learn CSS in the olden days and waited until browser technology caught up, and now use dotnetnuke technology other considerations to factor into designing a site and find that although CSS makes some great eye candy, the old skills of table design still come in handy!

This is an excellent overview and very well written!! This link was posted on the forum and I’ve now bookmarked your site.

Thankyou - Nina Meiers

Minz Meyer said on May 13, 2004 12:05 PM

Once again a very well written article. If I didn’t know you and your work, you would have gotten me ;)
But speaking of linearized accessible tables, I’d dare to make a claim that you have to know both HTML, CSS and Accessibility techniques pretty well to make your table based page as accessible as say throwing some absolute positioned divs onto the canvas (I am referring to the Frontpage and Dreramweaver cowboys here…).

More than that, I’d state that only a person like you, Andy, that has been studying and using “high-speed” CSS for a long time now may outweigh the pros and cons for either using a table-based hybrid (and that’s what you are talking about, aren’t you?) or a pure CSS layout.

It’s like “…only Nixon could go to visit China.”

Steffen Schramm said on May 13, 2004 12:23 PM

I currently create a small private site for someone else, and tried out designing everything with CSS. The most important point for me was separation of content and design. But I’m more a programmer, not a web designer, and after some investigation of CSS I decided to switch back to table-based layout.

The table based layout was done in minutes, and it does what it should. I’m still using CSS - for font styles, margin, padding etc - but I didn’t manage to handle the floats. And it’s not necessary. I agree that it would be a really bad idea to fill in site content into tables (or even nested ones), having all these layout tags around it. Instead I’m using XML files for the site content and XSLT stylesheets to create the resulting table based html files.

“The seperation of content and presentation. No matter how lean your layout table code is it still is very prescriptive of what layout the page will be in. With CSS (one day…:)), we hope to be able to make our HTML content device independent. […]”

What would you say to that argument? (

In my opinion, CSS is only one way out of many. Server side scripting, template engines, XML and XSLT stylesheets etc can combine layout and site content for different devices even before a user can see the page. CSS is a good thing, but there is much more potential in web techniqes, and I don’t think there will be a final answer, how to design web pages.

Dan Webb said on May 13, 2004 12:33 PM

Yes, that is true but having pure, content only HTML has got to be one of the simplest and most elegant solutions.

XSLT, template engines and the like do provide similar functions but only for specific services and are liable to be implemented in different ways. may have a CMS that can provide content to PDAs but others won’t.

If all pages on the web were written using CSS presentation and semantic code (which is the objective for web standards types) then all the web would be device independent…

Matt Pennell said on May 13, 2004 2:38 PM

For all that I’m tempted to take this as a blessing to give up on trying to get my contact form to display how I want it using only CSS, I have to agree with Dan Webb - device independence has to take its place in the top 5 or so goals of any designer, and without alternate site versions, a table-based design is more likely than not going to run into problems when displayed on a mobile phone or your television set.

Remember that it’s not just the browser manufacturers who we’re waiting for to get it right; you just know that once they do there’ll be a whole new set of problems and inconsistencies on the next generation of browsing devices (whatever they may be).

sosa said on May 13, 2004 3:31 PM

Mind blowing article!
table-based layouts makes sense because it makes easy to understand the way design organization is supposed to be. Screen is a two-dimensional medium so, as any graphic designer has to know, designing for bidimensional mediums is about placing graphic elements (also called modules) in a master grid.
No designer that respect himself and the art/profession he has chosen will design positioning elements arbitrarily or “floating” them across a page.
Despite the fact that tables are for tabular data, it has become the perfect medium for making a grid in web design so we can place our elements correctly in the page.
One thing that is obvius is that neither CSS or (X)HTML was made by designers but programmers.
When we try to mimic table-based in a CSS layout (once converted to the Zeldman Evangelion) it’s graphic design’s old grid what we want to acomplish.
CSS is broken because it lacks of design most basic concept: Grids.

(Sorry, bad English)

Jeff Croft said on May 13, 2004 4:04 PM

Matt, and others:

While I agree that device independence is a top priority for me, it may not be for everyone, even if we think it should be.

The point is, someone, somewhere, may be in a situation where he/she knows tables a lot better than CSS, his/her boss is breathing down his/her neck, the client is only interested in it working in IE6, the project is due in one week, and it pay ten million dollars.

In this situation, wouldn’t he/she better smarter to choose a table-based layout?

Yes, it’s fantastical, but the point is simple: you’ve got to weight the pros and cons based on each individual situation. While it may not be often, there are some situations in which tables may win — at least in theory. :)

Mike D. said on May 13, 2004 5:26 PM

Let’s also not forget two things:

1. Floats were never meant to act as positioners of columns, as many people use them. They are no better suited for this task than tables, really. Floats were meant to shove peripheral elements off of the side and have textual content flow around them. Hence the word “float”. The 3-pixel Win IE float bug is inescapable evidence of this. Try to make a two-column 800 pixel layout with a 600 pixel image on the left and a 200 pixel image floated in the right column. Doesn’t work. Floated column automatically clears itself in Win IE. Yes, I know it’s a bug, but it occurs mainly when people try to position entire columns with floats.

2. This isn’t really CSS vs. Tables as I’m sure everyone understands. It’s Pure CSS-P vs. Tables. Just a clarification.

3. Most of this debate would be moot if the CSS spec (or browser makers’ implementation of it) did not take absolutely positioned elements completely out of the document flow. You should be able to put two absolutely positioned columns inside a master div and then create divs after that master div which appear unconditionally below those two columns. THAT, in my opinion, is the biggest CSS-P oversight/shortcoming of them all, and it is the cause of this whole mess. If that could be done, everyone would use absolute positioning and designers would be more free to do what they do best. Given all the crafty JS-based enhancements that have been coming out lately like Shaun Inman’s IFR and the IE 7 thing, I wonder if a simple “behavior” could be developed which allowed specified divs to clear absolutes automatically.

Any JS gurus have any ideas? You could be a king. I suspect the hardest part about such a function would be gracefully degradation in the case of no javascript. Stuff might be all over the place.

Richard Earney said on May 13, 2004 6:02 PM

This mixture of tables and CSS is really what XHTML 1.0 Transitional is for after all!

In the early days of CSS evangelism, I tried to do everything without tables, but got frustrated very quickly, until Mr Zeldman put me right by saying to me that tables are not wrong - just that they are made for tabular data (and forms I agree).

But I must admit that when it comes to using a table I have to think harder about how to use them than a few years ago cos I am so much more used to CSS design now!

Jeremy said on May 13, 2004 6:09 PM

Web standards and CSS based design are defiantly the way forward.
Why does this conjure up images of carefully disheveled designers shaking their fists and chanting slogans like Down with Anti-Semanticism?

Great insightful post, and equally insightful comments from many. Remember though, that there’s a counterpart to the oft used adage “If it ain’t broke, why fix it” and that is “Just because it works, doesn’t mean it’s not broken.” We don’t all have to be activists or evangelists for the adoption of web standards, but the more we do to support those efforts, the more likely there is to be positive change.

Jeremy said on May 13, 2004 6:13 PM

For some reason my citations got dropped off the posting, though they previewed properly.

For the record, the first line of my post is quoted from the first sentence of the conclusion…

David House said on May 13, 2004 7:42 PM

Giving up a technology just because one or two browser vendors apparently refuse support of it is just unforgiving. That way, we’ll never see the advent of CSS dominion (hmm, that sounded significantly more sinister than I wanted). Stick it through a couple more years, I’m guarenteeing that CSS will see an increase in support. Who knows, maybe Microsoft will have a Trident overhaul when CSS3 hits. (Although they really should have done that by now, CSS2 is 6 years old!)

CSS design does hold many more advantages over tabular design. I believe that CSS in its current maturity is flexible and supported enough to cater for any site, regardless of complexity of design, complexity of content and markup literacy of authors (teach them, for Pete’s sake!).

Within the next few years we’ll only see an increase in CSS based design, I’m relieved to say. With people like Zeldman and Cederholm writing books, hopefully within a few years most web developers won’t be getting funky with FrontPage but will instead be creating semantic, structural designs without the aid of obsolete, inbenefitial and frankly incompetent technology such as layout tables!

I, for one, refuse to go hypocrytical, and will always try to create a flexible CSS design before I bend over backward to incorperate the straggling mess we find in layout tables.

Rimantas said on May 13, 2004 8:29 PM

For me the use of CSS is obvious and very practical.
Separating code from presentation, separating content from presentation - I can see how that increases efficiency daily in my work.

Talking about tables - well, use them if you want to. Only there are so few properly built hybrid sites. If one uses table he feels some urge to use dozen of them where is sufficient. And a whole bunch of decorative images stuffed into code. Not quit “tables for layout only”.

The main point is, that proper coding in css and that separation of code from presentation requires quite a shift in mindset, and I am not sure how many have an ability to make that shift.

Tom Dell'Aringa said on May 13, 2004 10:02 PM

Well said, well said! I’ve had this saying that we shouldn’t be “standards lemmings” and follow this concept over a cliff. The form example is just perfect. I always use tables to build my forms. One table - not nested - and it works perfectly. Everything lines up and of course I use CSS to style it.

The “ease” of CSS has definitely been overstated. I have been coding since 1996 yet I still have trouble with some of the more intricate and advanced techniques. Some of the stuff on CSS Zen Garden blows me away. It’s great - but I wouldn’t take the time to do it in a production environment.

Anyway, trying not to blather on here - well said!


David said on May 13, 2004 10:07 PM

I wonder… for a true beginner, what would be easier?

1) Learning table based layout and all of its cross-browser hacks, nuances, and tweaks.

2) Learning CSS based layout and all of its cross-browser hacks, nuances, and tweaks.

With almost 10 years of experience doing it the “wrong” way I don’t know if I can objectively answer that.

If I could start over again with a clean slate, this time with CSS and box-model hacks as my toolset, would it really be more difficult to learn how to build cross-browser compatible sites than my first time around? Again, I can’t answer that objectively, too much baggage.

While your article is a refreshing read and you make your point well, are you being completely objective?

Do you really need the full 12K of CSS on the home page? You can strip out what you don’t need and load it on pages that need it. On a site with more than a few pages I don’t know if you’re really benefiting by “evenly distributing” the presentation markup accross the site?

Feeling like a beginner all over again can be frustrating. It is comforting to rely on tools and tricks that already work.

I’ve worked on many large projects done the “wrong” way before there was a “right” way. When I started to “get” CSS it made such perfect sense. Despite the steep learning curve and sometimes arcane hacks, CSS based layout still feels as right as rain.

Gerrit van Aaken said on May 13, 2004 10:23 PM

Just finished a little coding-job: HTML eMail! Urgh. Tried to do this with css - no way! eMail Clients only render table-layouts. After some hours of frustrating CSS-coding, it took only a few minutes to build some tables in Dreamweaver, place my spacer-GIFs, just like in old times. It scared me, because it was so easy.

Today Ive fixed some IE 5 CSS-issues on my website. Im feeling sophisticated now. Like a pioneer. Like a real expert.

But tables are still easier. Im doing them since 1997. I came across CSS in February …

Martin Lucas-Smith said on May 13, 2004 10:34 PM

Two other things which seem not to have been mentioned are:

1) That CSS makes future redesigns much easier.

2) That CSS can result in a significant saving in bandwidth costs to organisations with very busy sites.

I think these are valid business decisions when considering the CSS-P vs. Tables argument.

Ireney Berezniak said on May 13, 2004 11:41 PM

Excellent article! It sums up my own thoughts perfectly …


pb said on May 13, 2004 11:59 PM

How would you make this table in CSS?


pb said on May 14, 2004 12:00 AM

Better question: how do you put HTML in comments?

Scott said on May 14, 2004 12:12 AM

I hear the “it’ll make later redesigns easier” a lot, but I’m not sure I buy it the way it is stated in such a sweeping fashion. Just using css-p in no way guarantees that. Yes, if you have fully semantic code, and no presentation in your html, then yes it would be very simple. But I would suspect there are very few sites built that really could be redesigned easily just by changing the css file. Most would require tweaking the individual html files as well, to some degree at least. The same could be achieved with a cleanly built table+css based site.

Granted it’s very easy to make text changes, background color changes, etc. but that’s true for table+css based sites as well.

John said on May 14, 2004 5:51 AM


simply replace the word “table” with “font tag” and the article is almost identical. And of similar value. How much I’ll leave as an exercise to the reader.

Mike D. said on May 14, 2004 6:19 AM

Replace the word “table” with “font tag”? I don’t know about that. I can think of at least a few good reasons to use tables and at least a few advantages to them. Not so with font tags.

Can’t think of a single advantage to a font tag really, unless you’re running some sort of twisted Netscape 2 Fan Club website.

Jim said on May 14, 2004 8:44 AM

Hey Jeff, for $10 million I’d do multiple nested tables, animated gifs, cyan colored backgrounds, hell I’d even throw in some scrolling text! :P

But seriously, yes, tables are still valid in some situations, especially for ‘no-stress’ forms.

Richard@Home said on May 14, 2004 11:50 AM

Great article Andy, tables DO have a place in a modern webpages. I can’t say I agree with your (and others) point abour tables being good for forms. I was going to state my reasons here, but it turned into a bit of a ramble so I blogged it:

Olav Junker Kjr said on May 14, 2004 12:47 PM

Why is layout tables the only presentational markup still widely used by competent webdesigners?

Because HTML-tables suport specific presentational features which is not achievable with semantic markup + CSS. All other presentational markup which was once needed (FONT, CENTER etc.) can be fully replaced by CSS.

Consider this layout:


Both columens are aligned to the left, and the width of the columns are determined by the width of the content. If you change the content in the left column, the layout will automatically adjust. You cannot do that with CSS. You have to define a fixed width on all the elements in the first column, thereby breaking the seperation between content and presentation: If you change the text you have to modify the stylesheet also.

Olav Junker Kjr said on May 14, 2004 1:02 PM

Damn, the table-tags was stripped from the example in my previous comment! But I hope you get the point anyway.

richs said on May 14, 2004 2:16 PM

Olav, I don’t understand your comment. You can do that in CSS. You can break it by using fixed-width structural elements, as you point out, but it’s doable.

Carolus Holman said on May 14, 2004 2:21 PM

I develop (webPages) called portlets, for the Plumtree Portal product. Try using CSS in that framework, all of my page elements jump out of the portlet and obscure other regions of the page. I am forced to use table based design. Another reason I stick with tables for the time being is the crummy support for layout in VS2003. It works okay, but MMDMX2004 works much better. When I do stand alone sites, I use DMX2004 to design my pages, then copy the code into VS2003, it doesn’t always work, but I think Microsoft needs to improve the VS2003 toolset to support CSS, layers, etc.

Sean Scott said on May 14, 2004 2:42 PM

Having made the plunge into the css world a few months ago, the struggles with the various hacks are still fresh in my mind.

Being from a programming background i likened css and tables to object oriented programming vs procedural programming. Both have their places depending on the project being tackled.

Often when a new technology enters the market, evangelist tend to preach a exclusionary policy. Use A not B. A is good, B is evil. Few (Zeldman was the first) utilize B to get to A.

Eris said on May 14, 2004 2:47 PM

Tables for tabular data in its time and place? Justified completely.

Tables because “css is hard to learn”? Sounds like an excuse. (but, maybe I’m biased because I learned css before tables).

All my other points have been made already, and in some cases, better than what I would have said. Separation of content/style, industry/browser improvement, etc..

Shaun Inman said on May 14, 2004 3:36 PM

“Using <ins>font tags</ins> for layout opened up the possibility of visually designing a page?” Not exactly John.

Inspired by the third point in Mike D’s first comment I whipped up a script that allows an element to “clear” the absolutely positioned elements contained inside.

dusoft said on May 14, 2004 4:34 PM

I can only agree with you, Andy. Ive been coding comply with valid XHTML 1.0 Strict code and later found that tables are necessary for the layout. It was quite difficult to fight all float bugs when making it 3-column CSS layout, also it has not been good for SEO. I have found it difficult to find solutions to some bug that occured and I guess that had to do with floats widely used. Nevertheless, I changed for basic TABLE layout with 3 columns defining <table id=”xxx”> and <tr id=”yyy”> when needed. Thats just plain markup with CSS on top. We can use it, thats not so bad. Otherwise <div>s are used.

Julian Gall said on May 14, 2004 5:00 PM

This may be heresy but is there perhaps a problem with CSS itself? Most would agree that separation of content and presentation is “a good thing” but CSS is not the only conceivable way to do it. As a programmer, I get very frustrated with CSS because it bears so little relation to modern object-oriented techniques. Why?

Or looked at another way, does CSS really separate content from presentation? You can specify a DIV in the BODY which is positioned with a style in the stylesheet, but isn’t a DIV a presentational element? Are we really clear about what is presentational and what is not? How about bulleted lists? Sometimes they are purely presentational; sometimes fundamental to content structure.

I am a mere beginner with CSS but always find it very frustrating. It doesn’t seem to work quite like a program (for programmers) or like a layout (for designers).

Rob Cameron said on May 14, 2004 5:30 PM

Dang Andy, writing this article was like giving all these guys permission to come out of the closet about their love of tables! To their friends they wanted nothing but perfect seperation of presentation and structure. But deep inside, they had a secret … ;)

When I redesigned our company site it was immediately after reading Zeldman’s book. I knew I wouldn’t be able to survive without tables, not because I had a hugely complicated design in mind that CSS couldn’t handle but because I had been warned by people at work that the majority of our customers are old crusty divers who barely know how to use computers. Needless to say, this meant they probably aren’t upgrading their browsers quite as regularly as most of us. Mosaic 1.0 came to mind.

I didn’t want the site to be completely trashed for them. Well, not “trashed,” but graceful degredation isn’t always so graceful when it’s an e-commerce site. I used tables for the big, main chunks of content so at least there would be some semblance of a site when CSS is turned off or broken. And I think I got by without nesting any tables, which I was very proud of at the time. Everything was still useable (and looked pretty good, too) down to Netscape 4. The homepage almost validates as XHTML 1.0 Transitional (if it wasn’t for Flash and a couple proprietary attributes thanks to the translation box at the bottom).

Now that we’ve got some logging going on (we didn’t have any kind of analyzation going on when I got the job) it looks like I might be able to turn up heat a little and peel off a couple more tables. Almost everyone is running IE 6 or higher, with a couple 5.5’s and 5.01’s. It might be time for the main navigation to become an unordered list rather than table.

So in a (very) roundabout way I’m saying that I still think tables have a place in practical web design, even for layout. Sure our blogs can be XHTML 2.0 valid since we can do whatever we want. But as someone above said, when the boss is breathing down your neck, using a table or two suddenly doesn’t seem like such a bad idea.

David House said on May 14, 2004 6:24 PM

Olav: You definately can! Imagine: (attributes stripped for clarity)

<form> <fieldset>
<label> Name: </label> <input />
<fieldset> <form>

(many elements there included for structure alone, I only need the input and fieldset to create a table-like layout effect). CSS:

form fieldset { position: relative }
form input { position: absolute; left: 20em }

Magnus Haugsand said on May 14, 2004 7:11 PM

David: Or even easier:

  <input />

label input {
float: right;

It is a good idea to specify width to label too.

I guess it is allowed to have input inside the label-element, since The Man in Blue is using it in an example (

travis said on May 14, 2004 8:39 PM

Magnus, the W3C spec shows inputs inside of tags:

Ricardo said on May 14, 2004 8:47 PM

I totally agree with the author, there is a need for simple understanding of standards vs performance. I have been going to various web design forums and a lot of it is edicts, dogmas and prejudices towards other than what they use. It is time for this stuff to end.

anony5 said on May 14, 2004 11:16 PM

well 1 major thing i have not come across in any of the responces, admittedly i dont have time to read them all, is how CSS based designs, if properly implemented, works on cell phones and PDAs. oh and this popped in my head too, how well does a table based design fail in older browsers? a proper CSS build (should) fail gracefully.

Bill Humphries said on May 14, 2004 11:56 PM

Using tables for layout only shifts the cost from the designer to the engineering team who have to implement templating/XSLT, etc. to render pages.

It’s been my experience that using tables for layout adds anywhere from 10 to 25% of engineering resources spent on a project.

If the design can’t be done in CSS, maybe it’s time to rethink the design.

Marek Moehling said on May 15, 2004 1:54 AM

Test case by: Olav Junker Kjr
comments by: David House and Magnus Haugsand

The proposed solutions require the text to be of a specified length, else they break; this is inconvenient with dynamically generated HTML or user provided text.

I set up a demo at:
and I’m not quite happy with the result…


Marek Moehling said on May 15, 2004 1:57 AM

sorry, now let’s have that clickable:

Scott Johnson said on May 15, 2004 3:28 AM

One thing that I’d like to point out is that it is very possible to build a site with a table-based layout that is standards-compliant and validates. Tables are valid parts of the HTML spec. Sure, using them for layout and structure of an entire page might not be the semantic thing to do, but it works and isn’t necessarily bad.

I like a good 100% CSS site just as much as Dave Shea, but I really hate it when people forget that tables are just as valid as divs.

Luke Redpath said on May 15, 2004 5:13 AM

My coments are summed up pretty well here:

Luke Redpath said on May 15, 2004 5:25 AM

I also notice that a lot of bugs people complain about are releated to floats. As somebody has already pointed out, floats aren’t really ideal for creating page columns, and their real use is to float content (such as boxouts/images etc.) over to one side.

I have no such problems because I just use absolute positioning for my 3-col layouts. Admittedly, the technique I use relies on knowing which column will be the longest (generally the main content column) and positioning that using normal positioning, and positioning the side columns absolutely within their container, but it works, and I rarely have problems.

Perhaps people are just going about things the wrong way?

Admittedly, the need to clear absolutely positioned elements (some kind of y-index?) is something desperately needed in CSS.

Luke Redpath said on May 15, 2004 5:27 AM

And can people please stop going on about how forms are tabular data (they AREN’T) just so they can justify to themselves that its fine to use tables for form layout. Forms are data INPUT devices, but not actual data, therefore it is not possible for them to be tabular data either.

John Penlington said on May 15, 2004 2:06 PM

Building web sites is a serious retirement hobby for me. I’m self-taught and proud of the skills I’ve developed over several years using books and the Web.

ASP, PHP, ASP.NET, JavaScript, XML - none of that was rocket science for me. Then I tackled web standards CSS for layout. Four months of confusion and anxiety! And I do know where to get help from discussion lists on the Web.

Encouraged by the success of a number of tables-layout sites I’d built, I was on the verge of starting a small business, not as a “cowboy” but as a professional developer using web standards. I had to abandon the idea, however, for two reasons:

(a) the utter frustration I suffered trying to make various layouts display uniformly across even a few browsers

(b) the fact that in Australia the W3C’s Web Accessibility Guidelines 1.0 is, in effect, the LAW because it’s the yardstick used for testing complaints under the Disability Discrimination Act which covers ALL websites - government, private enterprise, not-for-profit and hobbyist.

XHTML is a breeze for me. Web standards layout is a nightmare. I know I’m not alone. What I detest is the guilt that some, though not all, web standards zealots try to load on to newcomers.

I applaud those who hang in there and keep on trying, but I know web standards will never become universally practised until the browser bugs and inconsistencies are ironed out.

The result: I’ve gone back to tables for layout. I use CSS for styling where ever I can - but only when it displays consistently across a range of browsers.

CSS for layout is an awful disappointment to me - not because it’s a bad standard, but because it’s so poorly applied by browsers so long after CSS2 became a recommendation. And CSS3 is coming along to add even more variety and confusion to the picture.

The agonising irony is that all the sites I’ve built display consistently in almost every browser because I’ve used tables for layout. The site-owners are happy. Ninety per cent of the visitors are using Microsoft Internet Explorer.

My case rests, but I’ll keep on trying to learn CSS for layout.

Chris said on May 15, 2004 2:27 PM

You’ve hit the nail on the head for me with the footer issue. I’ve yet to see a CSS solution that works as well, across browsers, as a single table.

Josh Hughes said on May 15, 2004 7:05 PM

Great article. It’s nice to see a pragmatic view of the subject, rather than a knee-jerk “Tables bad, CSS good” response.

CSS is fragile, and it doesn’t maintain relationships between elements on its own. This means there are many layouts that are simply impossible to do with CSS right now. The footer issue is indicative of that.

And “A more semantically proper website” simply isn’t going to fly when I have to bill a client for the 5 hours I spent figuring out what stupid thing was causing IE 5 to fudge my layout.

James said on May 15, 2004 8:06 PM

Without making this a major issue, many designers who are calling for ‘standards’ are on Mac. Even though table-less design has been (so far) even more ‘non standard’ across browsers than table-based design, it remains a dream for the Mac designer/coder not to have to go through the awful process of frequently checking their work on a PC.

Because of MSFTs monopoly, Web browsers haven’t changed very much in five years. Like the point about designers adopting standards/CSS to elevate themselves career-wise, the passion of standards advocates often feels like organized resistance. There should be resistance, just as there should be ways for professionals to separate themselves from hacks, but these reasons should be listed in opinion pieces promoting standards.

Bruce said on May 16, 2004 3:28 AM

Great Article!

I am just now starting to learn css and have developed some simple templates with pure css. At first I hated CSS but the more I use it the more I like it. I still don’t understand it enough to make it do what tables can do though. So I will still use tables sparingly. I am a visual designer rather than a coder and found that the beauty of tables is in the WYSIWYG editors. CSS seems to have none(yet). From what I have seen so far CSS has a lot more cross browser compatability issues than tables. Personally I am trying to stick to only CSS1 design until older browsers die out; which will be a long time haha.

Thanks for that article! You have pretty much summed up what I have been feeling but havent been able to put into words :)

Stay safe all

Olav Junker Kjr said on May 17, 2004 10:41 AM

Thanks for the test case, Marek.

The point is that positioning and floats isn’t a replacement for tables. It is two different approaches to layout, which sometimes, but not always, may be used to solve the same problems.

Tables have been used for many different layout-effects, like creating borders and margins, controlling the width of elements and so on, all of which can now be achieved with CSS.

The remaining feature is the grid-layout with elements aligned both vertically and horizontally.

CSS is perfect for basically single-column layouts. Secondary blocks like sidebars can be placed outside the main column with float. This solves the layout requirements of many websites, but requires the designer to rethink the layout as column-based rather that grid-based. It’s not just a case of moving some attributes into a slightly different CSS syntax.

However, sometimes you really need blocks aligned in two dimensions. You can emulate it with positioning and fixed sizes, but this will not, like tables, adjust gracefully if content is changed.

So my point is, it’s not a case of CSS being harder to learn and tables beeing more familiar (the same could be said of font-tags then, but i dont think many uses them any more), its a case of CSS not supporting 2D grid-layouts.

Maybe display: table and display: table-cell may be used in the future, but they are not avaliable today.

Luke Scammell said on May 17, 2004 1:50 PM

I have to say that I completely disagree that CSS based designs are front heavy. Every time I’ve recoded a broken site for a friend it’s always been significantly lighte on the load time, even on the home page.

Also, I think that in general, most of the points made in the article are good… for people just starting to learn CSS. I’m no Guru, but even so I’ve managed to make 2 and 3 column layouts with tables which are reasonably semantic.

Regarding the “CSS is harder/slower” point. Now that I’ve been using CSS for a year or so I don’t find it any slower than coding with nested tables. Often with old table layouts I’d start from scratch, with most CSS layouts I can figure out what’s going on and fix from there without having to redo EVERYTHING all over again.

Marek Moehling said on May 18, 2004 4:49 AM

Olav, I agree (I avoid tables too), but as you said: “its a case of CSS not supporting 2D grid-layouts” and so far I haven’t heard of future CSS enhancements that would help to adapt containers to unpredictable user input and the like. (Am I wrong? Info welcome)

Maybe it’s naive approach, but I reckon a table attribute like type would help - it should have two values: “layout” and “data”, thus giving http-clients clues for semantic evaluation. Even then, to ensure semantic soundness, presentational tables should be used only if CSS provides no alternative.

Of course, a CSS defined new container type could be introduced too, but I guess the markup would require about as many elements as tables require presently, so there might be no point in doing so

I test most of my sites with Lynx and more often than not it handles the (few) tables quite well, so spiders and the visually impaired will get what they need. Basically, a web designer has to know about these issues and act responsibly.

Olav Junker Kjr said on May 18, 2004 8:56 AM

CSS2 does allow purely CSS defined table-layouts through several new display types like display:table-cell, display:table-row

The sematic html form in Davids example could (slightly modified) be styled something like this:

label { display: table-row; }
span, input { display: table-cell; }


This should work exactly as if table,tr,td-elements were used. Best of both worlds.

However, this is not yet widely supported, and MSIE 6 does not support it, so its not really useful yet.

Marek Moehling said on May 19, 2004 1:30 PM

Thanks Olav,
That’s an eye opener and leaves room for hope…

marc said on May 19, 2004 3:37 PM

Thanks for a stimulating article (and subsequent comments)
To go right back to the first paragraph, I’d like to take issue with the statement ‘…few, if any, go back…’ I went back, or actually, I went forward, because I never knew how to use HTML tables before. My road to Damascus moment was when I began to realise that CSS guru Eric Meyer was so stingy with code that he would zip a 6kb HTML file to make it 4! For sure the argument loses mch of its validity in an age of broadband connections.
Tables for positioning, CSS for style is my rule. All CSS needs is for a tables-based methodology to be incoporated into CSS3 and we can all stop arguing.

Andy Budd said on May 19, 2004 5:39 PM

Thanks everybody for your thoughts and comments. Much appreciated.

As you can tell, my article has provoked a lot of discussion, both on and off this site. Some people have suggested that this article gives developers cart blanche to ignore web standards and go back to 1998 style coding practices. Obviously that’s not the intention of the article and I really don’t agree that it does.

When I talk about CSS based design I’m talking about using CSS for layout and more specifically about CSS2, positioning and floats. I’m not for a second suggesting that we should resurrect the font tag. When I talk about the occasional use of tables, I’m talking about very simple un-nested tables with the minimal of mark-up. Not the heavily nested, spacer gif ridden tables of yore.

Others seem to have taken this article as criticism of the web standards community as a whole. Again, this isn’t the intention of the post or the views of the author. I think there is a lot of “tables are evil” type talk going around and the zealous attitudes of a few (and it is only a few) can really put people off adopting web standards and CSS based layout. However the majority of web standards developers are very reasonable and level headed individuals.

Hopefully that’s cleared up some of the ambiguities, so I’ll now return you to your normal programming. Watch out for future posts including “Why frames are great” and “Let’s resurrect the blink tag”.


David said on June 8, 2005 8:33 AM

I like your article, and it makes sense, but I still need some type of tutorial or something, because it didn’t explain how to do it; only that it should be done.


Ziggi said on June 21, 2005 4:21 PM

In fact, one of the biggest disadvantage of CSS positioning is lack of reliable information on the absolute position of elements. You can see that easily if you try to read X-Y coordinates of a box positioned using floats and to use these coordinates to position the second (very same) box with absolute DIV. Normally - two boxes never align perfectly and moreover - the shift is browser dependent and it goes worse more we go down from the top of the viewport. This is a big designing problem as simply speaking designers would like to use DIVs as Photoshop layers but this mechanism is so poor that all the alignement breaks compltely in minutes… There is no reliable way to mix float-positioned DIVs with absolute-positioned DIVs in an eastetic way…

nick said on June 22, 2005 3:14 PM

Very enlightening read.

I’m still using tables for layout. It seems more intuitive to me. Or maybe I’m already so used to it. Heck, I can even conjure up the table code (however complicated) in my head.

I use CSS mainly for styling, so the sites I’ve designed are a hybrid of tables and CSS.

I remember those font tags and how they were literally all over the webpage. I experienced that. When you needed to make a change, you had to change every occurence of those tags in the affected pages. It really sucked.

CSS solved that sort of problems. Of course, I’m aware that CSS is far more powerful than that. It allows for the separation of presentation from content and enables faster downloads (because the style sheet is supposedly only loaded once).

Recently, I tried to play with a 3-coloum layout and I didn’t find it that intuitive. There’s quite a bit you’ve to know before you can become comfortable with it when dealing with a more-involed layout.

I don’t know. Maybe it will become more natural to me once I get used to it.

And I was wondering if things might have been better were TABLE named GRID or some such in traditional html. Then you won’t have the problem of it being seen as mis-used for layout (instead of tabular display of data).

Also, I tend to think that CSS just moves the complexity to the style sheets - hides the complexity. After a while, even the original designer might have problems understanding them. Worse, if he or she leaves the job, the newcomer will have a hard time working with the style sheets when he has to add stuff or make changes.

Sure, tables can get complicated too especially when they are nested (in reference to hand-coding), but using borders (during development) can lessen the complexity.

Just some ranting…

Ashish said on June 25, 2005 7:23 PM

I am new to web development, and working on moving our application over the web. There is a big learning curve, cross browser support issues, etc. One of the issues I have been struggling with is whether to control form layout using tables or CSS. Your article has been very helpful. Thanks!

Benjamin Cutler said on June 28, 2005 6:35 AM

It doesn’t matter if using a table for layout is easier when it breaks the meaning of a table. I don’t think anybody is going to argue whether tabular layout is currently easier to design across multiple browser platforms than css. The current state of affairs says, CSS support is still lacking. However, this doesn’t mean that CSS is a bad idea, or that tabular design is a good idea.

The biggest argument against using tables for presentation is that it breaks the meaning of a table. The idea that your content should have meaning is more than academic. There are a lot of really neat things we could do, if all web pages were well designed, where each and every tag carried along some sort of meaning with it. (Even div tags can carry meaning with the id or class attributes.)

Consider this: in the future websites will be read and processed more and more by programs. Documents exist on the web, and should be accessible from various media (think about it: text browsers, pda’s, cell phones, screen readers for the blind). A web browser may want to parse the (x)html, using the header tags to create a table of contents and the table and image tags to create a table of figures. This can all be done on the fly, but only if web page designers are not breaking the meaning of the table tag! This is why it is important to use the (x)html for the meaning of your content, and only for the meaning of your content.

If you use a table for layout purposes, you are breaking the meaning of the table, but any machine reading your document will not understand this. They will not see the presentation or css, just the (x)html. What about screen readers? How do they handle tabular layouts? Are you making your site inaccessible to the blind by using a tabular layout? If so, is it then ethical to use a tabular layout just because it is easier on you?

I am not a professional web page designer, but I do understand why the W3C and co. believe that using tables for presentation is a bad idea. Just because something is easier to do for your purposes, doesn’t mean you should do it. For example, in application development, it is often times easier to start coding up a solution. However, in the end you learn that it is much better to sit back and design your system before you go out and code it (i.e. should we add these extra levels of abstraction to make it easier to change our code in the future, even though currently it would be harder to do?). You need to think about more that what you are currently doing. You need to think about the future, because code (and websites) stick around a lot longer than you may first expect.

The whole point is that a computer program reading your web page that uses a table for layout purposes will not understand that this is not a table. This will break current and future technologies that expect tabular data to be just that: tabular data.

Remember, CSS is a developing technology. There are some problems with it, but those are being fixed. We are now going through the growing pains of the web. It is growing up now, becoming more mature. These are the hardest times for the web, because of all of the changes occurring. I don’t expect the web to remain in it’s current state for long. Things are changing.

Brian said on July 5, 2005 2:27 AM

quote: 6-12 month learning curve from knowing basic CSS to actually being able to develop CSS based sites competently. End quote

Ill have to disagree. Im 15.. I learned CSS in 1-2 weeks. I already am getting really good with almost everything to do with CSS. Im using it to make my moms website and its been pretty easy. has some nice CSS tutorials that taught me it so quickly. And tables, there almost impossible to visualize in a text editor, I would probably need a WYSIWYG editor. And no I can’t afford dream weaver.

Heck is I did maybe I would be using tables.. anyway nice thingy or w/e you would call this.

Know of any good free WYSIWYG editors?

- Brian

aranade said on August 2, 2005 2:53 AM

Benjamin, good post but I have to disagree with you when you say that using tables for presentation breaks the meaning of a table. Forget original intent or the precise definition of the word table. What tables are in HTML is a simple way to organize elements into rows and columns. You correctly mention an increasing number of web pages will be read and processed by programs. If we discard the original intent of the tag name “table”, assume that people writing the programs that read web pages will have at some point in their lives designed a web page, and look at the way the “table” tag has been used it doesn’t really make sense to say that a program would have an easier time sifting through a page organized with nested divs than with table cells.

In the end, positioning/organization with both tables and divs can be very useful. Each has its strengths and weaknesses; the trick is figuring out how to leverage these correctly. In my experience—limited though it may be—I find that tables are useful for a sort of high level, general organization of a web page and CSS positioning is the way to go when you need finer or more precise control of where an element needs to be.

If anyone agrees with me on this one I would love to read some insights into how to make the best decision possible on tables vs. CSS postioning. Or if you disagree with my completely, please blast me to shreds and help me understand why I should never use a table again.

On a different note…Brian, how much control do you need? MS Word uses the definition of “table” that we ended up with while web designers were abusing it for all their positioning needs so it is still pretty straighforward to lay out a document using the table feature of word and then saving your document as a web page. Although, I would say that once you see the table tag used for layout a couple times it gets pretty easy to visualize what things will look like even while coding in plain text.


Daniel Diaz said on August 16, 2005 8:06 AM

It doesn’t matter what you use (whether CSS-P or tables), as long as your end-users can read the content without confusion. That means, the regular joe who views the website and who won’t even care to view the source code of the pages. Because the truth is, MAJORITY of end-users won’t care how something was done.

There’s no point in using something one thinks is the best way, when the actual design of a website is disorienting and repugnant to the end-users.

William McIlhagga said on August 16, 2005 7:29 PM

1) It’s a bit silly to insist that because it’s called a “table” they are therefore for tabular data only. If the tag was called LAYOUT instead of TABLE, would we be saying that tables are for layout, not tabular data?

2) CSS-P does a really bad job of layout, rather than positioning. Layout is about the relationship between elements, but CSS-P doesn’t address this, except weakly through float and clear. If you look at layout toolkits like TCL/Tk, or FLTK or WxWindows, you’ll soon appreciate how impoverished and weak CSS-P really is.

3) Having programmed for many more years than is healthy, I have often been involved with projects where the wrong tools were used. Using CSS for layout feels like using COBOL for artificial intelligence. You can, but you’d be mad to try. Of course, if you did succeed, you’d be a COBOL god, but that isn’t worth much these days. Being a CSS god isn’t much better.

4) Many of the comments that people make about putting all the layout in CSS so it can be changed easily must be from people that don’t use CMS or wikis for their websites. These automatically separate layout (in a few template files) from content (in the rest). CMSs can even be run without any server-side help, e.g. tinycms.

5) Another aspect of CSS that annoys me is the fragility of it. I’ve many times taken code generated by CSScreator and attempted to change it to suit myself, but found that small changes to the CSS wrecks the layout in strange and unexpected ways. One that I always remember was adding a clear:right to something and finding this allowed another float to creep up on the right. Exactly the opposite of what you might expect. Now I’m sure there was a good CSS reason for this, but that only emphasises how remote CSS is from any intuitive idea of what should happen.

6) Accessibility for a two column design means that the main column should appear in code before the left column. In tables this is easy with:

<td height=0></td>
<td rowspan=2>right column</td>
<td>left column</td>

(sometimes you have to kill the padding in the zero-height cell too)

7) Device-independence from CSS? Only for the simplest of sites. Most websites would need a complete overhaul to appear on a phone screen, or even a palm screen, compared to even a small computer screen.

King Arthur said on September 4, 2005 2:31 AM

Very informative and balanced article, it was definately a good read.

When ever I hear that one should only use CSS for their layouts because tables are for tabular data and nothing else, it disgusts me. Especially when they say that with the only reason being… you guessed it: “Tables are only for tabular data!”.
Tables do not neccesarily make the page(s) less accesible, done right they are accessible just as a .txt file. It’s when tables get nested to the height of Mt. Everest and get clogged with spacer GIFs enough to fill the entire Atlantic Ocean that things get messy and the coder deserves to get yelled at.

I myself am an avid coder of table layouts that are intermixed with CSS (Table/CSS Hybrids) and are quite lean and conservative on the table markup to do my work, and I’ve had no troubles doing it that way. All browsers that I target (Firefox, IE, and Opera) render them correctly without fail, and they are understandable with all CSS styling and tables (if applicable) taken out. On the other hand if I tried my hand at a complete CSS layout, it’d take me ages and thousands of CSS hacks (if any) to get the exact same things as I’d get with tables. Not to mention tables solve the problems of menu and content heights being the same quite easily, I’ve always disliked the content dropping down beyond the height of the menu.

If CSS layouts work for people, well good for them. They’ve found a tool they are comfortable using and do not hamper them in any shape or form and I will respect that, we all have our preferences of tools to use.
Like wise I will continue to use Table/CSS Hybrid layouts until I get a very good reason to switch to pure CSS.

Sven Alkered said on September 7, 2005 2:34 AM

We are currently developing a new Java architecture for component based webdesign, a pretty complex task even with my 12 years as a professional developer. In an early stage we decided to use the pure CSS apporace, not using any tables. But we soon run in to serious problems that forced us to undertake a rigorous investigation to find out wherer we could use pure CSS or not. We found a large number of problems with CSS and that layout with CSS is not compatible with component based webdesign. Despite our intention to develope an architecture based on the latest CSS-technology, we ended up developing an architecture based on old reliable technology that won’t give us more headache, tables. In addition, we can be confident that it works well with all browsers, and by using tables we were able to implement a few features that we could never have done with pure CSS, for instance laying out components in a GridBag-manner.

One of my conclusions from the investigation of pure CSS vs. tables is that CSS is good for setting element properties, but it should not be used for layout management, especially not in a complex component based design. And since component based design is the only way to manage future complex applications, I don’t see that CSS will survive in its current form.

Extensive use of CSS is a bad idea from a number of more reasons. Read more about it here:

Andy Budd said on September 7, 2005 8:07 AM

It is true that the majority of end users won’t look at the source code and care how something is done. However they will care if the site loads faster and is more accessible. Site owners will care if the site cots less in bandwidth charges and gets a higher ranking in Google, and dev teams will care if the site is easier to integrate into the back end and easier to maintain.

If tables were initially designed for layout and separated layout from presentation, then great. However they weren’t designed for presentational use and they do clutter up your mark-up, especially when heavily nested.

There is absolutely nothing wrong with using CSS for layout if you know what you are doing. Sure there are a few things that are difficult or impossible to achieve using CSS to control layout, but the same was true of table based design. The problem most developers face when they start using CSS is that they just don’t understand it fully, and make mistakes. This isn’t a problem with the language, it’s a problem with the developers.

There should should be no reason why CSS based design is causing problems with your Java architecture. In fact it should be perfect for this application as it encourages the separation of presentation from content, or to use a more OOP term, view from data.

The point is, your Java application should have architecture should have nothing to do with CSS. You should be spitting out standards compliant and non-presentational HTML, which will definitely make your life easier. As long as you are producing a good HTML framework, your developers should be able to style the pages as they see fit.

Interestingly all the negative comments here about CSS are the same type of negative comments I heard from people two years ago who didn’t “get” it. These same people have now spent time learning and using CSS and no longer have the objections they did at the start.

Joseph Boudreau said on October 9, 2005 2:43 PM

from 1999 to 2002, I was heavily into designing Websites only to become very fustrated with browser incompatibility. So what did I do? I sat back for 3 years until this summer (2005) to see who the big winner will be. XML? PHP? CSS? ASP? PERL? I like PHP and XML myself…not to mention the browser wars… you get the drift. So now I am back in the game and still find that tables have as much use to me now as they did 5 years ago. I am not about to give up on tables anytime soon, sorry if i’m old school… lol

Andreas Baitis said on October 19, 2005 5:19 AM

I’m new to web design, about a year into it I guess, I see lots of these discussions on the web, none of them seem to make any sense. Somehow when so called CSS experts talk about tables, they talk about them as if they are not part of CSS design (as you are doing here). My interpretation of the CSS spec is that they are well and truly part of CSS design.

IMO in some cases there are jobs you can’t do any other way, and if you try your just wasting your time and your clients money. If you want to use columns and rows in your layout, then why would you even consider trying to do it using only divs? It just doesn’t make any sense.

I think using the term CSS design as if it does not include the use of tables is incorrect, tables can be styled using CSS as can divs, I think you’re all missing the point, CSS allows site wide styling rules for all HTML elements, including tables.

If I’ve missed the point, I’m sure you’ll let me know.

Andy Budd said on October 19, 2005 7:58 AM

I think you may have missed the point, but only slightly. Sure CSS allows you to style tables. Nothing wrong with that. However its the way developers use tables that are the cause of the problem. Ideally your HTML should be purely about information, separating all of your presentational code into your CSS files. That way your HTML is less cluttered and more flexible. Tables are fine if used as intended, for data. However if you use tables for layout you lose a lot of the potential benefits CSS has to offer. For instance if you use tables for layout, you can’t simply change the layout of your page by editing a few lines of code. You literally have to do a find and replace across the whole site, which is time consuming and potentially quite risky.

Andreas Baitis said on October 19, 2005 10:36 AM

Thanks for clarifying for me what you guys are discussing, I guess I look at it differently as I usually use PHP/Mysql to spit out my HTML, so I too only have to change one file to make a site wide change to any one class of page.

I don’t agree that tables are only meant for Data though, the following is from HTML 4.0

“11.1 Introduction to tables

The HTML table model allows authors to arrange data — text, preformatted text, images, links, forms, form fields, other tables, etc. — into rows and columns of cells.”

Data can be anything, including HTML elements.

I guess we should all do what’s right for us, personally, I think tables are much better suited to laying out the base of a page, links, buttons etc. And with server side dataBases, changing a layout site wide is pretty easy.

nick said on November 1, 2005 8:30 AM

Most of the discussion boards I’ve come across use tables for layout - phpBB, vbulletin, YaBB, Ikonboard, Invision Board etc.

I suspect it will be hard if not impossible to code a discussion board (not a blog) with div’s.

What are your thoughts?

Andy Budd said on November 1, 2005 9:37 AM

The reason that most of the discussions boards you come across use tables is partly because they were built several years ago when CSS based design was less prevalent, and partly because programmers have traditionally, and rather surprisingly in my mind, not been interested in creating valid and semantically marked up XHTML.

There is a very nice looking discussion board called “Vanilla”“ that uses pure CSS. Although this does raise the question as to whether a discussion board made up of a list of peoples names, topic, date posted etc is actually tabular data

nick said on November 2, 2005 2:09 AM

Nice link, thanks Andy.

I don’t know. Maybe I’m used to seeing a discussion board organised in a tabular format. It makes for easier locating of information e.g. author, time of post, etc.

I took a look at the Vanilla forum. While I must say just it’s a nice departure from the ubiquitous forum layout, I saw that it does have a “problem” of displaying standard information such as author, time of post, number of comments, etc, in the sense that they aren’t properly aligned.

It’s a bit like the way a classroom is set, with rows and columns of students. You expect to see a particular student at a particular spot. That’s for a tabular layout.

daj said on November 14, 2005 10:40 AM

Yeah in some cases CSS & DIV design rocks but TABLE design ROCKS as well…so can’t compete or compare with table design & css based div…table design is classics so it ROCKs and it save much time…so go for table design… :)

Jr. said on January 10, 2006 10:18 PM

I have my doubts about css because I have been doing table programming for many years. I can picture a whole nested table in my mind before I start even coding.
I recently got into css programming and I’m picking it up fast but trying to position and pad on a page took me 3 hours to get today. I just think the learning curve will take a bit. I just wanted to say this is a great article.

John Bower said on April 19, 2006 10:47 AM

If the design can’t be done in CSS, maybe it’s time to rethink the design. - Bill Humphries

Oh you did not just say that! ANY layout design should work in CSS. If CSS is purely for laying out content, but HTML can lay out something in a way CSS currently can’t, that just shows how broken CSS still is as a standard. It is a great idea, but it needs to be fixed before it will truely take over.