I am a Winforms and business engine developer who is using asp.net for the first time in over 2 years, and in that time I have noticed a few convention changes.
What is the logic behind the anti-'tables for layout' movement?
Is it to allow css classes to be used to handle layout, and if so, should this really be an issue on pages you are fairly sure will remain static, or is it just considered 'ugly'?
There are a number of reasons. One reason is accessibility...layout tables do not add semantics to the content so screen readers have trouble with them. So only use tables for tabular data.
Here are a few points that answer the question in more details
It makes accessibility hard. Imagine you're a text browser and you want to read out loud the content of the website to blind persons. Most Table-based Layouts tend to be very hard to scrape and to "understand" for a machine.
There IS a lot of elitism/politics/fanaticism going on in these discussions of Tables vs. CSS, but on a large scale, CSS Layouts are cleaner than Table-based layouts.
Theoretically, they are also easier to maintain. Say, you want to move the navigation from the left to the right? Sure, just change one CSS file and you're good. But then again, this usually falls flat on more complex websites where the CSS are often deeply nested and so complex that changes are not easy, whereas templating systems make table based layouts not completely unmaintainable.
There's a pretty good article on sitepoint which puts designing a page in tables vs css head to head. It's a pretty interesting read and highlights some of the major pitfalls for the designer / developer when using tables such as mangled source code with tables, extra source code is often required and future changes are inevitably complicated.
A few additional points:
Don't be an 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%.
Honestly, don't worry that much about using tables. Even some of the best, most semantically correct people advise using tables if it's easier for the flow of the document. Just use what works for - the dissadvantage to using tables isn't all that great.
I highly recommend reading the book Designing with Web Standards. It suits designers, developers and people with a more business oriented role.
The idea is that marking up the content/meaning of the page is a better thing to do, not just because it makes it easily modifiable and styleable but also (possibly more importantly) because it improves accessibility, for those using screenreaders, etc (and for search engines!). Read Dive into Accessibility sometime. [And if you have tabular data, you should use a table of course.]
Although "try to use CSS, not tables, for layout" is a very important rule that you should try to follow as much as possible, ultimately, "doing the right thing" has some cost, and when it gets too high, you should reconsider your priorities. See http://giveupandusetables.com/
With support for newer CSS display properties in IE8, this debate about tables vs CSS might soon end. Since it's easier and sensible to think of layouts in the grid/table format, the availability of table, table-row, table-cell, table-caption, table-column, table-row-group, etc, as CSS properties will ease layout implementation significantly.
This article has a detailed overview.
Its worth mentioning that <table> tags are still legitimately used when displaying tabular data. The rule of thumb I use is if I'm displaying something that could easily live in a speadsheet, then a table tag is the way to go.
This may not be right on the topic but the most frequent problem I have with CSS layouts is that they can be difficult to set up so that they always stretch the parent node instead of just overflowing it. This becomes even bigger pain when you hit one of the not very rare instances of IE doing something completely different than FF. Fixing this mess with a table is usually easier and more compliant than various JS workarounds you would be otherwise forced to use.
Most advantages (faster, no spacer.gif, accessibility, content vs mark-up etc) are mentioned already, but it surprises me that nobody mentions that css can do stuff tables just can't or is at least easier.
Furthermore, it's just a thing of using the right tool for the right job. Tables are for tabular data and css is used for styling your content. What people tend to forget is, you can also style your tables ...
The problem is that browser support is lacking. Therefore people use hacks. Therefore browsers interpret css differently to accommodate those hacks. It's a never ending circle.
One of the main points of criticism of table-based layouts is that they are rigid. They were used to create pixel-perfect pages across all browsers. The price for this is rigidity, which harms accessibility. A layout design for a 800x600 pixel screen might cause someone with a wide-screen HD display to have to really squint to read everything. When a visitor forces an increase of the font size in the browser, it breaks the layout, sometimes quite badly.
A CSS-driven layout is flexible and can be used to create a layout that will look nice (and similar, but not the same) at any screen/font size. The improved internal structure also helps screen readers and other accessibility tools, as well as mobile platforms/devices.
The table tag is not deprecated and still has a role to play in CSS driven layouts: It should be used when displaying tabular data (like in a spreadsheet). For this, it is perfect - but it should no longer be used for page layout.
Honestly, the anti-table crowd are often guilty of simply being standards nazis. The fact is that humans have been using tables for layout since "leading" involved using actual lead.
The primary argument against tables is accessiblity; and that's an important topic. However, CSS is just a band-aid solution to the real culprit: HTML is a horrible markup language!
If HTML was never supposed to be for layout, then why do we have <center>, <b>, <u>, or <i>? Why don't we have a <story> tag to semantically group paragraphs with? Why do we have 6 heading tags?
We need to stop pretending HTML is strictly semantic when clearly it is not. While CSS is good at implementing presentation, it's not so good about defining it. If it were, we wouldn't need div soup to do a 3-column layout. What really should be happening with HTML5 (but, of course, isn't) is to have layout tags with clear roles, and use CSS to clarify what those tags do.