将HTML5验证能得不偿失？

StackOverflow https://stackoverflow.com/questions/432933

  •  10-07-2019
  •  | 
  •  

题

这是广泛认为，最好的理由来验证一个人的HTML是确保所有浏览器将把它一贯的和可以预见。

HTML5草案，但是，含有两种规范之一。第一提交人的规范，描述元素和属性HTML作者应用，以及它们的相互关系。验证HTML5页是基于这个规范。元素和属性，包括不直接来自HTML4，但需要是有理由从第一的原则，这意味着一些HTML4功能，例如该摘要属性 <table>,longdesc上 <img> 和档属性上 <head>，目前不会出现在这个草案。这些特征不被认为已过时，他们只是不包括在内。(他们没有从该草案仍然是一个有争议的问题，虽然将它们列入任何时候似乎不可能。)

第二，草案定义的浏览器处理规范，旨在定义究竟是如何浏览器分析器会把任何字节流这是鉴于，无论如何形成的和有效HTML。这意味着当浏览器完全支持HTML5，它将有可能预测任何浏览器将享HTML为一个更广泛的投入，而不仅仅是那些通过验证。

特别是，因为HTML5限定为100％向后兼容今天的网络，所有有效HTML4，和所有无效，但通常使用的标记，将继续是处理完全相同的，因为它是今天，无论它是否是HTML5效或没有。

因此，在最低限度，任何人使用任何特征，从HTML5，4，或任何先前的版本HTML，以及许多私有的扩展，可以确信，他们HTML将得到一致和可预测的治疗所有的浏览器。

有鉴于此，它不会使任何意义上限制人HTML5，它将验证，哪些实际利益，我们将获得这样做?

有帮助吗？

解决方案

  • 首先是该层有效应"分析错误"在 HTML5分析算法.这一层相似的XML格式良好.最重要的原因，以避免具有错误，在你的文件上的这一层你可以得到一个令人惊讶的分析树。如果你的文件是错误的，在这一层，你会得到较少的特定的日期和时间来调试的时候写JS或CSS工作与DOM。
  • 作为一个特殊的情况下，上述层，有5doctype: <!DOCTYPE html>.为什么人会想要遵守的这是标准模式可能最简单的方法。它的东西，你可以记住不像HTML4.01或XHTML1.0doctypes你需要看看达和复制和粘贴。当然，为什么你想要的标准模式被较少的惊喜CSS层。
  • 原因主要关心的验证上层高于分析算法捕捉你的错别字以为你花更少的时间的调试，为什么你的页面的工作不像你期待。
  • 前一点并不能解释为什么你应该关心关于验证当一个给定的元素或特性的，你没有拼写错误是支持通过浏览器作为一项传统，但5规范仍然避开它。这里就是为什么HTML5已经废弃的语法是这样的：
    • HTML5使用obsoletion来信作者的一些特征是在浪费他们的时间。这些包括 longdesc, summary 和 profile.(注意，人们不同意这些是否的确是浪费时间，但目前草拟的，HTML5使它们过时。) 也就是说，如果你已经有限的资源，提高可及性、有限的资源更好地用在其他的东西比 longdesc 和 summary.如果你已经有限的资源对语义的纯度，资源更好地用在其他的东西比使得确定你有正确的咒语在 profile.
    • HTML5废弃某些陈述的功能，可以重复CSS指导作者使用CSS为自己好。这种方法，作者不考虑维护他们自己都应该引导到更可维护的代码不过。就个人而言，我宁愿做更多的传统陈述的东西符合，并把它留给提交人自己来决定其做事的方式为他们工作。
    • 有些事情是废弃出于政治原因。的 <font> 元素是废弃，因为它符合将使抗<font> standardistas认为，5人已经疯了，这可能导致不好的公关。 <applet> 是废弃的主要作为一个原则问题不给予特殊的标记，以一个特定的插件。的 classid 属性 <object> 是废弃的，因为它是在实践中件的具体内容。
    • 有些事情是废弃的语言的基础上设计美学。这包括 name 属性 <a> 和 language 属性 <script>.

(I制定的验证程序。nu HTML5验证程序，这也是5验证的发动机使用的W3C验证程序。)

其他提示

  

鉴于此，将HTML 5限制为将验证的内容是否有任何意义，以及我们将从中获得哪些实际好处？

是的，当然。你忘了未来是不固定的。特别是，您隐含地假设HTML 5规范永远不会更改，并且永远不会弃用任何功能。当然，这只会巩固现状。绝对希望长期取消对某些功能的支持，以便更容易进行新的开发（特别是如果这些可能相互冲突）。

生成有效的HTML 5可能没有直接的好处（除了仍然进行验证，因此开发更容易）。但是，如果大多数网站的质量都有所提高，那么可能会有一个长期的好处，因为它使得现有技术和标准的使用变得更加容易。

即使在HTML5开始之前，验证也从未真正用于在浏览器之间获得一致的结果。那些不理解他们所谈论的内容的人传播了这个神话，即使他们认为他们这样做了。

验证的真正原因始终是纯粹的质量保证问题。这只是一种检测错误的方法。即使任何给定错误的结果可能会或可能很快变得一致，但是结果本身仍然不是预期的。

对于作者而言，能够捕获代码中的错误非常重要，因为更简洁，无错误的标记更易于使用和维护，尤其是在团队环境中工作时。虽然大多数个别错误可能最终是良性的并且不会导致任何重大问题，但有些错误可能会产生意外结果。例如错误地，重叠或未闭合的元素在某些情况下可能会导致意外的布局问题，并让验证器告诉您错误的位置，有助于纠正问题。但如果结果充满了许多其他良性错误，那么它可能会使检测和处理变得更加困难。

这确实是我对HTML5的一个狡辩。如果浏览器必须以相同的方式处理所有流，那么将流的子集定义为“有效”是毫无意义的。在WHATWG列表中花费了大量时间来讨论回退机制，这大大浪费了每个人的时间，特别是当XML已经解决了所有解析问题时。

制作解析遗留无效文档的最佳实践文档本来是一个有用的想法，但这不属于Web标准，它只是进一步混淆HTML5周围水域的另一个因素，无法决定是否它希望编纂现有的行为（如HTML 3.2所做的），重新定义一个更干净的平台（如HTML 3.0尝试过）或者逐个添加新的扩展。

无论如何，问题可能是错误的，因为永远不会有一个浏览器<！>完全支持HTML5 <！>。其中有太多的东西：浏览器制造商即使他们想要也无法将所有内容实现到细枝末节，至少微软明确没有这样做。相反，明显有用的功能将由供应商从中挑选出来，并得到更广泛的接受。

HTML5不是一个连贯的HTML规范，它是Hixie对于他认为Web浏览器应该做的每一个随机事物的庞大，难以理解和未完成的配方。它会失败。而W3的替代方法XHTML2已经失败了。 Web标准没有一致的未来发展方向。我们丢球了。

这是一个很好的问题。

验证的主要目的（至少对我而言）是帮助我捕获标记中的错误，并在不同浏览器中测试页面时为我提供良好的基础;如果标记有效，并且该页面在IE6中被标记，那么这是一个IE6问题。

即使您的标记包含技术上无效的HTML5（例如表格摘要或锚点访问键），浏览器仍应以可预测的方式运行，这一事实会使水域变得混乱。

作为一般的经验法则，出于上述原因，我总是希望我的页面能够验证。但是，如果（例如）某个属性从HTML5规范中删除而没有添加明显合适的替换，我可能倾向于继续使用已弃用或过时的属性，并接受验证错误。

与以往一样，我认为这是了解你的手艺的一个例子。

如果您知道自己在做什么，并且做出有意识的决定来构建一个不能出于合理原因验证的页面，那么这不是问题。如果您只是编写无法验证的代码，因为您不知道更好，那完全是另一回事。

斯蒂芬

W3C HTML5验证程序的维护者在这里。我最近写了一个简短的"为什么验证?"部分"有关"部分的5验证程序:

http://validator.w3.org/nu/about.html#why-validate

源于文的这一部分是在这里：

https://github.com/validator/validator/blob/master/site/nu-about.html#L160

和拉的请求与建议的改进/加是值得欢迎的。

我目前是这样的：

核心的原因运行HTML文件通过一个一致性 检查是简单的：要赶上非故意的错误—错你可能会 否则错过了—这样你就可以解决这些问题。

除此之外，一些文档的一致性要求(有效性的规则) 在HTML规范是有帮助你和用户文档 避免某些种类的潜在问题。解释的理由 后面这些要求，该HTML规范包含这两个部分：

总结表明在这两个部分：

  • 有些标记的情况下定义为错误，因为他们是 潜在的问题，为可获取性、可用性、互操作性， 安全、或维护性--或者因为它们可以导致贫穷 性能，或可能引起你的脚本到失败的方式 难以解决。
  • 随着这些，有些标记的情况下定义 为错误的，因为它们可以使你遇到潜在的问题 HTML分析和差错的处理行为—这么说，你结束了 与一些不直观，意想不到的结果在DOM中。

验证你的文件提醒你那些潜在的问题。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top