So what happened to XHTML5?
That page is a draft for both xhtml5 and html5? So there's no difference between these doctypes?
In 2012 at the moment of writing, it was clear that W3C decided to abandon XHTML for HTML 5. This decision was motivated by several reasons:
The spec of October 2014 mentions XHTML syntax. For the moment, it is unclear whether there is such a thing as the new XHTML language (not syntax), and if there is, what will be the position of XHTML, nor the adoption of the new XHTML standard by the mainstream browsers.
HTML5 - A vocabulary and associated APIs for HTML and XHTML
W3C Recommendation 28 October 2014
The title of the standard contains the string "and XHTML", so, we are talking about a final decision of W3C to merge HTML and XHTML into one single standard; and this standard shows how to serialize an HTML file into XHTML file and vice-versa.
Understanting and using
As summarized by LF Sikos
So, strictly speaking (and emphasized by @vaxquis) "XHTML is just a syntax for XML serialization", there are no DTD or other kind of XML schema.
Some people not like to say "XHTML5 is XHTML". The question must split into a mini-FAQ about "when I can use it as XHTML". This is a WIKI, please correct if there are some "misunderstanding"...
Can I use XHTML5 as the "2014's version of XHTML standard"?
There are some problems in a "perfect and generic HTML5-to-XHTML5/XHTML5-to-HTML5 convertions", you must do "personal choices" and lost information. As the context will be different answers:
Can I use (fearless!) XHTML5 serialization with XSLT, XPath, etc.?
Yes, you can. Even serializing fragments.
Can I validate XHTML5?
Yes, but not so fast and easy than the old DTD's... See complex validators, as validator.nu
Can I use XHTML5 as non-terminal output in a XSLT chain?
Yes, you can. Let's explain what you can.
Some frameworks, like Cocoon, use "XSLT chains". HTML5 and XHTML5 outputs can be used as "last output in the chain"... Of course, in intermediary steps, HTML5 can not be used because is non-XML, but XHTML5 can be used.
The above problem of validation reappears here: there no strong convention, so, sometimes, less clarity of "XHTML standard structure" appears. In that situation you must pay attention in "yourself conventions", and be consistent.
When using DOMDocument of a HTML5 page, can I use a
XHTML5 is a synonym for "HTML5 serialized as XML".
*quoted from http://www.w3.org/TR/html5/introduction.html#html-vs-xhtml (Note that is also says "This section is non-normative.", and even further further it says that "At the time of writing, no such rules actually exist." about XHTML5 parsing rules)
Also, there's a nice document on writing HTML5 polyglots (pages, that can be serialized both as regular HTML5 and XML) here:
And a validator even!
It's rarely called XHTML5 nowadays (and probably even more seldom used), since it's basically still HTML5 but it's still there.
Simply put, every change to HTML5 spec is also an implicit, corresponding change to XHTML5.
Yes unfortunately XHTML is gone.
Adding 1 more reason to MainMa's great answer:
When XHTML was created, it was meant to be used by WebApps to serve structured content that would be understood by non-browser softwares, that would not have tag-soup HTML parsers. For ScreenReaders XHTML is still great, but for any other kind of software, WebServices fit that need, and they mostly use XML or JSON. SOAP itself has its own XML Schema, simpler than XHTML and operation-oriented.
As long as I know, there's not even 1 WebApp in the world that serves the same HTTP message to both browsers and other clients. Even REST architecture, which was meant to serve the same representation of a content in multiple content types based on client's preference, isn't used to serve XHTML/feed browsers.
In Java EE for exemple, using Eclipse we can deploy a unique war file holding Servlets+JSPs to serve HTML, together with Axis2 to serve a WebService. It's simply easier to develop separated softwares aimed for browsers and WebService than have a unique, complex software that serves them all.
The major reason for REST being rejected is exactally the complexity (and it was meant to be simple!) of developing a server that serves the same content for any type of client without knowing anything about it. And it's also hard to handle Web's need of fast evolving, together with keeping a stable definition that would not force non-browser clients to be updated everytime a XHTML changes, say it to keep the XHTML valid when it's built by many different modules.
In the same way, it's very harder to develop a non-browser client that parses a XHTML document, even it being valid, because of all those XML elements that are meant to structure the browser-rendered layout, and not meant to hold content.
If REST adopters already complain about SOAP's XML complexity, which is WAY simpler than a XHTML meant for a browser, imagine how hard it is to handle XHTML for multiple client types, server and client-side.
In practice: use HTML, XML-like if you want, to build WebSites for browsers, and any kind of WebService solution for non-browser clients.
BUT, I also think that XHTML5 must be created. XHTML 1.1 (ok, 1.0, 1.1 is unusable) will become outdated with HTML5, and we still need a validator that accepts HTML5's elements and validates XML wellformedness.
Thank you for your interest in this question.
Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.
Would you like to answer one of these unanswered questions instead?