XHTML is barely more than a clone of HTML written in XML. To put it in other words, XHTML is the XML serialization of HTML. There should be no differences in the Document Object Model between two documents written respectively in HTML and XHTML, if both are well-written. There are several polyglot issues, such as XML namespaces, which HTML5 allows for the sake of intercompatibility between the two serializations.
What are the differences, then? What should you use?
When writing in plain HTML the browser is watching over you, and your code will work even if something is a bit wrong. You rarely need to test, and can throw whatever garbage you want into your page. In short, you can do the kind of stuff that gives programmers nightmares (and also funds quite a bit of their work).
So that’s where it is. People with no experience can still create content for the web, while anyone who wants to say they know how to code (even if they only code markup, rather than program) must adopt proper coding standards.
Essentially, XHTML is HTML. If a ‘programmer’ is learning HTML, the X can be assumed. There is no reason to even mention XHTML anymore, because (beyond a few quibbles) the markup a programmer writes and the markup someone else writes should build the same DOM.
They are learning to mark up hypertext. The serialization is only a detail, for advanced usage. Even the new doctype is the same for both HTML5 and the XHTML serialization of HTML5. (I’d say XHTML5; but that’s a misnomer, as it is actually XHTML 1.0.)
Now, the argument between
application/text+xhtml is another story (and is XHTML 1.1 rather than 1.0), and one that I should delve deeper into in a later post. But as far as naming goes, for standard code being served to a browser with no special headers being changed, the X in XHTML is little more than a name.