对于无效的 XHTML，是否可以接受？

这要视情况而定。我的博客遇到了这个问题，其中 YouTube 视频导致无效的 XHTML，但它呈现得很好。另一方面，我有一个“有效 XHTML”链接，并且“有效 XHTML”声明和无效 XHTML 的组合并不专业。

由于 SO 不声称是有效的，我认为这是可以接受的，但就我个人而言，如果我是 Jeff，我会很烦恼并尝试修复它，即使它在现代浏览器中看起来不错，但有些人宁愿继续前进并实际完成工作，而不是修复不存在的错误。

只要它在 IE、FF、Safari 中工作，（在此处插入其他浏览器）您应该没问题。验证并不像在多个浏览器中正确呈现它那么重要。例如，仅仅因为它是有效的，并不意味着它可以在IE中正常工作。

在您的网站上运行 Google Analytics 或类似浏览器，看看您的用户正在使用哪种浏览器，然后判断您最需要支持哪些浏览器，并在有空闲时间时担心不太重要的浏览器。

我根本不会为了给自己省去哲学压力而使用 XHTML。无论如何，它不像任何浏览器都将其视为XHTML。

如果页面以 application/xhtml+xml 的形式发送，浏览器会拒绝较差的标记，但很少会拒绝。这很好。

我更关心的是 CSS 和 JavaScript 与 Stack Overflow 的内联使用，因为它们使维护更加困难。

我说，如果它渲染正常，那么它是否像素完美并不重要。

让一个网站按照你想要的方式启动和运行需要一段时间，回去进行更改会稍微改变页面的呈现方式，然后你必须解决这些问题。

现在，我并不是说你应该构建草率的网页，但我认为没有理由修复没有损坏的东西。在不久的将来，浏览器不会放弃对纠错的支持。

我不明白为什么当某些浏览器在正确呈现标准代码时，每个人都会试图使他们的网站符合标准。我从事网页设计已经有 10 年了，我停止了双重溺爱（阅读：hacking css），并更改了愚蠢的东西，以便我可以在我的网站上放置一个按钮。

我相信使用< div>无论如何都会导致您无效，并且如果没有它，做任何主要的 JavaScript/AJAX 都会变得有点困难。

有这么多的标准，它们被“执行”或支持得如此糟糕，我认为这并不重要。不要误会我的意思，我认为应该有标准，但由于它们没有被执行，所以没有人遵循它们，这是一个巨大的螺旋式下降。

虽然我相信努力实现有效的XHTML和CSS，但由于多种原因，这通常很难做到。

• 首先，一些内容可以通过 AJAX 加载。有时，片段未正确插入到现有 DOM 中。
• 您正在查看的 HTML 可能并非全部生成在同一文档中。例如，页面可以由组件或模板组成，然后在浏览器呈现之前将其组合在一起。这不是借口，但你不能假设你看到的 HTML 是一次性手动编码的。
• 如果 Markdown 生成的部分代码无效怎么办？你不能责怪 Stack Overflow 没有生成有效的代码。
• 最后，DOCTYPE的目的不是简单地说“嘿，我使用的是有效的代码”，而是让浏览器知道你正在尝试做什么，以便它至少可以接近正确解析该信息。

我不认为大多数开发人员指定了 DOCTYPE，然后明确地不遵守它。

对于99.999%的网站来说，这真的无关紧要。我唯一一次遇到这个问题时，我通过 HTMLTidy 运行 HTML 输入以对其进行 XHTML 化，然后对其进行处理。

这几乎是老程序员的公理：不相信输入。

虽然我同意“如果它很好，那就不用担心”的说法，但是它有利于遵循标准，即使它现在可能没有得到完全支持。您仍然可以使用 Table 进行布局，但这是有原因的。

使用有效标记的原因有很多。我最喜欢的是，它允许您使用验证作为回归测试的一种形式，防止等价于“delta rot”的标记在错误达到某个临界质量时导致真正的渲染问题。实际上，允许“懒惰”错误（如拼写错误和错误嵌套/未关闭的标签）累积起来是很草率的。有效的标记是识别充满激情的程序员的一种方式。

还有调试的问题：有效的标记还为您提供了一个稳定的基线，从中可以解决不可避免的跨浏览器兼容性问题。任何珍惜时间的 Web 开发人员都不应该在开始调试浏览器兼容性问题之前，首先要确保标记至少在语法上是有效的，而任何其他无效的标记都应该有充分的理由存在。

（顺便说一句，stackoverflow.com 这两个测试都失败了，解决问题的建议被拒绝了。

综上所述，为了回答您的具体问题，除非您计划生成有效（或至少格式良好）的标记，否则可能不值得使用其中一种 XHTML 文档类型。XHTML的主要优点在于XHTML是XML，允许它通过处理XML的工具和技术进行处理和转换。如果您不打算将 XHTML 格式正确的 XML，那么选择该文档类型就没有意义了。最新的 HTML 4 规范可能会满足您的所有需求，而且它更加宽容。

我们应该始终尝试使其根据标准进行验证。我们将确保该网站将在当前浏览器和未来浏览器上显示并正常运行。

我不认为，如果您指定了文档类型，则没有任何理由不遵守此文档类型。

使用 XHTML 使自动错误检测变得容易，可以自动检查每个更改是否存在无效标记。这样可以防止错误，尤其是在使用自动生成的内容时。对于使用模板引擎（JSP、ASP.NET StringTemplate 等）的 Web 开发人员来说，复制/粘贴一个结束标签太少或太多非常容易。当这是您唯一的错误时，可以立即检测并修复它。我曾经为一个网站工作，每个页面有 165 个验证错误，其中 2 或 3 个是实际错误。这些在其他错误的混乱中很难找到。自动验证本来可以在源头上防止这些错误。

毋庸置疑，选择一个标准并坚持下去永远不会有利于与其他系统（屏幕抓取工具、屏幕阅读器、搜索引擎）的互操作性，而且我从未遇到过一种情况，即所有主流浏览器都不可能使用带有 CSS 解决方案的有效语义 XHTML。

显然，在处理复杂系统时，并不总是能够坚持使用文档类型，但这主要是由于开发这些系统不同部分的不同团队之间沟通不当的结果，或者很可能是遗留系统。在最后一种情况下，最好隔离这些情况并相应地更改文档类型。

务实一点是件好事，不要因为有人这么说就坚持XHTML，不管成本如何，但以目前对CSS和浏览器、测试和验证工具的了解，大多数时候收益远远大于成本。

你可以说我对XHTML的有效性有强迫症。我发现代码无效的大多数问题都来自程序员不知道HTML和XHTML之间的区别。我一直在编写 100% 有效的 XHTML 和 CSS 或一段时间，并且从未遇到过其他浏览器的任何重大渲染问题。如果你保持一切有效，并且不尝试任何太奇特的css明智，你将为自己节省大量的修复时间。

不可以，如果不能保证格式正确，则不应使用 XHTML，而实际上，如果不使用 XML 序列化程序生成标记，则无法保证 XHTML。阅读有关生成 XML 的信息。

格式良好是 XHTML 与 HTML 的区别。带有“只有一个”标记错误的 XHTML 不再是 XHTML。它每次都必须是完美的。

如果“XHTML”网站似乎存在一些错误，那是因为浏览器忽略了 DOCTYPE 并将页面解释为 HTML。

请参阅强制将页面解释为 XHTML 的 XHTML 代理。大多数时候，他们惨遭失败。这也是为什么XHTML的未来是不确定的，也是为什么HTML的发展已经恢复的原因之一。