By Benno Richters

2008-09-17 13:19:09 8 Comments

It seems to be the general opinion that tables should not be used for layout in HTML.


I have never (or rarely to be honest) seen good arguments for this. The usual answers are:

  • It's good to separate content from layout
    But this is a fallacious argument; Cliche Thinking. I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?

    Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and CSS.

    By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.

  • Readability of the code
    I think it's the other way around. Most people understand HTML, few understand CSS.

  • It's better for SEO not to use tables
    Why? Can anybody show some evidence that it is? Or a statement from Google that tables are discouraged from an SEO perspective?

  • Tables are slower.
    An extra tbody element has to be inserted. This is peanuts for modern web browsers. Show me some benchmarks where the use of a table significantly slows down a page.

  • A layout overhaul is easier without tables, see css Zen Garden.
    Most web sites that need an upgrade need new content (HTML) as well. Scenarios where a new version of a web site only needs a new CSS file are not very likely. Zen Garden is a nice web site, but a bit theoretical. Not to mention its misuse of CSS.

I am really interested in good arguments to use divs + CSS instead of tables.


@Nicholas Flynt 2008-09-24 07:18:29

When I design my layout using CSS, I generally give every major section its own root (body level) div, and use relative/absolute positioning to get it into its proper place. This is a bit more flexible than tables, as I'm not limited to an arrangement that I can represent using rows and columns.

Furthermore, if I decide that I want to rearrange the layout (say I want the navigation bar to be on the right now) I can simply go and alter the position for the elements in one place (the CSS file) and the HTML doesn't have to change. If I were doing that with tables, I would have to go in and find the information and do a lot of attribute modding and copying and pasting to get the same effect.

In fact, using CSS, I can even have my users select how they want their layout to work. So long as the general size of the content areas doesn't change, I'm perfectly OK with using a bit of PHP scripting to output my CSS based on user preferences, and allowing them to rearrange the site to their own liking. Once again, possible with tables, but much much harder to maintain.

Finally, CSS allows one MAJOR benefit that tables will never provide: the ability to reformat content based on the display device. CSS allows me to use a completely different style set (including position, formatting, etc) for a printer than the one I use for the monitor. This can be extended to other media as well, an excellent example is Opera Show, which allows a cleverly designed (and very standard) CSS enhanced page to be viewed as a slide show.

So in the end, flexibility and management are the real winners. Generally, CSS allows you to do more with the layout. There's nothing technically nonstandard about a table based layout, but why would you want to limit yourself?

@17 of 26 2008-09-17 13:47:25

It's good to separate content from layout
But this is a fallacious argument; Cliche Thinking

It's a fallacious argument because HTML tables are layout! The content is the data in the table, the presentation is the table itself. This is why separating CSS from HTML can be very difficult at times. You're not separating content from presentation, you're separating presentation from presentation! A pile of nested divs is no different than a table - it's just a different set of tags.

The other problem with separating the HTML from the CSS is that they need intimate knowledge of one another - you really can't separate them fully. The tag layout in the HTML is tightly coupled with the CSS file no matter what you do.

I think tables vs divs comes down to the needs of your application.

In the application we develop at work, we needed a page layout where the pieces would dynamically size themselves to their content. I spent days trying to get this to work cross-browser with CSS and DIVs and it was a complete nightmare. We switched to tables and it all just worked.

However, we have a very closed audience for our product (we sell a piece of hardware with a web interface) and accessibility issues are not a concern for us. I don't know why screen readers can't deal with tables well, but I guess if that's the way it is then developers have to handle it.

@erlando 2008-09-17 14:08:06

screenreaders deals with tables ok.. It's the way that tables don't deal with screenreaders that's the problem. A table-based layout is prone to present the information in an inaccessible manner. Think about how a right-side navigation would look like. It would be pretty far down the page.

@17 of 26 2008-09-17 14:11:43

Ok, that makes sense then - thanks!

@Pete Michaud 2008-09-17 17:33:37

Separation of content from presentation only occurs when the markup is semantic. Most people don't know how to write really semantic mark up, and they also can't present that markup properly with css. That is a failure of the dev, not the technology. I can do it, it's not that hard.

@Mark Brackett 2008-09-18 10:34:50

Just because <table> or <div> have a default presentation in most screen agents, doesn't equate them to being presentation elements instead of semantic elements.

@17 of 26 2008-09-19 02:46:55

I'm not talking about HTML specifically, I'm talking about conceptually in basic UI design. A table dictates how things are laid out on the screen, i.e. how they are presented to the user. That is presentation.

@DisgruntledGoat 2009-07-04 23:19:27

@erlando: true, but then most designs using divs would float columns left and therefore have the navigation later in the HTML. I've yet to see a design where the navigation is the very first thing in the HTML.

@DaveDev 2010-08-06 23:43:24

"I spent days trying to get this to work" - if something I'm trying to figure out ever takes more than a couple of hours, I put it to the StackOverflow community. Not knowing how to do something correctly is no excuse for not doing it correctly. Especially when we have all the answers at our fingertips.

@Nightwolf 2011-06-18 07:47:23

+1 for "A pile of nested divs is no different than a table - it's just a different set of tags." I must add that I require most of the time the same amount of tags to achieve the same result.

@bmarti44 2011-08-27 19:33:54

Tables should ONLY by used for data, not layout. Yes, you can use them for layout if your boss doesn't know better, or if you don't care about SEO, or if you don't care if you write crap code. @Nightwolf that's the most ridiculous thing i ever heard, three times the number of tags are required to do the same thing as ONE div tag.

@Nightwolf 2011-08-27 20:01:02

@bmarti44: Yes, you are right. There are cases where one "div tag" does the trick, and the "table tags" still require its bulky amount. But as an example if you create a login screen with div layout, you cannot use less tags than "table tags" to create the same layout. If you still disagree with me I would like you to show me how to improve my login screen code. Don't get me wrong, I believe you should use divs where you don't display data even if it is more tags than tables.

@MetalFrog 2012-01-19 13:39:30

@Nightwolf, yeah this is old, but I'd love to see your login screen code and rewrite it with more efficient tags. Please share! :D

@Nightwolf 2012-01-20 11:32:00

@MetalFrog: you can find my login screen code here:

@MetalFrog 2012-01-20 12:57:27

@Nightwolf, sweet! Should be fun!

@needlestack 2011-02-10 23:52:02

Layout should be easy. The fact that there are articles written on how to achieve a dynamic three column layout with header and footer in CSS shows that it is a poor layout system. Of course you can get it to work, but there are literally hundreds of articles online about how to do it. There are pretty much no such articles for a similar layout with tables because it's patently obvious. No matter what you say against tables and in favor of CSS, this one fact undoes it all: a basic three column layout in CSS is often called "The Holy Grail".

If that doesn't make you say "WTF" then you really need to put down the kool-aid now.

I love CSS. It offers amazing styling options and some cool positioning tools, but as a layout engine it is deficient. There needs to be some type of dynamic grid positioning system. A straightforward way to align boxes on multiple axis without knowing their sizes first. I don't give a damn if you call it <table> or <gridlayout> or whatever, but this is a basic layout feature that is missing from CSS.

The larger problem is that by not admitting there are missing features, the CSS zealots have been holding CSS back from all it could be. I'd be perfectly happy to stop using tables if CSS provided decent multi-axis grid positioning like basically every other layout engine in the world. (You do realize this problem has already been solved many times in many languages by everyone except the W3C, right? And nobody else denied that such a feature was useful.)

Sigh. Enough venting. Go ahead and stick your head back in the sand.

@Dan Herbert 2011-02-11 04:58:35

"CSS zealots" (as you put it) are not ignorant of this fact. The next CSS spec has not just one, but two solutions to fix the problems with layouts in CSS. Template Layouts: And Grid Positioning: This doesn't introduce competing specs. The 2 specs actually complement each other. As of the time of writing this comment though, no browser implements it, yet.

@3lectrologos 2011-02-11 17:30:18

+1: I completely agree. You shouldn't have to "get it to work" (although I don't like tables either).

@bobwienholt 2012-02-02 14:55:10

This is 100% exactly how I feel. I wish I could upvote you to the top answer.

@Halil Özgür 2010-11-01 18:08:39

  1. Try to merge/split a 10/20 something deep colspan/rowspan. More than once I had to supress my instinct to start a fight with someone. [?!]
  2. Try to change source code order without changing visible order. [SEO, usability, ...]
  3. The very (really simple) page we're looking at is ~150K. I bet It can nearly be halved using proper CSS. [SEO (Yes, SEO, read latest Google specs etc), perfo, ...]
  4. Try to make an iterator template that can work in any width.
  5. The discussion of the matter in this table-based medium of SO can cause a singularity and destroy us all

@Petras 2008-11-10 02:18:57

It doesn't have to be a war. Harmony is possible.

Use one table for the overall layout and divs inside it.

    <tr><td colspan="3"><div>Top content</div></td></tr>
        <td><div>Left navigation</div></td> 
        <td><div>Main content</div></td> 
        <td><div>Right navigation</div></td> 
    <tr><td colspan="3"><div>Bottom content</div></td></tr>

Look - no nested tables.

I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.

Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?

Note that this approach will give you 100 % CSS compliance at link text

@Michael L 2008-12-05 19:48:07

You say look ma no nested tables, but remember you also haven't added the complexity of your left navigation, or main content, once you add complexity in , then you'll have to start nesting tables, but who cares, there is nothing wrong with nesting tables.

@Petras 2009-04-07 15:19:22

Once I have the overall table structure which works effortlessly - unlike the ridiculously complicated divs you need to work in all browsers (see, I use divs inside the cells. There are no more tables.

@Steeven 2011-07-08 12:24:50

You don't need tables to work in all browsers?

@user825628 2011-07-02 00:47:33

The issue of strictly separating presentation and content strikes me as roughly analogous to separating header files from implementation files in C++. It makes sense, but it can also be a pain. Witness Java and C# where classes are defined in a single source file. The authors of the newer languages noticed something that was causing programmers headaches and they got rid of it. That seems to be the gist of this discussion. One side is saying CSS is too difficult, the other side is saying one must become a CSS master.

For simple layout issues why not bend the rule that says presentation must be completely separate? What about a new tag (or some extension to the div tag) that allows us to control presentation directly in HTML? After all, aren't we already leaking presentation into HTML? Look at h1, h2...h6. We all know these control presentation.

The ability to read code (and HTML is code) is very important. Gurus tend to overlook how important it is to make a programming environment as accessible to the masses as possible. It is very shortsighted to think that only professional programmers matter.

@Carl Camera 2008-09-17 14:03:51

Here's my programmer's answer from a simliar thread

Semantics 101

First take a look at this code and think about what's wrong here...

class car {
    int wheels = 4;
    string engine;

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

The problem, of course, is that a bike is not a car. The car class is an inappropriate class for the bike instance. The code is error-free, but is semantically incorrect. It reflects poorly on the programmer.

Semantics 102

Now apply this to document markup. If your document needs to present tabular data, then the appropriate tag would be <table>. If you place navigation into a table however, then you're misusing the intended purpose of the <table> element. In the second case, you're not presenting tabular data -- you're (mis)using the <table> element to achieve a presentational goal.


Will visitors notice? No. Does your boss care? Maybe. Do we sometimes cut corners as programmers? Sure. But should we? No. Who benefits if you use semantic markup? You -- and your professional reputation. Now go and do the right thing.

@Jimmy 2008-09-17 20:40:53

Sorry, that doesn't hold water. You don't use car for mybike because you would define a "bike" class instead. You can't define something else for "<table>" because it is more than a simple semantic tag -- it tells the browser how to render its content as well.

@sectrean 2008-09-18 18:13:04

Exactly. You would use a bike class instead. That was the point. You should use what's appropriate. You wouldn't use the car class for mybike just because its Render() method formatted things nicely. You'd make the bike class render how you want it to.

@Charles Roper 2008-09-21 16:55:18

I think the point is also that loose coupling is desirable in a system. Using tables instead of DIVs+CSS to define the layout is equivalent of a tightly coupled system. More on loose coupling here:

@Sherm Pendley 2008-11-13 09:10:03

Nice analogy, and great conclusion. Why should anyone have to be forced by one's boss and/or users into doing the right thing? Doesn't anyone take pride in their own work any more?

@markus 2008-11-16 01:09:14

I think this is quite an arrogant post which doesn't explain anything but just repeats the same claims again without answering the question. I don't understand why it got so many upvotes????

@Richard Ev 2008-11-27 11:33:35

I agree with tharkum. This response is rather subjective, and does not actually answer the question posed. While I agree that DIVs should be used for page layout, I cannot imagine that any web designer would be confused by a table-based layout.

@roryf 2008-11-30 18:12:55

"I cannot imagine that any web designer would be confused by a table-based layout" Without Firebug I would never understand a nested table layout.

@glenatron 2008-12-02 16:36:00

I have been through nested table layout hell so many times by this point that Richard E's comment there makes my brain hurt.

@Vinko Vrsalovic 2008-12-14 17:06:35

@tharkun & Richard: How come "semantically incorrect" is subjective and does not explain anything?

@Mike B 2008-12-16 17:45:51

I'm also surprised that this answer is rated so highly, as it doesn't even answer the question.

@Benno Richters 2009-01-16 07:48:48

I'm afraid this is the kind of fallacious reasoning I hoped to avoid. "You -- and your professional reputation. Now go and do the right thing." This is begging the question. (It assumes that a professional attitude is using CSS, while that is the thing to be proved.)

@Carl Camera 2009-01-17 14:15:28

I don't think it's fair to attack my conclusion as fallacious reasoning when it is no reason at all -- it is a conclusion. My reason is in the preceding paragraph: "You're misusing the table element to achieve a presentational goal" - using the table element for something it was never intended for.

@Benno Richters 2009-01-18 15:33:11

@Carl Camera: That sentence doesn't show what the negative consequences are of using the table element for presentational goals. To state that it 'reflects poorly on a programmer' and questioning a 'professional' attitude, is the 'begging' part in this answer.

@Carl Camera 2009-01-21 14:26:03

@bno Yes, you must accept my premise that tool misuse reflects poorly on the craftsman to accept my conclusion that proper tool use reflects positively on the craftsman. If not, then using ul for indentation or blockquote for side margins would not bother you either.

@ANeves 2010-08-02 09:37:17

@Carl Camera's last comment: you can't use ul for indentation or blockquote for side margins after you've used a CSS reset... hehe.

@Chris Fletcher 2011-03-29 14:35:40

I completely agree with this analogy, and the people writing the HTML5 specs must agree, too. Think about it, they're giving us elements like section, article, aside, hgroup, header, footer, nav, figure, figcaption, so we don't have to use div for everything.

@Niklas R. 2011-08-19 14:41:48

I understand something similar to your post: If it's data you can use tables but if it's something else you should use CSS

@Chris Fletcher 2011-03-29 14:49:00

DOM Manipulation is difficult in a table-based layout.

With semantic divs:

    // Do awesome stuff

With tables:

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night

Now, granted, the second example is kind of stupid, and you can always apply IDs or classes to a table or td element, but that would be adding semantic value, which is what table proponents so vehemently oppose.

@Sylverdrag 2011-04-11 06:56:41

Whoever said that table proponent oppose semantic value? The only thing table proponents like about using table for layout is that it is fast and easy to write, it's easy to generate, and it never breaks. No matter the browser or the window size, you know that you will never have a cell pushed down below or above something else.

@Ross 2008-09-18 10:10:56

Here's a section of html from a recent project:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="" xml:lang="en" lang="en">
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        <div class="clearfix"></div>
    <div id="sidebar">
        <!-- Sidebar content -->
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>

And here's that same code as a table based layout.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="" xml:lang="en" lang="en">
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
    <table cellspacing="0">
            <td><!-- Page Title --></td>

            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
            <td colspan="2">Footer</td>

The only cleanliness I see in that table based layout is the fact that I'm overzealous with my indentation. I'm sure that the content section would have a further two embedded tables.

Another thing to think about: filesizes. I've found that table-based layouts are twice the size of their CSS counterparts usually. On our hig-speed broadband that isn't a huge issue but it is on those with dial up modems.

@Mr. Shiny and New 安宇 2008-10-28 13:30:00

speed isn't the only thing that is hurt by larger files: many companies pay for bandwidth. If you can cut your client's bandwidth bills in half simply by coding well, that's a great advantage.

@goldenratio 2009-05-08 22:35:37

Yeah but don't forget that while the HTML might be twice as large in a CSS-less layout, using a DIV+CSS layout will result in (at least) an extra HTTP Request for the CSS file, plus the bandwidth usage for the file itself.

@user151841 2009-12-17 16:37:29

But the css file need only be downloaded once, where as the whole table structure is resent on each page request.

@Draemon 2010-01-29 20:12:00

You've picked a design well-suited to div+css and shown that it's more verbose in a table-based design? So what: It would be just as easy to create a design that was well-suited to table-based layout and show the hoops you'd have to jump through to replicate it in CSS.

@Bobby Jack 2010-11-08 12:19:10

@Draemon: Maybe you'd like to give an example?

@Pixelgrey 2011-05-03 22:47:00

By still using table for layouts, we are missing on the innovation on the div side.

Many have come up with solutions that make creating layout for divs easier. The most popular being the grid architecture. There are dynamic layout generators based on this architecture. Check out: 1) and ( 2) blueprint and so many of late.

I have not seen much of innovation in terms of architecture and tools with the tables layout.

I would say, all the theories aside, practically layout with CSS and divs are faster. Rather innovation in this direction made it easier than anything.

@Biranchi Panda 2011-04-25 10:19:30

As per my knowledge on tables, if too many tables are nested, there is a great overhead to browser in rendering the page.

1 - The browser has wait to render the final view wait until the entire table gets loaded.

2 - The algorithm to render the table is expensive and is not in a single go. The browser, as and when, gets the contents, will try to render calculating the content width and height. So, if you are having nested tables, say, the browser has received the first row and the 1st cell is having large amount of content and width and height not defined, it will calculate the width and will render the first row, In the mean while it gets the 2nd row will cell#2 having loads of content! It will now calculate the width for 2nd row cells.. What about the first ? It will calculate widths recursively. That's bad at client side. (To site an example) As a programmer, you'll optimize stuffs such as time to fetch data, optimized data structures and etc. You optimize things to complete on server side, say in2 secs, but end user in getting the final view in 8 secs. What is wrong here ? 1. May be network is slow! What if network is fine ? What is network is delivering the contents in next 1 sec ? Where is this extra 5 secs getting consumed ? Thing to worry about-- The browser might be taking lot of time in estimating and rendering the tables!

How to optimize tables ? If you're using tables, I would suggest, always define width for the cells. This does not guarantees that browser will blindly take this widths only, but would be of great help to browser in deciding the initial widths.

But, at the end, div are great way as CSS can be cached by the browser; while table aren't cached !

@Sylverdrag 2011-04-11 11:59:25

I was surprised to see some issues were not already covered, so here are my 2 cents, in addition to all the very valid points made earlier:

.1. CSS & SEO:

a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.

b) When the layout is moved over to CSS, the HTML page is lighter and therefore loads faster for a search engine spider. (spiders don't bother downloading external css files). Fast loading pages is an important ranking consideration for several search engines, including Google

c) SEO work often requires testing and changing things, which is much more convenient with a CSS based layout

.2. Generated content:

A table is considerably easier to generate programmically than the equivalent CSS layout.

foreach ($comment as $key=>$value)
   echo "<tr><td>$key</td><td>$value</td></tr>";

Generating a table is simple and safe. It is self-contained and integrates well within any template. To do the same with CSS is considerably harder and may be of no benefit at all: hard to edit the CSS stylesheet on the flight, and adding the style inline is no different from using a table (content is not separated from layout).

Further, when a table is generated, the content (in variables) is already separated from the layout (in code), making it as easy to modify.

This is one reason why some very well designed websites (SO for instance) still use table layouts.

Of course, if the results need to be acted upon through JavaScript, divs are worth the trouble.

.3. Quick conversion testing

When figuring out what works for a specific audience, it is useful to be able to change the layout in various ways to figure out what gets the best results. A CSS based layout makes things considerably easier

.4. Different solutions for different problems

Layout tables are usually dissed because "everybody knows divs & CSS" are the way to go.

However the fact remains that tables are faster to create, easier to understand and are more robust than most CSS layouts. (Yes, CSS can be as robust, but a quick look through the net on different browsers and screen resolutions shows it's not often the case)

There are a lot of downsides to tables, including maintenance, lack of flexibility... but let's not throw the baby with the bath water. There are plenty of professional uses for a solution which is both quick and reliable.

Some time ago, I had to rewrite a clean and simple CSS layout using tables because a significant portion of the users would be using an older version of IE with really bad support for CSS

I, for one, am sick and tired of the knee-jerk reaction "Oh noes! Tables for layout!"

As for the "it wasn't intended for that purpose and therefore you shouldn't use it this way" crowd, isn't that hypocrisy? What do you think of all the CSS tricks you have to use to get the darn thing working in most browsers? Were they meant for that purpose?

@Shanimal 2011-02-28 08:22:17

Flex has a tag for laying things out in vertical columns. I don't think they got the whole layout/content thing right either to be honest, but at least they've resolved that issue.

Like many of the people frustrated with CSS I've also looked far and wide for an easy answer, was duped into feeling elated when I thought I had found it, and then had my hopes dashed to pieces when I opened the page in Chrome. I'm definitely not skilled enough to say it's not possible, but I haven't seen anyone offer up sample code for peer review proving unequivocally that it can be done reliably.

So can someone from the CSS side of this island recommend a mindset/methodology for laying out vertical columns? I've tried absolute positioning in second and third rows, but i end up with stuff overlapping everywhere and float has similar issues if the page is shrunk down.

If there was an answer to this I'd be ecstatic to -do the right thing- Just tell me something like, "Hey have you tried **flow:vertical|horizontal" and I'm totally out of your hair.

@Tim Black 2011-02-11 21:51:25

I still don't quite understand how divs / CSS make it easier to change a page design when you consider the amount of testing to ensure the changes work on all browsers, especially with all the hacks and so on. Its a hugely frustrating and tedious process which wastes large amounts of time and money. Thankfully the 508 legislation only applies to the USA (land of the free - yeah right) and so being as I am based in the UK, I can develop web sites in whatever style I choose. Contrary to popular (US) belief, legislation made in Washington doesn't apply to the rest of the world - thank goodness for that. It must have been a good day in the world of web design the day the legislation came into force. I think I'm becoming increasingly cynical as I get older with 25 years in the IT industry but I feel sure this kind of legislation is just to protect jobs. In reality anyone can knock together a reasonable web page with a couple of tables. It takes a lot more effort and knowledge to do this with DIVs / CSS. In my experience it can take hours and hours Googling to find solutions to quite simple problems and reading incomprehensible articles in forums full of idealistic zealots all argueing about the 'right' way to do things. You can't just dip your toe in the water and get things to work properly in every case. It also seems to me that the lack of a definitive guide to using DIVS / CSS "out of the box", that applies to all situations, working on browsers, and written using 'normal' language with no geek speak, also smells of a bit of protectionism.
I'm an application developer and I would say it takes almost twice as long to figure out layout problems and test against all browsers than it does to create the basic application, design and implement business objects, and create the database back end. My time = money, both for me and my customers alike so I am sorry if I don't reject all the pro DIV / CSS arguments in favour of cutting costs and providing value for money for my customers. Maybe its just the way that developers minds work, but it seems to me far easier to change a complex table structure than it is to modify DIVs / CSS. Thankfully it now appears that a solution to these issues is now available - its called WPF.

@Grad van Horck 2008-09-17 13:29:08

The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.

And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).

It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).

@Tim Black 2010-11-25 14:25:39

CSS/DIV - it's just jobs for the design boys, isn't it. The hundreds of hours I've spent debugging DIV/CSS issues, searching the Internet to get some part of markup working with an obscure browser - it drives me mad. You make one little change and the whole layout goes horrendously wrong - where on eath is the logic in that. Spending hours moving something 3 pixels this way then something else 2 pixels the other to get them all to line up. This just seems plain wrong to me somehow. Just because you're a purist and something is "not the right thing to do" doesn't mean you should make use of it to the nth degree and under all circumstances, especially if it makes your life 1000 times easier.

So I've finally decided, purely on commercial grounds, although I keep use to minimum, if I anticipate 20 hours work to get a DIV placed correctly, I'll stick in a table. It's wrong, it upsets the purists, but in most cases it costs less time and is cheaper to manage. I can then concentrate on getting the application working as the customer wants, rather than pleasing the purists. They do pay the bills after all and my argument to a manager enforcing the use of CSS/DIV - I would merely point out the customers pay his salary as well!

The only reason all these CSS/DIV arguments occur is because of the shortcoming of CSS in the first place and because the browsers aren't compatible with each other and if they were, half the web designers in the world would be out of a job.

When you design a windows form you don't try moving controls around after you have laid them out so I kind of think it's strange to me why you would you want to do this with a web form. I simply can't understand this logic. Get the layout right to start with and what's the problem. I think it's because designers like to flirt with creativity, whilst application developers are more concerned with actually getting the application working, creating business objects, implementing business rules, working out how bits of customer data relates to each other, ensuring the thing meets the customers requirements - you know - like the real world stuff.

Don't get me wrong, both arguments are valid, but please don't critise developers for choosing an easier, more logical approach to designing forms. We often have more important things to worry about than the correct semantics of using a table over a div.

Case in point - based on this discussion I converted a few existing tds and trs to divs. 45 minutes messing about with it trying to get everything to line up next to each other and I gave up. TDs back in 10 seconds later - works - straight away - on all browsers, nothing more to do. Please try to make me understand - what possible justification do you have for wanting me to do it any other way!

@Daniel Szabo 2010-11-25 22:20:31

I couldn't agree more with this post. In the 10 years I've been in design, I cannot think of a single time where the argument "we use CSS because it makes sitewide changes easier to manage" played out as accurate.

@Jiaaro 2010-11-29 18:32:33

know what makes sitewide changes easy to manage? MVC and template systems

@Tim Black 2011-02-11 22:19:12

Please don't get me wrong - I still use CSS but I use it to apply style (colour, background images and so forth) and not layout. CSS seems to be pretty much consistent across browsers when used to control style only. Where it is flawed and falls down in a big way is the way in which layout is both specified and implemented across browsers. Has anyone ever tried to get ASP.NET MasterPages working reliably with DIVs? Its almost impossible!

@workmad3 2008-09-17 14:52:08

div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.

That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.

@JacquesB 2008-09-18 09:43:50

Tables are not in general easier or more maintainable than CSS. However, there are a few specific layout-problems where tables are indeed the simplest and most flexible solution.

CSS is clearly preferable in cases where presentational markup and CSS support the same kind of design, no one in their right mind would argue that font-tags are better than specifying typography in CSS, since CSS gives you the same power than font-tags, but in a much cleaner way.

The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer - in other browsers this is easliy achieved by using display:table-cell).

So it's not really a question of whether tables or CSS is preferable, but it is a question of recognizing the specific cases where use of tables may make the layout more flexible.

The most important reason for not using tables is accessibility. The Web Content Accessibility Guidelines advice againt using tables for layout. If you are concerned about accessibility (and in some cases you may be legally obliged to), you should use CSS even if tables are simpler. Note that you can always create the same layout with CSS as with tables, it might just require more work.

@Chuck Le Butt 2010-11-29 18:45:50

Because it's HELL to maintain a site that uses tables, and takes a LOT longer to code. If you're scared of floating divs, go take a course in them. They're not difficult to understand and they're approximately 100 times more efficient and a million times less a pain in the ass (unless you don't understand them -- but hey, welcome to the world of computers).

Anyone considering doing their layout with a table better not expect me to maintain it. It's the most ass-backwards way to render a website. Thank god we have a much better alternative now. I would NEVER go back.

It's scary that some folks might not be aware of the time and energy benefits from creating a site using modern tools.

@Simon Measures 2010-09-09 19:30:37

Google gives very low priority to text content contained inside a table. I was giving some SEO advice to a local charity. In examining their website it was using tables to layout the site. Looking at each page, no matter what words - or combination of words - from their pages I used in the Google search box the pages would not come up in any of the top search pages. (However, by specifying the site in the search the page was returned.) One page was well copy written by normal standards to produce a good result in a search but still it didn't appear in any of the first pages of search results returned. (Note this text was within a table.) I then spotted a section of text on the pages which was in a div rather than a table. We put a few of the words from that div in the search engine. Result? It came in at No.2 in the search result.

@DLH 2010-08-09 13:10:10

The fact that this is a hotly debated question is a testament to the failure of the W3C to anticipate the diversity of layout designs which would be attempted. Using divs+css for semantically-friendly layout is a great concept, but the details of implementation are so flawed that they actually limit creative freedom.

I attempted to switch one of our company's sites from tables to divs, and it was such a headache that I totally scrapped the hours of work I had poured into it and went back to tables. Trying to wrestle with my divs in order to gain control of vertical alignment has cursed me with major psychological issues that I will never shake as long as this debate rages on.

The fact that people must frequently come up with complex and ugly workarounds to accomplish simple design goals (such as vertical alignment) strongly suggests that the rules are not nearly flexible enough. If the specs ARE sufficient, then why do high-profile sites (like SO) find it necessary to bend the rules using tables and other workarounds?

@Konrad Rudolph 2008-09-17 16:23:06

I'm going to go through your arguments one after another and try to show the errors in them.

It's good to separate content from layout But this is a fallacious argument; Cliché Thinking.

It's not fallacious at all because HTML was designed intentionally. Misuse of an element might not be completely out of question (after all, new idioms have developed in other languages, as well) but possible negative implications have to be counterbalanced. Additionally, even if there were no arguments against misusing the <table> element today, there might be tomorrow because of the way browser vendors apply special treatment to the element. After all, they know that “<table> elements are for tabular data only” and might use this fact to improve the rendering engine, in the process subtly changing how <table>s behave, and thus breaking cases where it was previously misused.

So what? Does my boss care? Do my users care?

Depends. Is your boss pointy-haired? Then he might not care. If she's competent, then she will care, because the users will.

Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and css.

The majority of professional web developers seem to oppose you[citation needed]. That tables are in fact less maintainable should be obvious. Using tables for layout means that changing the corporate layout will in fact mean changing every single page. This can be very expensive. On the other hand, judicious use of semantically meaningful HTML combined with CSS might confine such changes to the CSS and the pictures used.

By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.

Deeply nested <div>s are an anti-pattern just as table layouts. Good web designers don't need many of them. On the other hand, even such deep-nested divs don't have many of the problems of table layouts. In fact, they can even contribute to a semantic structure by logically dividing the content in parts.

Readability of the code I think it's the other way around. Most people understand html, little understand css. It's simpler.

“Most people” don't matter. Professionals matter. For professionals, table layouts create many more problems than HTML + CSS. This is like saying I shouldn't use GVim or Emacs because Notepad is simpler for most people. Or that I shouldn't use LaTeX because MS Word is simpler for most people.

It's better for SEO not to use tables

I don't know if this is true and wouldn't use this as an argument but it would be logical. Search engines search for relevant data. While tabular data could of course be relevant, it's rarely what users search for. Users search for terms used in the page title or similarly prominent positions. It would therefore be logical to exclude tabular content from filtering and thus cutting the processing time (and costs!) by a large factor.

Tables are slower. An extra tbody element has to be inserted. This is peanuts for modern web browsers.

The extra element has got nothing to do with tables being slower. On the other hand, the layout algorithm for tables is much harder, the browser often has to wait for the whole table to load before it can begin to layout the content. Additionally, caching of the layout won't work (CSS can easily be cached). All this has been mentioned before.

Show me some benchmarks where the use of a table significantly slows down a page.

Unfortunately, I don't have any benchmark data. I would be interested in it myself because it's right that this argument lacks a certain scientific rigour.

Most web sites that need an upgrade need new content (html) as well. Scenarios where a new version of a web site only needs a new css file are not very likely.

Not at all. I've worked on several cases where changing the design was simplified by a separation of content and design. It's often still necessary to change some HTML code but the changes will always be much more confined. Additionally, design changes must on occasion be made dynamically. Consider template engines such as the one used by the WordPress blogging system. Table layouts would literally kill this system. I've worked on a similar case for a commercial software. Being able to change the design without changing the HTML code was one of the business requirements.

Another thing. Table layout makes automated parsing of websites (screen scraping) much harder. This might sound trivial because, after all, who does it? I was surprised myself. Screen scraping can help a lot if the service in question doesn't offer a WebService alternative to access its data. I'm working in bioinformatics where this is a sad reality. Modern web techniques and WebServices have not reached most developers and often, screen scraping is the only way to automate the process of getting data. No wonder that many biologists still perform such tasks manually. For thousands of data sets.

@John MacIntyre 2009-05-20 14:30:06

"changing the corporate layout will in fact mean changing every single page" - Do people still actually duplicate the corporate layout on every page? It's so easy to resolve with master pages or user controls in .net, include files in php or classic asp, etc ... Anybody who copies the company layout like this deserves an a** kicking! ;-)

@BenAlabaster 2009-05-20 15:47:25

@John MacIntyre: I entirely agree. Template as much as possible and only vary where necessary. It's simple laws of management.

@Konrad Rudolph 2009-05-21 09:25:52

John: true, that argument doesn't really apply on a well-structured site. However, even with master pages I see that at least some style elements will be duplicated, simply because there won't be just one master page. Redundancies will always exist, even when using both templates and proper CSS. Both techniques help reducing them, though.

@cletus 2009-06-17 21:48:04

Sorry but this is really "pie int he sky" wishful thinking. Users care? No. Noone cares except a small number of misguided revisionists. HTML (including tables) is far older than the relatively new notion of "semantics vs layout". Oh and source please for "the majority of professional web developers oppose you".

@Konrad Rudolph 2009-06-18 08:58:05

cletus: come to think of it, the “majority” thing is most probably wrong. About the rest, i heatedly disagree with you. Semantics were implied in the beginning, although their real advantage became clearer and more important with time. To that extend, yes, the standard was revised. So what? Why's that misguided? Do users care? Maybe not today but they certainly did in the times of dialup when the friggin' site just wouldn't load bc' the browser waited for the whole table before starting displaying. Is the debate obsolete? No, because the separation between content & layout was made clearer …

@Konrad Rudolph 2009-06-18 09:02:24

… with every revision of the standards. The advantages of the separation pile up. My biggest problem with the use of tables for layout in big sites is that this directly prevents standards folks and implementors from making important changes, for fear of breaking compatibility. Moronic use of tables for layout directly hinders progress. Sorry for the strong language but that's just the way it is.

@Konrad Rudolph 2009-06-18 09:11:51

Typo above: semantics were implied from the beginning. <table> in HTML was always only meant for tabular data, never for layouting (back in the early years you couldn't change the table looks anyway, thus preventing its use as a layout anchor). In fact, early drafts of HTML had no notion of layout at all, and HTML was never meant for layout, but for structuring text. Even more: the very first proposal of HTML repeatedly warns against abusing tags to influence the layout, and cautions to use logical over physical markup.

@corymathews 2009-07-26 16:42:18

Get a screen reader and have it read a page with a table layout. that is all.

@dpq 2009-08-24 08:14:59

"Search engines search for relevant data. While tabular data could of course be relevant, it's rarely what users search for." Except that if everybody and their dog uses tables for building layouts, search engines should (and indeed do) treat contents of tables accordingly, otherwise they won't be relevant. I agree with the rest of your post, though.

@Konrad Rudolph 2010-08-01 18:49:10

@Sergio: please do not edit out relevant information. This is an unsourced dubious claim I’m using there and I want to make that quite clear. Your edit put a claim in my mouth that I can’t back up, effectively making me a liar if this turns out to be false.

@Van Nguyen 2011-09-12 07:06:50

Why is tables used in html emails instead of divs?

@Skuld 2011-11-14 14:08:41

@Kaizoku Tables are used in emails because (sadly/for better or worse) most email clients don't allow the full spec of css, and therefore it is seen to be 'easier' to do emails as tables. (It's evil I know)

@Niklas R. 2010-05-01 21:47:09

Data: use tables. Layout: use styles. Tables can render fastest with a very lean browser, that is, Links 2 or Lynx with no styling, just plain markup.

@Allen Hardy 2008-09-17 15:25:42

If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.

Then try it with a nice semantically correct div layout site.

You'll see the difference.

Tables aren't evil if the data in them is tabular not to layout the page.

@Patrick May 2008-09-17 15:28:41

It's worth figuring out CSS and divs so the central content column loads and renders before the sidebar in a page layout. But if you are struggling to use floating divs to vertically align a logo with some sponsorship text, just use the table and move on with life. The Zen garden religion just doesn't give much bang for the buck.

The idea of separating content from presentation is to partition the application so different kinds of work affect different blocks of code. This is actually about change management. But coding standards can only examine the present state of code in a superficial manner.

The change log for an application that depends on coding standards to "separate content from presentation" will show a pattern of parallel changes across vertical silos. If a change to "content" is always accompanied by a change to "presentation", how successful is the partitioning?

If you really want to partition your code productively, use Subversion and review your change logs. Then use the simplest coding techniques -- divs, tables, JavaScript, includes, functions, objects, continuations, whatever -- to structure the application so that the changes fit in a simple and comfortable manner.

@Sean McMillan 2011-07-27 16:29:26

+1 for the first two sentences.

@Ben Scheirman 2008-09-17 15:36:31

One table for layout wouldn't be that bad. But you can't get the layout you need with just one table most of the time. Pretty soon you have 2 or three nested tables. This becomes very cumbersome.

  • It IS a LOT harder to read. That's not up to opinion. There's just more nested tags with no identifying marks on them.

  • Separating content from presentation is a good thing because it allows you to focus on what you're doing. Mixing the two leads to bloated pages that are hard to read.

  • CSS for styles allows your browser to cache the files and subsequent requests are much faster. This is HUGE.

  • Tables lock you into a design. Sure, not everyone needs the flexibility of CSS Zen Garden, but I've never worked on a site where I didn't need to change the design a little bit here and there. It's much easier with CSS.

  • Tables are hard to style. You don't have very much flexibility with them (i.e. you still need to add HTML attributes to fully control a table's styles)

I haven't used tables for non-tabular data in probably 4 years. I haven't looked back.

I'd really like to suggest reading CSS Mastery by Andy Budd. It's fantastic.

Image at,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

@Jacob T. Nielsen 2008-10-03 13:01:16

I can highly recommen this book

@KMån 2010-01-14 12:41:03

Contains good examples for box model, selectors, and positioning.

@Rimian 2009-02-22 09:48:31

I researched the issue of screen readers and tables a few years ago and came up with information that contradicts what most developers believe:

"You will probably hear some accessibility advocates say that layout tables are a bad idea, and that CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of disabilities can easily access tables, as long as the tables are designed with accessibility in mind. "

@RVeur23 2009-02-16 16:30:50

I'm sorry for my English but here's another reason :

I worked in some governmental organization and the number one reason to not use TABLE, is for disabled peoples. They use machines to "translate" web pages.

The problem is this "translation machine" can't read the website if it's done by TABLE. Why ? Because TABLE are for DATAS.

in fact, if you use TABLES, for each CELLS you have to specify some informations to let disabled people to know where they are in the TABLE. Imagine you have a big table and have to zoom to see only 1 cell in the screen : you have to know in which line/col you are.

So, DIV are used, and the disabled can simply read text, and don't get some weird informations about lines/cols when they don't have to be there.

I also prefer TABLE to make quick and easy templates, but I'm now used to CSS... it's powerful, but you really have to know what you are doing... :)

@jalf 2008-12-05 20:17:35

1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.

A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.

2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.

3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.

And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.

Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.

@mltorrefranca 2008-11-10 02:15:03

In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):

Content and design mashed up together via tables = updating both content and design.

Content separate from design = updating design and maybe a little content.

If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.

Related Questions

Sponsored Content

10 Answered Questions

[SOLVED] Why does HTML think “chucknorris” is a color?

5 Answered Questions

[SOLVED] What is the purpose of the "role" attribute in HTML?

32 Answered Questions

[SOLVED] How to create an HTML button that acts like a link?

28 Answered Questions

[SOLVED] HTML 5: Is it <br>, <br/>, or <br />?

  • 2009-12-22 13:39:08
  • Eikern
  • 1384202 View
  • 2058 Score
  • 28 Answer
  • Tags:   html

33 Answered Questions

[SOLVED] Make a div fill the height of the remaining screen space

  • 2008-09-18 05:06:17
  • Vincent McNabb
  • 1040730 View
  • 1937 Score
  • 33 Answer
  • Tags:   html css html-table

28 Answered Questions

[SOLVED] Redirect from an HTML page

23 Answered Questions

[SOLVED] What are valid values for the id attribute in HTML?

  • 2008-09-16 09:08:52
  • Mr Shark
  • 449037 View
  • 2023 Score
  • 23 Answer
  • Tags:   html id

26 Answered Questions

[SOLVED] Retrieve the position (X,Y) of an HTML element relative to the browser window

Sponsored Content