名站网址导航名站网址导航小编为爱好网页hTML5的朋友提供关于网页hTML5的相关知识。
- 本篇文章的具体介绍如下
Jeremy Keith在 Fronteers 2010 上的主题演讲
下载PPT(PDF) http://adactio.com/extras/slides/designofhtml5.pdf
观看视频 http://fronteers.nl/congres/2010/sessions/the-design-of-html5-jeremy-keith
51CTO推荐专题：网页网页hTML 5 下一代Web开发建设标准详解
今天我想跟大家谈一谈网页网页hTML 5的设计。主要分两个方面：一方面，当然了，就是网页网页hTML 5。我可以站在这儿只讲网页网页hTML 5，但我并不打算这样做，因为如果您想了解网页网页hTML 5的话，您可以Google，可以看书，甚至可以看规范。
实际上，确实有人会谈到规范的内容。史蒂夫·福克纳(Steve Faulkner)会讲网页网页hTML 5与可访问性。而保罗·艾里什(Paul Irish)则会讲网页网页hTML 5提供的各种API。因此，我今天站在这里，不会光讲一讲网页网页hTML 5就算完事了。
说老实话，在正式开始之前，我想先交待清楚我所说的网页网页hTML 5到底是什么意思。这话听起来有点搞笑：这会子您一直在说网页网页hTML 5，难道咱们还不知道什么是网页网页hTML 5吗?大家知道，有一个规范，它的名字叫网页网页hTML 5。我所说的网页网页hTML 5，指的就是这个规范。但问题是，有些人所说的网页网页hTML 5，指的不仅仅是这个规范，还有别的意思。比如说，用网页网页hTML 5来代指CSS3就是一种常见的叫法。我可不是这样的。我所说的网页网页hTML 5，不包含CSS3，就是网页网页hTML 5。
类似的术语问题以前也有过。Ajax本来是一种含义明确的技术，但过了不久，它的含义就变成了“用JavaScript来做一切好玩的东西”。这就 是Ajax，对不对?今天，网页网页hTML 5也面临同样的问题，它本来指的是一个特定的规范，但如今含义却成了“在Web上做一切好玩的事。”我说的不是这种网页网页hTML 5，不是这种涵盖了最近刚刚出现的各种新东东的网页网页hTML 5。我说的仅仅是规范本身：网页网页hTML 5。
刚才已经说了，我今天想要讲的内容不多，也没有打算介绍网页网页hTML 5都包含什么。今天我要讲的是它的另一方面，即网页网页hTML 5的设计。换句话说，我要讲的不是规范里都包含什么，而是规范里为什么会包含它们，以及在设计这个规范的时候，设计者们是怎么看待这些东西的。
设计原理
设计原理本质上是一种信念、一种想法、一个概念，是您行动的支柱。不管您是制定规范，还是制造一种有形的物品，或者编写软件，甚至发明编程语言。您 都能找到背后的一个或者多个设计原理，多人协作的任何成果都是例证。不仅仅Web开发建设领域是这样。纵观人类历史，像国家和社会这样大规模的构建活动背后， 同样也有设计原理。
就拿美国为例吧，美国的设计原理都写在了《独立宣言》中了。
咱们认为这些真理是不言而喻的，人人生而平等，造物主赋予了每个人不可剥夺的权利，包括生存、自由和追求幸福。
这里有一句口号：生存、自由和追求幸福。这是被写进宪法中的核心理念，它关系到咱们所有人的一切，也就是咱们构建自己社会的原则。
还有一个例子，就是卡尔·马克思(Karl Marx)，他的著作在20世纪曾被奉为建设社会主义的圭臬。其基本思想大致可以归结为下面这条设计原理：
各尽所能，各取所需。
这其实就是一种经济体系背后的设计原理。
还有一个例子，比前面两个的历史更久远一些，不过大同小异：
人人为我，我为人人。
这个极为简单的设计原理，是两千年前的拿撒勒犹太人耶稣基督提出来的。而这条原则成为了后来许多宗教的核心教义。原理与实践有时候并不是同步的。
下面是小说中的一个例子。英国小说家乔治·奥威尔(George Orwell)笔下的《动物庄园》，就是在一条设计原理的基础上构建起来的虚拟社会。这条设计原理是：
四条腿的都是好人，两条腿的都是坏蛋!
《动物庄园》中有意思的是，随着社会的变迁——变得越来越坏，这条设计原理也跟着发生了改变，变成了“四条腿的都是好人，两条腿的就更好了。”最关键的是，即使是在虚构的作品里，设计原理都是存在的。
还有一套虚构的作品是以三条设计原理为基础构建起来的，那就是美国著名小说家艾萨克·阿西莫夫(Issac Asimov)的机器人经典系列。阿西莫夫发明了机器人学这个术语，并提出了机器人学三大法则，然后在这三个简单的设计原理基础上创作了一系列经典作品 ——大约有50本书。无论作品的情节如何变化，实际上都是从不同的角度来阐释这三大设计原理。我想，在座各位对机器人三大法则都不应该陌生。
机器人不得伤害人类，或袖手旁观人类受伤害。
机器人必须服从人类命令，除非命令违反第一法则。
机器人必须自卫，只要不违背第一和第二法则。
这些恐怕是第一次出现在小说中的针对软件的设计原理了。虽然基于这三个设计原理的软件运行在虚构的机器人的“正电子脑”中，但我想这应该是软件设计原理的事实开端。从此以后，咱们才看到大量优秀软件背后的设计原理。
蒂姆·伯纳斯-李(Tim Berners-Lee)，Web的发明者，在W3C的网站上发表过一份文档，其中有一个URL给出了他自己的一套设计原理。这些设计原理并不那么容易理 解，不仅多，而且随着时时间推移，他还会不断补充、修改和删除。不过我还是觉得把自己认同的设计原理写出来放在某个地方真是个不错的主意。
实际上，CSS的发明人之一伯特·波斯(Bert Bos)，也在W3C的网站上放着一份文档，其中讲的都是基本的设计原理，比如怎样设计并构建一种格式，无论是CSS还是其他格式。推荐大家看一看。
只要您在W3C的站点中随便找一找，就可以发现非常多的这种设计原理，包括蒂姆·伯纳斯-李个人的。当然，您还会看到他从软件工程学校里借用的一些 口号：分权(decentalisation)、容忍(tolerance)、简易(simplicity)、模块化(modularity)。这些都是 在他发明新格式的时候，头脑中无时无刻不在想的那些关键词。
在座各位对蒂姆·伯纳斯-李的贡献都是非常熟悉的，因为大家每天都在用。他发明了Web，与罗伯特·卡里奥(Robert Cailliau)共同发明了Web，而且在发明Web的同时，也发明了咱们每天都在Web上使用的语言。当然，这门语言就是网页hTML：超文本标记语言。
网页hTML
网页hTML最早是从2.0版开始的。从来就没有1.0版。如果有人告诉您说，他最早是从网页hTML 1.0开始使用网页hTML的，那他绝对是在忽悠您。从前确实有一个名叫网页hTML Tags的文档，其中的部分网页文章标签一直用到现在，但那个文档并非官方的规范。
使用网页文章标签、尖括号、p或h1，等等，并不是蒂姆·伯纳斯-李首创的想法。当时的SGML里就有了这些概念，而且当时的CERN(Conseil Europeen pour la Recherche Nucleaire，欧洲核子研究委员会)也在使用SGML的一个特定的版本。也就是说，即便在那个时代，他也没有白手起家;这一点在网页hTML后来的发展 过程中也体现了出来：继往开来、承前启后，而不是另立门户、从头开始。
换句话说，这篇名为网页hTML Tags的文档可以算作网页hTML的第一个版本，但它却不是一个正式的版本。第一个正式版本，网页hTML 2.0，也不是出自W3C之手。网页hTML 2.0是由IETF，因特网工程任务组(Internet Engineering Task Force)制定的。在W3C成立之前，IETF已经发布了不少标准。但从第三个版本开始往后，W3C，万维网联盟(World Wide Web Consortium)开始接手，并负责后续版本的制定工作。
20世纪九十年代网页hTML有过几次快速的发展。众所周知，在那个时代要想构建网站，可是一项十分复杂的工程。浏览器大战曾令人头疼不已。市场竞争的 结果就是各家浏览器里都塞满了各种专有的特性，都试图在专有特性上胜人一筹。当时的混乱程度不堪回首，网页hTML到底还重不重要，或者它作为Web格式的前 景如何，谁都说不清楚。
从1997年到1999年，网页hTML的版本从3.2到4.0到4.01，经历了非常快的发展。问题是到了4.01的时候，W3C的认识发生了倒退， 他们说“好了，这个版本就这样了，网页hTML也就这样了;网页hTML 4.01是网页hTML的最后一个版本了，咱们用不着网页hTML工作组了。”
W3C并没有停止开发建设这门语言，只不过他们对网页hTML不再感兴趣了。在网页hTML 4.01之后，他们提出了X网页hTML 1.0。虽然听起来完全不同，但X网页hTML 1.0与网页hTML 4.01其实是一样的。我的意思是说，从字面上看这两个规范的内容是一样的，词汇表是一样的，所有的网页元素是一样，所有的属性也都是一样的。唯一一点不同之 处，就是X网页hTML 1.0要求使用XML语法。也就是说，所有属性都必须使用小写字母，所有网页元素也必须使用小写字母，所有属性值都必须加引号，您还得记着使用结束网页文章标签，记着 对img和br要使用自结束网页文章标签。
从规范本身的内容来看，实际上是相同的，没有什么不同。不同之处就是编码风格，因为对浏览器来说，读取符合网页hTML 4.01、网页hTML 3.2，或者X网页hTML 1.0规范的网页都没有问题，对浏览器来说这些网页都是一样的，都会生成相同的DOM树。只不过人们会比较喜欢X网页hTML 1.0，因为不少人认同它比较严格的编码风格。
到了2000年，Web标准项目(Web Standards Project)的活动开展得如火如荼，开发建设人员对浏览器里包含的那些乱七八糟的专有特性已经忍无可忍了。大家都很生气，就骂那些浏览器厂商“遵守个规范 就他妈的真有那么难吗?”当时CSS有了长足的发展，而且与X网页hTML 1.0结合得也很紧密，CSS加X网页hTML 1.0基本上就可以算是“最佳实践”了。虽然在我看来网页hTML 4.01与X网页hTML 1.0没有本质上的不同，但大家都接受了。专业的开发建设人员能做到网页元素全部小写，属性全部小写，属性值也全部加引号：由于专业人员起到了模范带头作用，越来 越多的人也都开始支持这种语法。
我就是一个例子!过去的10年，我一直都使用X网页hTML 1.0文档类型，原因是这样一来验证器就能给我帮上很大的忙，对不对?只要我写的是X网页hTML 1.0，然后用验证器测试，它就能告诉我是不是忘了给属性值加引号，是不是没有结束某个网页文章标签，等等等等。而如果我写的是网页hTML 4.01，同样的问题就变成了有效的了，验证器就不一定会提醒我了。
这就是我一直使用X网页hTML 1.0的原因。我估计很多人都……使用X网页hTML 1.0的朋友，请把手举起来。好的。网页hTML 4.01呢?人少多了。一直没有举手的呢，大声点，您们用什么?网页网页hTML 5，也很好!更早的呢，还有人使用更早的文档类型吗?没有了?
10年来我一直使用X网页hTML 1.0，就是因为验证器能够真正帮到我。有人用X网页hTML 1.1吗?您知道有人用吗?请举手，别放下。有人把网页标记为XML文档吗?有吗?那您们使用的就不是X网页hTML 1.1。
这就是个大问题。X网页hTML 1.0之后是X网页hTML 1.1，只是小数点后面的数字加了一个1，而且从词汇表的角度看，规范本身没有什么新东西，网页元素也都相同，属性也都相同。但对X网页hTML 1.1来说，唯一的变化是您必须把自己的文档标记为XML文档。在使用X网页hTML 1.0的时候，还可以把文档标记为网页hTML，而咱们也正是这样做的，否则把文档标记为XML没准真会把人逼疯的。
为什么这么说呢?首先，把文档标记为XML后，Internet Explorer不能处理。当然，IE9是可以处理了。恐怕有人会讲“真是太可爱了”，他们到现在居然都没有忘了这件事。这艘船终于靠岸了!不过那时候， 作为全球领先的浏览器，IE无法处理接收到的XML文档类型的文档，而规范又要求您以XML文档类型来发送文档，这不把人逼疯才怪呢。
所依说X网页hTML 1.1有点脱离现实，而您不想把文档以XML格式发送给那些能够理解XML的浏览器，则是因为XML的错误处理模型。XML的语法，无论是属性小写，网页元素 小写，还是始终要给属性值加引号，这些都没有问题，都很好，事实上我也喜欢这样做，但XML的错误处理模型却是这样的：解析器如果遇到错误，停止解析。规 范里就是这么写的。如果您把X网页hTML 1.1标记为XML文档类型，假设您用Firefox打开这个文档，而文档中有一个和号(&)没有正确编码，就算整个页面中就这一处错误，您看到 的也将是黄屏，浏览器死掉了。Firefox会说：“没戏了，页面中有一个错误，您看不到这个网页了。”根据XML规范，这样处理是正确的，对 Firefox而言，遇到错误就停止解析，并且不呈现其他任何内容是严格按照XML规范做的。因为它不是网页hTML，网页hTML根本就没有错误处理模型，但根 据XML规范，这样做没错。
这就是为什么您不会把文档标记为XML的另一个原因。接下来，新的版本是X网页hTML 2，大家注意后面没有日期，因为这个规范并没有完成。
现在就说说X网页hTML 2，我很愿意把问题说清楚，X网页hTML 2实际上真是一个非常非常好的规范，确实非常好……从理论的角度来说。我的意思是说，制定这个规范的人都是非常非常有头脑的。直说吧，领导制定这个规范的 家伙是斯蒂芬·彭伯顿(Stephen Pemberton)，他应该是本地人，是一个聪明过人的家伙。规范本身也很了不起，如果所有人都同意使用的话，也一定是一个非常好的格式。只不过，还不 够实际。
首先，X网页hTML 2仍然使用XML错误处理模型，您必须保证以XML文档类型发送文档;这一点不言自明：没人愿意这样做。其次，X网页hTML 2有意不再向后兼容已有的网页hTML的各个版本。他们甚至曾经讨论过废除img网页元素，这对每天都在做Web开发建设的人来说确实有点疯了的味道。但咱们知道，他 们之所依这样做，理论上确实有充足的理由——使用object网页元素可能会更好。
因此，无论X网页hTML 2在理论上是多么完美的一种格式，但却从未有机会付诸实践。而之所依难以将其付诸实践，就是因为像您我这样的开发建设人员永远不会支持它，它不向后兼容。同样，浏览器厂商也不会，浏览器厂商必须要保证向后兼容。
为什么X网页hTML 1.1没有像XML那样得到真正广泛地应用，为什么X网页hTML 2从未落到实处?因为它违反了一条设计原理，这条设计原理就是著名的伯斯塔尔法则(Postel’s Law)。大家都知道：
发送时要保守;接收时要开放。
没错，接收的时候要开放，而这也正是Web得以构建的基础。开发建设浏览器的人必须敞开胸怀，接收所有发送给浏览器的东西，因为它们过去一直都在接收那 些不够标准的东西，对不对?Web上的很多文档都不规范，但那正是Web发展的动力。从某种角度讲，Web走的正是一条混沌发展之路，虽然混沌，但却非常 美丽诱人。在Web上，格式不规范的文档随处可见，但那又怎样呢?如果所有人都能够写出精准的XML，所有文档的格式都十分正确，那当然好了。可是，那不 现实。现实是伯斯塔尔法则。
作为专业人士，在发送文档的时候，咱们会尽量保守一些，尽量采用最佳实践，尽量确保文档格式良好。但从浏览器的角度说，它们必须以开放的姿态去接收任何文档。
有人可能会说XML有错误处理模型，X网页hTML 1.1和X网页hTML 2都使用该模型，但那个错误处理模型太苛刻了。它绝对不符合接收时开放这个法则，遇到一个错误就停止解析怎么能叫开放呢?咱们只能说它与健壮性法则(也就是伯斯塔尔法则)是对立的。
网页网页hTML 5
之后，就到了网页网页hTML 5，但网页网页hTML 5并不是由W3C直接制定的。故事的经过是这样的，到20世纪末的时候，还没有网页hTML工作组，W3C内部的一些人就开始琢磨了，“网页hTML也许还可以更 长寿一点，只要咱们对它稍加扩展就行了。只要把咱们放在X网页hTML上的时间和精力拿出一部分来，就可以提升一下网页hTML中的表单，可以让网页hTML更接近编 程语言，就可以让它更上一层楼。”
于是，在2004年W3C成员内部的一次研讨会上，当时Opera公司的代表伊恩·希克森(Ian hickson)提出了一个扩展和改进网页hTML的建议。他建议新任务组可以跟X网页hTML 2并行，但是在已有网页hTML的基础上开展工作，目标是对网页hTML进行扩展。W3C投票表决的结果是——“反对”，因为网页hTML已经死了，X网页hTML 2才是未来的方向。然后，Opera、Apple等浏览器厂商，以及其他一些成员说：“那好吧，不指望他们了，咱们自已一样可以做这件事，咱们脱离 W3C。”他们成立了Web hypertext Applications Technology Working Group(Web超文本应用技术工作组，WhATWG)——可巧的是，他们自称工作组，而不是特别小组(task force)，这就为网页网页hTML 5将来的命运埋下了伏笔。
WhATWG决定完全脱离W3C，在网页hTML的基础上开展工作，向其中添加一些新东西。这个工作组的成员里有浏览器厂商，因此他们不仅可以说加就加，而且还能够一一实现。结果，大家不断提出一些好点子，并且逐一做到了浏览器中。
WhATWG的工作效率很高，不久就初见成效。在此期间，W3C的X网页hTML 2没有什么实质性的进展。特别是，如果从实现的角度来说，用原地踏步形容似乎也不为过。
结果，一件有意思的事情发生了。那是在2006年，蒂姆·伯纳斯-李写了一篇博客，说：“您们知道吗?咱们错了。咱们错在企图一夜之间就让Web跨 入XML时代，咱们的想法太不切实际了，是的，也许咱们应该重新组建网页hTML工作组了。”善哉斯言，后来的故事情节果真就是这样发展的。W3C在2007 年组建了网页网页hTML 5工作组。这个工作组面临的第一个问题，毫无疑问就是“咱们是从头开始做起呢，还是在2004年成立的那个叫WhATWG的工作组既有成果的基础上开始工 作呢?”答案是显而易见的，他们当然希望从已经取得的成果着手，以之为基础展开工作。于是他们又投了一次票，同意“在WhATWG工作成果的基础上继续开 展工作”。好了，这下他们要跟WhATWG并肩战斗了。
第二个问题就是如何理顺两个工作组之间的关系。W3C这个工作组的编辑应该由谁担任?是不是还让WhATWG的编辑，也就是现在Google的伊 恩·希克森来兼任?于是他们又投了一次票，赞成“让伊恩·希克森担任W3C 网页网页hTML 5规范的编辑，同时兼任WhATWG的编辑，更有助于新工作组开展工作。”
这就是他们投票的结果，也就是咱们今天看到的局面：一种格式，两个版本。WhATWG的网站上有这个规范，而W3C的站点上同样也有一份。
如果您不了解内情，很可能会产生这样的疑问：“哪个版本才是真正的规范?”当然，这两个版本内容是一样的……基本上相同。实际上，这两个版本将来还 会分道扬镳。现在已经有了分道扬镳的迹象了。我的意思是说，W3C最终要制定一个具体的规范，这个规范会成为一个工作草案，定格在某个历史时刻。
而WhATWG呢，他们还在不断地迭代。即使目前咱们说的网页网页hTML 5，也不能完全涵盖WhATWG正在从事的工作。最准确的理解是他们正在开发建设一项简单的网页hTML或Web技术，因为这才是他们工作的核心目标。然而，同时 存在两个这样的工作组，这两个工作组同时开发建设一个基本相同的规范，这无论如何也容易让人产生误解。误解就可能造成麻烦。
其实这两个工作组背后各自有各自的流程，因为它们的理念完全不同。在WhATWG，可以说是一种独裁的工作机制。我刚才说了，伊恩·希克森是编辑。他会听取各方意见，在所有成员各抒己见，充分陈述自己的观点之后，他批准自己认为正确的意见。
W3C则截然相反，可以说是一种民主的工作机制。所有成员都可以发表意见，而且每个人都有投票表决的权利。这个流程的关键在于投票表决。从表面上 看，WhATWG的工作机制让人不好接受。岂止是不好接受，简直是历史的倒退。相信谁都会认为“运作任何项目都不能采取这种方式!”
W3C的工作机制听起来让人很舒服。至少体现了人人平等嘛。但在实践中，WhATWG的工作机制运行得非常非常好。我认为之所依会这样，主要归功于伊恩·希克森。他的的确确是一个非常称职的编辑。他在听取各方意见时，始终可以做到丝毫不带个人感情色彩。
从原理上讲，W3C的工作机制很公平，而实际上却非常容易在某些流程或环节上卡壳，造成工作停滞不前，一件事情要达成决议往往需要花费很长时间。那 到底哪种工作机制最好呢?我认为，最好的工作机制是将二者结合起来。而事实也是两个规范制定主体在共同制定一份相同的规范，我想，这倒是非常有利于两种工 作机制相互取长补短。
两个工作组之所依能够同心同德，主要原因是网页网页hTML 5的设计思想。因为他们从一开始就确定了设计网页网页hTML 5所要坚持的原则。结果，咱们不仅看到了一份规范，也就是W3C站点上公布的那份文档，即网页网页hTML 5语言规范，还在W3C站点上看到了另一份文档，也就是网页hTML设计原理。而这份文档的一位编辑今天也来到了咱们大会的现场，她他就是安妮·奇泰丝 (Anne Van Kesteren)。如果大家对这份文档有问题，可以请教安妮。
这份文档非常好，真的非常出色。这份文档，可以说见证了W3C与WhATWG同心协力共谋发展的历程。难道您们不觉得他们像是一对欢喜冤家吗?那他们还怎么同心同德呢?这份文档忠实地记录了他们一道做了什么，他们共同拥护什么。
接下来，我想要讲的就是这份文档。因为，既然他们能就这份文档达成共识，那么我相信，网页网页hTML 5必将是一个伟大的规范，而他们已经认可这就是他们的共同行动纲领。为此，您才会看到诸如兼容性、实用性、互用性之类的概念。即便W3C与WhATWG之 间再有多大的分歧——确实相当多——至少他们还有这份文档中记录的共识。这一点才是至关重要的。正因为他们有了共识，才有了这份基于共识描述设计原理的文 档。
避免不必要的复杂性
下面我就给大家介绍一些这份文档中记载的设计原理。第一个，非常简单：避免不必要的复杂性。好像很简单吧。我用一个例子来说明。
假设我使用网页hTML 4.01规范，我打开文档，输入doctype。这里有人记得网页hTML 4.01的doctype吗?好，没有，我猜没有。除非……我的意思是说，您是傻冒。现场恐怕真有人背过，这就是网页hTML 4.01的doctype：
-
- "http://www.w3.org/TR/html4/strict.dtd">
我不记这个两行具体代码，不然还要记事本、要Google、要模板有什么用呢?
要是我使用X网页hTML 1.0呢，这个规范我都已经用了10年了。有谁记得住这个doctype吗?没错，它的长度跟网页hTML 4.01的差不太多：
-
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
是不是，基本上相同。它要告诉浏览器的是：这个文档是X网页hTML 1.0的文档。那么在网页网页hTML 5中，省掉不必要的复杂性，doctype就简化成了：
- >
仅此而已。好了，就连我也能过目不忘了。我用不着把这几个字符记在记事本里了。我得说，在我第一次看到这个doctype的时候——我当然以为这是 一个网页hTML文档的doctype——被它吓了一跳：“是不是还少一个数字5啊?”我心里想：“这个doctype想告诉浏览器什么呢?就说这个文档是 网页hTML吗?难道这是有史以来唯一一个网页hTML版本吗，这件事我得首先搞清楚，网页hTML今后永远不会再有新版本了吗?”好一副唯我独尊的架式!我错了，因 为这个doctype并没有这个意思。为此，必须先搞清楚为什么文档一开头就要写doctype。它不是写给浏览器看的。Doctype是写给验证器看 的。也就是说，我之所依要在文档一开头写那行X网页hTML 1.0的doctype，是为了告诉验证器，让验证器按照该doctype来验证我的文档。
浏览器反倒无所谓了。假设我写的是网页hTML 3.2文档，文档开头写的是网页hTML 3.2的doctype。而在文档中某个地方，我使用了网页hTML 4.01中才出现的一个网页元素。浏览器会怎么处理这种情况?它会因为这个网页元素出现在比doctype声明的网页hTML版本更晚的规范中，就不解释呈现该网页元素 吗?不会，当然不会!它照样会解释呈现该网页元素，别忘了伯斯塔尔法则，别忘了健壮性。浏览器在接收的时候必须要开放。因此，它不会检查任何格式类型，而验证 器会，验证器才关心格式类型。这才是存在doctype的真正原因。
而按照网页网页hTML 5的另一个设计原理，它必须向前向后兼容，兼容未来的网页hTML版本——不管是网页hTML6、网页hTML7，还是其他什么——都要与当前的网页hTML版本，网页网页hTML 5，兼容。因此，把一个版本号放在doctype里面没有多大的意义，即使对验器证也一样。
刚才，我说doctype不是为浏览器写的，这样说大多数情况下没有问题。在有一种情况下，您使用的doctype会影响到浏览器，相信在座诸位也 都知道。但在这种情况下，Doctype并非真正用得其所，而只是为了达到某种特殊的目的才使用doctype。当初微软在引入CSS的时候，走在了标准 的前头，他们率先在浏览器中支持CSS，也推出了自己的盒模型——后来标准发布了，但标准中使用了不一样的盒模型。他们怎么办?他们想支持标准，但也想向 后兼容自己过去推出的编码方式。他们怎么知道网页作者想使用标准，还是想使用他们过去的方式?
于是，他们想出了一个非常巧妙的主意。那就是利用doctype，利用有效的doctype来触发标准模式，而不是兼容模型(quiks mode)。这个主意非常巧妙。咱们今天也都是这样在做，在咱们向文档中加入doctype时，就相当于声明了“我想使用标准模式”，但这并不是发明 doctype的本意。这只是为了达到特殊的目的在利用doctype。
下面我出一道有奖抢答题，听好：“一分钟后开始，如果您手快的话，第一个在文档前面写完doctype html，然后我用Internet Explorer打开您的文档，会触发它的标准模式，还是会触发它的兼容模式?”
答案是，这是在Internet Explorer中触发标准模式的最少字符数目。我认为这也说明了网页网页hTML 5规范的本质：它不追求理论上的完美。网页网页hTML 5所体现的不是“噢，给作者一个简短好记的doctype不好吗?”，没错，简短好记是很好，但如果这个好记的doctype无法适应现有的浏览器，还不 如把它忘了更好。因此，这个平衡把握得非常好，不仅理论上看是个好主意——简短好记的doctype，而且实践中同样也是个好主意——仍然可以触发标准模 式。应该说，Doctype是一个非常典型的例子。
还有一个例子，同样可以说明规范是如何省略不必要的复杂性，避免不必要的复杂性的。如果前面的文档使用的是网页hTML 4.01，假设我要指定文档的字符编码。理想的方式，是通过服务器在头部信息中发送字符编码，不过也可以在文档这个级别上指定：
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
同样，我也不会把这行具体代码背下来。我还想省下自己的脑细胞去记点别的更有价值的东西呢。不过，如果我想指定文档使用UTF-8编码，只能添加这行代 码。这是在网页hTML 4.01中需要这样做。要是您在X网页hTML 1.0指定同样的编码，就得多敲一下键盘，因为您还得声明meta网页元素位于一个开始的XML网页文章标签中。
- xml version="1.0" encoding="UTF-8" ?>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
在网页网页hTML 5中，您要敲的字符只有：
- <meta charset="utf-8">
简短好记。我能背下来。
同样，这样写也是有效的。它不仅适用于最新版本的浏览器，只要是今天还有人在用的浏览器都同样有效。为什么?因为在咱们把这些meta网页元素输入浏览 器时，浏览器会这样解释它：“元数据(meta)点点点点点，字符集(charset)utf-8。”这就是浏览器在解释那行字符串时真正看到的内容。它 必须看到这些内容，根据就是伯斯塔尔法则，对不对?
我多次提到健壮性原理，但总有人不理解。咱们换一种说法，浏览器会想“好，我觉得作者是想要指定一个字符集……看，没错，utf-8。”这些都是规范里明文规定的。如今，不仅那个斜杠可以省了，而且总共只要写meta charset=”utf-8″就行了。
关于省略不必要的复杂性，或者说避免不必要的复杂性的例子还有不少。但关键是既能避免不必要的复杂性，还不会妨碍在现有浏览器中使用。比如说，在 网页网页hTML 5中，如果我使用link网页元素链接到一个样式表，我说了rel=”stylesheet”，然后再说type=”text/css”，那就是重复自己了。 对浏览器而言，我就是在重复自己。浏览器用不着同时看到这两个属性。浏览器只要看到rel=”stylesheet”就够了，因为它可以猜出来您要链接的 是一个CSS样式表。所依就不用再指定type属性了。您不是已经说了这是一个样式表了嘛;不用再说第二次了。当然，愿意的话，您可以再说;如果您想包含 type属性，请便。
同样地，如果您使用了script网页元素，您说type=”text/javascript”，浏览器差不多就知道是怎么回事了。对Web开发建设而言，您还使用其他的脚本语言吗?如果您真想用其他脚本语言，没人会阻拦您。但我要奉劝您一句，任何浏览器都不会支持您。
愿意的话，您可以添加一个type属性。不过，也可以什么都不写，浏览器自然会假设您在使用JavaScript。避免-不必要的-复杂性。
支持已有的内容
支持已有的内容。这一点非常重要，因为很多人都认为网页网页hTML 5很新，很闪亮;它应该代表着未来发展的方向，应该把Web推向一个新的发展阶段。这就是网页网页hTML 5，对吗?显然，咱们都会考虑让Web的未来发展得更好，但他们则必须考虑过去。别忘了W3C这个工作组中有很多人代表的是浏览器厂商，他们肯定是要考虑 支持已有内容的。只要您想构建一款浏览器，就必须记住这个原则：必须支持已有的内容。
下面咱们就来看一个网页网页hTML 5支持已有内容的例子。
这个例子展示了编写同样内容的四种不同方式。上面是一个img网页元素，下面是带一个属性的段落网页元素。四种写法唯一的不同点就是语法。把其中任何一段代 码交给浏览器，浏览器都会生成相同的DOM树，没有任何问题。从浏览器的角度看，这四种写法没有区别。因而在网页网页hTML 5中，您可以随意使用下列任何语法。
- <img src="foo" alt="bar" />
- <p class="foo">hello worldp>
- <img src="foo" alt="bar">
- <p class="foo">hello world
- <IMG SRC="foo" ALT="bar">
- <P CLASS="foo">hello worldP>
- <img src=foo alt=bar>
- <p class=foo>hello worldp>
好了，看到这几段具体代码，恐怕有人会说“不对不对不对。其中只有一个是对的，另外三个——说不好。”不对，应该给属性值加引号!拜托，咱们可是一直都给属性值加引号的!网页元素名大写对吗?这种做法10年不是就被抛弃了吗?
看到网页网页hTML 5同时允许这些写法，我心里忍不住一阵阵想吐。我写了10年的X网页hTML 1.0，已经非常适应严格的语法了。但您必须明白，站在浏览器的角度上，这些写法实际上都是一样的。确实没有什么问题。
还有谁也感到不舒服了吗?有谁看到这些之后想“噢，这不是乱写嘛，这样做不对”?只有我这样想吗?还有别人吗?
但是，网页网页hTML 5必须支持已经存在的内容，而已有的内容就是这个样子的。不是吗?根据伯斯塔尔法则，浏览器没有别的选择。
有人可能会说“这样不行。我觉得语言本身应该提供一种开关，让作者能够表明自己想做什么。”比如说，想使用某种特定的语法，像X网页hTML，而不是使 用其他语法。我理解这些人的想法。但我不赞成在语言里设置开关。因为咱们讨论的只是编码风格或者写作风格，跟哪种语法正确无关。对于像咱们这样的专业人 士，我认为可以使用lint工具(一种软件质量保证工具，或者说是一种更加严格的编译器。它不仅可以象普通编译器那样检查出一般的语法错误，还可以检查出 那些虽然完全合乎语法要求，但很可能是潜在的、不易发现的错误)，对其他技术咱们不是也在使用lint工具嘛。
比如说对JavaScript使用lint工具。JavaScript同样也是比较混乱、不严谨的例子，但它非常强大，原因恰恰是它混乱、不严谨， 而且有很多不同的编码方式。在JavaScript，您可以在每条语句末尾加上分号，但不是必需的，因为JavaScript会自动插入分号……是不是听 起来有点不好接受?
正因为如此，才有了像JSlint这样的工具，在道格拉斯·克劳克福德(Douglas Crockford)的网站jslint.org上面。有个网页上写着“JSlint可能会伤害您的感情。”但这确实是个非常棒的工具，它可以把 JavaScript具体代码变得完美无瑕。如果您通过JSlint运行JavaScript，它会告诉您“好，您的JavaScript具体代码有效，但写法不 妥。您这种编码风格啊，我不喜欢。不赞成您这样写。这样写不好。”特别是对团队，对于要使用统一的编码风格的团队，JSlint是非常方便的工具。
我个人认为，不仅对团队来说，就算是您自己写具体代码，也要坚持一种语法风格。从浏览器解析的角度讲，不存在哪种语法比另一种更好的问题，但我认为，作 为专业人士，咱们必须能够自信地讲“这就是我的编码风格。”然而，我不认为语言里应该内置这种开关。您可以使用lint工具来统一编码风格。现在就来说说 lint工具。大家可以登录htmllint.com，在其中运行您的网页网页hTML 5文档，它会帮您检查属性值是否加了引号，网页元素是否小写，您还可以通过勾选复选框来设置其他检查项。
但这不意味着拒绝粗心大意的标记，做不做清理完全取决于您自己。我说过，因为浏览器必须支持已有的内容，网页网页hTML 5自然也不能例外。归根结底还是伯斯塔尔法则。咱们始终离不开伯斯塔尔法则。
解决现实的问题
网页网页hTML 5的另一个设计原理是解决现实的问题。显而易见的是，解决各种问题的格式和规范已经比比皆是了，因此在我看来，这个原理其实是要解决理论问题，而非解决现实的问题。这条设计原理是要从理论上承认人们普遍存在的问题，消除敏感问题。
下面我来举个例子。相信这个例子有不少人都遇到过。假设我使用网页hTML 4或X网页hTML 1，页面中已经有了一块内容，我想给整块内容加个链接，怎么办?问题是这块内容里包含一个标题，一个段落，也许还有一张图片。如果我想给它们全部都可以点 击，必须使用3个链接网页元素。于是，我得先把光标放在标题(比如说h2网页元素)中，写一个链接网页文章标签，然后再选中所有要包含到链接里面来的文本。接着，再把光标 放在段落里，写一个链接网页文章标签，然后把段落中的文本放在链接里……
- <h2><a href="/path/to/resource">headline texta>h2>
- <p><a href="/path/to/resource">Paragraph text.a>p>
在网页网页hTML 5中，我只要简单地把所有内容都包装在一个链接网页元素中就行了。
- <a href="/path/to/resource">
- <h2>headline texth2>
- <p>Paragraph text.p>
- a>
没错，链接包含的都是块级网页元素，但现在我可以用一个网页元素包含它们。这样太好了。因为我碰到过类似的情形，必须给几个块级网页元素加上相同的链接，所有能这样写就太好了。为此，我就非常欢迎网页网页hTML 5这个新标准。
它解决了一个现实的问题。我敢说在座不少朋友都曾遇到过这个问题。
那这到底解决的是什么问题呢?浏览器不必因此重新写具体代码来支持这种写法。这种写法其实早就已经存在于浏览器中了，因为早就有人这样写了，当然以前这 样写是不合乎规范的。所依，说网页网页hTML 5解决现实的问题，其本质还是“您都这样写了很多年了吧?现在咱们把标准改了，允许您这样写了。”
求真务实
在所有设计原理中，这一条恐怕是最响亮的了——求真务实。不知道大家有没有在公司里开会时听到过这种口号：“开拓进取，求真务实。”实际上，除了作 为企业的口号，它还是一条非常重要的设计原理，因为求真务实对于网页hTML的含义是：在解决那些令人头痛的问题之前，先看看人们为应对这些问题都想出了哪些 办法。集中精力去理解这些“民间的”解决方案才是当务之急。
网页网页hTML 5中新的语义网页元素就是遵循求真务实原理的反映。新增的网页元素不算多，谈不上无限的扩展性，但却不失为一件好事。尽管数量屈指可数，但意义却非同一般。这些新 网页元素涉及头部(header)、脚部(footer)、分区(section)、文章(article)……，相信大家都不会觉得陌生。我的意思是说，即 便您不使用网页网页hTML 5，也应该熟悉这些称呼，这些都是您曾经使用过的类名，比如class=”header”/“head”/“heading”，或 class=”footer”/“foot”。当然，也可能是ID，id=”header”，id=”footer”。这些不都是咱们已经司空见惯了的 嘛。
好，举个例子吧，假设您今天写了下面这个文档。
- <body>
- <div id="header">...div>
- <div id="navigation">...div>
- <div id="main">...div>
- <div id="sidebar">...div>
- <div id="footer">...div>
- body>
这里有一个div使用了id=”header”，另一个div使用了id=”navigation”，……。怎么样，都轻车熟路了吧?在网页网页hTML 5中，这些网页元素都可以换掉。说起新增的语义网页元素，它们价值的一方面可以这样来体现：“嘿，看啊，这样多好，用网页网页hTML 5新增的网页元素可以把这些div都替换掉。”
- <body>
- <header>...header>
- <nav>...nav>
- <div id="main">...div>
- <aside>...aside>
- <footer>...footer>
- body>
当然了，您可以这样做。在文档级别上使用这些网页元素没有问题。但是，假如新增这些网页元素的目的仅仅是为了取代原来的div，那就真有点多此一举了。
虽然在这个文档中，咱们用这些新网页元素来替换的是ID，但在我个人看来，将它们作为类的替代品更有价值。为什么这么说呢?因为这些网页元素在一个页面中不 止可以使用一次，而是可以使用多次。没错，您可以为文档添加一个头部(header)，再添加一个脚部(footer);但文档中的每个分区 (section)照样也都可以有一个头部和一个脚部。而每个分区里还可以嵌套另一个分区，被嵌套的分区仍然可以有自己的头部和脚部，是这样吧?
这四个新网页元素：section、article、aside和nav，之所依说它们强大，原因在于它们代表了一种新的内容模型，一种网页hTML中前所 未有的内容模型——给内容分区。迄今为止，咱们一直都在用div来组织页面中的内容，但与其他类似的网页元素一样，div本身并没有语义。但section、 article、aside和nav实际上是在明确地告诉您——这一块就像文档中的另一个文档一样。位于这些网页元素中的任何内容，都可以拥有自己的概要、标 题，自己的脚部。
其中最为通用的section，可以说是与内容最相关的一个。而article则是一种特殊的section。Aside呢，是一种特殊的section。最后，Nav也是一种特殊的section。
好，即便是现在，您照样可以使用div和类来描述页面中不同的部分，就像下面这样：
- <div class="item">
- <h2>...h2>
- <div class="meta">...div>
- <div class="content">
- ...
- div>
- <div class="links">...div>
- div>
其中包含可能是有关内容作者的元数据，而下面会给出一些链接，差不多就这样。在网页网页hTML 5中，我完全可以说这块内容就是一个文档，通过对内容分区，使用section或article或aside，我可以说“这一块完全是可以独立存在的。” 因此，我当然可以使用header和footer。
- <section class="item">
- <header><h1>...h1>header>
- <footer class="meta">...footer>
- <div class="content">
- ...
- div>
- <nav class="links">...nav>
- section>
请注意，即便是footer，也不一定非要出现在下面，不是吗?这几个网页元素，header、footer、aside、nav，最重要的是它们的语 义;跟位置没有关系。一想到footer这个词，咱们总会不由自主地想，“噢，应该放在下面。”同样，咱们把aside想象成一个侧边栏。可是，如果您看 一看规范，就会发现这些网页元素只跟内容有关。因此，放在footer中的内容也可以是署名，文章作者之类的，它只是您使用的一个网页元素。这个网页元素并没有说“必 须把我放在文档或者分区的下面。”
这里，请注意，最重要的还不是我用几个新网页元素替换了原来的div加类，而是我把原来的h2换成了h1——震撼吧，我看到有人发抖了。我碰到过不少职 业的Web开发建设人员，多年来他们一直认为规范里说一个文档中只能有一个h1。还有一些自诩为万能的SEO秘诀同样说要这样。很多SEO的技巧其实是很教条 的。所谓教条，意思就是不相信数据。过去，这种教条表现为“不行，页面中包含两个以上的h1，您就会死掉的。”在网页网页hTML 5中，只要您建立一个新的内容块，不管用section、article、aside、nav，还是别的网页元素，都可以在其中使用h1，而不必担心这个块里 的标题在整个页面中应该排在什么级别;h2、h3，都没有问题。
这个变化太厉害了。想一想吧，这个变化对内容管理是革命性的。因为现在，您可以把每个内容分区想象一个独立的、能够从页面中拿出来的部分。此时，根 据上下文不同，这个独立部分中的h1，在整个页面中没准会扮演h2或h3的角色——取决于它在文档中出现的位置。面对这个突如其来的变化，也许有人的脑子 会暂时转不过弯来。不要紧，但我可以告诉您，我认为这才是网页网页hTML 5中这些新语义标记的真正价值所在。换句话说，咱们现在有了独立的网页元素了，这些网页元素中的标题级别可以重新定义。
我的文档中可能会包含一个分区，这个分区中可能会嵌套另一个分区，或者一篇文章，然后文章再嵌套分区，分区再嵌套文章、嵌套分区，文章再嵌套文章。 而且每个分区和文章都可以拥有自己的h1到h6。从这个意义上讲，h网页元素真可谓“子子孙孙，无穷匮也”了。但是，在您在编写内容或者内容管理系统的时候， 它们又都是独立的，完全独立的内容块。这才是真正的价值所在。
实际上，这个点子并不网页网页hTML 5工作组拍脑门想出来的，也不是W3C最近才提出来的。下面这几句话摘自蒂姆·伯纳斯-李1991年的一封邮件，邮件是发给丹·康纳利(Dan Connolly)的。他在邮件中解释了对网页hTML的理解，他说：“您知道……知道我的想法，我认为h1、h2这样单调地排下去不好，我希望它成为一种可 以嵌套的网页元素，或者说一个通用的h网页元素，咱们可以在其中嵌套不同的层次。”但后来，咱们没有看到通用的h网页元素，而是一直在使用h1和h2——那是因为咱们 一直在支持已有的内容。20年后的今天，这个理想终于实现了。
平稳退化
下一条原理大家应该都很熟悉了，那就是平稳退化。毕竟，咱们已经遵守这条规则好多年了。渐进增强的另一面就是平稳退化。
有关网页网页hTML 5遵循这条原理的例子，就是使用type属性增强表单。下面列出了可以为type属性指定的新值，有number、search、range，等等。
- input type="number"
- input type="search"
- input type="range"
- input type="email"
- input type="date"
- input type="url"
最关键的问题在于浏览器在看到这些新type值时会如何处理。现有的浏览器，不是将来的浏览器，现有的浏览器是无法理解这些新type值的。但在它们看到自己不理解的type值时，会将type的值解释为text。
无论您写的是input type=”foo”还是input type=”bar”，现有的任何浏览器都会说：“嗯，也许作者的意思是text。”因而，您从现在开始就可以使用这些新值，而且您也可以放心，那些不理 解它们的浏览器会把新值看成type=”text”，而这真是一个浏览器实践平稳退化原理的好例子。
比如说，您现在输入了type=”number”。假设您需要一个输入数值的文本框。那么您可以把这个input的type属性设置为 number，然后理解它的浏览器就会呈现一个可爱的小控件，像带小箭头图标的微调控件之类的。对吧?而在不理解它的浏览器中，您会看到一个文本框，一个 您再熟悉不过的文本框。既然如此，为什么不能说输入type=”number”就会得到一个带小箭头图标的微调控件呢?
当然，您还可以设置最小和最大值属性，它们同样可以平稳退化。这是问题的关键。
再看input type=”search”。您也可以考虑一下这种输入框，因为这种输入框在Safari中会被呈现为一个系统级的搜索控件，右边还有一个点击即可清除搜 索关键词的X。而在其他浏览器中，您得到的则是一个文本框，就像您写的是input type=”text”一样，也就是您已经非常熟悉的文本框。那为什么还不使用input type=”search”呢?它不会有什么副作用，没有，对不对?
网页网页hTML 5还为输入网页元素增加了新的属性，比如placeholder(占位符)。有人不知道这个属性的用处吗，没有吧?没错，就是用于在文本框中预先放一些文本。 不对，不是网页文章标签(label)——占位符和网页文章标签完全不是一回事。占位符就是文本框可以接受的示例内容，一般颜色是灰色的。只要您一点击文本框，它就消失 了。如果您把已经输入的内容全部删除，然后单击了文本框外部，它又会出现。
使用JavaScript编写一些具体代码当然也可以实现这个功能，但网页网页hTML 5只用一个placeholder属性就帮咱们解决了问题。
当然，对于不支持这个属性的浏览器，您还是可以使用JavaScript来实现占位符功能。通过JavaScript来测试浏览器支不支持该属性也非常简单。如果支持，后退一步，把路让开，乐享其成即可。如果不支持，可以再让您的JavaScript来模拟这个功能。
现在，我不得不提到另一个话题了：网页网页hTML 5对Flash。也许您早听说过了，或者在哪里看到了这方面的讨论。说实话，我一点也不明白。我搞不懂人们怎么会仅仅凭自己的推测来展开争论。
首先，他们所说的网页网页hTML 5对Flash，并不是指的网页网页hTML 5，也不是指的Flash。而是指网页网页hTML 5的一个子集和Flash的一个子集。具体来说，他们指的是视频。因此，不管您在哪里听到别人说“网页网页hTML 5对Flash”，那很可能说的只是网页网页hTML 5视频对Flash视频。
其次，一说网页网页hTML 5对Flash，就好像您必须得作出选择一样：您站在哪一边?实际上不是这样的。网页网页hTML 5规范的设计能够让您做到鱼和熊掌兼得。
好，下面就来看看这个新的video网页元素;真是非常贴心的一个网页元素，而且设计又简单，又实用。一个开始的video网页元素，加一个结束的video元 素，中间可以放后备内容。注意，是后备内容，不是保证可访问性的内容，是后备内容。下面就是针对不支持video网页元素的浏览器写的具体代码：
- <video src="movie.mp4">
-
- video>
那么<
关于网页hTML5的相关知识就说到这里希望可以帮助朋友们。,网页hTML5教程 对各个网页文章标签的定义与规定：base
