So what happened to XHTML5?
That page is a draft for both xhtml5 and html5? So there's no difference between these doctypes?
W3C decided to abandon XHTML for HTML 5. This decision is motivated by several reasons:
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.
For all intents and purposes, XHTML has been abandoned.
There is no XHTML 5 and there will not be one.