Here’s a new one for the debate regarding semantic tableless CSS-based design versus old-fashioned tables-for-everything HTML.
Let’s say you design a great site with floated DIVs, negative margins, semantic tags, all driven by well-formed CSS free of browser-specific hacks. At this stage you’re quite proud of the code quality, and all is well with your world.
Then along comes the request: it now needs to be multilingual…
Functionally, that’s not a problem. You pick your method (a folder per language, or a session-based locale with strings in a database, etc), and sooner or later you have a site that is operational in more than one language.
However, if one of those languages is Portuguese or worse still French, unless you’re a veritable CSS genius, you now have a broken layout. Strings of content that previously fitted nicely between a logo and a login form are now twice as long and all your floats are appearing in the wrong place (or not at all). Wider buttons push floats below other floats, etc. Anything where you assumed that some text would be a certain maximum length, and placed other elements alongside it in some fashion. Firefox tends to cope with this sort of thing better than IE (especially IE6), but you’re likely to find problems in all the current browsers.
At this point you have three choices:
1. You spend time recrafting your CSS so that it can cope with much more verbose content (which could well push you beyond commercial deadlines – good CSS takes time – and you may come up against problems you simply don’t know how to solve)
2. You throw your rattle out of the pram and rebuild the site to be completely table-based (which is guaranteed to work but could take at least as long, will screw your SEO and the shame may lead to deep psychological problems)
3. You take the hybrid approach. You look at the specific areas that are breaking, and introduce the minimum number of tables and table cells that it takes to stop them breaking.
I like pure tableless CSS layouts as much as anyone, but I’m also pragmatic. You’ll have guessed from the way I phrased the options that when I faced this issue, I took option 3.
In fact I think there’s a lot to be said for hybrid coding, especially when you’re up against tight commercial deadlines. You could easily spend days sorting out multi-column floats and partial clears, when one table could mean the difference between meeting and missing a deadline.
My Snorkel Shack site is an example of hybrid design – it uses a table to define the columns, but is still semantic (header tags are used properly, etc), and it does alright in the search engines. On the other hand, my Ta’Qali Crafts Village site is fully tableless, but even though it’s a simple layout, the page template definitely took longer. Of course, with both of these sites being personal projects, I had the luxury of no deadlines.
So let’s hear it for pragmatism. Hybrid designs don’t appear to suffer in the SEO stakes, as long as the use of tables for layout is kept to the absolute minimum, and as long as other tags are used semantically (headers, lists, etc). If you’re the kind of designer who likes perfectly-crafted CSS but find it sometimes just takes too long, give yourself a break. A table a day keeps the deadline at bay.