| ...and it does not separate style from content...
I often hear this mantra, but why is it really important?
I think it's a good goal, but not to the extent that a designer is spending a ton of extra hours working on a layout simply to try to ensure this perfect separation of style from content.
...well you may as well ask why MVC (or MVP or similar) is important.
They all share the base reasons, which is the seperation of concerns, which ultimately leads to systems/solutions being easier to develop/maintain/extend/change.
I suppose I should clarify. I didn't mean to imply that content-vs-presentation was unimportant; I think it is important. I meant to ask, is it always important enough to justify all the extra cost associated with it?
It's presented as this cardinal rule: the web designer shalt not mix layout and content, nor shall the designer obfuscate thy code with any table, less it is presented in the form of a database view. (+1 for dramatic license.)
And I would be all for that, IF the development platform that we were all forced to use actually supported that in a helpful way.
But, it doesn't. Give me a little time, and I'm pretty sure I can come up with at least one presentational trick that is absolutely, positively impossible with cross-browser CSS -- and I'll even allow you to use all the CSS hacks you can come up with. But, the very same presentational effect is a piece of cake with a single HTML table.
MVC, or MVP, are sound ideas ... where they're made practical by the development environment. However, it's possible to write perfectly easy-to-maintain code for a business without strictly following those models, and if you're dealing with some framework or development environment that makes the MVC model difficult, then I think it's foolhardy not to make some practical considerations in lieu of this stainless ideal.
EDIT: I just remembered the CSS layout that I wanted so badly and never could figure out. It drove me nuts, but this was a couple of years ago and somebody might have figured it out since. All I wanted was two columns; first was completely liquid, the second was liquid with a minimum width; auto scroll bars (but not displayed unless necessary); and -- the part I couldn't get to work -- a single line border drawn between the two. For some reason, no matter what I tried, introducing that line border caused one browser or another to add scrollbars, or draw it short, or something else idiotic. Three days of Googling, CSS hackery, and other nonsense later, and I wrote a table in just about a minute that did the job fine.
Where I work, we separate layout and content quite religiously because they're done by different people. A mess of table based HTML may make things easier for the layout guy, but it makes it more difficult for the content people to work with later on.
For example, let's say the HTML guy makes a page where product data should go. What exactly that product data is, he does not know when he's making the page. It doesn't matter, he can just make the HTML and fill it up with some Lorum Ipsum text. Then when it's time to put the actual product data in, this will take ten minutes at most for the content people to do if the HTML is clean and minimalist, while it will take a few hours if it's nested tables or worse (Dreamweaver generated crap or somesuch).
In the end, the cost of having someone do HTML properly, meaning using HTML for content only and dealing with presentation in CSS, which the content people will never see, offsets the costs of having developers wade through messy HTML every time they need to change something.
I often hear this mantra, but why is it really important?
I think it's a good goal, but not to the extent that a designer is spending a ton of extra hours working on a layout simply to try to ensure this perfect separation of style from content.