James Graham wrote:
However, let's assume that we have a tool that can guarantee well-formed markup. As you note the pieces for building such tools do exist (although, as you fail to note, they are typically both slower and harder to use than the pieces for building sites based on simple string interpolation). One example is turbogears [1], which comes with the Kid template system by default [2]. Under the covers the Kid template is turned into an XML ElementTree [3] and page rendering involves mutation of that tree. Given that, Turbogears will produce sites are good to be sent over the wire as application xhtml+xml to supporting browsers (of course it is almost certainly possible to break this property if you try hard enough). Despite this, _none_ of the sites listed on the turbogears front page are sent as anything other than text/html. Apparently authors desire the browser support and error-handling of HTML over the simpler parsing of XHTML even in situations where they have a real choice.
Publishers don't use application/xhtml+xml because it causes big problems for IE6. (Again, possibly another non-issue by the time this spec is actually done.) I actually do publish a few pages as application/xhtml+xml, and I get complaints about that.
However, if you're sending well-formed XHTML out as text/html, then it can be handled quite nicely today by existing browsers. Furthermore, you get all the benefits of easy parseability with XML tools. This is a really useful, practical combination. I use this on a *lot* of pages, as do most other people I know publishing well-formed or valid XHTML.
-- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
