我现在正在建立一个网站，到目前为止，我一直在痛苦地强迫所有内容都符合要求，并且在所有浏览器中看起来都差不多。但是，我开始实现一些第三方/免费的javascript，它们执行诸如添加属性的操作(例如，order = 2)。我可以解决这个问题，但这很痛苦，而且我开始失去确保一切都有效的原则。真的，有没有必要解决类似这样的问题？我得到了用于firefox的HTMLValidator插件，并且查看了大多数主要网站(包括该网站，google等)，它们不是有效的XHTML或者HTML。

解决方案

请记住，在大多数浏览器中，XHTML标记的呈现方式与不呈现时有所不同。 DOCTYPE属性确定浏览器呈现的模式，并指示允许和禁止的模式。如果我们违反XHTML规范，请务必在所有浏览器中重新测试。

我个人尽可能使用最新的标准，但是我们必须权衡时间/金钱与合规性，这取决于大多数人的个人喜好。

验证对于确定何时无法满足我们可能同意的标准很有用。如果我们有目的地使用的工具专门添加了验证标准中未包含的内容，那么这显然不会违反个人标准协议。

如果我们有一个老板或者客户认为一切都应该得到批准，那么讨论将变得更加困难，因为我们必须向他们解释以上内容，并说服他们，这不仅仅是我们懒惰。

也就是说，请确保这不仅仅是因为我们懒惰。尽管验证者可能会烦人地不断提出第三方属性的每个实例，但这并不会使(他们)提到的其他验证错误无效。作为仔细检查工作的一种方法，通常值得进行扫描。

HTML有效通常对我们和浏览器呈现引擎都有帮助。浏览器需要处理的怪癖越少，他们就越会专注于添加新功能。我们越严格，就会花更少的时间去思考为什么这个f @＃cking专有标签在其他浏览器中不起作用。

另一方面，恕我直言，XHTML毫无意义，除非我们计划将其集成到某些XML文档中。由于IE仍然无法识别它，因此坚持下去是没有用的。

如果我们打算利用XHTML作为XML，那么使页面有效且格式正确是值得的。否则，可能会想要普通的旧语义HTML。无论哪种方式，观众的需求都超过了验证者的需求。

符合标准是要增加页面在未经测试的浏览器中运行的机会。这包括屏幕阅读器以及我们要测试的浏览器的下一个更新，以及我们要测试但却由用户以意外方式配置的浏览器。

验证不能为我们提供任何保证，因为页面可以进行验证，但仍然不够明确，以致于某天在某些浏览器上不会表现出我们希望的方式。

但是，如果页面确实通过了验证，那么我们至少具有XHTML规范的力量来说明其行为。如果没有通过验证，那么我们所拥有的就是浏览器编写者之间的一系列非正式约定。

如果我们想做某件事，但不允许另一件事，那么编写有效的HTML 3可能比无效的XHTML更好。

在大多数情况下，我都会尝试编写兼容的代码，权衡时间/成本与受众需求之间的关系，只有一种情况。如果代码需要符合503标准，那么编写符合标准的代码既符合最大利益，也符合听众的利益。我遇到了许多屏幕阅读器，当代码甚至稍微关闭时，它们就会爆炸。

就像大多数海报所说的那样，这实际上就是听众需要的东西。

我认为编写"有效代码"很重要，这仅仅是因为我们通过遵循规则来设置示例。如果每个开发人员都为Fx，Safari和Opera写过代码，我认为IE必须比版本8更早地"开始遵循规则"。

我还没有遇到这样一个实例：添加非标准属性会导致任何浏览器出现渲染问题。

不要尝试解决这些非标准属性。验证器非常有用，可以作为工具仔细检查代码中是否存在意外错误，但是众所周知，即使是完全有效的xhtml也不会始终在浏览器中呈现一致。很多时候，设计决策要求我们使用特定于浏览器的(和非标准的)hack来达到效果。这是Web开发人员的生命，这一点可以通过未经验证的技术驱动网站(谷歌，雅虎等)的数量来证明。

无论如何，这并不是没有意义的，但是有足够的理由打破它。在CSS开发的初始阶段，如果标记有效，则对于诊断浏览器问题非常有用。除此之外，如果我们想做某事并且觉得最合适的方法是取消验证，那通常就可以了。

使用自定义属性的一种替代方法是使用'rel'属性，例如，请参见Litebox(及其同类)。

就浏览器而言，XHTML的合规性是没有意义的：

• 浏览器没有XHTML解析器。它们具有非特定于版本的，与Web兼容的HTML解析器，这些解析器围绕http://www.w3.org/1999/xhtml命名空间构建DOM。
• 某些具有XML解析器的浏览器可以将XHTML标记作为application / xhtml + xml视为XML。这将采用XML，并为http://www.w3.org/1999/xhtml命名空间中的元素提供默认的HTML样式和行为。但是，就解析而言，它与XHTML无关。遵循XML解析规则，而不遵循某些XHTML DTD规则。

因此，当我们使用XHTML标记时，我们将给浏览器一些陌生的东西，看看它是否按预期出现。问题是，我们可以使用任何标记来执行此操作。如果它按预期进行渲染并生成正确的DOM，则说明我们做得很好。我们只需要确保牢记切换DOCTYPE并确保我们不依赖浏览器错误(因此在没有该错误的浏览器中不会分崩离析)。

符合XHTML的好处是语法检查(通过验证)以查看标记是否格式正确。这有助于避免解析错误。当然，这也可以用HTML来完成，因此在这种情况下，XHTML没什么特别的。无论哪种方式，我们仍然必须在浏览器中进行测试，并希望浏览器供应商制造出可以接受各种废话的超赞HTML解析器。

努力符合浏览器的期望并不是没有意义的。 HTML5帮了大忙。而且，就HTML5而言，我们可以定义所有所需的自定义属性。只需在它们前面加上data-即可，例如<p data-order ="这是一个有效的自定义属性。">测试</ p>。

当然，我们始终可以按照自己喜欢的方式进行编写，并确保至少可以使用。当然，我们已经经历过这种想法，并见证了它的输出Internet Explorer 6.

我是Mike Davidson面向标准开发方法的忠实拥护者。

Just because you can validate your code doesn’t mean you are better than anybody else. Heck, it doesn’t even necessarily mean you write better code than anybody else. Someone who can write a banking application entirely in Flash is a better coder than you. Someone who can integrate third-party code into a complicated publishing environment is a better coder than you. Think of validation as using picture perfect grammar; it helps you get your ideas across and is a sign of a good education, but it isn’t nearly as important as the ideas and concepts you think of and subsequently communicate. The most charismatic and possibly smartest person I’ve ever worked for was from the South and used the word “ain’t” quite regularly. It didn’t make him any less smart, and, in fact, it made him more memorable. So all I’m saying is there are plenty of things to judge someone on… validation is one of them, but certainly not the most important.

很多人误解了这篇文章，这意味着我们不应该按照标准进行编码。显然，我们应该这样做，但这甚至不是真正值得考虑的事情。验证军将始终谴责那些未通过验证的人，但是验证的意义远不止有效代码。

因此，请不要失去原则，但请记住，如果我们遵循这些标准，那么将来遇到更深层次的问题的可能性就会大大降低。我们尝试提供的内容比其显示方式重要得多。