ML still being a Big Thing To Come, let's leave it for now and discuss what are the ways (if any) to pursue more XML-like document creation patterns with the current technology we have now: HTML, with or (more often, due to Web authors' inertia and poor implementation in browsers) without CSS.  It's not that current technology is completely unable of separating content from presentation; the biggest obstacles on the way have more to do with psychology, rather than technology---you have to somehow gain a new understanding of what you post on your Web site.

Just like nobody to date observed a bodiless soul, so its existence can be doubted, it's extremely difficult to imagine, and even harder to implement, a completely "presentationless" content.  No less difficult is perceiving how content, even if it existed independently, can be absolutely orthogonal (i.e. independent) with respect to presentation.  This is a challenging abstraction exercise, and it actually requires some training, plus a special mentality or frame of mind, to immediately see where the dividing line should be drawn (and yes, there are cases when this line can be drawn in more than one way).  Otherwise, SGML would have long ago become a commonplace and wouldn't need any advocacy.

Since in the case of HTML without CSS we have a single language responsible for both structure and presentation aspects, it is highly important to develop certain usage conventions that would allow for an easy, ideally automatic, separation of presentation from content (however, in compliance with its level of abstraction roughly corresponding to that of word processor formats, HTML's "separated content" mostly consists of the plain text part of the document---hence, for example, the importance of proper alt texts for images).  Thus, besides their primary role, all HTML elements and attributes tend to form two groups at both sides of the Great Divide, one group with primarily structural and another with primarily presentational meaning.  This principle is behind the segregation of "deprecated" elements and attributes found in HTML specification, as well as in the foundation of most accessibility guidelines that HTML authors should obey.  Unfortunately, many HTML users simply don't realize why the structural elements are there and what they could be used for.

Apart from technology where the two aspects are confused due to the unfortunate development path taken by HTML in the past, one might face some difficulties when trying to differentiate these aspects in the first place.  Formal mechanisms, be they HTML or XML, can do their job of markup only after the two aspects already lie separated before the author.  In fact, if we take an already formatted document and try to tear it up into presentation and content parts (this task may seem a bit easier than composing a new document while maintaining orthogonality of aspects), this process may prove quite ambiguous for a number of reasons.

One difficulty is that in the final document, the two aspects are not only fused together---they can even overlap.  When boiling down "pure content," you will often find it necessary to add descriptions or placeholders for some valuable pieces of information expressed by strictly visual means.  For example, icons often need textual equivalents (alt texts) even if in the visual version of the document they are purely graphic.  For a more complex example, consider how visual elements might show the connection of corresponding pieces of content only by their relative positioning on the page; in the content-only version, some structural or textual means must be added for expressing the same relations.

On the other hand, when evaporating presentational parameters, you'll have to carry off some bits of content as well.  These bits are usually called "generated content" and include numbering of headings (which must be generated by stylesheets rather than hard-wired into the text), sidebar headings such as "NB:" or "Tip:" consistent throughout the document, etc.  Additional difficulty is that presentation information must have a somewhat different structure than content---the former is usually grouped per element types while the latter is mostly sequential.  Here, the responsibility of the stylesheet language is to make the task of structuring presentational information as natural as possible.