XHTML strict 解决了什么问题？

我真的不明白 XHTML strict 的魅力。内联 JavaScript 通常需要大量的转义以使其与 XHTML 兼容，并与 MSIE 5 和 6 半向后兼容。然后就存在对用户输入的强迫症不够严重的问题，以确保您不会错过任何非法字符。这看起来只是付出了更多的努力，而不是其价值。没关系，我一起工作的几乎每个开发人员都忘记确保从服务器返回的内容类型被重置为 XHTML 页面，从 text/html 到 application/xhtml+xml。

希望我知道博主的名字，但其他人指出，大多数所谓的 XHTML 兼容网站和开源包实际上并不是因为最后一个问题，忘记了正确设置内容类型标头。

我希望了解为什么 XHTML 有用，或者构建足够多的论据以防止它在我影响的未来项目中使用。

XHTML1 与 HTML4 以及严格与过渡是完全正交的问题。

XML 可能不会给当今的浏览器带来任何巨大的优势，但在服务器端，使用 XML 处理文档比尝试解析旧式 SGML（除了不是真正的 HTML4 之外）的混乱要容易一个数量级。

将自己限制在 [X]HTML Strict 本身并没有实现任何目标，除了它阻止使用您无论如何都不应该使用的旧的、难以维护的技术之外。

内联 JavaScript 通常需要大量转义以使其与 XHTML 兼容

只要不使用字符

无论如何，将脚本保留在外部更容易管理；你不想做任何重要的内联事情。

然后存在的问题是对用户输入的强迫症不够大，以确保您不会错过任何非法字符。

带外字符在 HTML4 Transitional 中与在 XHTML1 Strict 中一样无效。

如果您接受用户提交的 HTML，并且没有足够仔细地检查/转义它以防止格式良好的错误，那么您将遇到比仅仅遵守文档类型更大的问题。您将允许注入攻击，并使您的网站容易受到跨站点脚本安全漏洞的攻击。

忘记确保将 XHTML 页面从服务器返回的内容类型从 text/html 重置为 application/html+xml。

这不是“忘记”，而是有意为之：今天提供 application/xhtml+xml 服务并没有多大意义。为了解释 IE，你必须嗅探 UA，然后确保你理解两种解析模式中出现的 CSS 和 JavaScript 差异......你可以这样做来证明你的技术实力，但它并不能真正给你带来任何好处。

将 XHTML 作为旧版 HTML 提供可能并不理想，但它可以让您保留更简单、更易于处理的 XML 语法（以及与 SVG 等其他 XML 语言的潜在互操作性），同时仍然对浏览器友好。

人们抱怨格式正确的错误过于挑剔，但立即发现这些错误并修复它们，比默默地将它们留在那里，准备让未来的浏览器出错要好得多。