I started trying to learn the Pure CSS methods. But I kept banging my head against browser issues that, even with hacks, are actually quite a pain.
Do you validate [validator.w3.org]
your pages? I cannot express how must easier
this makes developing with CSS only, and my guess is that 90% of cross browser issues automagically disappear. If you have to apply hacks, look for another approach.
1 - Is CSS really worth changing methods?
As a recovered table addict, absolutely.
2 - Will a SE spider really see the difference?
Questionable, but the real effect is not so much SE's, it's devices
or clients. As mentioned, mobile devices, screen readers, and especially devices that haven't even been invented yet - all will benefit from using semantic
markup (next. . . )
3 - What am I not considering?
Semantics. I believe one of the most overlooked Important Things about building documents is we've forgotten what they taught us in high school for our essays, the idea of document structure (heading, introduction, subheading, paragraphs, lists, conclusion.) This is how people digest information, this is how you write essays, this is how you build documents. When you surround content with a <p>, the device reading it knows it's a paragraph. <h1>This is the page heading,</h1> which tells us what the document is about. And <table><tr><td>this is tabular data, a two dimensional set of intersecting data values.</td></tr></table>
<td>This is my content and</td>
<td>New! get it while it lasts, $20 off unrelated widgets!</td></tr>
<tr><td colspan="2">now my wraparound message has my ad in the middle of it. That's not good.</td>
Reads like this (apologies in advance if it's not entirely correct . . . )
"table data" This is my content and "table data" New! get it while it lasts, $20 off unrelated widgets! "table data" now my wraparound message has my ad in the middle of it. That's not good.
Another important reason is the basis for using CSS based layouts - separating content from markup. With tabled based layouts you have a lot of in-document markup that is not relevant to the page (CSS can do this too, look for "div-itis" here - it's the same problem as table based layout in that developers use "div" for everything when a semantic container is a far better choice.)
When you use semantic markup and take away the style sheets, you should see a simple source code where each tag represents the content it contains - no <br> (or <br/>) for spacing, no or other visual tricks - those are managed by CSS. If you keep empty elements
to a minimum (<table> for layout, <br>, <div>, <span>, these have no semantic value) Your document becomes easier to read, and affords context to the content. I have no proof, but I have a pretty strong feeling that this also affects document relevance.
This also allows you to leverage another important point, the concept of SOC (Source Ordered Content.) An item can be at the bottom of the page in display but if you want it at the top of the source code for SE's, you can position it accordingly with CSS. As we know, "what's up top" is often most important as it's rumored SE's may not consider "all" the document relevant. * * You can apply SOC with tables too, but it takes a lot of ingenious tweaking and most often heavily nested tables to move the same content to the top.
Last is one that will hit home for most of us - once you get past the learning curve, it's far easier to maintain. A table "locks" you into a set of rows and columns. To reformat the page, you need to modify the layout table structure, which means going into every page and modifying it. With CSS, most of the time you can just tweak the CSS.
It also allows you to use the exact same content for a mobile site version - instead of developing a whole new site, if a mobile device is detected you use the same content but the CSS and images are located on a mobile subdomain. You can't really do that with this:
<table width="1100" cellpadding="0" cellspacing="0">
people also say that a CSS layout will display quicker than a nested table layout. that is true, but if you've only got a simple table with a few cells, then that is not a good reason either, because it will make no difference at all.
This was really an eye-opener for me - the concept is the browser must render from <table> to </table> before it displays. It can be a simple table but if it's socked with content, it won't render as quickly. I've seen it happen even with a single cell container table.
I am not a purist, nor an "expert," but it's a decision you just know is right when it hits you - like finding God or the first time you hook a 2 pound trout (take your pick. :-) )