我一直在考虑将我的当前HTML5文档转换为多语言HTML5文档。我想即使它们只作为text/html提供，编写XML的额外检查也有助于保持我的编码习惯整洁和有效。
在仅限于HTML5的领域中，有什么特别激动人心的东西会使这成为一个不明智的选择吗？
其次，规范对如何验证多语言文档有些模糊。我假设基本要求是：
但还有其他规则我错过了吗？
第三，既然它是多语言的，是否有人知道将其作为application/xhtml+xml提供给支持浏览器和text/html提供给不支持浏览器的任何注意事项？
编辑： 经过一点小实验，我发现像 这样的实体在XHTML5（没有DTD）中会出错。那个XML解析器有点双刃剑，我想我已经回答了我的第三个问题。
For now serve only as text/html. Stop worrying that it will actually parse as exactly the same DOM with same runtime behavior in both HTML and XML modes.
Only strive that it parses as some well-formed XML. It helps readers, it helps editors, it lets me use XML parser on my own documents.
Unfortunately, polyglot tools are rare to non-existant — it's hard to even serialize back XML in a way that also passes the HTML requirements...
No brainer: always self close void tags (<hr/>) and separately close non-void tags (<script ...></script>).
No brainers: use lowercase tags and attr (except some SVG but foreign content uses XML rules anyway), always quote attribute values, always provide attribute values (selected="selected" is more verbose than stanalone selected but I can live with that).
Inline <script> and <style> are most annoying. I can't use & or < inside without breaking XML parsing. I need:
<script>/*<![CDATA[*/
foo < bar && bar < baz;
/*]]>*/</script>
...and that's about it! Not caring about XML namespaces or matching HTML's implied DOM for tables drops about half the rules :-)
Await some future when I can directly go to authoring XHTML, skipping polyglotness. The benefits are I'll be able to forget the tag-closing limitations, will be able to directly consume and produce it with XML tools. Sure, neglecting xml namespaces and other things now will make the switch harder, but I think I'll create more new documents in this future than convert existing ones.
Actually I'm not entirely sure what's stopping me from living in that future right now. Is it only IE 8? I'm also a tiny bit concerned about the all-or-nothing error handling. I'm slighly hoping a future HTML spec will find a way to shrink the HTML vs XML gaps, e.g. make browsers accept <hr></hr> and <script .../> in HTML— while still retaining HTML error handling.
Also, tools. Having libraries in many languages that can serialize to polyglot markup would make it feasible for programs to generate it. Having tools to validate and convert HTML5 <-> polyglot <-> XHTML5 would help. Otherwise, it's pretty much doomed.
考虑到W3C有关HTML和XHTML差异的文档尚未完成，因此尝试进行多语言可能不值得您花费时间。 至少现在还是这样...再给它几年时间。
无论如何，只有在极为狭窄的情况下，即您正在积极计划将HTML作为XML解析以实现某些特定目的时，您才应该投资额外的时间来符合XML标准。 纯粹为了供Web浏览器使用而这样做没有好处，只有缺点。
你需要吗？是的。但首先需要澄清几点。
发送Content-Type: application/xhtml+xml头仅意味着它应该通过XML解析器，就我所知，它仍然具有HTML5的所有优点。
关于 ，在XML中没有定义，XML定义的字符实体引用只有lt、gt、apos、quot和amp，你需要使用数字字符引用来表示其他任何内容。 nbsp的代码是 或 ，我个人更喜欢十六进制，因为Unicode代码点以这种方式表示（U+00A0）。
发送头文件对测试很有用，因为您可以快速找到标记未关闭、偏离结束标记、可能被解释为标记等的标记问题，基本上是可以破坏您网站外观甚至功能的东西。
我认为最重要的是，如果您允许用户输入并且无法解析，则通常意味着您没有转义其数据并且正在留下漏洞。作为HTML解析，您可能永远不会注意到问题，直到有人开始注入脚本来骚扰您的用户或窃取数据。
这个页面非常好地解释了多语种标记的概念：https://blog.whatwg.org/xhtml5-in-a-nutshell
htmlentities($dirty,ENT_QUOTES|ENT_XML1|ENT_SUBSTITUTE,"UTF-8",true)（我为了方便将其包装在一个函数中）来处理PHP中用户生成的内容或将其作为JSON提供给javascript并设置 textContent（适用于重复的标记）。我很好奇你觉得这有什么难度。 - Chinoto Vokro这听起来是一件非常困难的事情。XHTML 的一个缺点是无法成功地在 XML 和传统 HTML 之间平衡竞争需求。
我认为，如果您编写 HTML5 并成功验证它，您将拥有任何人所需的整洁和有效的文档。