Table Layouts vs. Div Layouts: From Hell to… Hell?


Over the last several years, developers have moved from table-based website structures to div-based structures. Hey, that’s great. But wait! Do developers know the reasons for moving to div-based structures, and do they know how to? Often it seems that people are moving away from table hell only to wind up in div hell.

This article covers common problems with layout structure in web design. The first part goes through what table and div hells are, including lots of examples. The next section shows how to write cleaner and more readable code. The final part looks at what features await in future. Please join us on this journey from hell to heaven.

Photo of a road sign containing heaven and hell1
Image by lpinc.19882.

Table Hell

You’re in table hell when your website uses tables for design purposes. Tables generally increase the complexity of documents and make them more difficult to maintain. Also, they reduce a website’s flexibility in accommodating different media and design elements, and they limit a website’s functionality.

MAMA3 (Metadata Analysis and Mining Application) is a structural Web page search engine from Opera Software4 that crawls Web pages and returns results detailing page structures. If we look into MAMA’s key findings, we see that the average website has a table structure nested three levels deep. On the list of 10 most popular tags, table, td and tr are all there. The table element is found on over 80% of the pages whose URLs were crawled by MAMA.

Semantically speaking, the table tag is meant for listing tabular data. It is not optimized to build structure.

Ease of use

Using tables to build structure is quite intuitive. We see tabular data every day, and the concept is well known.

And the existence of table attributes makes for a rather flat learning curve because the developer doesn’t have to use a separate style sheet. With divs, the developer must use the style attribute or an external style sheet, because the div tag doesn’t have any attributes attached to it.

Also, tables don’t break when the content is too wide. Columns are not squeezed under other columns as they are in a div-based structure. This adds to the feeling that using tables is safe.


Table contains different tags: the table tag being the wrapper, tr for each row and td for each cell. The thead and tbody tags are not used for structural purposes because they add semantic meaning to the content. For readability, each tag is normally given its own line of code, with indention. With all of these tags for the table, several extra lines of code are added to content. The colspan and rowspan attributes make the code even more complex, and any developer maintaining that page in future has to go through a lot of code to understand its structure.

<table cellpadding="0" cellspacing="0" border="0">
		<td colspan="3" height="120px">....</td>
		<td class="menu" valign="top">...</td>
		<td class="content" valign="top">...</td>
		<td class="aSide" valign="top">...</td>
		<td colspan="3">...</td>
<div id="header">...</div>
<div id="menu">...</div>
<div id="content">...</div>
<div id="aSide">...</div>
<div id="footer">...</div>

As we see from the example, the table-based layout contains more code than the div-based version. Imagine now if this difference in size stays consistent as the code base grows (by a ratio as much as 2:1). In a div-based structure, it is also possible to skip the menu div and use an unordered list (ul) as a container instead.

Nested tables are code smell5 that a website is stuck in table hell. The number of lines of code is endless, and the complexity is overwhelming. Tables are far from clean code and don’t bring anything semantic to the content unless you’re dealing with actual tabular data. And if you’ve happened to inherit the maintenance of a website that has poor readability, it’s a nightmare. Nested tables are a poor substitution for semantically meaningful, block-level elements.

Another drawback to tables is that they make it harder to separate content from design. The border, width, cellpadding and cellspacing tags are used in about 90% of all websites that use tables, according to MAMA. This adds code to the HTML that should instead go in the style sheet.

Excess code slows down development and raises maintenance costs. There’s a limit to how many lines of code a programmer can produce per hour, and excess code is more complicated for others to understand. Developers may not even understand their own code after a while.

More lines of code mean larger file sizes, which mean longer download times. Developers should keep in mind new media, such as mobile devices, which usually have low bandwidth. Websites will have to support media other than traditional monitors in future, and bad code limits the possibilities. A large code base has more bugs than a small one. Developers tend to produce a certain number of bugs per line of code. Because tables increase the code base, such structures likely contain more bugs than layouts with less code lines.

Screenshot of without a stylesheet6
Websites with tags that properly describe content are easily identifiable. Disabling the style sheet on craigslist7 shows us a table-based layout. Headlines are marked only with the bold tag, and all links could easily be put in individual lists.

Flexibility with media

In an ideal world, the same markup would be used for printers, mobile devices, screens and other media. Using tables for structure provides less flexibility in moving columns around and hiding entire columns. Your user may want to put the side column at the bottom or view a printer-friendly version. With tables, this would require a separate page for each media, which means extra costs during development and higher maintenance costs compared to a div-based website that separates content and design.

Further reading:

Websites currently in table hell:

Div Hell

Websites in div hell have more div tags than are necessary. This is also known as “divitis.”

The div tag is a block-level element that defines a section within a document. Divs are thus suitable for building the structure of Web pages. The div tag is also used to describe content that cannot be properly described by other more semantic tags. When developers do not understand the semantic meaning of other block-level elements, they often add more div tags than are needed.

Heaven in hell19
Some programmers mistakenly believe that using a lot of divs is just fine. Maybe this photo by my_ladyhawk20 makes a good point. Is overuse of divs the best of the worst?

Ease of use

Div-based structures have a much steeper learning curve than table-based structures. The developer must know CSS and understand the difference between block-level elements and inline elements, when to use floats and when to use absolute positioning and how to solve browser bugs.

The div element isn’t visual like the table element. Everyone knows what a table looks like, but divs are not as obvious. The good thing about a div, though, is that it’s only one element. It’s not wrapped in a parent element the way td tags are in tables. The container, then, is more flexible and doesn’t have the limitations of its parent tag.

Using a div for structure can make a page more fragile when content is pushing the div to its limit. It can also force columns to fall under each other. But this is usually only true for older browsers (particularly IE6); newer browsers make content flow to the next column.

Dealing with browser bugs can be a little tricky at first, but with experience developers can identify and fix them. Browser support for W3C21 standards is getting better and better. With the growing popularity of Firefox22 and Safari23 and the introduction of Google Chrome24, we are seeing a big fight over market share, which inevitably makes for better browsers.


The biggest problem with div tags is that they are used too often. Divs should only be used to build structure and as placeholders for design elements when no other block-level elements can describe the content. The div tag is for logical groupings of elements.

Nesting div tags deeply is a sure path to maintenance hell, and the code will make developers think twice before touching it, simply because it’s so unreadable. True, using descriptive class and structure names makes the code more understandable, but using them for nested div tags is not always easy.

Too many div tags is code smell that content isn’t being described as it should. It means divs are being used when semantic block-level tags would better describe the content; for instance, headings should be wrapped in h1 to h5 tags. Writing semantic code usually reduces the code base; and less divs with floats helps keep browser bugs away.

Screenshot of without a style sheet25
Disabling the style sheet for Twitter26 shows us some nice semantic code. Twitter uses lists, headings, hr and fieldset and shows good understanding of how to mark up content.

Of course, ids and classes can carry semantic values that no other tags have. The problem is that these values are not standardized. For example, div id="banner" could have a semantic value for software containing advanced algorithms, telling it that this is a banner. Classes and ids that have semantic values added to them will never be a substitute for tags that have semantic values built in.

Giving semantic values to classes and ids will dramatically increase the readability of code and help avoid bad class names like bigRedText. Also, search engines such as Google use complex algorithms that use the semantic information in classes and ids.

One interesting technology is microformats, which are built on the idea of semantic classes. With the help of special standardized formats, content can be automatically processed by microformat-aware software.

<div class="vcard">
 <span class="tel">
  <span class="type">home</span>:
  <span class="value">+1.415.555.1212</span>

An example of an hCard27 microformat. The hCard is a format for representing people, companies, organizations and places.

The presence of the style attribute is code smell that a website is languishing in div hell, because it doesn’t have any particular rendering behavior. 53.54% of all websites indexed by MAMA contain a style attribute, and 35.40% of all websites have divs that use a style attribute. Classes and ids would help separate design and content and clean up this widespread use of the style attribute.

Classes and ids would also facilitate access to elements in the document object model28 (DOM) through scripts.

Semantic code helps machines understand content. While humans are capable of finding the Norwegian word for “monkey” using the Web, computers cannot do this without human direction. That’s why it’s very important to use tags that describe content properly.

Here are a couple more reasons why machines need to be able to understand website content:

  • Spiders crawl websites, indexing pages for search engines. Adding semantic meaning to content probably makes websites rank higher.
  • Screen readers are used by people with visual impairments. They read content out loud to the user or send it to a braille display that the user reads with his or her fingers. Also, visually impaired people use the keyboard to navigate and use a wide range of keyboard commands. They can also get lists of all headings and links on a page, and each of those lists has meta information on how many elements it contains. Setting the language attribute is also important so that screen readers read content in the correct language. The importance of semantic markup is illustrated by comparing the strong and b tags. The strong tag adds semantic meaning to the content; and b tag adds only visual meaning. As a result, people using screen readers won’t get the same information from that content as people seeing it visually. Many countries have laws that prescribe accessibility support for government websites. Others will follow.

Photo of a braille display29
A braille display. Photo by cobalt12330.

Every extra div the developer adds makes the code harder to read. More lines of code lead to longer download times, and so on. This all rings of the code smell we get from table-based layouts. Overusing div tags is as bad as having a table-based layout, except that it is more flexible with media.

To illustrate the circles of div hell, let’s look at examples:

<div id="menu">
	<div class="selected">
		<div class="graphicLeft">
			<div class="graphicRight">
				<a href="#">Home</a>
		<div class="graphicLeft">
			<div class="graphicRight">
				<a href="#">About</a>

Here is a typical example of a menu with too many div tags. Using a list and setting the anchor tag to display: block in the style sheet would have made all of these divs unnecessary.

<div class="headingOne">My heading</div>
<div class="headingTwo">My heading</div>
<div class="headingThree">My heading</div>

Headings created like this add only visual effect to the content. Their semantic value is lost, and screen readers and web spiders can’t tell they’re headings. (This is the same as what we see when b is used instead of strong.)

News list
<div class="news">
	<img />
	<h2 />
	<p />
	<a />
<div class="news">
	<img />
	<h2 />
	<p />
	<a />

Developers who don’t see the potential of list elements often use divs instead. Lists save some class definitions and help screen readers know how many items there are.

Different widths for containers

Page 1

<div id="contentNormal"></div>
<div id="aSideNormal"></div>

Page 2

<div id="contentWide"></div>
<div id="aSideSmall"></div>

When every column on a website is given its own container, many unnecessary div ids are created. This can easily be rectified by adding a class to the body tag. Let each container simply inherit the class of the body tag and then give each page its own layout in the style sheet. This makes it easy to read the content and page. The improved readability of both the HTML and style sheet simplifies maintenance.

Flexibility with media

Even a website in div hell can be flexible with different media as long as the design is separated from the content and put in the style sheet. Read the excellent article “Going to Print31” on A List Apart32 for guidelines on building a printer-friendly version of your website. This is beyond the scope of this article, but it’s important to point out that a div-based structure is more flexible in supporting different media than a table-based structure. Not having to maintain separate pages for each media saves maintenance and development costs. A div-based structure allows you to move columns around and even hide columns using display: none in the style sheet.

When a website is in div hell and has a lot of floats, finding out which floats to disable to avoid printing bugs on Gecko-based browsers like Netscape33 6.x and Mozilla34‘s is very hard. These browsers do not print long floating elements well. If a floating element runs past the bottom of a printed page, the rest of the float effectively disappears and is not printed on the next page.

Further reading:

Websites currently in div hell:

From Hell To Heaven

Photo in direction of heaven43
Photo taken by supernova944.

Using divs correctly

Before creating a div, the developer should consider, “Do I really need this, or can I do this with a block-level element?” Liberal use of h1 to h5 for headings and ul and dl for lists helps a lot, and don’t forget the paragraph tag. Another element that doesn’t need div wrapping is form. For more flexibility with forms, try combining the fieldset element with a list: that way, the content has semantic value, and the developer has block-level elements to design with.

Because a div element marks up only one block at a time, the code base is much smaller than that of a table-based structure. Less code is code that is more readable, easier to maintain, faster to develop, less buggy, smaller in size, you get the point. You want as little code as possible to do the job right.

When a structure is tagged correctly, more divs are needed only for graphics. When we can’t put background-color, border, background-image, etc. on a block-level element, introducing a div is okay. Clean code shouldn’t stand in the way of a good graphic design.

Screenshot of with outlined block-level elements and tables45

See how many block-level elements Yahoo46 has on its home page. This screenshot, with tables and block-level elements outlined, was taken with the Web Developer47 plug-in for Firefox. Could Yahoo have used fewer containers?

Tips and tricks

Let’s go through some basic examples. The examples below should inspire developers to dig deeper into the subject of clean code and ways to avoid divitis. Notice how the semantics in the code help keep the code readable.

<ul id="menu">
	<li><a href="#">Home</a></li>
	<li><a href="#">Products</a></li>
	<li><a href="#">About</a></li>

A menu as a list is easier to use than as a div and saves many lines of codes. The li tag is a block-level element that can have background properties attached to it, as it is the anchor tag if its display attribute is set to block in the style sheet. Two block-level elements exist to contain the beginning and end of each menu item’s layout. Using a list also makes the page more accessible for people with disabilities and allows you to nest lists for sub-menus.

<h1>Main heading</h1>
<h2>Normal heading</h2>

Use headings where possible. They add semantic value to content and boost website rankings in search engines. They also help people who use screen readers access and understand content.

News list
<ul class="newsList">
		<img />
		<h2 />
		<p />
		<a />
		<img />
		<h2 />
		<p />
		<a />

Group similar pieces of content together and put them in lists. It’s amazing how much of the web is in lists. Lists are perfect containers. They save many lines of code and make code much more understandable than it would be with tables or a mess of divs. And lists let people with screen readers know how many elements they contain. So many main pages of websites already contain lists of news.

Different widths for containers


<body class="newsShow">
	<div id="content"></div>
	<div id="aSide"></div>


/* Containers */
#content { float: left; }
#aSide { float: right; }

/* Page structures */
.newsShow #content { width: 80%; }
.newsShow #aSide { width: 20%; }

.home #content { width: 70%; }
.home #aSide { width: 30%; }

.oneColumn #content { width: 100%; }

With a class for body, there is no need for contentSmall, contentNormal, contentWider and so on. Simply refer to the container through the body parent class and then control the width in the style sheet. The style sheet will be more readable, and the developer won’t need to refer to so many bad classes. The page type (body class) will tell you which one to refer to.

List post data
	<dt>Your name is:</dt>
	<dd>Susan Hanson</dd>
	<dt>Your address is:</dt>
	<dd>Street name 1</dd>
	<dt>You live in:</dt>

Use the dl tag when listing key value pairs. Many people would probably use a table for this purpose. But using the dl tag saves code and makes it possible to float the dt and dd tags and set their widths for a nice layout. The dl tag semantically links the dd to the dt tag. Both dt and dd are block-level elements.

Simple form
	  <legend>Person info</legend>
		  <label for="name">Name:</label>
		  <input type="text" name="name" id="name" />
		  <label for="age">Age:</label>
		  <input type="text" name="age" id="age" />
	  <legend>Address info</legend>
		  <label for="address">Address:</label>
		  <input type="text" name="address" id="address" />
		  <label for="zip">Zip:</label>
		  <input type="text" name="zip" id="zip" />

This example is of a form that is semantic and has containers for the layout. Getting a nice layout with forms can often be quite messy. Nested tables are often used for this purpose. But using lists instead tells screen readers how many elements a form contains. The fieldset is a block-level element that groups related data and can be nicely designed using CSS.

Using divs to manage structure (header, menu, footer and so on) and using other block elements, like p, ul, dl and form, where appropriate would make the world a much easier place to live. Lists are already widely used and perfect as containers. And don’t forget to include a class with your body tag. When developers start coding cleanly and semantically, they never look back.

Further reading:

Tips on Moving From a Table- to Div-Based Structure

  • Work your way from the outer table to the inner table. Remove tables one by one and replace them with proper markup that describes their content. Perhaps table aren’t even needed. Starting with the outer table will make the rest of the code more readable. If the outer tables are part of a framework, removing them may affect multiple pages. It’s also a good idea to work on the most important or popular pages first.
  • Don’t introduce new tables unless they are used for tabular data.
  • Separate design and content. Put layout-specific code in the style sheet, and let the markup tell the browser what kind of content it is.
  • Every time someone works on a page, she or he should check if the code can improved a bit, whether by making it more semantic, more readable or cleaner.
  • It would probably cost more to replace the whole system than fix it bit by bit, especially if it’s a large website.
  • Don’t continue writing bad code if the website already contains bad code. Write good semantic code and remind yourself that the bad code will eventually be replaced. Writing good code saves time in the end. Make a difference now, right away by writing only clean, semantic code.

The Future

Two upcoming technologies look very interesting in how they deal with structure. HTML 5 will come with tags that have structural semantic meaning and a table-based layout for CSS. CSS 3 will come with a nice feature called multi-column layout.


With HTML 5, we’ll actually see semantic markup for the structure of Web pages, which mean the structure will have meaning.

Image of new structure elements in html5

This will add many possibilities for the way machines read websites:

  • Search engines will have more ways to rank content, based on the structure.
  • Screen readers will have more semantic markup with which to help visually impaired people.
  • Markup for small-screen devices will become standardized.

Along with new structural elements, HTML 5 also introduces many new tags. Some of the most interesting elements:

  • The video and audio tag will bring new, semantically meaningful markup to content and allow video and audio to be streamed directly in the browser.
  • Forms will get new and improved semantics for text input and form validation.
  • The new canvas tag will have a 2-D drawing API.

HTML 5 also contains many new APIs, such as:

  • Immediate-mode 2D drawing
  • Timed media playback
  • Offline storage
  • Editing
  • Drag and drop
  • Messaging/networking
  • “Back” button management
  • MIME and protocol handler registration

Work on HTML 5 started in late 2003 and has the following timeline:

  • First W3C Working Draft in October 2007
  • Last Call Working Draft in October 2009
  • Call for contributions for the test suite in 2011
  • Candidate Recommendation in 2012
  • First draft of test suite in 2012
  • Second draft of test suite in 2015
  • Final version of test suite in 2019
  • Reissued Last Call Working Draft in 2020
  • Proposed Recommendation in 2022

This may look ridiculous (2003 to 2022 is 19 years!), but consider the case of HTML 4, DOM2 HTML and XHTML1, the three specifications that HTML 5 is supposed to replace. The HTML 5 team wants to have a test suite with which at least two browsers completely pass before calling it a day. This doesn’t mean that developers can’t start using HTML 5 before 2022, only that the specification may change during this period. HTML 5 will probably be usable by 2012, depending on how fast browser makers implement the features and distribute their browsers to users. Some APIs and tags have even been implemented in today’s browsers.

The semantic structure of HTML 5 will save developers from having to add many divs, but marking up the rest of the content correctly will still be important for having a semantic website. Last but not least, understanding the difference between block-level elements and inline elements and what every tag is for will still be very important.

Table-based layout with CSS

Another new feature will display block-level elements as tables with the help of CSS. The display attribute for the wrapper would be set to table, and the display attribute for block-level elements that are columns would be set to table-cell. Table-based layout with CSS will be more robust than the float model, in which the layout often breaks when the font size is extreme. Another positive effect is that columns will automatically be equal in height.

With the release of IE853, all three major browsers now support the styling of block-level elements as tables. It will probably be a while, though, before the majority of users actually use a browser that renders the feature as intended.

 <ul id="menu">
	<li><a href="#">Home</a></li>
	<li><a href="#">Products</a></li>
	<li><a href="#">About</a></li>
 <div id="content">
	<p>Fusce quis velit...</p>
 <div id="aSide">
	<p>Praesent iaculis commodo elit...</p>
body { display: table; table-layout: fixed;}
#menu, #content, #aSide { display: table-cell; }
#menu { width: 20%; border: 2px solid red;}
#content { width: 50%; border: 2px solid blue; }
#aSide { width: 29%; border: 2px solid green;}

The wrapper (in this example, body) is set to display as a table, and the relevant columns are set to table-cell. This even works for list elements, as the example shows (and it saves a div). This is a trimmed example; a normal structure would contain a header and footer. This would have required an extra div to contain the row with menu, content and aSide. The container that holds each row would need its display set to table-row. The container for each row is needed to get a break line after the columns.

A screenshot of how the example code look like

This example shows the above code running in Firefox.

Multi-column layout with CSS

Some CSS 3 magic will help developers arrange text in columns within an element. This will be possible in two ways: by defining either a column width or a column count.

Multi-column layout is currently supported in Mozilla and Webkit-based browsers, which prefix these properties with -moz- and -webkit-, respectively.

Column width

The number of columns displayed depends on how wide the column is set (spacing between columns is controlled by the column-gap property) and how wide the container is.

-webkit-column-width: 8em;
-webkit-column-gap: 1em;
-moz-column-width: 8em;
-moz-column-gap: 1em;

Screenshot showing an example of column-width look like

This example was created with column-width on the paragraph tag and a body width set to 495px. The code is rendered in Google Chrome.

Column count

The column-count property defines how many columns text is divided into. The width of the columns depends on how wide the container, column gaps and column borders are.

-webkit-column-count: 2;
-webkit-column-gap: 1em;
-webkit-column-rule: 1px solid black;
-moz-column-count: 2;
-moz-column-gap: 1em;
-moz-column-rule: 1px solid black;

Screenshot showing an example of column-count look like
This example was created with column-count on the paragraph tag and a body width set to 490px.The code is rendered in Google Chrome. (It looks the same in Firefox, aside from the column divider not showing.)

Further reading:

Knowing the difference between block-level and inline elements

A block-level element is an HTML tag (such as p, table, h1 or div) that generates a break line. A block-level element has five spacing properties: height, width, margin, border and padding. An inline element, such as a span or anchor, doesn’t generate a break line and isn’t as flexible a container as a block-level element. A block-level element is not allowed inside an inline element. Read more about this by checking out the links in the “Further Reading” sections throughout this article, because this is key for Web developers to know.



  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59,339028420,339292515,00.htm
  60. 60
  61. 61

↑ Back to top Tweet itShare on Facebook

Geir Wavik works as a senior consultant at Miles located in Oslo, Norway. His main focus is web technology with an expertise in programming user-friendly and accessible designs.

  1. 1

    Its a very good article for me, because i am in verge of changing my tables to divs for my site, and learned more.Thanks for the information

  2. 202

    table is still better for beginner. I often get into trouble when create overlapping multicolumn page with .

  3. 403

    I think the amount of CSS-purist elitism being spewed forth in the comments here is pretty astounding. There are numerous design inclusions that necessitate tables in a structural layout role.

    If you’re a web developer and you’ve never run across one of these, then you’re not as experienced and professional as you think you are. Those of you who -have- and dismiss them as “not that common” (like the commenter near the top in reference to vertically aligning variable height content) are even worse, since you’re ignoring the number one rule in programming (and various other professions since the dawn of time):

    Use the right tool for the job.

    Semantic code is nice. Using MVC design and separating structure, design, and behavior makes for cleaner and simpler code. Not using tables when other tags/styles can easily accomplish the same task is wonderful. Compromising on graphical design because you refuse to use the right tool for the job = failure. I like squares. You like squares. We all love squares. But you need to step back and think again the next time you try to shove one in a round hole.

  4. 604


    This is a seriously excellent article, or almost a book as another poster said. Thanks a lot for sharing this information. I am a starting-out web designer and this article really helped me!

  5. 805
  6. 1006

    Excellent article! I agree with traza because that was my reason for using tables. I have just upgraded a website admin system to divs rather than tables and the php dynamic content is now a dream and I hardly need the visual interface anymore of DWeaver, so now I can move to a php plug-in for Visual studio and cast aside these old style editors. It is great to see your web pages pixel perfect, and if it is not in one browser type then just make the adjustments for that browser only.

    Anyone reluctant to make the move to divs, just sit down and learn it, it is a pain but well worth it.
    have a DIVine time. pete

  7. 1207

    There’s this 2008 sitepoint book by Rachel Andrews which explains how to use the css 2.1 table-layout specification to create layout on divs. The short of it is represented in this article.

    I like css table-layout for getting rid of the faux column problem. I can use it to set deliberate height on divs with full background scaling and it is wonderful for (vertical) grid-like positioning and rhythm.

    But all these good new points about css table-layout are negated by the following caveats:

    1 Even with fixed table-layout, my em formatting is ignored. It seems necessary to recalculate everything back to pixels. This leads to scaling issues and a lot more calculis on my part.

    2 I just said goodbye to browser defaults with my reset.css. Now I notice that I am not familiar with the browser defaults for these table lay-outs and that good descriptions are lacking anywhere on the Net. I need more sources.

    3 Having the default column widths be set automatically by the first row is a problem to me because my headers often span multiple columns. It leaves me with great difficulties to set the width of the cells in the subseding rows.

    4 I find myself setting multiple wrappers to cope with quirks, whereas with floats i need one wrapper max (if at all).

    5 Any of the ten table display definitions stops me from pulling columns from the left to the right and vice versa. This is my major and most urgent dislike with css table layouts.
    The display is influenced by the semantics and vice versa. I need to change my html source order to change my display. To change my layout i’ll be recoding at 2 places: html & css, that or use extra classes for rtl instances. That’s not just a bump in the road or a learning curve problem. It’s a major #fail.

    All of the above has made me decide that I will not start css table-layout for positioning unless i’m dealing with customers who want a pixelperfect photoshop based website and don’t care about scaling. It seems fine for actual tables, though.

    I would loove to eat my words. I look forward to better documentation: more articles on column span, css table-layout defaults and swapping columns. Anything better than the brave but halfwit attempt by Kevin Yank and Rachel Andrew that set me on this seemingly doomed path in the first place.

  8. 1408

    The whole table v’s div debate seems to be typical of the web unfortunately. A bunch of t*ssers, come along with their heads up their own ars*s and start changing something that has been working fine for years.
    I still use tables. Divs can p*ss off. and if you dont’ like it, you can p*ss off too.

  9. 1609


    Did you wet your diaper?

    Using div tags in-place of tables is much easier and more convenient.

    The convenience increase when you take advantage of relative, and absolute positioning! Ad list layouts and header layouts and watch the use of standard table layouts go the way of the standard CRT TVs!!!

    Live the dream, learn the way of the Div!

    Also, go piss off!

  10. 1810

    Let me start by saying, this web article is ridiculously long!

    Next, the writer/coder made a good point about using list tags, but the writer/coder failed to mention how poorly is coded. Wow, talk about sloppiness when it comes to proper coding. Something smells funny!

    As for using too many div tags, there is no min or max recommendation when using div tags.

    Clean coding is important, proper use of div tags is important, proper understanding of CSS is also important.

    Use of div tags,

    div tags no no no:

    div start
    div start
    div start
    div start
    div start
    div end
    div end
    div end
    div end
    div end

    div tags yes yes yes:

    div start
    div start
    — Content Area 1 —
    div end
    div start
    — Content Area 2 —
    div end
    div end

    The above examples were written in non-code form do to the possibilities that form processor may not allow code tags to be displayed or pass through.


    Stop wining and learn how to use CSS.

  11. 2011

    Ha! Ha!

    Yes, you are right! A real professional puts the customer first, but a real professional needs have the skills to do that!

    How does he do that? By putting is pursuit of knowledge (Proper and modern coding/program) first!

    Getting the job done is important, but getting the job done properly is more important. I like to keep my customer!

    So, I put my pursuit of knowledge before my customers. Why? Figure it out!

  12. 2212

    I designed my firts web page in 1995 with notepad and paintbrush, it was made with pure html code: tables. I still use tables, I’m an old school designer, I still use a text mode editor (I dont like Dream Weaver or front page), I know a lot of CSS and Divs, but I like the old school design! and PacMan and Space Invaders!!
    Log live to the Tables
    Diseño Web

  13. 2413

    Would be nice if world would be so standard. Messing with divs you end up with css2 – that is a nice thing but I have always seen some incompatibility problems with the browsers. With tables – at least to give the main structure it is safer and you can also give classes to table entry.
    So, the flexibility that divs give may die in the css compliance of the browsers and unnecessary number of divs floating around.
    And why tables are not optimized for build? It is a form of giving a safe structure for your data where you often end up at a grid layout. That is a table. Columns and rows can be individually edited and attributed. Why not. Less flexible than div, indeed, but safer and 90% offers the same.
    And div is not optimized for anything, you have to give a number of attributes to have it done anything – in css2. It would be so nice to have all the css2 possibilities seen in the browsers and not diving in the annoyance of ‘this is a *IE workaround for this and that’ problem. Remarks are not designed to contain code. But in web world it does. Silly.
    Size of code: what about the bulk of JavaScript gadgets, comments and whatever that passes through the wire? That bloats the design.

  14. 2614

    Hi this is use full and reply to apply…..and to try….

  15. 2815

    I’m observing this “Table vs. CSS” debate, and as much as I’d like to switch to CSS, I’m not impressed with the hacks one has to resort to in order to in order to get CSS-based designs working with all browsers.

    The dismissive “It’s too haaaard” comment misses the point: I can handle ‘hard’. I just don’t want to waste my time when there’s an easier way.

    One of the arguments for CSS it that it makes the code more maintainable. Well, if you have to use all sorts of hacks to make a page look the same in all browsers, you are not simplifying the code, you are making it more complicated, which defeats the purpose.

    Also, the extra CSS code requires more bandwidth to download. Less code is supposed to be one of the arguments in favor of CSS. Kind of defeats the purpose.

    Show me the money.

  16. 3016

    Michael Puckett

    May 12, 2010 6:42 am

    web page—-
    |div|-centered content|/div|

    style sheet—-
    { align: center; }

    used | bc angle brackets won’t post

  17. 3217

    .Net Developer

    July 9, 2010 1:06 pm

    Yep, that’s true for small php web sites, but not true for big business applications, with clear design and structure, true for sites with bringing popups, messages, menus and so on from all sides and so on, but not true for a seriously app with powerful back-end logic.

  18. 3418

    this very nice articall

    good work man!!!

  19. 3619

    Well, there is some cool article(a book), that You may read:

  20. 3820

    nice tutorial.. grr888 work

  21. 4021

    Great knowledge !!!
    It’s solve my problems…

  22. 4222

    Thomas, thanks for this comment! We work in reality, not in theory.

  23. 4423

    edit: walmart should be *now* on div hell :)

  24. 4624

    good article, thanks for sharing!

  25. 4825

    Keep learning… man, lot of power HTML had and I never knew.
    Thanks for the article. After it and a quick read through XHTML tag reference, and I have a lot of HTML refactoring to do.

    Many thanks for sharing!

  26. 5026

    Sorry but I prefer for my css to be 100% browser-compatible (or close) without having to devote hours to the subject or use hacks that will die off in a year and a half just for the sake of skirting around using tables.

    When the hell did flexibility become more important than compatibility?

  27. 5227

    Excellent tutorials. Here are some of my experiences that I shared some time back.

  28. 5428

    i never thought there was a table element. thanks for sharing.

  29. 5629

    Very well written… I have been using tables for a long time but now I see reason to change to divs :) thank u

  30. 5830

    nice and useful,

  31. 6031

    nice post.i appreciate the team builder and about this blog.thanks

  32. 6232

    Dean Meehan (roozo)

    October 10, 2011 5:34 am

    Using Tables to represent data seriously limits the ability to call jquery, jFon and other layout controls. Tables are harder to manage, to have a forum or other interactive Web2.0 or 3.0 website would be a living hell to work in the first place.

    The Hacks to get CSS working on all browsers is becoming smaller every year, and normal putting in 9 lines of code will reset the CSS to make it useable accross many browsers.

    I would recommend using CSS over tables any day, and after weighing all the pros and cons you will see too.

  33. 6433

    Good Post. A dev just forwarded me this link since I advocate tables and we hire front end dev to finalise our layout (funny only takes them few days which saves us bucks!).
    We use tables for the main layout of the page such as headers, menu, side panels contents (depends on how many) and footers. Using tables for this parts is very easy to understand.
    When do we use Div? Well, we use div when we needed to use div. We use div lets say you have a comment content and it will contain like hundreds of comments if totally expanded. Ofcourse, it is very bad to use tables in this aspect. Another one is, a floater. Let’s say you have a promotion and you want to float it around the header or anywhere you wanted. You cannot do this using tables, or even put this in a table. So make use of CSS and a div if you need to put more tags in it.
    When do we use tables? If we need to lay it out structured to make more simple (KISS many new devs do not care at all) and easier to maintain and no need to use CSS to lay it out but use CSS to style it.
    As you see, my team consists of OO sw engrs. And they can focus on their strong points which is strong OO mindset. I will not let them handle front end stuff as it is easier to get a front end dev in a few days to finalise the layout.
    Good architecture, means you mix tables and div for web development.

  34. 6634

    I coded up 3 different versions of the same page (divs, tables, tables with table-layout:fixed), and then ran some benchmarks on performance and file sizes.
    The performance claims I’ve read about elsewhere on the web for divs over tables are over-hyped – I found only a 10 ms advantage for the div technique over the table technique. My div test page was only 2285 bytes smaller then my table page which would save me 1.74 MB/month of data transfer. If you have a high volume site, it might be a good reason to consider using divs. Here is a link to an article with more detail:

  35. 6835

    Thank you very much. Loved this article and completely agree with it. I am a new designer and am not stuck in the old ways of using tables. I LOVE divs and will always use them until something comes out that’s better of course ;)


  36. 7036

    good article, but u have used inline CSS in many places. We have to control the Table using only CSS and it should be used for n-number of rows and columns

  37. 7237

    Awesome article thanks for sharing!

  38. 7438

    And to add to the alignment … the above is good if you want to align the whole div in the center, but I presume @Fake Name was talking abt the content inside the div it shud be


    text-align: center;

    and not { align: center }


  39. 7639

    Maintain all the good work going by posting more informative posts. Thank you. Time effectively spent on this post.

  40. 7840

    Best article i’ve read in a very long time!
    What i thought would be another poorly written, short and boring lesson on tables vs. divs, actually turned out to be the most interesting article i’ve ever read about semantics, and it kept me reading from start to end.

    I’ll definately bookmark it for future reference, as i’m one of those lazy developers who suffers from divitis, although it’s getting better day by day since i started using HTML 5 and CSS 3.

  41. 8041

    WOW! it was amazing,
    it really changed my point of view to website layouts
    thank you so much!!! :D

  42. 8242

    Aurelio De Rosa

    April 19, 2012 3:11 pm

    One of the best article I’ve ever read.

  43. 8443

    Conceptually, using floating divs to create layout columns is just an enormous hack (and a nightmare if concerned by cross browsers issues)… I use them, but I cannot be proud.

    More than that, I’m wondering how someone could proclaim himself a “css purist”, with this kind of workarounds…

  44. 8644

    I believe using DIV just to mimic the behaviour of table is just silly.

    Simply use table when you need layout like a table!

  45. 8845

    Thank you for this article! It’s clean and clear!

  46. 9046

    hi, DIVs for me have been always better than table layouts, ohh yes, we have been programming on since a few years, however, i can tell, complex layouts need even complex divs, thats how it is.. nice post thought

  47. 9247

    Div’s can be used improperly, just as tables can. Sometimes a purely CSS solution can end up being more code and hacky to the point of being hard to understand and maintain.

    Point being, there is not an every-situation correct way.

  48. 9448

    You should see the div layout I’ve been given to fix, it will make you want to stab yourself in the face repeatedly.

  49. 9649

    From what i can understand you only coded one page, then try and scale that up to a full website with thousands of users online 24/7, and the divs over tables aren’t that over-hyped anymore :)

    EDIT: Sorry, i only read to the part where you mentioned how much traffic would be saved per month, and at that point thought to myself “Well dah, one page won’t cut off alot of the load time, but try with a full scale website”.

    Guess i was a little too quick to comment, hehe :D


↑ Back to top