I should add that I am a very experienced programmer but a novice to website design ...
Fred, designing with tables has become a bit like writing code that relies on GOTO
There is absolutely nothing wrong with using a GOTO. Except that it's rarely ever necessary and, unlike more structured elements, careless use of GOTO can very quickly lead to sloppy results. The GOTO doesn't make you write bad code, but it certainly encourages it.
In a similar vein, many people believe that using tables as design elements encourages structural flaws, many of which have already been mentioned in this thread. Nesting tables is bad and slows down browser rendering, they say. Using table columns introduces the potential for non-linearized content, they claim, so that screen readers (and SE spiders) don't read content in the same order as do people sitting in front of a screen. The list goes on.
They're right, too. Those are, indeed, design mistakes that we should avoid. They're not caused
by tables, however, even though they can sometimes be encouraged by using tables.
Any browser that can't quickly render an outer table because it doesn't yet know the size of an inner (nested) table, is going to have exactly
the same problem with nested DIVs. Browsers don't suddenly become prescient just because we switched to a different HTML element, after all. And non-linearized content is certainly easy enough to create with DIVs -- just introduce a float:right and screen readers are guaranteed to suddenly see things in a different order than sighted visitors. With one possible exception, I honestly can't think of any complaint against tables that isn't equally true of DIVs. Both are simply containers and design problems are caused by the way we use them, not by the containers themselves.
The one exception?
When we start reading an article in Reader's Digest we don't usually expect to find large spreadsheets embedded on page three, and similarly, when we open a spreadsheet we don't expect to find a whole article resting in cell B7. It's a matter of expectations, which in turn and over time, becomes a matter of semantics. Strictly speaking, tables should be used for tabular data.
Even here, however, it's a question of whose
expectation are being explored. It's certainly not the expectations of the search engines, as any quick examination of some highly competitive SERPs will quickly attest. The pages that have won their way to high rankings don't seem to eschew tables as design elements, after all, or insist on purely semantic structure. If using tables had any measurable effect on search engine rankings, we'd be seeing very different SERPs than what we do. That isn't just logical, it's empirical.
(We shouldn't forget, however, that expectations are always subject to change. Search engines are interested in relevance, not semantics, and with most of the World Wide Web still sitting inside tables, they're going to rank pages accordingly. Should tables become less ubiquitous, however, and semantics be shown to lead to greater relevance, it might WELL be worth revisiting what search engines expect. Today, there's ample evidence they don't care. Tomorrow, they might.)
The crusade against GOTO statements started in the Sixties, but when I started programming in 1980 there were still a lot of language implementations, including MS BASIC and pretty much all machine languages, that nonetheless relied on GOTOs. We didn't have structured loops or block-level conditionals, and no useful program could be written without using a GOTO. The languages didn't enforce structured design, so good programmers had to take it upon themselves to ensure they did it right. Bad programmers, of which there were many, cooked a lot of spaghetti code.
In my opinion, Fred, that's pretty much where we sit today in terms of web design.
We already know that tables, when used as design elements, tend to encourage sloppy design and too quickly lead to flaws, especially for accessibility. Just as in 1980, however, we're not quite ready to throw them away because -- in too many instances -- we don't yet have equitable replacements. As you delve deeper into CSS-2, you'll discover there are a lot of things we can do with positional DIVs that can eliminate unnecessary tables. But there's still some few things we can't yet do, not without equally distasteful browser hacks or design compromises.
Now, as then, it's up to good
designers to take it upon themselves to make sure they avoid the flaws in spite of the tools available. For a good long time yet, I think that's going to be true whether you opt for tables or for DIVs.