我注意到很多站点(包括SO)都将XHTML用作其标记语言，但随后却没有遵守规范。只是浏览源代码，所以缺少段落，无效元素等的结束标记。

因此，如果工具(和开发人员)将要产生无效的标记，则应使用XHTML doctype吗？浏览器是否应该更坚决地接受不良加价？

并且在任何人喊伪君子之前，我的博客上都有一个涉及captha的无效标记(或者我上次检查的标记)，涉及样式化noscript标记。

解决方案

回答

这取决于。我在博客中遇到了一个问题，其中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生成的某些代码无效怎么办？我们不能责怪堆栈溢出没有产生有效的代码。
• 最后，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个是实际的错误。在其他错误的混乱中很难找到这些。自动验证可以从源头上防止这些错误。

不用说，选择一个标准并坚持下去永远不会与其他系统(屏幕抓取器，屏幕阅读器，搜索引擎)实现互操作性，而且我从来没有遇到过这样一种情况：不可能为所有人提供有效的语义XHTML和CSS解决方案主要浏览器。

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

务实而不拘泥于XHTML是一个好习惯，只是因为有人这样说而已，无论花费多少，但是凭借有关CSS和浏览器，测试和验证工具的最新知识，大多数时候收益要比成本大得多。

回答

我们可以说我在XHTML有效性上有一个OCD。我发现，代码无效的大多数问题来自程序员，他们不知道HTML和XHTML之间的区别。我已经写了100％有效的XHTML和CSS已有一段时间了，并且从未在其他浏览器上遇到任何重大渲染问题。如果我们使所有内容保持有效，并且不尝试在CSS方面做过奇特的尝试，那么我们将节省大量的修复时间。

回答

不，如果不能保证格式正确，就不应使用XHTML；实际上，如果不使用XML序列化器来生成标记，则不能保证XHTML。了解有关生成XML的信息。

格式正确是将XHTML与HTML区别开的东西。带有"仅一个"标记错误的XHTML不再是XHTML。每次都必须是完美的。

如果" XHTML"站点似乎有某些错误，那是因为浏览器会忽略DOCTYPE并将页面解释为HTML。

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