The thread started by Elliotte Rusty Harold (super smart guy) called Why XHTML is provoking a number of intelligent and articulate responses. Here's my take:
I used to be firmly in the XHTML camp, but now I'm not. I'm not against people outputting valid XHTML instead of HTML, probably they should. Unless it is too hard. I just don't think that it matters all that much in practice. My rationalization for this is pretty straightforward, and goes like this:
The web in made up of a nearly infinite variety of html-ish documents, some valid xhtml, some valid html, but mostly just almost-valid almost-html. So if you are writing a client for the web as it is, you will need to accept the most liberal input possible because a client that throws errors when it sees a missing
'/>' symbol isn't a very useful client at all.So take the best possible case: A client sees a document, and the server declares that document's mime type to be
application/xhtml+xml or the document declares one of the xhtml doctypes, so the client fires up a validating XML parser, finds the document to be valid XML, outputs a XML tree (nothing html specific here), then walks that tree according to the most state-of-the art html heuristics (e.g., the html5 grammar), and renders the document accordingly (the hard and time-consuming part).That's the best case.
The worse case is: A client sees a document, and the server doesn't bother to set a mime-type at all (or sets the wrong one) and/or doesn't declare an xhtml doctype, and the client starts walking the characters in the document according to the most state-of-the art html heuristics (e.g., the html5 grammar), and renders the document accordingly (the hard and time-consuming part).
The difference between the best and the worst case is slight enough, and I'm not particularly convinced that the cost of running the first pass through a validating XML parser and creating a XML parse tree buys you much benefit when starting to parse the interesting stuff, the html itself.
But the real clincher is that the best case scenario is fleetingly unlikely. There are three possible outcomes here: 1) either the document isn't declared to be xhtml at all so you fall through to the worse case, 2) the document is declared to be valid xml so you start parsing it only to find out it was invalid, so you start over again with the worst case, or 3) the document is valid xml and you have the best case scenario.
In practice on the real web, cases 1 and 2 are so much more likely that if you're a pragmatic client you may as well start with the worst case and never bother parsing the document for the best case in the first place.
Now if you're a document author, and you know that pragmatic clients are going to interpret your document according to the worst case rules no matter what you do, your only real incentive for writing xhtml over html is one of personal preference.
I can see some cases with machine-generated documents that emitting xhtml is actually just as easy as emitting html (say, if you are building up a DOM tree to represent your content anyway), or if you need to round-trip within a closed ecosystem of clients. But as soon as humans are involved in the production of the document, given the axiom that no human should ever have to write xml by hand, you are almost certainly going to be producing html, not valid xhtml.
Ultimately it comes down to the human element. People write the content and people will always write it using non-validating formats, if for no other reason that writing compliant documents is hard, and people have better things to do with their time than check for missing
'/>' symbols. (And moreover, people also write the software that generates xhtml, and that software is often buggy and produces invalid documents anyway.)My conclusion is that if you can produce valid xhtml, go for it. But in the end it doesn't make much of a difference. In fact, I'm pretty certain that the web itself wouldn't have succeeded if xhtml was required from the beginning, because a web that renders and displays documents is a much better web than one that throws validation errors all over the place.
(And all this, coming from a former xhtml guy...)
Footnote, a few of the other axioms that inform my thinking on this:
- HTML is intended to be written by humans (by hand).
- HTML is intended to be displayed to humans.
- Machines that want to interpret HTML need to act like humans, and not the other way around.