HTML 5验证是值得的蜡烛? [英] Will HTML 5 validation be worth the candle?

查看:74
本文介绍了HTML 5验证是值得的蜡烛?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

人们普遍认为,验证HTML的最佳理由是确保所有浏览器都能一致且可预测地对待它。

然而,HTML 5草案包含两个规范。首先是作者规范,描述了HTML作者应该使用的元素和属性及其相互关系。验证HTML 5页面是基于此规范。所包含的元素和属性不是直接从HTML 4中提取出来的,但需要根据第一原则进行验证,这意味着一些HTML 4特性(例如< table>的summary属性,< img>的longdesc)并且< head>上的配置文件属性目前不出现在此草稿中。这些功能不被视为弃用,它们不包括在内。 (他们不参加草案仍然是一个争议问题,尽管很快它们很快就会出现。)第二,草案定义了一个浏览器处理规范,寻求准确定义浏览器的解析器如何处理给定的任何字节流,而不管HTML的格式和有效性如何。这意味着,当浏览器完全支持HTML 5时,可以预测任何浏览器如何将HTML处理为更广泛的输入,而不仅仅是那些通过验证的浏览器。



<特别是,因为HTML 5被定义为与今天的网站100%向后兼容,所有有效的HTML 4以及所有无效但常用的标记都将继续像现在一样继续进行处理,无论无论它是否为HTML 5有效。



因此,至少任何人使用HTML 5,HTML 4或任何以前版本的HTML的任何功能,以及许多专有扩展可以确信他们的HTML将在所有浏览器中得到一致和可预测的处理。

鉴于此,是否有任何意义将HTML5限制为这将验证,我们从中得到什么样的实际好处?

有效性层更正应对 HTML5解析算法中的解析错误。这一层类似于XML格式良好。避免在你的文档中出现错误的最重要的原因是你可能会得到一个令人惊讶的分析树。如果您的文档在此图层上没有错误,那么在编写与DOM一起工作的JS或CSS时,您可以获得更少的惊喜。
  • 作为上述图层的特例,有HTML5文档类型:<!DOCTYPE html> 。人们希望遵守的原因是以最简单的方式获得标准模式。这是您可以记住的东西,不像您需要查看每次复制和粘贴的HTML 4.01或XHTML 1.0文档类型。当然,为什么你需要标准模式的原因是在CSS层面上减少了惊喜。

  • 关注图层高于解析算法的验证的主要原因是抓住你的错别字,这样你可以花更少的时间调试为什么你的页面不能像你所期望的那样工作。 前面的观点并不能解释为什么当给定的元素或属性作为遗留问题,浏览器不支持拼写错误,但HTML5规范仍然避开它。这就是为什么HTML5过时的语法是这样的:


    • HTML5使用过时标签告诉作者某些功能会浪费他们的时间。这些包括 longdesc 摘要个人资料。 (注意人们不同意这些是否确实浪费时间,但是正如目前草拟的那样,HTML5使它们过时了。)也就是说,如果你有足够的资源来改善可访问性,那么你有限的资源最好花在除 longdesc 摘要。如果您的语义纯度资源有限,那么您的资源最好用于其他方面,而不是确保您在个人资料中具有正确的咒语。

    • HTML5过时了一些可以在CSS中复制的表现性特征,以指导作者为了自己的利益而使用CSS。这样,不考虑可维护性的作者应该被引导到更可维护的代码。就个人而言,我宁愿让更多的传统表现形式符合,并将其留给作者自己去决定哪种做法对他们有用。 有些东西由于政治原因已经过时了。 < font> 元素已过时,因为使它符合会使< - c $ c>< font> standardistas认为HTML5人疯了,这可能导致公关不良。 < applet> 主要是因为不对特定插件给予特殊标记的原则。 < object> 中的 classid 属性已过时,因为它实际上是特定于ActiveX的。

    • 有些东西在语言设计美学的基础上已经过时了。这包括< a> 上的名称属性和语言< script>




    (我开发了Validator.nu HTML5验证程序,它也是W3C验证程序使用的HTML5验证引擎。)


    It's widely considered that the best reason to validate one's HTML is to ensure that all browsers will treat it consistently and predictably.

    The HTML 5 draft, however, contains two specifications in one. First an author spec, describing the elements and attributes that HTML authors should use, and their interrelationships. Validation of an HTML 5 page is based on this spec. The elements and attributes included are not directly drawn from HTML 4, but have needed to be justified from first principles, which means that some HTML 4 features, such as the summary attribute on <table>, longdesc on <img> and the profile attribute on <head>, do not currently appear in this draft. Such features are not considered deprecated, they are simply not included. (Their absence from the draft remains a matter of dispute, although their inclusion any time soon does not seem likely.)

    Second, the draft defines a browser processing specification that seeks to define exactly how a browser's parser will treat any byte stream it's given, regardless of how well formed and valid the HTML. This means that when the browsers fully support HTML 5, it will be possible to predict how any browser will treat HTML for a much wider range of inputs than merely those that pass validation.

    In particular, because HTML 5 is defined to be 100% backward compatible with today's web, all valid HTML 4, and all invalid but commonly used mark-up, will continue to be processed exactly the same as it is today, regardless of whether it is HTML 5 valid or not.

    Therefore, at the very minimum, anyone using any feature from HTML 5, HTML 4, or any previous version of HTML, plus many proprietary extensions, can be confident that their HTML will get consistent and predictable treatment across all browsers.

    Given this, does it make any sense to limit ones HTML 5 to that which will validate, and what practical benefit will we get from doing so?

    解决方案

    • First there’s the layer of validity corresponding to "parse errors" in the HTML5 parsing algorithm. This layer is similar to XML well-formedness. The foremost reason to avoid having errors in your documents on this layer is that you may get a surprising parse tree. If your document is error-free on this layer, you get fewer suprises to debug when writing JS or CSS that works with the DOM.
    • As a special case of the above-mentioned layer, there’s the HTML5 doctype: <!DOCTYPE html>. The reason why one would want to comply here is getting the standards mode in the easiest way possible. It’s something you can memorize unlike the HTML 4.01 or XHTML 1.0 doctypes you need to look up and copy and paste each time. Of course, the reason why you’d want the standards mode is fewer surprises on the CSS layer.
    • The main reason to care about validation on the layer higher than the parsing algorithm is catching your typos so that you spend less time debugging why your page isn’t working like you are expecting.
    • The previous point does not explain why you should care about validation when a given element or attribute that you did not misspell is supported by browsers as a matter of legacy but the HTML5 spec still shuns it. Here’s why HTML5 has obsoleted syntax like this:
      • HTML5 uses obsoletion to signal to authors that some features are a waste of their time. These include longdesc, summary and profile. (Note that people disagree on whether these are, indeed, waste of time, but as currently drafted, HTML5 makes them obsolete.) That is, if you have limited resources to improve accessibility, your limited resources are better spent on something other than longdesc and summary. If you have limited resources for semantic purity, your resources are better spent on something other than making sure you have the right incantation in profile.
      • HTML5 obsoletes some presentational features that can be duplicated in CSS to guide authors to use CSS for their own good. This way, authors who don’t consider maintainability on their own are supposed to be guided to more maintainable code nonetheless. Personally, I’d prefer making more of the legacy presentational stuff conforming and leaving it to authors themselves to decide which way of doing things works for them.
      • Some things are obsoleted for political reasons. The <font> element is obsoleted, because making it conforming would make anti-<font> standardistas think that the HTML5 people have gone crazy, which could lead to bad PR. <applet> is obsoleted mainly as a matter of principle of not giving special markup to one particular plug-in. The classid attribute on <object> is obsoleted, because it’s in practice ActiveX-specific.
      • Some things are obsoleted on the basis of language design aesthetics. This includes the name attribute on <a> and the language attribute on <script>.

    (I develop the Validator.nu HTML5 validator which is also the HTML5 validation engine used by the W3C validator.)

    这篇关于HTML 5验证是值得的蜡烛?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

  • 查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆