【发布时间】：2011-05-21 02:09:03
【问题描述】：
我正在开始一个项目，客户要求使用 XHTML 1.0 Strict。现在我想知道Sending XHTML as text/html Considered Harmful 中描述的问题是否仍然存在，我是否应该尝试让客户相信这个（非常强烈的）要求会适得其反。
Internet Explorer 现在可以正确处理application/xhtml+xml 了吗？
【问题讨论】：
标签： xhtml
【发布时间】：2011-05-21 02:09:03
【问题描述】：
这取决于您所说的“Internet Explorer”是什么意思。
例如，IE6 仍然来自类似 2001 的版本（没有改变），不，它仍然不能正确处理它。
【讨论】：
Internet Explorer 9 将通过标签汤解析器处理 application/xhtml+xml 文档。
Internet Explorer 8 及更早版本将提示用户保存文档或在另一个应用程序中打开它。
Internet Explorer 6 和更新版本都拥有重要的市场份额（尽管这在某种程度上取决于您的市场）。
多年来，浏览器对真正 XHTML 的支持没有任何重大变化。
除非您在生产链中实际使用 XML 解析器（在这种情况下，祝您好运，说服他们输出符合 HTML 兼容性指南的 XHTML）
【讨论】：
-
你的第一个陈述有参考吗？它似乎完全违背了 XHTML 的目的。
-
IE9 的
application/xhtml+xml解析器并不是真正的标签汤解析器。它会因 XML 格式正确的错误而窒息而死；与其他浏览器的不同之处在于，它将显示从页面获得的内容到目前为止直到错误点，而不是用错误消息替换整个页面。遗憾的是（在当前的测试版中）没有给出页面提前终止的视觉指示，但这是一个开始。 -
我一定是被误导了。我没有对它进行过多的研究，因为 IE9 成为 IE 的主要版本还需要几年的时间，所以很长一段时间内看 application/xhtml+xml 已经没有任何意义了。这些天我坚持使用 HTML（尽管如果有人报告它们，我仍然会修复 Catalyst::View::ContentNegotiation::XHTML 中的错误）。
-
并不是真正的 XML 解析器 需要输出与 HTML 兼容的 XHTML，因为它是 XML 序列化器。而且真的没有那么难。我这样做，并使用内容协商为不同的用户代理提供不同的内容类型。确实需要一点编程技能，但我可能只用了一个晚上就搞定了。
-
@Alohci：我认为双媒体类型对大多数作者来说有点野心勃勃。对 CSS 模型进行了调整，并对脚本和 DOM 模型进行了重大更改，这将使使用第三方脚本和样式装饰其页面的普通 clod 绊倒。加上内容协商意味着提供
Vary标头，这会给 IE 带来很大的缓存问题。对于大多数人来说，鉴于服务application/xhtml+xml的实际优势微乎其微，我不相信这是值得的。
IE9 处理application/xhtml+xml，包括其中的 SVG，这是想要使用这种媒体类型的主要原因之一。 （否则，迄今为止使用它的意义相对较小，因为您会得到一堆脚本更改，并且 IE
我不同意 Hixie 的观点，即以 text/html 的形式提供 XHTML曾经真的有害。使用 HTML 兼容性指南，XHTML 对自古老的 Netscape 4 以来的任何浏览器都没有问题。虽然它在客户端并没有真正为您提供任何东西，但如果您正在工作，它会对您自己的页面处理工作流程有所帮助使用 XML 处理工具。并且 XML 语法规则比 HTML 更严格但更简单，对作者来说是一件好事；这使验证器有机会发现 SGML/HTML 中的有效构造但几乎可以肯定不是您的意思的错误。 （另一方面，由于验证器不会强制执行 HTML 兼容性准则，因此在一些地方它可以让格式良好但麻烦的标记通过，最常见的是自我关闭的 <script> 标记破坏整个页面.)
具体来说，回答他的观点：/> 和相关的 SGML 问题只是那些真正相信 HTML 是 SGML 的工具的问题——过去从来不是浏览器。将来，它在非 XML HTML5 中被明确允许。
从“旧”（HTML 3.2 之前！）浏览器中隐藏脚本/样式表已经有十年左右的时间了：我想出了他（正确地）嘲笑为荒谬的错误评论黑客，但它是只是一个练习；我从来没有打算让任何人使用它，除非在一些奇怪的假设紧急情况下。在 XHTML-as-HTML 中使用嵌入式脚本和样式表当然不是“必要的”...如果您需要能够包含 < 和 & 字符，并且更常见的是您甚至不需要那个。
实际上没有人想要嗅探 XHTML-as-HTML 并以不同的方式对待它，因此整个部分都没有实际意义。 “将 XHTML 1.1 作为 text/html 发送永远不会很好”已被 W3C 更改（毕竟现在很好），XHTML 2.0 已死。
是的，如果您愿意，可以使用 XHTML 1.0 Strict，或者 XHTML 1.1 或 XHTML5。但在 IE9 成为您的基准浏览器之前（ages 不会是这种情况），您必须坚持使用text/html。
【讨论】：
-
“以 text/html 格式发送 XHTML 1.1 永远不会很好”的问题是一团糟。 XHTML 工作组发布了一份说明（内容丰富，不规范，并且“未得到 W3C 成员的认可”）说没问题，但没有（据我所知）实际上覆盖了有关该主题的 IETF RFC .
-
据我了解W3C流程，如果有人写了一个草稿说“我认为x是个好主意”，而其他人没有足够的支持来支持它，这样的提案就失败了，草稿不是已删除，但以 W3C 注释的形式结束其生命。这似乎或多或少是在允许 XHTML 1.1 以 text/html 形式提供的提案中发生的情况。
-
是的，“正确的混乱”是正确的。在实践中当然没有客户端反对 XHTML 1.1 为
text/html。最初禁止这样做是为了及时将网络推送到application/xhtml+xml，以适应下一个明确与 HTML 不兼容的 XHTML 版本。当然，在现实世界中，IE 多年没有更新，也没有人想要 XHTML 2.0，所以这个计划出错了。
根据netmarketshare，在过去一年（2017 年 5 月 27 日 - 2018 年 4 月 27 日）中，IE 6、7 和 8 的总份额为 1.72%。
所有其他主流浏览器都支持真正的 XHTML（即使用 application/xhtml+xml MIME 类型发送。我对您的回答是“不，它无害”。
无论它是否有利，我想这并不重要，除非您真正了解并在 Web 上舒适地使用 XML 技术（SVG、MathML 等）（是的 HTML 语法也支持它们，但它实际上是一种 hack）。
如果浏览器制造商在 XML 解析器上投入更多精力，那么纯解析速度仍然很重要。
【讨论】：