我现在正在构建一个网站，到目前为止，我已经痛苦地强制所有内容都合规，并且它在浏览器中看起来几乎相同。但是，我开始实现一些第三方/免费的 javascript，它们执行诸如添加属性之类的操作（例如 order=2）。我可以解决这个问题，但这很痛苦，而且我开始失去确保一切都有效的原则。真的，解决这样的事情有什么意义吗？我得到了 firefox 的 HTMLValidator 插件，并且查看了大多数主要网站（包括这个、google 等），它们不是有效的 XHTML 或 HTML。
【问题讨论】：
标签： html xhtml standards-compliance
当然，您总是可以继续按照您想要的方式编写它，并确保它至少可以正常工作。当然，我们已经经历过这种心态，也见证了它的输出，Internet Explorer 6。
我是Mike Davidson approach to standards-oriented development 的忠实粉丝。
仅仅因为您可以验证您的代码并不意味着您比其他任何人都好。哎呀，这甚至并不一定意味着您编写的代码比其他任何人都好。可以完全在 Flash 中编写银行应用程序的人是比您更好的编码器。可以将第三方代码集成到复杂的发布环境中的人是比你更好的编码员。将验证视为使用图片完美语法；它可以帮助您传达您的想法，并且是良好教育的标志，但它并不像您想到并随后交流的想法和概念那么重要。我曾经为之工作过的最有魅力，可能也是最聪明的人来自南方，并且经常使用“不是”这个词。这并没有让他变得更聪明，事实上，这让他更令人难忘。所以我想说的是，有很多事情可以判断一个人……验证是其中之一，但肯定不是最重要的。
很多人误解这篇文章的意思是我们不应该按照标准进行编码。显然，我们应该，但这甚至不应该被真正考虑。 验证大军总是会谴责那些不验证的，但验证的意义远不止有效代码。
所以，不要失去你的原则，但请记住，如果你遵循标准，你在未来陷入深层次问题的可能性就会大大降低。您尝试提供的内容远比其显示方式重要。
【讨论】：
这无论如何都不是毫无意义的，但是有很多理由可以打破它。在 CSS 开发的初始阶段，如果您的标记有效，它对于诊断浏览器问题非常有用。除此之外，如果你想做某事并且你觉得最合适的方法是打破验证，那通常是可以的。
使用自定义属性的替代方法是使用“rel”属性，例如参见Litebox（及其亲属）。
【讨论】：
就浏览器而言，XHTML 合规性毫无意义：
浏览器没有 XHTML 解析器。它们具有非特定于版本、与 Web 兼容的 HTML 解析器，可围绕 http://www.w3.org/1999/xhtml 命名空间构建 DOM。
某些具有 XML 解析器的浏览器可以将作为应用程序/xhtml+xml 的 XHTML 标记视为 XML。这将采用 XML 并为 http://www.w3.org/1999/xhtml 命名空间中的元素提供默认的 HTML 样式和行为。但是，就解析而言，它与 XHTML 无关。遵循 XML 解析规则，而不是某些 XHTML DTD 的规则。
因此，当您使用 XHTML 标记时，您是在向浏览器提供一些陌生的东西，并查看它是否如您所愿。问题是，您可以使用任何标记来执行此操作。如果它按预期呈现并生成正确的 DOM，那么你做得很好。您只需要确保记住 DOCTYPE 切换，并确保您不依赖浏览器错误（因此在没有错误的浏览器中事情不会崩溃）。
XHTML 合规性的好处是语法检查（通过验证）以查看标记是否格式正确。这有助于避免解析错误。当然，这也可以用 HTML 完成，所以在这种情况下 XHTML 没有什么特别之处。无论哪种方式，您仍然需要在浏览器中进行测试，并希望浏览器供应商能够做出能够接受各种废话的出色 HTML 解析器。
尝试符合浏览器的期望并不是没有意义的。 HTML5 帮助了这个大时代。而且，说到 HTML5，您可以随心所欲地定义自定义属性。只需在它们前面加上 data-，如
test
.【讨论】：
我还没有遇到过添加非标准属性导致任何浏览器出现渲染问题的情况。
不要试图绕过那些非标准属性。验证器作为工具可以方便地仔细检查您的代码是否存在意外错误，但众所周知，即使是完全有效的 xhtml 也不会总是在浏览器中一致地呈现。很多时候，设计决策要求我们使用特定于浏览器的（和非标准的）hack 来实现效果。这就是网络开发人员的生活，许多技术驱动的网站（谷歌、雅虎等）无法验证。
【讨论】：
我认为编写“有效代码”很重要，因为您是在遵循规则树立榜样。如果每个开发人员都为 Fx、Safari 和 Opera 编写过代码，我认为 IE 必须比版本 8 更早地“开始遵循规则”。
【讨论】：
我大部分时间都在尝试编写合规代码，在所有情况下都会权衡时间/成本与受众的需求，但只有一种情况除外。如果您的代码需要符合 503 标准，那么编写符合标准的代码符合您的最大利益和受众的利益。我遇到了一堆屏幕阅读器，当代码稍微偏离时它们就会爆炸。
就像大多数海报所说的那样，这完全取决于观众的需求。
【讨论】：
标准合规性是为了增加您的网页在您未测试的浏览器中运行的机会。这包括屏幕阅读器、您进行测试的浏览器的下一次更新，以及您进行测试但用户以意外方式配置的浏览器。
验证并不能向您保证任何事情，因为您的页面可能会验证但仍然足够模糊，以至于有一天它在某些浏览器上的行为方式不会像您希望的那样。
但是，如果您的页面确实通过了验证，那么您至少有 XHTML 规范的力量来说明它应该如何表现。如果它没有通过验证，那么你所拥有的只是浏览器编写者之间的一堆非正式约定。
编写有效的 HTML 3 可能比编写无效的 XHTML 更好，如果您想做的事情在其中一个允许但另一个不允许。
【讨论】：
如果您打算将 XHTML 用作 XML，那么让您的页面有效且格式良好是值得的。否则，您可能想要普通的旧语义 HTML。无论哪种方式，您的受众的需求都超过了验证者的需求。
【讨论】：
HTML Valid 通常对您和浏览器渲染引擎都有帮助。浏览器必须处理的怪癖越少，它们就越能专注于添加新功能。你越严格，你花在思考为什么这个 f@#cking 专有标签在其他浏览器中不起作用的时间就越少。
另一方面，恕我直言，XHTML 更没有意义，除非您打算将它集成到某个 XML 文档中。由于 IE 仍然无法识别它，所以坚持使用它是毫无用处的。
【讨论】：
验证对于确定何时未能达到您可能同意的标准很有用。如果您有意使用专门添加验证标准之外的内容的工具，显然这不会违反您的个人标准协议。
如果您的老板或客户认为一切都应该重新开绿灯，那么这种讨论会变得更加困难，因为您必须向他们解释上述内容并说服他们不仅仅是您懒惰。
也就是说，请确保这不仅仅是您懒惰的情况。虽然验证器可能会烦人地不断提出第三方属性的每个实例，但这并不会使他们提到的其他验证错误无效（ha）。作为仔细检查您的工作的一种方式，通常值得仔细阅读。
【讨论】：
请记住，XHTML 标记在大多数浏览器中的呈现方式与没有它时不同。 DOCTYPE 属性确定浏览器呈现的模式，并规定什么是允许的，什么是不允许的。如果您偏离 XHTML 合规性，请务必在所有浏览器中重新测试。
我个人尽可能坚持最新标准，但您必须权衡时间/金钱与合规性，这取决于大多数人的个人喜好。
【讨论】：