Herenvardo - 5:58 pm on Aug 19, 2008 (gmt 0) I'll try to mention the main arguments on the topic (at least those I've heard about): Accessibility Cross-browser compatibility Ease of authorship Maybe I'm missing something, but these are the points that come to my mind now. In summary: it's only you who can check your needs and figure out which is the tool that better suits them. Hope this helps. Regards,
'tables are for displaying data'
Indeed, they are. And knifes are for cutting things, and screwdrivers are for puting and removing screws... yet I have found myself, when lacking a screwdriver, using a knife to remove screws and, know what? It worked ;)
I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables.
I have been experimenting with CSS for the past few weeks (just to find out what could I achieve with it that would work cross-browser) and yes, it will take more effort to create a page using CSS than using tables (in the layout aspect). However, it should be later easier to maintain/modify a page that uses markup only for logical structure, and CSS for layout+formatting. At least in theory: that still depends on the overall design practices applied.
In short, I'm thinking of making life a lot easier by simply reverting to tables for formatting, with a little CSS to tweak it. Is this really such a crime?
Of course, that's not a crime by itself. As long as this doesn't lead to other crimes; which mostly depends on the audience and needs of your site.
That's a quite interesting one: yes, indeed, separating content from presentation makes a page more "semantic". And, what's the point of it? I find the concept of semantic webs quite interesting, from the theoric view-point, but I have yet to see any practical benefit of making a site "semantic". Until I see that, I'll consider semantics as a philosophy rather than an argument.
Yet again, separation of concerns can be a good tool to improve accessibility; but it is not the only tool, nor is it a fool-proof tool: a site can be made completelly accessible while using tables for layout (and even font tags, for that matter); while other sites can be using only CSS for layout and still be completelly unaccessible. Of course, there also are some CSS-based accessible sites, and some table-based unaccessible sites. Both <table>s and CSS are tools. Indeed, they were made with specific purposes in mind, so they are likely to suit such purposes; but at the end the way you use them are totally up to you.
One easy alternative to CSS for accessibility is server-side negotiation: just check which kind of browser is requesting your page (ie: a visual desktop browser, a screen-reader, a hand-held device integrated browser, etc), and serve appropriate content for each relevant sector.
Another mechanism is to use CSS to its best, even while using tables; like adding a sheet only for aural media that "hides" all the navigational stuff (or that puts it on the end).
Finally, if you are using XHTML, you might try to go nuts with XSL. It's probably overkill, but it's turing-complete, so you can, in theory, achieve anything with it (I have even seen XSL-based prime number generators).
In summary: yes, using CSS instead of <table> for layout can help making your site accessible, but there are other tools that can achieve the job as well.
That's the point of the standards, after all. However, standards can only achieve compatibility among browsers that implement them; and the currently most used browser is well known to have too little compliance.
So this point should, in theory, pull towards CSS, but in practice it pulls towards tables.
As long as you keep your head over your shoulders, creating a table-based layout is simpler than creating a CSS-equivalent; but the latter should be easier to maintain and modify.
I'll try to mention the main arguments on the topic (at least those I've heard about):
Ease of authorship
Maybe I'm missing something, but these are the points that come to my mind now. In summary: it's only you who can check your needs and figure out which is the tool that better suits them.
Hope this helps.