Norman has posted useful follow-up material. And he says:
Frankly, the fact that the style is separated from the content seems perfectly reasonable to me.
Me too, but in the business context in which I work, where we commission internal and external designers to do page layout, we have never had satisfactory results from the div + CSS approach. We always go back to tables because the designers can make them work, cheaply. Even if CSS did not have all the problems it has with inconsistent implementation, it would still probably require more work to lay things out because of the complexity of the CSS model, and the disconnection between the things you are laying out and the layout language.
We have settled on another way of separating content from style. For alternate skins our designers make templates consisting of plain-old (x)HTML. They get to use their favourite editor (usually DreamWeaver in our case). The template gets all its parts labelled in a consistent way using CSS classes. For example you could have a cell containing table of contents and content like so:
<td class="layout-main-part"><div class="TOC">...</div> <div class="content">...</div></td>
The designer can put in sample content if they wish. And we do use CSS to make the tables look pretty. We don't usually come across problems with code samples, but ocassionally long unbroken strings of text break the formatting by forcing a table to stretch. I'm not sure what can be done about this in a table.
Then we use those plain-old HTML templates to format every page we serve, via XSLT. We use XSLT on the server-side, although it is supposed to work with modern browsers at the client side. So far, though, client-side XSLT is even worse for me than CSS in that I can't make it work at all in either of the browsers I have on my computer, and yes they are supposed to support it (IE6 and Firefox). I need to spend more time on this.
If client-side XSLT processing can be made to work, how about this approach: