Answers:
在撰写本文时，很明显，在2012年，W3C决定放弃XHTML for HTML5。此决定的动机有以下几个原因：
很少有人真正对XHTML感兴趣。大多数网站都是用纯HTML编写的。
真正了解XHTML的含义和使用方法的人越来越少。太多假装提供XHTML的网站使用了错误的标题，而不是Content-Type: application/xhtml+xml。
即使您完全了解了XHTML是什么，标题也必须是什么，对于某些糟糕的浏览器不接受/不支持application/xhtml+xml内容类型的情况，事情还是很棘手的。这意味着您必须根据浏览器更改标题。
XHTML的XML部分也引起了开发人员必须解决的一些奇怪问题。一种是在XHTML页面中的元素上INVALID_STATE_ERR: DOM Exception 11分配包含HTML字符（如é）的文本时出现的消息。当您在执行AJAX请求后在大型Web应用程序中遇到此错误及其非常有用的消息时，您真的不知道这是JQuery，AJAX还是其他错误。
编写HTML 5代码并不意味着要混淆所有标签。如果您对XML和XHTML充满热情，则仍然可以编写看起来与XML非常相似的HTML 5代码。
在手机的早期，对于功能不十分强大的移动设备，XHTML很有趣。解析XML比HTML容易得多。现在，对于双核移动设备，它们是否必须解析干净的有效XML或充满黑客和混合标记的肮脏HTML确实无关紧要。
2014年10月的规范提到了XHTML语法。目前尚不清楚是否存在诸如新的XHTML 语言（不是语法）之类的东西，如果存在，XHTML的地位如何，主流浏览器是否会采用新的XHTML标准。
XHTML5 是 “ HTML5序列化为XML”的同义词。
有多种具体语法可用于传输使用此抽象语言的资源，本规范中定义了其中两种。
...
第二种具体语法是XHTML语法，它是XML的应用程序。当使用XML MIME类型（例如application / xhtml + xml）传输文档时，Web浏览器会将其视为XML文档，由XML处理器进行解析。提醒作者，对XML和HTML的处理不同。特别是，即使是很小的语法错误也将阻止标记为XML的文档被完全呈现，而在HTML语法中将被忽略。该规范定义了XHTML语法的版本5.0，称为“ XHTML 5”。
另外，这里有一个不错的文档，关于编写HTML5多重标记（页面，可以序列化为常规HTML5和XML）：
http://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5
甚至还有一个验证器！
由于它基本上仍是HTML5，但现在仍然很少使用，因此如今很少被称为XHTML5（并且可能很少使用）。
简而言之：对HTML5规范的每次更改也是对XHTML5的隐式对应更改。
HTML5是事实上和法律上的标准！XHTML也在那里，作为标准。
W3C建议书2014年10月28日
该标准的标题包含字符串“ and XHTML”，因此，我们正在讨论W3C 将HTML和XHTML合并为一个单一标准的最终决定。该标准说明了如何将HTML文件序列化为XHTML文件，反之亦然。
XHTML 零件和重要说明：
application/xhtml+xmlLF Sikos总结
XHTML5是HTML5的XML序列化。语法由HTML5规范描述。但是，不应混淆，因为XHTML5是XML的一种应用程序。换句话说，HTML5和XHTML5具有相同的词汇表但具有不同的解析规则。
HTML5文档也可能是有效的XML文档。该标记通常被称为“多语言”语言。它是同时为HTML5和XML文档的文档的重叠语言。HTML5和XHTML5序列化是相互兼容的。但是，XHTML5具有更严格的语法。此外，XHTML5的某些部分在HTML5中无效，例如处理指令。
因此，严格来说（由@vaxquis强调）“ XHTML只是XML序列化的语法”，没有DTD或其他类型的XML模式。
有些人不喜欢说“ XHTML5是XHTML”。这个问题必须分解成一个迷你的常见问题，有关“何时可以将其用作XHTML”。这是维基百科，如果有一些“误解”，请更正...
“完美且通用的HTML5到XHTML5 / XHTML5到HTML5转换”存在一些问题，您必须“个人选择”并且丢失信息。由于上下文将有不同的答案：
宽松的说话：是的。有很多（简单）的示例，其中映射是完美的和可逆的。
严格来说：没有。另请参见下面的@vaxquis评论和此页面中的旧答案。一些典型的问题：
是的你可以。甚至序列化片段。
是的，但是没有旧的DTD的快速和容易。请参阅validator作为validator.nu。
是的你可以。让我们解释一下您可以做什么。
一些框架，例如Cocoon，使用“ XSLT链 ”。HTML5和XHTML5输出可以用作“链中的最后一个输出” ...当然，在中间步骤中，不能使用HTML5，因为它不是XML，但是可以使用XHTML5。
上面的验证问题再次出现：这里没有很强的约定，因此有时“ XHTML标准结构”的清晰度降低。在这种情况下，您必须注意“您自己的约定”并保持一致。
saveXML()方法吗？是。这是使用序列化建议的典型情况。XML将是有效的，XHTML5代码是从原始HTML5和DOM状态映射而成的。但是，在某些结构中，如上所述，某些信息可能会丢失。
是的，不幸的是XHTML不见了。
在MainMa的出色答案中再加上1个理由：
创建XHTML时，WebApp打算使用它来提供非浏览器软件可以理解的结构化内容，这些浏览器软件不具有标记汤HTML解析器。对于ScreenReaders，XHTML仍然很棒，但是对于任何其他类型的软件，WebServices都可以满足需求，并且它们大多使用XML或JSON。SOAP本身具有自己的XML模式，比XHTML更简单并且面向操作。
据我所知，世界上甚至没有1个WebApp向浏览器和其他客户端提供相同的HTTP消息。甚至REST体系结构（该体系结构旨在根据客户端的首选项为多种内容类型提供相同的内容表示形式）也不用于XHTML / Feed浏览器。
例如，在Java EE中，我们可以使用Eclipse部署一个唯一的war文件，其中包含Servlets + JSP来提供HTML服务，以及Axis2来提供WebService服务。开发针对浏览器和WebService的单独软件要比拥有可为所有浏览器和WebService服务的独特，复杂的软件简单得多。
拒绝REST的主要原因是开发服务器的复杂性（这本来很简单！），该服务器为任何类型的客户端提供相同的内容，却一无所知。而且，很难满足Web的快速发展需求，并保持稳定的定义，这种定义不会在每次XHTML更改时强制更新非浏览器客户端，例如，当它由许多不同的模块构建时，它可以使XHTML保持有效。
同样，由于所有这些XML元素都旨在构成浏览器呈现的布局，而不是用于保留内容，因此很难开发一个非浏览器客户端来解析XHTML文档，即使它是有效的。
如果REST采用者已经抱怨SOAP的XML复杂性（这比用于浏览器的XHTML更为简单），请想象一下为多种客户端类型，服务器和客户端处理XHTML有多么困难。
实践中：使用HTML（如果需要的话，类似XML）来构建用于浏览器的WebSite，以及用于非浏览器客户端的任何WebService解决方案。
但是，我也认为必须创建XHTML5。XHTML 1.1（好的，1.0，1.1不可用）将在HTML5中过时，并且我们仍然需要一个接受HTML5元素并验证XML格式正确的验证器。