What's wrong with nested tables?

I've been reading in a few spots lately where people really look down on nested tables as a design technique, but they don't say why. Anybody care to explain why nested tables are so inherently evil?

 

"Inherently evil" is an interesting way of saying it. I don't think I would go so far as to call nested tables as "inherently evil". The short answer to the question is people have discovered a better way of laying out web pages.

The longer answer is, by using cascading stylesheets (css) for presentation it has made the use of tables for layout not necessary anymore. Tables now can be used for what they were intended for in the first place, tabular data. The layout of the page and site can be controlled by a stylesheet that can determine where the menu is suppose to go and where the content goes etc. Then when someone changes their mind about the layout of the site in theory the whole site layout and presentation can be changed by simply changing the stylesheet.

The other added benefit about moving away from tables for layout is that the required code to layout a page is a lot less, which speeds up download times. So the web does not end up being quite as slow for those people that are still on dialup, and yes there are people still on dialup.

I am sure there are others that have more to say on the topic. As a side note, there are still occasions when you need to use tables for layout still. Often because a certain web browser does not follow web standards very well .

 

Are you saying that tables cannot be styled with CSS?

J.D.

 

Right, CSS can control layout, that I understand. I use CSS to control my fonts. I guess I should have been more specific with my question by asking "what negative impacts on SEO do nested tables have?". I can see how a few extra lines of code for the tables would cause a slightly slower page load, but unless you have a zillion tables I don't see how it's that much more than by using CSS.

Making sitewide layout changes is easy enough by using include files for non-content areas.

So, are there any significant drawbacks to nested tables in terms of SEO? I just can't see any other serious drawback to them, but then again I'm not the brightest chap

 

If tables are styled properly (i.e. no bgcolor, valign, etc), they won't be much larger than div's - a layout table is typically a couple of rows and a couple of columns, which adds only a couple of dozen bytes to the page size. From a SE's perspective, tables or divs or anything else doesn't really matter - they just strip off anything that is not text. Smart SE's (or those that pretend to be smart) may look at the styling/colors/etc in order to figure out things like links in background color, but I'm not sure they do this nowadays too much (thinking of things like animated menus built with initial display property set to none).

J.D.

 

In general tables are stupid. See why with the scenario here: http://www.hotdesign.com/seybold/index.html

 

That is brilliant! I've been looking for something that puts it so boldly and succinctly for a long time.

Cheers!

Chris

 

A rule of thumb - stay away from docs that mix up comics and technical advice.

* Tables will work fine with many PDA's and are included into XHTML Basic (designed for PDA's, cell phones, vending machines, etc)

* Tables will not take much longer to download - compare the size of <div></div> vs. <td></td> per cell; so, what you really add is <tr>'s

* Tables will not take longer to render - depending on your layout structure with divs, there may be more for the browser to do in order to render div's (e.g. it will have to examine and may be shift inline content, some of the blocks, etc)

* Makes no difference for SE's - they strip off tags anyway

A good layout design will use anything to make it easier to maintain - tables, divs, whatever. Tables have something that div's don't - rows, which means that you can guarantee the size of two adjacent cells (setting height to 100% doesn't always do the trick). Another important difference is that tables will grow, even if you set their width and height explicitly - div's will overflow and their content will be visible outside div's in this case. This makes tables perfect for resizable sites.

J.D.

 

J.D, I am not aware of such problems. My web site is also tableless, and when resizing fonts or resolutions, I have not experienced such problems.

And what do you think about this? http://www.evolt.org/article/Tables_or_CSS_Choosing_a_layout/25/21429/

 

You have to admit, it makes the job for spiders a little harder, sometimes a lot.
Unless you don't care if SEs love you or not, tables are for tab data. It's like using CSS for data, they weren't intended for that.

Still, it's true that it's often not worth switching because it makes difference, but very little IMO.

 

And my last resource to this issue: http://www.davespicks.com/essays/notables.html

 

What makes you think this way? All a SE parser has to do is to strip off the tags and analyze the resulting text fragments.

J.D.

 

Tables don't print as well: use media print and set it up.


I have to agree 100% with J.D.

One thing I never get is people saying "Tables are meant for tabular data"

That may be what their original purpose was, but who cares?
Computers were originally designed to do math and print out text.
Choo choo trains were originally designed to carry freight.
cars were originally designed to get from A to B, not for racing or off roading or pulling 40 foot trailers.
Microwaves were originally used for transmitting data, not heating food.

Oh, I need a structured layout, but it isn't numbers, so I can't use it????

If you don't use one table for the skeleton of a page, instead section the page and stack them so they render one after the other, there is almost no difference in rendering time.

I can't believe how much time I wasted when I started coding a couple years ago - big time CSS fanatacism influencing me and I joined in, and I would spend dozens of hours trying to get a table like structure that worked in all browsers. I am talking about a header with floated R and L image/div, and a sectioned div in the middle.

It was a nightmare, and ultimately an exercise in futility.

If you are starting out in CSS, use bloody tables until you get used to what CSS is for.

There is no deprecation in the foreseeable future for tables, they are used massively with xml, and you better know how to use tables if you ever plan to use CALS.

Use title tags, etc if you are worried about text readers, and set your nav to use the alt key to skip large junks of code that are meaningless.

I bet I got delayed by month's and month's by trying to never use tables, and cross browser layouts can still be a nightmare, with all the hacks you have to use.

CSS was never meant to be hacked.

Wait untill browsers are more on the same wavelength before trying to do everything in CSS.

Try to meet deadlines when you are fighting with a float right and placing images here and there.

Try and get someone else to understand what you have done when they look at it later, even yourself.

Thank you, I only know half as much as I think I do LMAO!

 

Technically, it's illeterate to say Tables vs. CSS - what it really should say is "Table Formatting vs. CSS Formatting". This means that use of any HTML formatting (e.g. bgcolor, align, valign, etc) is discouraged, whether with tables or with any other HTML elements. It *does not* mean that use of tables is discouraged.

There's a reference to W3C guidelines that the article makes, which sounds very convincing for most people:

If you follow the link, though, you will see that this point is mostly about table linearization (what makes it friendly to screen readers) and if tables can be read easily by screen readers, then they fall into the "unless the table makes sense when linearized" category.

J.D.

 

So far I know, search engines have to parse the HTML code of your site to find the relevant content. If your code have errors, search engines might not be able to find everything on your pages.

Many search engine crawler programs obey the Markup standards. They only can index your web site properly, if it is compliant to the Markup standards. If there's a mistake in your web pages markup, they might stop crawling your web site and they might lose what they've collected so far because of a bloody error.

What about that?

 

How's this relate to tables, again?

 

I am all for semantically correct, valid mark-up.
That said, I went to Google, and typed the first thing that came to mind:
http://www.google.ca/search?hl=en&q=fast+cars&meta=
Fast Cars

No doctype, thick, thick javascript and thick, thick tables.

I definitely do not endorse this type of stuff, but the fact is that I see so many pages ranked top or 1st page in results that have no doctype, and every link and font and b and td tags inline, that I really wonder if it makes any difference whatsoever.

You are doing yourself a huge favor by being forward compatible, and having power to maintain, and design your site that doesn't come the traditional way.

Facts are facts, though, it does 'the cause' (LOL) no good to say things that are obviously