Wednesday, November 12th, 2008

CSS and Tables; The war continues

Category: CSS, Fun

Time for a bit of fun. The eternal battle of tables vs. CSS layouts continues. We geeks have had classics such as vi vs. emacs, and Star Wars vs. Star Trek.

First up we have

And then we have

You have to take a look at the source for that one :)

  2. "">
  3. <html>
  4. <head>
  5.   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  6.    <title>Should I use tables for layout?</title>
  7.    <style type="text/css">
  8.       html,body{
  9.        background:#999;color:#ccc;
  10.       }
  11.       h1{
  12.         font-family:"Georgia",Helvetica,Arial,Sans-Serif;
  13.         font-size:10em;
  14.         padding:.1em 0;
  15.         text-align:center;
  16.         color:#333;
  17.         margin:.5em auto;
  18.       }
  19.   </style>
  20. </head>
  21. <body>
  22.   <h1>No.</h1>
  23.   <!-- Honestly, no. -->
  25.   <!--
  26.    <table border="0" width="100%">
  27.      <tr>
  28.        <td align="center">No.</td>
  29.      </tr>
  31.  -->
  32.   <!-- Fact: Chuck Norris hates layout tables! -->
  33. </body>
  34. </html>

Who will win? Maybe both, with display: table in the future.

Posted by Dion Almaer at 12:01 am

4.3 rating from 26 votes


Comments feed TrackBack URI

I have yet to see a layout in IE6+, FF2+ that required tables….
Does someone actually have an example of one that is easier to create and read with tables?

Comment by TNO — November 12, 2008

I dont use tables but there have been many times I keep thinking why on earth I chose to do something with CSS in the end. Especially true when something looks ok in firefox and when i preview in IE the div’s won’t fit and fall under.

Comment by kyriakos — November 12, 2008

I *really* don’t understand the evangelists.

* Not all of us are CSS gurus
* Not all of us know all the CSS hackery by heart, nor want to
* The boss wants you ‘to get the shit done’
* Some weird CSS hackery (like, for instance, a mulit-column auto-scaling layout with background images) take *AGES* to build and thén tweak

I am proud to say that i *dare* use tables for layout every now and then. CSS is the preferred way, but if i run into nasty stuff that makes CSS in multiple browsers a pain (floating footers anyone????) i switch to tables.

Then a question to all the stubborn evangelists that spend hours and hours fiddling to fix some weird css bug:
*HOW* on earth are you going to explain to your boss why a fairly simple feature cost you 12 hours instead of 2?

Comment by SchizoDuckie — November 12, 2008

in my opinion complex forms are almost always a challange when you try to make them without table layout. i’ve searched a lot for good looking css-only forms, but was not satisfied with the solutions i found:

e.g.: i did not find any css-form that can vertical-align labels and form-fields and keep the possibility to have long labels with line-breaks. almost all css-only forms i’ve seen for example bottom-align labels and fields, which looks really ugly — imo.

css-form design is always very time-consuming and error-prone.

but that’s for me the only case, where i still like to use tables for layouting every now and than.

Comment by aurora — November 12, 2008

Did anybody notice that has 1 td inside 1 tr inside 1 table. I mean I understand they are trying to promote tables but was it necessary to add 3 extra tags. Not exactly somebody I would want to listen to. Of course that’s probably part of the joke.

Comment by JonBad — November 12, 2008

@Shizoducky: and that is why we have CSS frameworks. If you don’t grok CSS and you don’t want to understand it, use something that works that other people built, maintain and test for you. It is a no brainer. When my boss asks me to repair the sprinkler system because experts cost money I say no. If you don’t want to work on CSS, don’t.

Comment by Chris Heilmann — November 12, 2008

Who cares, If you want to use tables, do it. If you don’t than don’t? Does it matter? NO as they both will render out the same if you use both techniques good..

Comment by V1 — November 12, 2008

Schizo: You don’t have to be a “CSS Guru”, but “the boss wants you ‘to get shit done'” is no excuse to not continue to improve your skills. OK, let’s say you’ve got to do a layout that you know doesn’t require tables, but that you don’t currently have the skill to do without it. Well, you’re never going to learn until you sit down and make yourself learn, just like you sat down and made yourself learn tables. So, fine, use the tables if your boss is so inflexible that he doesn’t care one whit for whether his employees spend extra time learning to get better at their jobs.

But it’s pretty important that you take the time, at some point, to learn how to do your job better. If you’re a web professional (and I presume you are, if you’re commenting here), improving your skillset is an ongoing, constant process. Our industry moves too fast to take a lackadaisical approach to keeping up to date. Techniques that were unknown two years ago are commonplace today and will be bad practices two years from now. A career in this field is something that must be nurtured, and that means aggressively continuing to stay on top of your abilities.

Plus, and this is important, you have a duty as a professional to provide an accessible website, and tables hinder accessibility. This isn’t just a matter of karma, this should be considered a business requirement. lost a huge lawsuit over having an inaccessible lawsuit. If you’re getting paid to make a website, you really are obliged to ensure that you’re not exposing your employers or clients to legal risk.

For myself, tables aren’t a matter of philosophy or dogma, they’re simply inconvenient. Once you start nesting them, once you have to make changes to a layout, once you want to start reusing HTML in different places, tables start to slow development time down. There’s real, tangible benefits to semantic, CSS based layouts that far outweigh the very short term gains tables give you.

Refusing to get better at your job isn’t something to take a stubborn pride in. It’s career suicide.

Comment by skippyK — November 12, 2008

@skippyK and Chris Heilman

I’m mostly a backend / web GUI developer. I know the ins and outs of CSS, can use a reset style, floats, understand absolute vs relative positioning and all that. i *know* CSS, but I *choose* to not ‘improve’ (if you can call learning all the different hacks by heart) my CSS skill level to cope with the crappy browsers.

I fully agree with this nice quote from

We want to make it work with CSS. But sometimes it’s just not worth the effort. The hacks and conditional comments ruin our clean markup. And we spend hours trying to make a simple layout work.

The reason why i agree with this has nothing todo with me doing my job better (understand that I will use nice semantic html 99% of the time), nor my boss not allowing me to evolve myself, It’s a personal choice. CSS, as it is now with all it’s crappy hacks *SUCKS* if you just want to output and style your html and make it work.

I cannot wait until CSS3 is adopted by all major browsers and we can just forget about the headache-causing hackjobs.

Comment by SchizoDuckie — November 12, 2008

@SchizoDuckie – Nobody really likes the hackery, but table based layouts are not the way to go – forget the layout and how it renders, it’s the semantic meaning of the markup and how this is read and understood (or not) by assistive technologies and search engines.

You’ll be pleased to know that IE8 joins the other browsers and supports CSS tables which are going to solve a lot of the hackery so there is a light at the end of the tunnel…

Comment by danh2000 — November 12, 2008


CSS is hacky, I agree. I’d say for any reasonably complex page, it’s 95% legitimate code, 5% hacks. That sucks, yes, but in all honesty, it’s about the same ratio as nearly any other programming language (except Python which is 96%/4% (j/k)). But let’s be honest here, isn’t using tables for anything other than presenting tabular data also a hack? Spacer gifs are hacks, invisible tables are hacks, so ditching CSS on the basis of “too many hacks” when the alternative is also a hack isn’t a very strong argument.

And to be honest, there’s only three hacks you really need to know for nearly all css: “zoom: 1;”, “*propertyname” and “_propertyname”. The rest you can accomplish through legitimate CSS and some vendor-specific CSS.

Comment by skippyK — November 12, 2008

Please understand that i never *totally* ditch css. Even if i use a table for some layout 100% of the rest of the layout is styled with css to keep the semantics as clean as possible. I’m just beyond the “when all you have is a hammer, everything looks like a nail” point.

Comment by SchizoDuckie — November 12, 2008

I can’t believe anyone still argues about this – if you still use tables for layout you’re not very good with CSS or design or both.

Lets argue about something much less solvable: what’s the semantics of having using a top level heading tag for your main content? Seems wrong to me ;-)

Comment by edeverett — November 12, 2008

“We want to make it work with CSS. But sometimes it’s just not worth the effort.”

That is complete and utter nonsense. It’s always worth the effort, if only for accessibility and seo reasons. Beyond that, it is good to keep in mind that most browsers today follow the standards ánd webdesign is something completely different to print design. You have to let go, a tiny bit. Loosen up. Not everything will be exact to the pixel in every browser, but if your design is flexible and good enough, it won’t matter.

A conditional stylesheet for IE, that’s one thing. But CSS hacks? That’s bad practice (if you’re not working on a site that needs to run on ie5.5) and completely unnecessary.

Now JavaScript, that’s a whole ‘nother ballpark.

Comment by DiSiLLUSiON — November 12, 2008

I would find their argument a lot more compelling if they hadn’t also given up and used flash for the in-page countdown timer, rather than a javascript solution.

Comment by henrah — November 12, 2008

Not to mention there are a number of CSS guru’s on the interwebs, floating around forums just waiting for an opportunity to increase their e-penor by solving your CSS problem

Comment by TNO — November 12, 2008

tables are for slobs.

Comment by RobRobRob — November 12, 2008

I think part of the reason some people get a hard on for tables is that it masks their flawed logic in some cases. You want a fluid 2 column layout, but you define everything in pixels instead of a percentage/em, and you also want it all on the screen at the same time regardless of the size of the end user’s browser size… And then you piss yourself when it wraps to the next line and blame Microsoft, God and the Republican party for your broken design. Then you run off and do it in tables and say: “Look, its moar better than stupic CSS”. When all that really happened is that the table ignored some of the crap you gave it and followed its own logic.

Comment by TNO — November 12, 2008

As for floats……
floats kill kittens

Comment by TNO — November 12, 2008

The very fact that people argue about it shows that CSS has not completely gotten rid of the need for tables.
The very fact that people are fighting over how to fix CSS so they can make it easier for people to implement the designs in there head tells you why people use tables.
I prefer CSS. But when the CSS gets so complicated that I don’t see a way to go forward, I use tables.
I expect that in five years, CSS will have the bits and pieces to accommodate how I want to do things, and I won’t have to use tables any more.
The problem is we’re moving from a more natural system of layout to a less natural one.
Yes, I used to work for a magazine, back in the time when the layout people were still pulling columns off the Linotype and cutting them with xacto knives and pasting them on the boards.
It’s silly to tell people to back away from a system that makes physical sense to one that is more abstract. It will work for some people but not for everyone.
Give me a CSS table that maps to the design in my head and I’ll use it 100% of the time. Promise.
You no-table people. You sound like the people telling me why Esperanto is better than English.

Comment by Nosredna — November 12, 2008

Personally, I keep a foot in both camps (though I do favor tables). There are times when tables just work and then there are other times that DIVs and floats are required. To completely reject one method or the other is foolish given the current state of browser HTML standards support.

Comment by RSarvas — November 12, 2008

Tables for layout and excessive floats are like the Kentucky Windages of the web. You basically say “forget what I just told you to do, just do what I mean.”
This isn’t just about initial design and “getting shit done”, it’s also maintenance. After you make your 4-5 deep nested tables to get your so called grid just right, how long is it going to take you or anyone else to go back behind you to update something or fix something? What if you need to change your site layout across an entire domain?
“The very fact that people argue about it shows that CSS has not completely gotten rid of the need for tables.”
I’ll partially agree with you there, but the way I would word it is:
“The very fact that people argue about it shows that CSS has not gotten rid of the DESIRE for tables”.
I think the majority of us can agree on both sides of the fence that CSS is not intuitive and is not necessarily moving in a direction to make things easier (Like the CSS3 ASCII layout in the other thread in this page IMO). But currently the standardized options are to use clunky, butt ugly, hard to maintain tables which are an intuitive common denominator for new comers, OR a not quite there, hard to understand abstract layout language that is progressively trying to encompass more than just “styling” (CSS).
Douglas Crockford brought up at one time how broken CSS is and how we need a replacement for it and I have to agree with him. But until we get that intuitive styling language, CSS is still the better choice regardless of the slightly steeper learning curve.
Of course you could use a CSS framework. Too bad we don’t see more of those advertised on ajaxian.

Comment by TNO — November 12, 2008

I mostly agree with you. I don’t nest tables (except for putting something that SHOULD be a table inside a scaffolding table).
You can certainly make an unmaintainable mess with tables. But that’s just an argument not to make a mess. You can make perhaps even a bigger mess in CSS.
Frameworks are great. I’ve used them. But they often don’t cover (well) all my cases.
I look forward to CSS getting more concrete and usable. Until then, I’m going to avoid zealotry and embrace pragmatism and do the best job with what is available.
Newcomers are going to screw up whatever they use. I think we can agree on that. Anyone who’s had to maintain old stuff will use whatever tools he has in more reasonable ways.

Comment by Nosredna — November 12, 2008

I think the excuses “oh it’s not semantic” and “oh it’s not accessible” are bandied about way too easily, without thinking it through. I seriously doubt that it’s not possible to combine table-based layout with screen reader accessibility. Also, “it’s not semantic” is a meaningless argument, because tons of nested divs aren’t semantic either, even if you give them sensible class names.

Comment by Joeri — November 12, 2008

We’re in a transitional period where CSS can’t do everything we need/want it to do, either because of technical limitations, lack of knowledgable developers, or both.

Therefore, it seems to me foolish to not have a transitional mindset as well.

Start from the premise that you’re going to do it with CSS, because that’s where we all pretty much agree we need/want to go. But, if and when you get to the point where it’s not happening, either because the technologies doesn’t seem to be up to it, or *you* don’t seem to be up to it, drop back to tables as necessary.

At the end of the day, most of us have a ton of work to get done. The better developers among us demand the time to do it right, and are more times than not granted it. Still, there comes a point where you simply can’t spend any more time on something and you have to use the fallback position. Your client doesn’t want to hear “but gee, we’re not applying the correct semantic meaning to the content on the page” or “CSS is the future and we have to be onboard with it fully RIGHT NOW!”. They just want the project done.

So, START with CSS, use CSS whenever possible, but don’t be so anal about it that you’ll never touch a table under any circumstances. And conversely, don’t just punt CSS because you don’t understand it or because it might be more effort. CSS is the right answer… until it’s not! :)

Speaking for myself, I’ve done some rather complex work with CSS with success. I’ve also ran into some issues at times that I couldn’t find a solution to after a day or so of research and so I went with some tables instead. I’m not about to flog myself over it, and the project stakeholders believe I made the right decision too.

Zealots on either side of an argument are usually not worth listening to. Have you ever watched that show Wife Swap? Ever notice how they always find the two most polar opposite families, both with extreme views? You sit there the whole time saying “neither of these bozos are right!”, and at the same time “both of these bozos are right!”. Seems to me the same can be said for the CSS vs. tables debate, at least during this period of transition.

Comment by fzammetti — November 12, 2008

To paraphrase John Resig on the design of js libraries, we start off by avoiding browser sniffing, we try and use feature testing and best practices, but in the end we come right back to browser sniffing because the technology isn’t quite where we need it.
When you’re dealing with very large sites with picky design-savvy clients, CSS evangelism gets counter-productive: doing things like client-editable multi-line top navs with vertically centered text with CSS isn’t exactly cleaner than just plopping in a small table. And don’t even get me started on complex multi-lingual forms :)

Comment by LeoHorie — November 12, 2008

There’s a heck of a lot of browser sniffing in jQuery. I keep wondering if that’s because the alternative would be too big or too slow. It’s hard to believe that it’s not feasible. Seems more like a trade-off for performance than a matter of something that can’t be done.
Over the long run, browsers will be closer to standards (I hope) and there will be less sniffing in the libraries.

Comment by Nosredna — November 12, 2008

people switched to css FROM table with reasons. It was hard to create some layout with tables. it’s hard to maintain too because that image is nested in table>tr>td>table>tr>td>table>tr>td>table>tr>td….and you need to specify colspan and rowspan if you want the top and bottom of this image align with the top of that and the bottom of another. if you add another row, oops, you need change the numbers, manually.

for people who aren’t really into web design but need to get the webpage up, there is nothing wrong with using this. but if anyone thinks this should be the direction all web designers should rethink and readopt, you can’t be serious.

Comment by coolnalu — November 12, 2008

>> There’s a heck of a lot of browser sniffing in jQuery. I keep wondering if that’s because the alternative would be too big or too slow.
In the talk John gave about library design, he said that a lot of that is because of specific quirks in how browsers draw things. It seems there are things you can’t reliably get programatically from javascript (John can probably list these issues better than I can).
As far as performance vs feasibility goes, I think they are very similar: in js you want things running as fast as possible, and that can’t be accomplished nearly as effectively without sniffing. In CSS, sometimes you want things to have certain elasticity properties without a ton of code and a ton of effort, and sometimes tables are simply more efficient at accomplishing that.

Comment by LeoHorie — November 12, 2008

Help me remove the tables here:

This should be a list of accomplices. However, if a li was taller than the next, the row after would display only one li.

If you know how to fix this via css without specifying the height let me know.

I’ve run out of ideas and used a table instead. :(

Comment by troynt — November 12, 2008

You’re my new hero. Ballsy to put yourself out like that. Wouldn’t it be cool if there were a place we could post our tables and ask for help to get to a pure css layout? There are already places we can post code and have people help simplify and optimize it.

Comment by Nosredna — November 12, 2008

As someone who is required to make email newsletters, I could not always use a tableless design. It’s almost impossible to get images to wrap properly in all (still used) versions of Outlook. I still use a mix where applicable.

Comment by azmoviez — November 12, 2008

@troynt: easiest page in the book:
1) Each block is a block element (li or div or whatever) and has float: left or float: right; and a specified width.
2) All blocks are wrapped in a container element (div) with a specified width.
3) Each first, alternating float has clear: both; (each second doesn’t).

That’s why people advocating tables sound so crazy to most webdesigners: Creating most layouts in div’s is easy, fast and clean if the design is good & flexible enough. Hacks are almost never needed (and haven’t been for some time now), and all you need are a few div’s and p’s and such. Most layouts can be built with only a few simple elements (don’t forget you can style the html and body elements as well). And all that in a fraction of the time it costs to build a table-based layout.

Because frankly, if typing table, thead, tbody, tr and td everytime you need a simple block is faster then simply creating only one element and positioning it, then you’re doing something very, very wrong indeed.

Comment by DiSiLLUSiON — November 12, 2008

The problem is mapping. From brains to CSS. Better tools is the only solution I see.

Comment by Nosredna — November 12, 2008

I can see where you’re coming from; to be a webdesigner you need to think both intuitively / creatively — creating the design, and structured / logically — creating the html/css (both simply put — though not exactly correct).
There’s no way around it, for now, though better tools would help.
But that still doesn’t justify the use of tables, except in those cases where the defense is not that it’s better or faster, but that “when I slice it up in photoshop it creates them”. But then again, “webdesigners” who can’t create html/css only design visually; they might be wonderful artists but I wouldn’t classify them as webdesigners.
However, do we really want to have that freedom? I’d think not; websites are about supplying/recieving information in an interactive way. The more creative it gets, the less usable it gets. There are infinitely more creative & original designs out there that are a complete and utter mess if you take usability and readability into account, compared to creative & original designs that are actually good, informative and a joy to use.

Comment by DiSiLLUSiON — November 12, 2008

(I forgot:)
A document is a document is a document.
What I mean is this: Websites can be classified in a few categories: Document, Application and Game/Promotional. The category dictates the kind of stuff you need. CSS is limited in some ways, yes. But then again, for the stuff CSS doesn’t have, there are usable alternatives; for applications there are things like XUL and Javascript layout managers, for game/promotional there are technologies like Flash & Silverlight and for Websites HTML & CSS is enough.
The only downsides of using CSS as it is now (how I see it):
1) In CSS it’s a hassle to center something vertically. But beyond a very, very few cases (an actual online business-card-like landing page or a portfolio with images of the same size) you would never want to! Websites are interactive documents (in the largest possible way), not business cards.
2) In CSS it’s a hassle to have UI-like flexible layouts. But beyond online applications (where it is actually preferred), you would never want to (and for applications there are formats like XUL). Why not? Because scrolling is as natural as turning a page. You wouldn’t want a book that’s printed on one huge paper with a transparent rectangle on top that you’d have to move by hand to read it.
3) In CSS/HTML/Javascript it’s a hassle to animate something. Up to a point, it can improve usability. Fortunately, there are Javascript libraries for that and SVG/Canvas for the other stuff. Beyond that, Flash is the way to go. You can forget accessibility, you can forget good search indexing but it might just be the thing to promote the client’s new product/service/whatever.
CSS isn’t perfect, but it’s a long cry away from deficient.

Comment by DiSiLLUSiON — November 12, 2008

Look, we can argue all day/week/month/year/century/etc. long. There will be those that advocate tables and those that advocate CSS.

The only issue I have with the giveup site is that they don’t even know enough good html to not use the deprecated font tag… I mean dang man!

Comment by HendryB — November 12, 2008

The reality is that we’re just not there yet with CSS. We’re close.
Want to see gratuitous? Go to Google Finance and use Web Developer Toolbar’s Outline->Outline Tables->Table Cells to show all the crazy ways Google is using tables for page layout.
iGoogle? Yep. For real table things, but also for layout, like that new sidebar to the left.
Twitter? Yep. For rough layout.
Google News? Yep. For layout.
Amazon? Lots of tables for layout.
Sure, you can say all these pros are lazy are dumb if you want, or we can try to improve the situation as we all learn to use CSS better. It’s going to be gradual.

Comment by Nosredna — November 12, 2008

CSS really isn’t that hard to learn. And once you do learn it – I believe it becomes much easier to maintain and alter large sites and apps than with a nested table layout.

Comment by WillPeavy — November 12, 2008

One more thing I wrote a while back about tables that I think ties nicely with this discussion: using tables for non-tabular data.

Comment by LeoHorie — November 12, 2008

@DiSiLLUSiON: Not so fast on that solution.
“if a li was taller than the next, the row after would display only one li.”

So your solution would require one to specify a height. I could use javascript to vjustify the elements, however I want it to work without javascript as well.

Comment by Tr0y — November 12, 2008

@DiSiLLUSiON: wait, maybe your suggesting something that looks like…

Which looks a lot like…

That solution is no better than a table.

It should be a list



Comment by Tr0y — November 12, 2008

grr.. ate my markup.

Which looks like a table.

Should be a list

If the LIs heights are not consistent this will break, you can fix this with javascript, but I want it to work without javascript as well.

Comment by Tr0y — November 12, 2008

@troynt You should us a list then apply a style of inline-block to each li. Nice looking site though.

Comment by edeverett — November 13, 2008

@troynt Here’s the two minute version of that layout. Ok, so there’s a small hack for IE, but that’s a small price to pay for the benefits of not using tables for layout (for me the benefits are most in having more maintainble flexible HTML).

Comment by edeverett — November 13, 2008

instead of using li use a span with inline block and it will work back to IE6 without a hack

Comment by TNO — November 13, 2008

@TNO – you can’t be having troynt’s H3s inside a span, but yes that would be simpler for my example.

Comment by edeverett — November 13, 2008

If you’re referring to block elements not being allowed within inline elements, its trivial to replace it using first-line:


Comment by TNO — November 13, 2008

use Flex. It looks the same in every browser, provides as complicated a layout as you want, and gives you selectable text! What more could you ask for?

Comment by endOfLine — November 14, 2008

Something that doesn’t cost a bajillion dollars to develop for,
doesn’t require a leaky abstraction in the page,
is easy to index by a search engine,
can be quickly updated without firing up an IDE,
Is standardized and future compatible
Is readable
Is open source

Comment by TNO — November 14, 2008

Leave a comment

You must be logged in to post a comment.