- From: Elliotte Harold <elharo@metalab.unc.edu>
- Date: Mon, 06 Nov 2006 08:51:36 -0500
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 elharo at metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Received on Monday, 6 November 2006 05:51:36 UTC