无效的 XHTML 是否可以接受？
https://stackoverflow.com/questions/3448
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我注意到很多网站（包括 SO）都使用 XHTML 作为标记语言，但却未能遵守规范。只需浏览 SO 的源代码，就会发现缺少段落的结束标签、无效元素等。
那么，如果工具（和开发人员）要生成无效标记，是否应该使用 XHTML 文档类型？浏览器是否应该更坚定地接受低劣的标记？
在有人大喊虚伪之前，我的博客有一个涉及 captha 的无效标记（或者我上次检查时确实如此），其中涉及 noscript 标签的样式。
解决方案
有 很多原因 使用有效的标记。我最喜欢的是，它允许您使用验证作为回归测试的一种形式，一旦错误达到一定的临界质量，就可以防止“delta rot”等价的标记导致真正的渲染问题。事实上，允许诸如拼写错误和错误嵌套/未封闭标签之类的“懒惰”错误累积是非常草率的。有效标记是识别的一种方法 充满激情的程序员.
还有调试的问题：有效的标记还为您提供了一个稳定的基线，可以在此基础上解决不可避免的跨浏览器兼容性问题。任何重视时间的 Web 开发人员都不应该在没有首先确保标记至少是的情况下开始调试浏览器兼容性问题。 句法上 有效——任何其他无效标记都应该有充分的理由存在。
（顺便说一句，stackoverflow.com 未能通过这两项测试，以及解决问题的建议 是 拒绝.)
综上所述，为了回答您的具体问题，可能不值得使用 XHTML 文档类型之一，除非您计划生成有效的（或在 至少 格式良好）标记。XHTML 的主要优点源于 XHTML 是 XML，允许使用 XML 的工具和技术对其进行处理和转换。如果您不打算使您的 XHTML 格式良好，那么选择该文档类型就没有意义。最新的 HTML 4 规范可能会满足您所需的一切，而且更加宽容。
其他提示
我们应该始终努力使其根据标准进行验证。我们将确保该网站能够在当前浏览器和未来的浏览器上正常显示和工作。
我认为，如果您指定了一个文档类型，就没有任何理由不遵守该文档类型。
使用 XHTML 使自动错误检测变得容易，每次更改都可以自动检查无效标记。这可以防止错误，尤其是在使用自动生成的内容时。对于使用模板引擎（JSP、ASP.NET StringTemplate 等）的 Web 开发人员来说，复制/粘贴一个结束标记太少或太多确实很容易。当这是您唯一的错误时，可以立即检测到并修复它。我曾经工作过一个网站，该网站每页有 165 个验证错误，其中 2 或 3 个是实际错误。在混乱的其他错误中很难找到这些错误。自动验证可以从源头上防止这些错误。
不用说，选择一个标准并坚持它永远不会有利于与其他系统（屏幕抓取器、屏幕阅读器、搜索引擎）的互操作性，而且我从未遇到过无法为所有人提供有效的语义 XHTML 和 CSS 解决方案的情况主要浏览器。
显然，在使用复杂的系统时，并不总是能够坚持您的文档类型，但这主要是由于开发这些系统的不同部分（或者很可能是遗留系统）的不同团队之间沟通不当造成的。在最后一种情况下，最好隔离这些情况并相应地更改您的文档类型。
务实一点是好事，不要仅仅因为有人这么说就坚持 XHTML，不考虑成本，但以当前有关 CSS 和浏览器、测试和验证工具的知识，大多数时候好处远远大于成本。
你可以说我对 XHTML 有效性有强迫症。我发现代码无效的大多数问题都来自于程序员不了解 HTML 和 XHTML 之间的区别。我编写 100% 有效的 XHTML 和 CSS 已经有一段时间了，并且在使用其他浏览器时从未遇到过任何重大的渲染问题。如果你保持一切有效，并且不要尝试任何太奇特的 css 明智的东西，你将为自己节省大量的修复时间。
我根本不会使用 XHTML 只是为了减轻自己的哲学压力。无论如何，并不是任何浏览器都将其视为 XHTML。
如果页面作为 application/xhtml+xml 发送，浏览器将拒绝不良标记，但这种情况很少发生。这可以。
我更关心诸如在 Stack Overflow 中内联使用 CSS 和 JavaScript 之类的事情，因为它们使维护变得更加困难。
尽管我相信要努力实现有效的 XHTML 和 CSS，但由于多种原因，这通常很难做到。
- 首先，一些内容可以通过 AJAX 加载。有时，片段未正确插入到现有 DOM 中。
- 您正在查看的 HTML 可能并非全部生成在同一个文档中。例如，页面可以由组件或模板组成，然后在浏览器呈现它之前将其组合在一起。这不是借口，但您不能假设您所看到的 HTML 是一次性手动编码的。
- 如果 Markdown 生成的某些代码无效怎么办？你不能责怪 Stack Overflow 没有生成有效的代码。
- 最后，DOCTYPE 的目的不是简单地说“嘿，我正在使用有效的代码”，而是让浏览器了解您正在尝试执行的操作，以便它至少可以接近正确解析该信息。
我不认为大多数开发人员指定了 DOCTYPE，然后明确地不遵守它。
虽然我同意“如果它渲染得很好，那就不用担心”的说法，但是遵循标准是有好处的，尽管它现在可能没有得到完全支持。您仍然可以使用 Table 进行布局，但它不好是有原因的。
不，如果不能保证格式良好，则不应使用 XHTML，并且在实践中，如果不使用 XML 序列化程序生成标记，则无法保证格式良好。读 关于生成 XML.
良构性是 这 XHTML 与 HTML 的区别。带有“只有一个”标记错误的 XHTML 不再是 XHTML。 每次都必须完美.
如果“XHTML”网站运行时出现一些错误，那是因为 浏览器忽略 DOCTYPE 并将页面解释为 HTML。
看 XHTML代理 强制将页面解释为 XHTML。大多数时候 他们惨败. 。这就是 XHTML 的未来充满不确定性的原因之一 为什么 HTML 的开发已经恢复.
这取决于。我有那个 我的博客有问题 YouTube 视频导致 XHTML 无效，但呈现良好。另一方面，我有一个“有效的 XHTML”链接，并且“有效的 XHTML”声明和无效的 XHTML 的组合并不专业。
由于 SO 并不声称有效，我认为这是可以接受的，但就我个人而言，如果我是杰夫，我会很烦恼并尝试修复它，即使它在现代浏览器中看起来不错，但有些人宁愿继续前进并实际完成工作而不是修复不存在的错误。
只要它能在 IE、FF、Safari（此处插入其他浏览器）中运行，就应该没问题。验证并不像在多个浏览器中正确呈现那么重要。例如，仅仅因为它有效，并不意味着它可以在 IE 中正常工作。
在您的网站上运行 Google Analytics 或类似工具，查看您的用户正在使用哪种浏览器，然后判断您最需要支持哪些浏览器，并在您有空闲时间时考虑不太重要的浏览器。
我说，如果它渲染得很好，那么它的像素是否完美并不重要。
需要一段时间才能让网站按照您想要的方式启动并运行，返回并进行更改将稍微改变页面呈现的方式，然后您必须修复 那些 问题。
现在，我并不是说您应该构建草率的网页，但我认为没有理由修复未损坏的内容。浏览器不会在不久的将来放弃对纠错的支持。
我不明白为什么当某些浏览器在正确呈现标准代码时仍然存在问题时，每个人都在努力使自己的网站符合标准。我从事网页设计大约有 10 年了，我停止了双重编码（阅读：黑客攻击CSS），并改变愚蠢的东西，这样我就可以在我的网站上放置一个按钮。
我相信使用 <div> 无论如何都会导致你无效，并且如果没有它，执行任何主要的 JavaScript/AJAX 都会变得有点困难。
标准如此之多，但它们的“执行”或支持却如此糟糕，我认为这并不重要。不要误会我的意思，我认为应该有标准，但由于这些标准没有得到执行，所以没有人遵循它们，这是一个巨大的螺旋式下降。
对于 99.999% 的网站来说，这真的不重要。我唯一一次遇到这种情况是，我通过 HTMLTidy 运行 HTML 输入以对其进行 XHTML 化，然后对其进行处理。
几乎，这是老程序员的公理：不信任任何输入。
