This is from Ian Hickson in 2006, regarding the emergence of HTML5:

"Regarding your original suggestion: based on the arguments presented by the various people taking part in this discussion, I’ve now updated the specification to allow “/” characters at the end of void elements."

To which Sam Ruby responded:

"This is big. PHP’s nl2br function is now HTML5 compliant. WordPress won’t have to completely convert to HTML4 before people who wish to author documents targeting HTML5 can do so using this software. Such efforts can now afford to proceed much more incrementally. This is much more sensible and practical possibility."

http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble

Remember that both men played fundamental roles in shaping HTML5. And I think this one sentence sums up the mindset that shaped HTML5:

"The truth is that most HTML is authored by pagans."

and this was Sam Ruby's view at the time:

"When all the religion was stripped away from the trailing slash in always-empty HTML elements discussion, only one question remained: I think basically the argument is “it would help people” and the counter argument is “it would confuse people”. This is a eminently sane way to approach discussions such as these. I would argue that it would both help people and reduce confusion if a void <a/> element continued to be invalid HTML5 and, by implication, be invalid in XHTML5. By invalid, I simply mean that a parse error would be reported by a conformance checker whenever such constructs are found in a document. Non-draconian user agents can, of course, chose to recover from this error."

People with real lives have perhaps missed the sad slow way that the argument for XML on the Web, and therefore XHTML, has imploded. But the sad souls (such as me) who have followed this story are aware that the case against XHTML has developed slowly over the years.

The first salvo against XML on the web was launched by Mark Pilgrim way back in 2004. This is when the mania for XML was at its peak (before JSON had appeared), a time when people felt XML/XPATH would eventually replace SQL and RDBMS (an idea promoted by no less an authority than Sir Timothy Berners-Lee, who, at that time, could make a believable case that RDF was the future of the Web).

This is Pilgrims article "XML on the Web has Failed":

http://www.xml.com/pub/a/2004/07/21/dive.html

an excerpt:

"There are things called "transcoding proxies," used by ISPs and large organizations in Japan and Russia and other countries. A transcoding proxy will automatically convert text documents from one character encoding to another. If a feed is served as text/xml, the proxy treats it like any other text document, and transcodes it. It does this strictly at the HTTP level: it gets the current encoding from the HTTP headers, transcodes the document byte for byte, sets the charset parameter in the HTTP headers, and sends the document on its way. It never looks inside the document, so it doesn't know anything about this secret place inside the document where XML just happens to store encoding information. So there's a good reason, but this means that in some cases -- such as feeds served as text/xml -- the encoding attribute in the XML document is completely ignored."

The article we are talking about "To close or not to close" states:

"XHTML is basically the same as HTML but based on XML."

This is stated as a fact, but in fact many people have made the argument that XHTML never full functioned as XML, partly for the reasons that Pilgrim talks about, but also because only the strict versions of XHTML ever triggered the strict draconian error handling that has always been part of XML. However, there are other ways where XHTML was difficult to treat the same as XML. For instance:

No more "XML parsing failed" errors

http://intertwingly.net/blog/2011/10/03/No-more-XML-parsing-...

an excerpt:

"Note that the reason to do this is to deal with bad browser sniffing where sites send HTML/XHTML markup meant to be served as text/html as application/xhtml+xml, application/xml or text/xml only to Opera, which causes Opera to encounter an XML parse error that breaks the site for Opera."

Sam Ruby is a co-chair of the W3C's HTML Working Group, and if you've read his blog over the years, you are aware of the many problems that arise when treating XHTML as XML.

Some of the debates that have happened over the years simply reveal how much reality differs from the specs:

"HTML charset vs XML encoding"

http://www.intertwingly.net/blog/2004/02/13/HTML-charset-vs-...

If it was easy to develop a version of HTML that truly acted as a form of XML, would such debates have been necessary?

Please understand me: I am not criticizing all of the intelligent people who worked very hard on the specs for HTML and XML and XHTML. I am pointing out that after 15 years of effort, no one has found an easy way to treat XHTML as a form of XML under all circumstances. Surely if the brightest minds in the tech industry fail to make this work after 15 years, this is a circle that can not be squared?

Consider the fact that companies like Google felt they had no choice but to ignore the mime type "application/xhtml+xml":

Google Hates XHTML?

http://www.intertwingly.net/blog/2007/03/15/Confirmed-Google...

Sam Ruby also makes clear that the concessions to an XML style, including closing void elements, were thought of as an effort to ease the transition:

"I believe that if those that had created XHTML had the courage of their convictions, both Google and Microsoft would have had no choice. I also believe that there should have been a maintenance release or two of HTML4. In HTML5, the root element MAY have an xmlns attribute, but only if it matches the one defined by XHTML; and void elements may have terminating slash characters in their start element. It is these small touches that make transition easier."

Also, in another blog post Sam Ruby makes the point that the draconian error checking that is mandatory for XML also makes it impossible to develop those technologies that supporters of XML were excited about. He gave the example of sending an SVG image to his daughter, and her wanting to post it to her MySpace page: but SVG is XML, and so it should not render on a malformed page, and MySpace was permanently malformed. Sam Ruby could send a gif or a jpeg to his daughter, and she could post that, without a problem, to MySpace, but SVG was limited to well-formed, correctly served pages -- in a world where few pages are well-formed and correctly served. See the comments here:

http://www.intertwingly.net/blog/2006/11/24/Feedback-on-XHTM...

Also, if you have the time, see the debate here between Sam Ruby and Henri Sivonen:

http://intertwingly.net/blog/2012/11/09/In-defence-of-Polygl...

I feel that debate reveals much of the thinking that lead to HTML5 being so much more accepting than XHTML was.

Also, if you have a lot of time, this post from 2009, and the debate in the comments, will teach you a lot about the thinking that shaped HTML5:

http://intertwingly.net/blog/2009/04/08/HTML-Reunification

Finally, in a post I can not find, Sam Ruby makes the point that, for some strange reason, people seemed to very much want something called XHTML, even though it would not be able to act like real XML, for all the reasons that had been discussed in thousands of blog posts and chat rooms. He seemed puzzled by it.

Anyone who advocates for XHTML needs to think long and hard about what it is, exactly, that they are advocating for. If you want an HTML that has an XML style, can you say why?