html - XHTML strict 解决什么问题?

标签 html xhtml project-planning xhtml-1.0-strict buzzword-compliance

我真的不明白对XHTML strict 的迷恋。内联 JavaScript 通常需要大量转义以使其与 XHTML 兼容并与 MSIE 5 和 6 半向后兼容。然后是用户输入时没有足够的 OCD 以确保您不会错过任何非法字符的问题.这似乎比它的值(value)更多的努力。没关系,几乎所有与我一起工作的开发人员都忘记确保为 XHTML 页面从服务器返回的内容类型从 text/html 重置为 application/xhtml+xml。

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

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

最佳答案

XHTML1 与 HTML4 和 Strict 与 Transitional 是完全正交的问题。

XML 可能不会给今天的浏览器带来任何巨大的优势,但在服务器端,使用 XML 处理文档比尝试解析旧式 SGML 的困惑要容易一个数量级,除了不是真正的 HTML4 .

将自己限制在 [X]HTML Strict 本身并没有取得任何成就,除了它不鼓励使用无论如何都不应该使用的旧的、不易维护的技术之外。

Inline javascript typically requires a rats nest of escapes to make it compatible with XHTML

只要您不使用字符 < 或 &,您就可以毫无逃脱地逃脱。而且‘//< [CDATA[’并不比过去的‘<!--’差多少。

无论如何,将脚本保持在外部更易于管理;你不想做任何重要的内联。

Then there is the issue of not being OCD enough on user input to make sure you don't miss any illegal characters.

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

如果您接受用户提交的 HTML 并且没有仔细检查/转义它以防止格式错误,那么您遇到的问题比仅遵守文档类型要大得多。您将让注入(inject)黑客通过并使您的站点容易受到跨站点脚本安全漏洞的攻击。<​​/p>

forgetting to ensure the content-type returned from the server is reset for XHTML pages from text/html to application/html+xml.

这不是“忘记”,而是故意的:今天提供 application/xhtml+xml 并没有多大意义。考虑到 IE,你必须嗅探 UA,然后确保你理解在两种解析模式中弹出的 CSS 和 JavaScript 差异......你可以这样做来证明你的技术实力,但它并没有真正让你得到任何东西.

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

人们提示格式良好错误的挑剔,但直接拾取这些错误供您修复它们比让它们静静地留在那里,准备好让 future 的浏览器出问题要好得多。

关于html - XHTML strict 解决什么问题?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/278746/

相关文章:

html - 在换行时对齐图像图标后面的链接文本

PHP if 语句在比较字符串时始终为 TRUE

testing - 从头开始采用软件项目管理和测试协议(protocol)

iphone - 我怎样才能避免大写的iphone safari第一个字母

javascript - 根据 URL (GET) 使 DIV 不显示或阻止

html - 在不向左推文本的情况下向右侧添加字母

visual-studio - Visual Studio 的任务列表

javascript - 按比例缩放网站以适应浏览器窗口

xhtml - 如何实现面包屑的schema.org标记?

c# - Python或C#中的项目构想