Under what conditions should you choose tables instead of DIVs in HTML coding?

+1  A: 

I believe just tabular content. For example, if you printed out a database table or spreadsheet-like data to HTML.

Thomas Owens
+5  A: 

I will usually opt for tables to display form-type information (First Name, Last Name, Address, etc.) where lining labels and fields across multiple rows is important. DIVs I use for layout.

Of course the table is wrapped in a DIV :)

My understanding is that this is one of the situations where table use is discouraged - it will flip out screen readers for starters. It is preferable to use <div><label for="firstName">First name:</label><input id="firstName" /></div>. CSS can then be used to fix the width of the label elements.
Richard Ev
But isn't it even more wrong to fix width? Width should be a product of font size, esp. to account for accessibility and differences on output media. And it's more width ratios (and perhaps min/max sizes, in suitable unit) that should be defined, not absolute sizes.
And fixing the width is awkward when you have to internationalise a site and don't know how long the label will be in each language. At least using a table it will be (ironically) more fluid.
This is my problem with div layouts. Until you can make a set of divs that automatically flow like tables do I find it strange to recommend divs over tables.
@Richard, IMO, lists are better than a series of divs. The OL/LI combo is more semantically correct. @Damo, fixed width does not mean fixed height. So long as each row can expand to accommodate wrapped text, it's usually a non-issue. How do you think non-web apps handle field labels when it comes to translation?
+37  A: 

When the data I am presenting is, indeed, tabular.

I find it ridiculous that some web designers used divs on tabular data on some sites.

One other use I would have for it would be forms, particularly label : textbox pairs. This could technically be done in div boxes, but it's much, much easier to do this in tables, and one can argue that label:textbox pairs are in fact tabular in nature.

Jon Limjap
Label/Textbox pairs should use the <label> tag. With a little work _{display:block;float:left;}_ you can style all the labels in a field set to have the desired width.
Joel Coehoorn
I agree with Joel on this one. The pairing is built into the semantics (<label for="txtMyTextBox" />) and with the proper css this can be handled very cleanly
Rob Allen
While you don't have to use a table, it is "tabular data". Imagine "Field Name" and "Value" headings on top of the columns. I have also seen it done with definition lists, which express a similar key-value relationship.
Roger Pate
No, the difference is that the Label/TextBox combination allows you to present it as tabular layout if you want, or not if you want something different. Using a table *forces* it into tabular layout, making it that much harder to change it later if you decide to go a different direction.
+14  A: 

Usually whenever you're not using the table to provide a layout.

Tables -> data

Divs -> layout


Jorge Córdoba
But data can be displayed in other ways besides a grid, and to do so, with CSS, you can make <table> not look like a grid. However, I instead reserve <table> only for data in gridform. Otherwise I use <div> because fancy CSS on <table> can be tricky with cross-browser compatibility.
+1  A: 

If you would like to have semantically correct HTML, then you should use tables only for tabular data.

Otherwise you use tables for everything you want, but there probably is a way to do the same thing using divs and CSS.

Peter Stuifzand
+3  A: 

Tables were designed for tabular content, not for layout.

So, don't ever feel bad if you use them to display data.

+2  A: 

1) For displaying tabular data. A calendar is one example of tabular data that isn't always obvious at first.

2) I work for a medical billing company, and nearly all of the layout for our internal work is done using CSS. However, from time to time we get paper forms from insurance companies that our billers have to use, and a program will convert them to an html format that they can fill out and print via the intranet. To make sure the forms are accepted they need to match the original paper version very closely. For these it's just simple to fall back to tables.

Joel Coehoorn
+8  A: 

Agree with Thomas -- the general rule of thumb is if it makes sense on a spreedsheet, you can use a table. Otherwise not.

Just don't use tables as your layout for the page, that's the main problem people have with them.

+121  A: 

The whole "Tables vs Divs" thing just barely misses the mark. It's not "table" or "div". It's about using a semantic layout.

Even the div tag plays only a small part in a well laid out page. Don't overuse it. You shouldn't need that many if you put your html together correctly. Things like lists, field sets, legends, labels, paragraphs, etc can replace much of what a div or span is often used to accomplish. Div should be used primarily when it makes sense to indicate a logical *div*ision, and only appropriated for extra layout when absolutely necessary. The same is true for table; use it when you have tabular data, but not otherwise.

Then you have a more semantic page and you don't need quite as many classes defined in your CSS; you can target the tags directly instead. Possibly most importantly, you have a page that will score much better with Google (anecdotally) than the equivalent table or div-heavy page and will help you better connect with a portion of your audience.

So if we go back and look at it in terms of table vs div, it's my opinion that we've actually come to the point where div is over-used and table is under-used. Why? Because when you really think about it, there are a lot of things out there that fall into the category of "tabular data" that tend to be overlooked. Answers and comments on this very web page, for example. They consist of multiple records, each with the same set of fields, and stored in a database table. The exact definition of tabular data. So an html table tag would absolutely be a good semantic choice to layout something like the posts here on StackOverflow. And this same principle applies to many other things as well.

Joel Coehoorn
Agreed. Years ago when I was first stepping away from table-based layouts, I had the whole "use divs" mantra drilled into my brain. The resulting code was even less semantic. Once you get to know HTML and all it offers, you learn to write meaningful code and it all becomes simple.
+1 It is nice to see this expressed so well.
Andrew Hare
Funny: I re-read it because you upvoted and had to go back and correct my own grammar :(
Joel Coehoorn
However, if you have to use a non-semantic div to get your layout, but it would be easier to use a non-semantic table, use the table. If you're forced to break semantic purity for layout, use whatever works best for your scenario.
True, with the exception that if you're approaching your semantic layout goal, an extra couple divs are going to be less disruptive to the semantics of the overall structure of the layout than a table is likely to be.
Joel Coehoorn
I wonder why this 5mo old post is getting so much attention today?
Joel Coehoorn
It's interesting to see where the big sites use tables. Get the WebDeveloper plugin for Firefox and use the feature that lets you outline tables. Then go to the big sites. You'll see tables in some interesting places. For example, Amazon has a table that shows a variable number of products depending on how wide the window is stretched. Almost everything is best done as a div, but some tricky cases are better with a table when you consider old browsers.
The large websites such as Amazon and many others will confirm that being backward compatible along with engineering for the future of the web are equally imperative. Surely you wont see Amazon telling their users to upgrade their browser, its almost ridiculous if not self-destructive if they attempted to do such a thing. Obviously a lot of your 'tableless' evangelists, who stick to the notion of forward compatibility without paying mind to older and limited browsers/clients, have not worked on high traffic and volume websites where reverse compatibility is a must.
drlouie - louierd
I must disagree about the StackOverflow uses of table to separate the post and the comment. Basically, I have a thumb rule: if the table have only `tr` tags, use `div`s instead.
@Mendy - I'm not saying StackOverflow uses them correctly, but I am saying that if they _wanted_ to take the time to build it out that way, this is the right kind of content for it.
Joel Coehoorn
@Joel Coehoorn Even though I agree on the DIV abuse I would stick to TABLES on TABULAR data. Though SO's layout today may be a bit on the tabular side, the DATA itself is not TABULAR. So tables would be out of the way.
@Frankie - thanks for just proving my point ;)
Joel Coehoorn
@Joel: I've often thought about just what you're saying with using <table> to display data even in non-grid format. I'm pretty good with CSS, but it can be tricky to achieve cross-browser compatibility with <tr> and <td> elements. To me, <tr> seems give me the most problems (is it just me??). However, I still mentally masturbate on whether to use <table> for data in non-grid format.
@JohnB - I'm not saying you _should_ use table for non-grid layouts. Just that it might be an acceptable choice from a _semantic_ perspective more often than we give it credit for.
Joel Coehoorn
+8  A: 

As many posters have already mentioned, you should use tables to display for tabular data.

Tables were introduced in HTML 3.2 here is the relevant paragraph from the spec on their usage:

[tables] can be used to markup tabular material or for layout purposes...

"or for layout purposes" - that kind of busts that myth that tables were never intended for layout by the HTML designers
Matthew Lock
+3  A: 

I use tables in two cases:

1) Tabular data

2) Any time I want my layout to dynamically size itself to its contents

17 of 26
+3  A: 

If your data can be laid out in a two-dimensional grid, use <table>. If it can't, don't. Using <table> for anything else is a hack (though frequently not one with proper alternatives, especially when it comes to compatibility with older browsers). Not using <table> for something that clearly should be one is equally bad. <div> and <span> aren't for everything; in fact, being completely meaningless on a semantic level, they are to be avoided at all costs in favor of more semantic alternatives.

Sören Kuklau
Well, table is also has no explicit semantic value, nor much implicit.It belongs to structural tags, not semantic ones. Granted, div and span are even more abstract, being anonymous block/inline placeholders more than anything else.

One other use I would have for it would be forms, particularly label : textbox pairs. This could technically be done in div boxes, but it's much, much easier to do this in tables, and one can argue that label:textbox pairs are in fact tabular in nature.

I see that a fair amount, especially among MS developers. And I've done it a fair amount in the past. It works, but it ignores some accessibility and best-practice factors. You should use labels, inputs, fieldsets, legends, and CSS to layout your forms. Why? Because that's what they are for, it's more efficient, and I think accessibility is important. But that's just my personal preference. I think everyone should try it that way first before condemning it. It's quick, easy, and clean.


Just to continue the question:

Can you use tables for grid layout?

+1  A: 


Is the layout tabular data? No, while it was standard a few years ago it's not now :-)

One other use I would have for it would be forms, particularly label : textbox pairs. This could technically be done in div boxes, but it's much, much easier to do this in tables, and one can argue that label:textbox pairs are in fact tabular in nature.

I tend to give the label a fixed width, or display it on the line above.

+8  A: 

I would make a distinction between HTML for public websites (tables no-no-no, divs yes-yes-yes) and HTML for semi-public or private web applications, where I tend to prefer tables even for page layout.

Most of the respectable reasons why "Tables are bad" are usually an issue only for public websites, but not so much of a problem with webapps. If I can get the same layout and have a more consistent look across browsers by using a TABLE than a complicated CSS+DIV, then I usually go ahead and aprove the TABLE.

+2  A: 

I can see the argument for tables for forms, but there is a nicer alternative... you just have to roll up your sleeves and learn CSS.

for example:

New Blog Post Title: Body:

You can take that html and layout the form either side-by-side labels, or labels on top of the textboxes (which is easier). Having the flexibility really helps. It's also less HTML than the table equivalent of either.

For some excellent examples of CSS forms, check out these excellent examples:




Ben Scheirman
I'd mark this answer up twice if I could. The second link had the exact answer to a problem I was having. Thanks!
+1  A: 

@Jon Limjap

For label : textbox, neither divs nor tables are appropriate: <dl>s are

+2  A: 

Tables are used for tabular data. If it makes sense to put it in a spreadsheet then use a table. Otherwise there is a better tag for you to be using such as div, span, ul, etc.

Matthew M. Osborn
+8  A: 

Ideally HTML tables should only be used for tabular data. However tables are also the simplest way to create some specific types of grid-based layouts, which are hard to emulate in cross-bowser compatible CSS. This article describes the issue in more details.

The CSS spec does support grid-based layouts equivalent to table markup using the display:table|table-cell property. However this part of the spec is not supported in Internet Explorer (although all other modern browsers support it.)

This leaves you with a dilemma: Either use HTML tables for layout - which is bad style because it is presentational markup. Or try to emulate a grid with floats and abolute positioning in CSS. This often turns into convoluted and hard to maintain CSS.

If accessibility or semantic purity is important for you, go with pure CSS. If you just want your layout-grid to work without too much hassle, you should probably use a table.

This is one of very few comments that actually makes a good point, tables are exactly the ONLY tool for any layout management (similar to Java AWT/Swing, or any other constraints-based GUI layouts pieces).
+6  A: 

I used to do pure CSS but I abandoned that pursuit in favor of hybrid table/css approach as the most pragmatic approach. Ironically, it's also because of accessibility. Ever try doing CSS on Sidekick? What a nightmare! Ever seen how CSS-based websites are rendered on new browsers? Elements would overlap or just don't display correctly that I had to turn off the CSS. Ever try resizing CSS-based websites? They look awful and often detrimental to the blind if they use zooming features in the browser! If you do that with tables, they scale much better. When people talk about accessibility, I find that many have no clue and it annoys me because I am disabled and they aren't. Have they really worked with the blind? The deaf? If accessibility is a main concern, why the hell are 99% of videos not closed captioned? Many CSS purists use AJAX but fail to realize that AJAX often makes content inaccessible.

Pragmatically, it's ok to use a single table as a main layout as LONG as you provide the information in a logical flow if the cells are stacked (something you'd see on mobiles). The CSS theory sounds great but partially workable in real life with too many hacks, something that is against the ideals of "purity."

Since using the CSS with tables approach, I've saved so much time designing a website and maintanance is much easier. Fewer hacks, more intuitive. I get fewer calls from people saying "I inserted a DIV and now it looks all screwed up!" And even more importantly, absolutely NO accessibility issues.

Yeah, I've found that scaling the text up is not handled well by many DIV-based sites. Tables handle that better.
The blind use visual zooming features in the browser? (What browsers have non-visual zooming?)
Roger Pate
+2  A: 

On this subject, I thought this site was pretty funny.

Especially since the site itself uses tables for layout.
Robert Harvey

When ever a page containg tables is loaded by any browser it takes more time for the browser to render properly the tag. Where as if the div is used ,the browser takes less time as it is lighter. And more over we can apply the css to make the divs appear as table,

The tables are normally heavy wieght and div are light weight.



(-1) plain misleading...
Eran Betzalel
This site is about providing meaningful answers and solutions, rather than "cryptic links" you have to click to get the answers. Keep the answers on this site please :-)

Divs are simple 'divisions', they are mean't to be used to group sections of the page that are in a semantic sense linked. They carry no implicit meaning other than that.

Tables were originally intended to display scientific data, such as lab results on screen. Dave Raggett certainly didn't intend them to become used to implement layout.

I find it keeps it fairly clear in your mind if you remember the above, if its something you would normally expect to read in a table, then that's the appropriate tag, if its pure layout, then use something else to accomplish your needs.

Guy W

It is clear that the DIV are used for Layout but It happened to me to being "forced" to use spreadsheets to do a grid layout within a div structure for this reasons:

the addition of percentage values did not allow a proper alignment with the div, while the same values expressed on cells of tables gave the expected result.

So I think that tables are still useful not only for data, but also for the situation above, on top of that, tables are still W3C compliant browser and alternative browsers (for the disabled for example) interpret theirs correctly.

Amirouche Douda