It seems like every time I try to create a pure CSS layout it takes me much longer than if I\'d use a table or two. Getting three columns to be equal lengths with different amou
Besides being easily updatable and compliant...
I use to design all table based web sites and I was resistant at first, but little by little I moved to CSS. It did not happen overnight, but it happened and it is something you should do as well.
There have been some nights I wanted to toss my computer out the window because the style I was applying to a div was not doing what I want, but you learn from those obstacles.
As for a business, once you get to designing web sites by CSS down to a science, you can develop processes for each site and even use past web sites and just add a different header graphic, color, etc.
Also, be sure to embed/include all reusable parts of your website: header, sub-header, footer.
Once you get over the hump, it will be all down hill from there. Good luck!
The main reason why we changed our web pages to DIV/CSS based layout was the delay in rendering table based pages.
We have a public web site, with most of its users base is in countries like India, where the internet bandwidth is still an issue (its getting improved day by day, but still not on par). In such circumstances, when we used table based layout, users had to stare at a blank page for considerably long time. Then the entire page will get displayed as a whole in a tick. By converting our pages to DIV, we managed to bring some contents to the browser almost instantly as users entered to our web site, and those contents where enough to get the users engaged till browser downloads entire contents of the page.
The major flaw with table based implementation is that, the browser we will show the content of the table only after it downloads the entire html for that table. The issue will blow out when we have a main table which wraps the entire content of the page, and when we have lots of nested tables. For the 'flexible tables' (those without any fixed width), after downloading entire table tag, browser has to parse till the last row of the table to find out the width of each columns, then has to parse it again for displaying the content. Till all these happens users has to stare at a blank screen, then everything will come to screen in a tick.
If you have a public facing website, the real business case is SEO.
Accessibility is important and maintaining semantic (X)HTML is much easier than maintaining table layouts, but that #1 spot on Google will bring home the bacon.
For example: Monthly web report: 127 million page views for July
Monthly web report: 127 million page views for July
...
Latimes.com keeps getting better at SEO (search engine optimization), which means our stories are ranking higher in Google and other search engines. We are also performing better on sites like Digg.com. All that adds up to more exposure and more readership than ever before.
If you look at their site, they've got a pretty decent CSS layout going.
Generally, you find relatively few table layouts performing well in the SERPs these days.
Keep your layout and your content separate allows you to redesign or make tweaks and changes to your site easily. It may take a bit longer up front, but the longest phase of software development is maintenance. A css friendly site with clear separation between content and design is best over the course of maintenance.
The idea is that Designers can Design and Web Developers can implement. This is especially the case in dynamic web applications where you do not want your Designers to mess around in your Source Code.
Now, while there are templating engines, Designers apparantly just love to go crazy and CSS allows to pull a lot more stunts than tables.
That being said: As a developer, i abandoned CSS Layout mostly because my Design sucks anyway, so at least it can suck properly :-) But if I would ever hire a Designer, I would let him use whatever his WYSIWYG Editor spits out.
Business reason for CSS layout: You can blow away the customers by saying "our portal is totally customizable/skinnable without writing code!"
Then again, I don't see any evil in designing block elements with tables. By block elements I mean where it doesn't make any sense to break apart the said element in different designs.
So, tabular data would best be presented with tables, of course. Designing major building blocks (such as a menu bar, news ticker, etc.) within their own tables should be OK as well. Just don't rely on tables for the overall page layout and you'll be fine, methinks.