我一直在考虑将我当前的 HTML5 文档转换为多语言 HTML5 文档。我认为即使它们只被用作text/html，编写 XML 的额外检查也将有助于保持我的编码习惯整洁和有效。
在仅限 HTML5 的空间中是否有什么特别令人兴奋的东西会使这成为一个不明智的选择？
其次，关于如何验证多语言文档的规范有点模糊。我假设基础是：
但是我还缺少其他规则吗？
第三，鉴于它是多语言的，有没有人知道为application/xhtml+xml支持浏览器和text/html不支持浏览器提供服务的任何警告？
编辑：经过一些试验后，我发现 XHTML5 中的实体（没有 DTD）像 break 一样。XML 解析器有点像一把双刃剑，我想我已经回答了我的第三个问题。
定义如何创建 HTML5 多语言文档的工作目前正在进行中，但请参阅http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html了解早期草案. 这当然是可能的，但它确实需要大量的编码纪律，并且您需要决定是否值得付出努力。虽然我创建了 HTML4.01/XHTML1.0 多语言文档，但我使用 XML 工具链创建它们，该工具链保证 XML 格式良好，并具有专门的代码来确保与 HTML 非空元素和有效 XML 字符的兼容性。直接手工编码将非常困难。
HTML5 中一个已知的当前问题是 iframe 元素上的 srcdoc 属性。因为属性的值包含标记，某些字符需要转义。HTML5 草案规范描述了如何为 HTML 序列化执行此操作，但没有（我上次查看）如何在 XHTML 序列化中执行此操作。
我迟到了，但 5 年后，这个问题仍然很重要。一方面，关闭我所有的标签对我很有吸引力。为了阅读它的人，为了更容易编辑，为了大正义。OTOH，查看多语言规范的血腥细节——http: //www.sitepoint.com/have-you-considered-polyglot-markup/最后有一个方便的总结——我很清楚我无法理解用手没问题。
https://developer.mozilla.org/en/docs/Writing_JavaScript_for_XHTML还为 XHTML 失败的原因提供了有趣的启示：选择使用 XML mime 类型在运行时会产生各种副作用。到目前为止，好的 JS 代码处理这些应该是例行公事（例如，在比较之前总是小写标签名称），但我不想要所有这些。有足够多的跨浏览器问题可以按原样进行测试，谢谢。
所以我认为有一个有用的中间方法：
目前仅作为text/html. 不要担心它实际上会在 HTML 和 XML 模式下解析为具有相同运行时行为的完全相同的 DOM。
只努力将其解析为一些格式良好的 XML。它可以帮助读者，可以帮助编辑，还可以让我在自己的文档上使用 XML 解析器。
不幸的是，多语言工具很少甚至不存在——甚至很难以一种同时满足 HTML 要求的方式序列化回 XML...
不费吹灰之力：总是自动关闭无效标签 ( <hr/>) 并单独关闭非无效标签 ( <script ...></script>)。
不费吹灰之力：使用小写标签和 attr（除了一些 SVG，但外国内容无论如何都使用 XML 规则），总是引用属性值，总是提供属性值（selected="selected"比 stanalone 更冗长，selected但我可以忍受）。
内联<script>和<style>最烦人的。我不能在不破坏 XML 解析的情况下使用&or inside。<我需要：
<script>/*<![CDATA[*/
foo < bar && bar < baz;
/*]]>*/</script>
......就是这样！不关心 XML 命名空间或匹配 HTML 的表隐含 DOM 会降低大约一半的规则 :-)
等待将来我可以直接去创作 XHTML，跳过多语言。好处是我将能够忘记标签关闭的限制，能够直接使用XML 工具使用和生成它。当然，现在忽略 xml 命名空间和其他东西会使切换变得更加困难，但我认为我将在未来创建更多新文档而不是转换现有文档。
实际上，我不完全确定是什么阻止了我现在生活在那个未来。只有IE 8吗？我也有点担心全有或全无的错误处理。我有点希望未来的 HTML 规范能找到一种方法来缩小 HTML 与 XML 之间的差距，例如让浏览器接受HTML <hr></hr>，<script .../>同时仍然保留 HTML 错误处理。
还有，工具。拥有可以序列化为多语言标记的多种语言的库将使程序生成它变得可行。拥有验证和转换 HTML5 <-> polyglot <-> XHTML5 的工具会有所帮助。否则，它几乎注定要失败。
鉴于 W3C 关于 HTML 和 XHTML 之间差异的文档还没有完成，您可能不值得花时间尝试多语言。反正还没有……再给它几年。
无论如何，只有在您积极计划将您的 HTML 解析为 XML 以用于某些特定目的的极其狭窄的情况下，您才应该在 XML 合规性上投入额外的时间。纯粹为了浏览器的消费而这样做没有任何好处——只有缺点。
你应该？是的。但首先要澄清几点。
发送Content-Type: application/xhtml+xml标头仅意味着它应该通过 XML 解析器，据我所知，它仍然具有 HTML5 的所有优点。
关于 ，XML 中没有定义，XML 定义的唯一字符实体引用是 lt、gt、apos、quot 和 amp，您将需要使用数字字符引用来处理其他任何内容。nbsp 的代码是 or  ，我个人更喜欢十六进制，因为 unicode 代码点以这种方式表示（U+00A0）。
发送标头对于测试很有用，因为您可以快速找到标记的问题，例如未闭合的标签、杂散的结束标签、可能被解释为标签的文本等，基本上是可能破坏网站外观甚至功能的东西。
在我看来，最重要的是，如果您允许用户输入并且它无法解析，这通常意味着您没有逃避他们的数据并且让自己容易受到漏洞的影响。解析为 HTML，您可能永远不会注意到问题，直到有人开始注入脚本来骚扰您的用户或窃取数据。
这个页面很好地解释了多语言标记是什么：https ://blog.whatwg.org/xhtml5-in-a-nutshell
这听起来是一件非常困难的事情。XHTML 的缺点之一是它不可能在 XML 和老式 HTML 的竞争需求之间成功地驾驭。
我认为如果您编写 HTML5 并成功验证它，您将拥有任何人都需要的整洁有效的文档。
这个 wiki 有一些 W3C 文档中没有的信息：http ://wiki.whatwg.org/wiki/HTML_vs._XHTML