我注意到很多网站，包括 SO，使用 XHTML 作为他们的标记语言，然后不遵守规范。只是浏览 SO 的源代码，缺少段落、无效元素等的结束标签。
那么，如果工具（和开发人员）要生成无效标记，是否应该使用 XHTML 文档类型？浏览器是否应该更坚定地接受不良标记？
在有人大喊伪君子之前，我的博客有一段无效标记涉及 captha（或者我上次检查时确实如此），其中涉及到 noscript 标签的样式。
【问题讨论】：
有many reasons 可以使用有效的标记。我最喜欢的是它允许您将验证用作回归测试的一种形式，一旦错误达到临界质量，就可以防止“delta rot”的标记等价物导致真正的渲染问题。确实，允许诸如拼写错误和错误嵌套/未关闭的标签之类的“懒惰”错误累积是很草率的。有效标记是识别passionate programmers 的一种方式。
还有调试问题：有效的标记还为您提供了一个稳定的基线，可以用来解决不可避免的跨浏览器兼容性问题。任何珍惜时间的 Web 开发人员都不应在未首先确保标记至少在句法上有效的情况下开始调试浏览器兼容性问题——任何其他无效标记都应有充分的理由出现。
（顺便说一句，stackoverflow.com 未能通过这两项测试，以及解决问题的建议weredeclined。）
综上所述，要回答您的具体问题，除非您计划生成有效（或至少格式良好的）标记，否则可能不值得使用其中一种 XHTML 文档类型。 XHTML 的主要优势源于 XHTML 是 XML 的事实，它允许通过使用 XML 的工具和技术对其进行处理和转换。如果您不打算使您的 XHTML 格式良好的 XML，那么选择该 doctype 就没有什么意义了。最新的 HTML 4 规范可能会满足您的所有需求，而且更加宽容。
【讨论】：
我们应该始终尝试使其根据标准进行验证。我们将确保该网站能够在当前浏览器和未来的浏览器上正常显示和运行。
【讨论】：
我不认为，如果你指定了一个文档类型，没有任何理由不遵守这个文档类型。
使用 XHTML 使自动错误检测变得容易，每次更改都可以自动检查无效标记。这可以防止错误，尤其是在使用自动生成的内容时。对于使用模板引擎（JSP、ASP.NET StringTemplate 等）的 Web 开发人员来说，复制/粘贴一个关闭标记太少或太多是非常容易的。当这是您唯一的错误时，可以立即检测并修复它。我曾经为一个每页有 165 个验证错误的网站工作，其中 2 或 3 个是实际错误。这些在其他错误的混乱中很难找到。自动验证可以从源头上防止这些错误。
不用说，选择一个标准并坚持它永远不会有利于与其他系统（屏幕抓取器、屏幕阅读器、搜索引擎）的互操作性，而且我从未遇到过这样的情况，即使用 CSS 解决方案的有效语义 XHTML适用于所有主流浏览器。
显然，在处理复杂系统时，并非总是可以坚持使用您的 doctype，但这主要是由于开发这些系统的不同部分的不同团队之间沟通不当造成的，或者很可能是遗留系统。在最后一种情况下，最好隔离这些情况并相应地更改您的文档类型。
务实而不是仅仅因为有人这么说就坚持 XHTML 是件好事，不计成本，但以当前对 CSS 和浏览器、测试和验证工具的了解，大多数时候收益远大于成本。
【讨论】：
你可以说我对 XHTML 有效性有强迫症。我发现代码无效的大部分问题来自于程序员不知道 HTML 和 XHTML 之间的区别。我一直在编写 100% 有效的 XHTML 和 CSS 或一段时间，并且在使用其他浏览器时从未遇到过任何重大的渲染问题。如果您保持一切有效，并且不要尝试任何过于奇特的 css，您将节省大量的修复时间。
【讨论】：
我根本不会使用 XHTML 来减轻自己的哲学压力。无论如何，并不是任何浏览器都将其视为 XHTML。
如果页面以 application/xhtml+xml 的形式发送，浏览器将拒绝糟糕的标记，但它们很少这样做。这很好。
我会更关心诸如内联使用 CSS 和 JavaScript 与 Stack Overflow 之类的事情，只是因为它们使维护变得更加困难。
【讨论】：
虽然我相信努力获得有效的 XHTML 和 CSS，但由于多种原因，这通常很难做到。
我认为大多数开发人员不会指定 DOCTYPE，然后明确地不遵守它。
【讨论】：
虽然我同意“如果它渲染得很好，那就不用担心”的观点，但是遵循标准是好的，即使它现在可能不完全支持。您仍然可以使用 Table 进行布局，但它不好是有原因的。
【讨论】：
不，如果不能保证格式正确，则不应使用 XHTML，实际上，如果不使用 XML 序列化程序生成标记，则不能保证它。阅读about producing XML。
格式良好是 XHTML 与 HTML 的区别。带有“只有一个”标记错误的 XHTML 不再是 XHTML。 每次都必须完美。
如果“XHTML”网站出现一些错误，那是因为browsers ignore the DOCTYPE 并将页面解释为 HTML。
请参阅XHTML proxy，它强制将页面解释为 XHTML。大多数时候they fail miserably。这也是 XHTML 前途未卜的原因之一，why development of HTML has been resumed。
【讨论】：
这取决于。我有那个issue with my blog，YouTube 视频导致 XHTML 无效，但它呈现得很好。另一方面，我有一个“有效 XHTML”链接，“有效 XHTML”声明和无效 XHTML 的组合并不专业。
由于 SO 没有声称是有效的，我认为这是可以接受的，但就我个人而言，如果我是 Jeff，我会感到困扰并尝试修复它，即使它在现代浏览器中看起来不错，但有些人宁愿继续前进，实际上把事情做好，而不是修复不存在的错误。
【讨论】：
只要它可以在 IE、FF、Safari 中运行（在此处插入其他浏览器）就可以了。验证不如让它在多个浏览器中正确呈现重要。例如，仅仅因为它是有效的，并不意味着它可以在 IE 中正常工作。
在您的网站上运行 Google Analytics（分析）或类似工具，查看您的用户正在使用哪种浏览器，然后判断您最需要支持哪些浏览器，并在您有空闲时间时担心不太重要的浏览器。
【讨论】：
我说，如果它渲染得很好，那么它是否像素完美也没关系。
让网站按照您想要的方式启动和运行需要一段时间，返回并进行更改会稍微改变页面的呈现方式，然后您必须解决这些问题.
现在，我并不是说您应该构建草率的网页，但我认为没有理由修复未损坏的内容。浏览器不会在不久的将来随时放弃对纠错的支持。
【讨论】：
我不明白为什么当一些浏览器在正确呈现标准代码时仍然存在问题时，为什么每个人都试图让他们的网站符合标准。我从事网页设计已经有 10 年了，我停止了双重编码（阅读：hacking css），并改变了愚蠢的东西，只是为了在我的网站上放一个按钮。
我相信使用 无论如何都会导致您无效，并且如果没有它，执行任何主要的 JavaScript/AJAX 都会变得有点困难。
【讨论】：
有很多标准，而且它们的“执行”或支持很差，我认为这并不重要。不要误会我的意思，我认为应该有标准，但由于没有强制执行，没有人遵循它们，这是一个巨大的螺旋式下降。
【讨论】：
对于 99.999% 的网站，这真的无关紧要。唯一一次重要的是，我通过 HTMLTidy 运行 HTML 输入以对其进行 XHTML 化，然后对其进行处理。
几乎，这是老程序员的公理：不信任任何输入。
【讨论】：