I used to ponder about this long ago, when designing websites.
My conclusion was, and I believe it still stands today, that even though XHTML and CSS are meant to be isolated from each other as content and presentation respectively, the reality of the matter still makes the look of the website pretty much depend on the document structure - i.e. markup, XHTML - and thus CSS alone will not give you the magic wand to make your website change its look completely based on a stylesheet. I wish it were so however - certainly, that is the main purpose of CSS. And certainly, that would be the beauty of it - since each is completely isolated from the other, website developers can in peace of mind program the structure of the website documents, almost while the CSS authors can work in parallel and write the stylesheets. Then both are combined, and with the knowledge that the markup does not need to be changed ever again. That is the theory anyway.
In practice this often fails to work - because a document has a top-to-bottom left-to-right (usually) bound semantics, it becomes difficult to for instance, make an element appearing at the bottom of the document structure, appear at the top of the browser page to the user. The limitations work against the theory.
Because of the above implications, and some other real-world limitations of the CSS and markup technologies, I have decided to simply consider markup as something in between the content and the style. I.e. some of the markup will unfortunately dictate style, no matter stylesheet - the sequence of elements being one (see above), pagination limitations, etc - and so, while most of the structure may be isolated from its appearance, some of this appearance will be dictated by it. For this reason, if we don't regard client side scripting (which may aid styling by re-arranging elements of a document) - one way to do it is use XML as content, XHTML as content-style hybrid layer, and CSS to finally dictate the appearance.
Where does XML come into this? Well, you transform (either in browser or server-side) it with XSLT into a XHTML document, which you consider as relevant in the styling process. I.e. if you have an artist list of 1000 entries, and you want to customize how the page looks like, you use the following content XML:
<artists>
<artist name="Moby" />
<artist name="Cocorosie" />
<!-- and so on -->
</artists>
This is considered as an unchanging content, no matter the final style - part of the point of separating content from presentation, something you could not have done fully with XHTML because CSS cannot do certain things. With XSLT however, you can further transform the above into a desired markup ( you can then apply CSS to):
<xsl:transform>
<!-- XSLT is beyond the scope of this... -->
</xsl:transform>
will transform the XML into something like:
<h1>Artists</h1>
<h2>Page 1 of 10</h1>
<ul>
<li><a>Moby</a></li>
<!-- Only 100 artists per page -->
</ul>
And then you style it.
Bottomline is, you get to control each point of the transformation of your raw database content into final end-user application.
Much of what XSLT does with XML, can be instead done with JavaScript on XHTML, but I consider client-side scripting an addition, not replacement to things like XSLT. Then again, Firefox and most other modern browsers can do XSLT client-side, which blurs the distinction between scripting and document serving.