Why Not Use Tables For Layout in Html

Why not use tables for layout in HTML?

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.

Why is using tables for website layout such an evil

A few additional points:

• Don't be a fanatic about it. CSS isn't perfect, and there are some things that can be done much easier with tables. So if you need to, put a little table in there. It won't kill you.

• The major "evil" of table-based layouts was the kind of deeply-nested mess that used to be the only way to get precise control over the page. You would have tables within tables within tables, and transparent images strategically placed to control spacing. I think this is pretty rare nowadays, and CSS will let you clean up 90% of this mess.

• The "semantic web", where tags are there to give meaning to the page, not to describe the layout, is a good goal. However, the current version of HTML doesn't go very far toward reaching it. As a result, you will ALWAYS have plenty of tags in your pages that are just there for layout, with no other meaning. That doesn't mean you shouldn't try to separate content and layout as much as possible; it just means you won't get there 100%.

Why _not_ use html tables for layout

Implementing your layout with divs, spans, etc, offers a ton more flexibility over tables. Consider floating, auto wrapping of block content vs. horizontal scrolling, specifying where an element should exist on a page, etc. Content is just plain easier to manipulate via CSS when not using tables.

When using tables you're pretty locked in to a strict structure.

Now that doesn't mean it's absolutely the wrong thing to do. From your information I'd likely stick with the theme of the application for consistency sake and implement using tables. Make the best choice for the situation vs. following "the rules" on what's popular right now.

Hope that helps!
Ian

Why not use tables for layout in HTML?

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.

Can tables be used for layout now that accessibility options exist?

In short, it is (and has always been) possible to use tables for layout with little or no accessibility impact. However, you are making more work for yourself.

If you use a CSS layout with divs, sections, main etc. you only need to think about ARIA landmarks for accessibility.

If you use tables for layout, you have to consider nullifying the table roles, then adding HTML5 semantics and landmarks.

NB: ARIA is not intended to replace regular HTML semantics, it is intended to add semantics for applications that are not (yet) supported by HTML. Oh, and there are no "accessibility tags", but HTML does include tags that help with accessibility, and ARIA adds attributes that help describe functionality.

Should Tables be avoided in HTML at any cost?

No - not at all. But use tables for tabular data. Just don't use them for general layouting.

But if you display tabular data, like results or maybe even a form, go ahead and use tables!

Are tables in HTML supposed to be bad? Why is there so much talk about tableless CSS?

Here's a writeup of some reasons: http://phrogz.net/css/WhyTablesAreBadForLayout.html

I personally think the main reasons why tables for layout are bad are:

1) Being unflexible when you want to redesign / use multiple designs. If you avoid using tables for layout, you should be able to change the design of a site by just changing the CSS. If you use tables, you will probably have to edit the site's HTML when you are moving things around.

2) Being semantically incorrect. Tables are meant for tabular data. If you use them for layout, you are using them in a way they are not originally intended for. This doesn't cause problems for most users, but it's a somewhat bad coding style which can affect some users such as visually impaired people who use screenreader software.

Is it ok to still use tables?

If you're presenting tabular data, it's fine to use tables. If you're doing layout, it's usually easier and lighter to use a few divs (and use a CSS framework like YUI or Blueprint) to do your work.

---

Related Topics