“Be conservative in what you send; be liberal in what you accept.
–The Robustness principle”
“发送时要保守；接收时要开放。
–伯斯塔尔法则”
一切从伯斯塔尔法则说起,伯斯塔尔法则是促成了HTML5规范形成的主线,当然它的引申义也可以上升到为人处世中去.
简单说,HTML5只是HTML语言规范中的一个版本.
HTML最早是从2.0版开始的。从来就没有1.0版。如果有人告诉你说，他最早是从HTML 1.0开始使用HTML的，那他绝对是在忽悠你。从前确实有一个名叫HTML Tags的文档，其中的部分标签一直用到现在，HTML Tag的文档作为HTML诞生的见证, 但是HTML Tag这份文档并不是官方的规范.
真正的官方HTML规范是从HTML2开始的, HTML2继承了HTML Tag的成果, 继往开来, 承前启后, 而非另立门户, 从头开始.
但是小悲剧的是, HTML2的标准出台的时候恰好是浏览器大战的年代, 浏览器厂商各行其道, 无视标准的存在, 而W3C也在这个时期也不停的将一些浏览器私有特性转换成标准的一部分.
97年 – 99年, 浏览器大战如火如荼, HTML标准也经历了从3.2 – 4.0 – 4.01的版本变迁, 非常的迅猛, 但是到了HTML4.01是, W3C的头也许是被敲坏了, 认为:”好了, HTML就这样了, HTML4.01是HTML的最后一个版本了, 我们也用不着HTML工作组了.”
而事实上W3C并没有停止开发这门语言, 只不过他们对HTML失去了兴趣, 在HTML4.01后, 他们提出了xHTML1.0,虽然听起来完全不同，但是xHTML1.0与HTML4.01其实都是一样的，唯一不同的，就是xHTML1.0要求使用 XML语法。也就是说我们现在习以为常的：所有标签必须小写，所有属性必须小写，所有属性值都必须加引号，所有标签必须闭合…
从规范本身的内容看,实际是相同的, 不同之处就是编码风格, 因为对浏览器来说, 读取符合HTML4.01,HTML3.2或者xHTML1.0规范的网页都没有问题, 对于浏览器来说,都会生成相同的DOM树,只不过xHTML1.0严格的编码风格让人们比较偏好.
到了2000年,Web标准项目的活动如火如荼, 开发人员对那些个私有特性都忍无可忍, 大家都在骂浏览器厂商:”他妈的支持个标准真有这么难吗?!”. 正巧那个时候CSS有了长足的发展,而且与xHTML1.0的结合也很紧密, CSS + xHTML1.0基本上就成了”最佳实践”.而xHTML的那种优雅的书写风格在专业人士的带领下, 成为了业界最被认可接受的风格了.
在xHTML1.0之后紧跟着出来的是xHTML1.1,xHTML1.1和xHTML1.0不仅仅是版本号加了0.1这样的差异, 1.1居然是要求必须把文档标记成XML? 而当时最先进的IE无法处理接收到XML文档类型的文档, 这这太崩溃了.
而真正使人不想把文档标注成XML的原因是, 如果你在文档中哪怕是只写错了一点点, 比如&没有编码成&那整个页面的渲染结果就是黄屏了,没戏了,这个页面中有一个错误,你丫别想看这个网页了. “解析器如果遇到错误，停止解析。”是的.这就是XML文档的错误处理机制.
接下来，新的版本是XHTML 2，大家注意后面没有日期，因为这个规范并没有完成。
当然并不是说这样的规范不好, 恰恰相反, 从理论角度他是个非常好的规范, 是个非常好的格式, 但仅限于理论角度, 问题就是他并不实际.
首先，XHTML 2仍然使用XML错误处理模型，你必须保证以XML文档类型发送文档；这一点不言自明：没人愿意这样做。
其次，XHTML 2有意不再向后兼容已有的HTML的各个版本。他们甚至曾经讨论过废除img元素，这对每天都在做Web开发的人来说确实有点疯了的味道。但我们知道，他们之所以这样做，理论上确实有充足的理由——使用object元素可能会更好。
依稀记得xHTML2的坟还没长草, 而促使他死亡的原因就是伯斯塔尔法则.
1.程序员们不会去支持他,因为XML的错误处理机制和xHTML2故意而为的不向后兼容.
2.浏览器厂商不会去支持他,因为浏览器必须要保证向后兼容.
作为专业人士，在发送文档的时候，我们会尽量保守一些，尽量采用最佳实践，尽量确保文档格式良好。但从浏览器的角度说，它们必须以开放的姿态去接收任何文档。
可以说伯斯塔尔法则是杀死xHTML2.0的战略性理论武器. 而且让他死的非常瞑目.
好吧, 回到当初和xHTML2.0并驾齐驱的HTML5.
HTML5并不是直接由W3C制定的,就在大伙认为HTML应该在HTML4.01时结束生命时, 有那么一伙人认为”也许HTML应该更加长寿一些,只要我们对他稍加扩展,只要我们把放在xHTML的时间和精力拿出一部分，就可以提升下HTML中的表 单，让HTML更加接近编程语言，就可以让他更上一层楼”
于是，在2004年Opera的伊恩.希克森提出了一个扩展和改进HTML的建议,他建议新任务和xHTML2并行,但在已有的HTML基础上开展工作,目标是对HTML进行扩展.W3C的投票结果是NO,因为HTML已死,xHTML2才是未来.
于是,Opera,Apple等浏览器厂商以及一些成员说, 那好吧不指望他们了,我们自己也能做好这件事,我们脱离W3C.他们成立了WHATWG.而在接下去的一段时间内,WHATWG的工作效率非常高， 并且在短时间得出了一些成果， 因为他们的工作组成员里有浏览器厂商，因为他们不仅可以说加就加，而且还能够一一实现，大家不断地提出一些好点子并且逐一做到了浏览器中。 反观W3C的xHTML2没有什么实质性的进展，特别是从实现的角度来看，用原地踏步形容都不足为过。
戏剧性的事情又发生了， 2006年蒂姆.伯纳斯-李写了一篇博客,说:你们知道吗?我们错了,我们错在企图一夜之间就让web跨入XML时代,我们的想法太不切实际了,是的,也许我们应该重建HTML工作组了.
So,2007年故事就真的这样发展了,W3C组建了HTML5工作组, 这个工作组面临的第一个问题是:我们重头开始做呢,还是在04年成立的那个啥WHATWG工作组的既有成果上开始工作? 答案显而易见,他们又一次投票同意了在WHATWG基础上继续工作.ok, W3C和WHATWG有并肩作战了.
那第二个问题就成了这两个工作组之间的关系,W3C这个工作组的主编是由谁来干呢?是不是让WHATWG的伊恩希克森来兼任?又一次投票,同意了这个提案.
这就变成了2个工作组都有一份自己的规范,而且看起来基本上一样,那到底那份是真正的规范呢?实际上这两个标准还是会分道扬镳,W3C最重要制定一 个具体的规范,这个规范最终会成为一个working draft,然后就定格了,而WHATWG呢?他们在不断的迭代,即便是现在HTMl5都不能涵盖他们的目标,他们是正在开发一项简单的HTML或者 web技术.
这两个工作组的流程截然相反,因为他们的理念完全不同.
WHATWG可以说是一种独裁的工作机制。我刚才说了，伊恩·希克森是编辑。他会听取各方意见，在所有成员各抒己见，充分陈述自己的观点之后，他批准自己认为正确的意见。
W3C是一种民主的工作机制。所有成员都可以发表意见，而且每个人都有投票表决的权利。这个流程的关键在于投票表决
WHATWG的工作机制让人很不舒服,而W3C的工作机制让人听起来很舒服,但实际情况是WHATWG工作的非常顺畅,主要归功于伊恩·希克森。他 的的确确是一个非常称职的编辑。他在听取各方意见时，始终可以做到丝毫不带个人感情色彩。W3C的工作机制很公平，而实际上却非常容易在某些流程或环节上 卡壳，造成工作停滞不前，一件事情要达成决议往往需要花费很长时间。
两个截然不同的工作组之所以能够同心同德，主要原因是HTML5的设计思想。因为他们从一开始就确定了设计HTML5所要坚持的原则。结果，我们不 仅看到了一份规范，也就是W3C站点上公布的那份文档，即HTML5语言规范，还在W3C站点上看到了另一份文档，也就是HTML设计原理。
设计原则, 是一种信念, 一种原则, 一种概念, 是设计原则涉及的人群行动的动力.
不管是W3C在制定规范, 还是通用在制造汽车, 还是我们在编写软件, 甚至是大牛们在创造编程语言, 设计原则也许就是贯穿整件事情的一条主脉, 任何矛盾与挫折都可以用他去衡量.
下面我就给大家介绍一些HTML5的设计原理。
- a. avoid needless complexity 避免不必要的复杂性
举个栗子:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>
上面3端代码片段分别代表着XHTML1, HTML4.01, XHTML1.1的文档类型申明和字符编码申明以及引入JavaScript和CSS时要书写的内容. 好吧, 谁能把这几段默写出来? 大概有人会说:”你疯了吗? 为什么不用模板生成呢?”
好吧, 让我们来看一看HTML5的这部分内容:
<!DOCTYPE html>
<html lang="en">
<meta charset="utf-8" />
<link rel="stylesheet" href="" />
<script src=""></script>
仅此而已。好了，就连我也能过目不忘了。我用不着把这几个字符记在记事本里了。我得说，在我第一次看到这个doctype的时候——我当然以为这是 一个HTML文档的doctype——被它吓了一跳：“是不是还少一个数字5啊？”我心里想：“这个doctype想告诉浏览器什么呢？就说这个文档是 HTML吗？难道这是有史以来唯一一个HTML版本吗，这件事我得首先搞清楚，HTML今后永远不会再有新版本了吗？”好一副唯我独尊的架式！我错了，因 为这个doctype并没有这个意思。为此，必须先搞清楚为什么文档一开头就要写doctype。它不是写给浏览器看的。Doctype是写给验证器看 的。也就是说，我之所以要在文档一开头写那行XHTML 1.0的doctype，是为了告诉验证器，让验证器按照该doctype来验证我的文档。
浏览器反倒无所谓了。假设我写的是HTML 3.2文档，文档开头写的是HTML 3.2的doctype。而在文档中某个地方，我使用了HTML 4.01中才出现的一个元素。浏览器会怎么处理这种情况？它会因为这个元素出现在比doctype声明的HTML版本更晚的规范中，就不解释呈现该元素 吗？不会，当然不会！它照样会解释呈现该元素，别忘了伯斯塔尔法则，别忘了健壮性。浏览器在接收的时候必须要开放。因此，它不会检查任何格式类型，而验证 器会，验证器才关心格式类型。这才是存在doctype的真正原因。
而按照HTML5的另一个设计原理，它必须向前向后兼容，兼容未来的HTML版本——不管是HTML6、HTML7，还是其他什么——都要与当前的HTML版本，HTML5，兼容。因此，把一个版本号放在doctype里面没有多大的意义，即使对验器证也一样。
刚才，我说doctype不是为浏览器写的，这样说大多数情况下没有问题。在有一种情况下，你使用的doctype会影响到浏览器，相信在座诸位也 都知道。但在这种情况下，Doctype并非真正用得其所，而只是为了达到某种特殊的目的才使用doctype。当初微软在引入CSS的时候，走在了标准 的前头，他们率先在浏览器中支持CSS，也推出了自己的盒模型——后来标准发布了，但标准中使用了不一样的盒模型。他们怎么办？他们想支持标准，但也想向 后兼容自己过去推出的编码方式。他们怎么知道网页作者想使用标准，还是想使用他们过去的方式？
于是，他们想出了一个非常巧妙的主意。那就是利用doctype，利用有效的doctype来触发标准模式，而不是兼容模型（quiks mode）。这个主意非常巧妙。我们今天也都是这样在做，在我们向文档中加入doctype时，就相当于声明了“我想使用标准模式”，但这并不是发明 doctype的本意。这只是为了达到特殊的目的在利用doctype。
这是在Internet Explorer中触发标准模式的最少字符数目。我认为这也说明了HTML5规范的本质：它不追求理论上的完美。HTML5所体现的不是“噢，给作者一个 简短好记的doctype不好吗？”，没错，简短好记是很好，但如果这个好记的doctype无法适应现有的浏览器，还不如把它忘了更好。因此，这个平衡 把握得非常好，不仅理论上看是个好主意——简短好记的doctype，而且实践中同样也是个好主意——仍然可以触发标准模式。应该说，Doctype是一 个非常典型的例子。
简短好记。我能背下来。
同样，这样写也是有效的。它不仅适用于最新版本的浏览器，只要是今天还有人在用的浏览器都同样有效。为什么？因为在我们把这些meta元素输入浏览 器时，浏览器会这样解释它：“元数据（meta）点点点点点，字符集（charset）utf-8。”这就是浏览器在解释那行字符串时真正看到的内容。它 必须看到这些内容，根据就是伯斯塔尔法则，对不对？
我多次提到伯斯塔尔法则，但总有人不理解。我们换一种说法，浏览器会想“好，我觉得作者是想要指定一个字符集……看，没错，utf-8。”这些都是规范里明文规定的。如今，不仅那个斜杠可以省了，而且总共只要写meta charset=”utf-8″就行了。
关于省略不必要的复杂性，或者说避免不必要的复杂性的例子还有不少。但关键是既能避免不必要的复杂性，还不会妨碍在现有浏览器中使用。比如说，在 HTML5中，如果我使用link元素链接到一个样式表，我说了rel=”stylesheet”，然后再说type=”text/css”，那就是重复 自己了。对浏览器而言，我就是在重复自己。浏览器用不着同时看到这两个属性。浏览器只要看到rel=”stylesheet”就够了，因为它可以猜出来你 要链接的是一个CSS样式表。所以就不用再指定type属性了。你不是已经说了这是一个样式表了嘛；不用再说第二次了。当然，愿意的话，你可以再说；如果 你想包含type属性，请便。
同样地，如果你使用了script元素，你说type=”text/javascript”，浏览器差不多就知道是怎么回事了。对Web开发而言，你还使用其他的脚本语言吗？如果你真想用其他脚本语言，没人会阻拦你。但我要奉劝你一句，任何浏览器都不会支持你。
愿意的话，你可以添加一个type属性。不过，也可以什么都不写，浏览器自然会假设你在使用JavaScript。避免-不必要的-复杂性。
- b. Support existing content 支持已有的内容
显然，我们都会考虑让Web的未来发展得更好，但他们则必须考虑过去。别忘了W3C这个工作组中有很多人代表的是浏览器厂商，他们肯定是要考虑支持已有内容的。
再来看几段代码:
<p class="foo">Hello World</p>
<p class="foo">Hello World
<IMG SRC="foo" ALT="bar"><P CLASS="foo">Hello World</P>
<img src=foo alt=bar><p class=foo>Hello World</p>
这个例子展示了编写同样内容的四种不同方式。一个是img元素，另一个是带属性的段落元素。四种写法唯一的不同点就是语法。把其中任何一段代码交给浏览器，浏览器都会生成相同的DOM树，没有任何问题。从浏览器的角度看，这四种写法没有区别。因而在HTML5中，你可以随意使用下列任何语法。
这几段代码有问题吗? 没有, 是的, 完全没有问题!
有谁看到这些之后想“噢，这不是乱写嘛，这样做不对”？只有我这样想吗？还有别人吗？
但是，HTML5必须支持已经存在的内容，而已有的内容就是这个样子的。不是吗？根据伯斯塔尔法则，浏览器没有别的选择。
有人可能会说“这样不行。我觉得语言本身应该提供一种开关，让作者能够表明自己想做什么。”比如说，想使用某种特定的语法，像XHTML，而不是使用其他语法。我理解这些人的想法。但我不赞成在语言里设置开关。因为我们讨论的只是编码风格或者写作风格，跟哪种语法正确无关。对于像我们这样的专业人士，我认为可以使用lint工具（一种软件质量保证工具，或者说是一种更加严格的编译器。它不仅可以象普通编译器那样检查出一般的语法错误，还可以检查出那些虽然完全合乎语法要求，但很可能是潜在的、不易发现的错误），对其他技术我们不是也在使用lint工具嘛。
比如说对JavaScript使用lint工具。JavaScript同样也是比较混乱、不严谨的例子，但它非常强大，原因恰恰是它混乱、不严谨，而且有很多不同的编码方式。在JavaScript，你可以在每条语句末尾加上分号，但不是必需的，因为JavaScript会自动插入分号……是不是听起来有点不好接受？
正因为如此，才有了像JSlint这样的工具，在道格拉斯·克劳克福德（Douglas Crockford）的网站jslint.org上面。有个网页上写着“JSlint可能会伤害你的感情。”但这确实是个非常棒的工具，它可以把JavaScript代码变得完美无瑕。如果你通过JSlint运行JavaScript，它会告诉你“好，你的JavaScript代码有效，但写法不妥。你这种编码风格啊，我不喜欢。不赞成你这样写。这样写不好。”特别是对团队，对于要使用统一的编码风格的团队，JSlint是非常方便的工具。
我个人认为，不仅对团队来说，就算是你自己写代码，也要坚持一种语法风格。从浏览器解析的角度讲，不存在哪种语法比另一种更好的问题，但我认为，作为专业人士，我们必须能够自信地讲“这就是我的编码风格。”然而，我不认为语言里应该内置这种开关。你可以使用lint工具来统一编码风格。现在就来说说lint工具。大家可以登录htmllint.com，在其中运行你的HTML5文档，它会帮你检查属性值是否加了引号，元素是否小写，你还可以通过勾选复选框来设置其他检查项。
但这不意味着拒绝粗心大意的标记，做不做清理完全取决于你自己。我说过，因为浏览器必须支持已有的内容，HTML5自然也不能例外。归根结底还是伯斯塔尔法则。我们始终离不开伯斯塔尔法则。
- c. solve real problems 解决现实的问题
这看起来有点像再说废话, 谁不是为了解决问题在做事情的呢?
而这条设计原理才是真正要解决今天的人们所面临的现实问题、令人头疼的问题。
好吧, 继续看代码:
<h2>Heading text</h2>
<p>Paragraph text.</p>
现在我们需要给这两个文本都加上一个链接, 那我们的做法会是什么? 给h2和p分别加上一个a标签？ 或许，也有聪明的同学会用a标签来整个包住h2和p，就像：
<a href="somewhere">
<h2>Heading text</h2>
<p>Paragraph text.</p>
</a>
这样写有错吗？没错吧？只不过是种不太好的习惯, 并且通不过严格的校验.
但是这样的应用场景肯定存在的, 那为什么不能这样写呢?
这种写法其实早就已经存在于浏览器中了，因为早就有人这样写了，当然以前这样写是不合乎规范的。所以，说HTML5解决现实的问题，其本质还是“你都这样写了很多年了吧？现在我们把标准改了，允许你这样写了。”
- d. pave the cowpaths 求真务实
Cowpath： 把一群牛放在地里，然后看牛喜欢怎么走，然后根据牛群踩过的痕迹来铺一条给牛走的路。
很有趣的比喻吧, 说的就是把一些既然存在的东西变得更加标准一些. 接上地气的标准才是能够被执行的标准.
举个栗子:
WHATWG对抽样对大量网站进行了分析, 得出了这样的一个结论:
id=”header”, id=”footer”, id=”content”, id=”navigation”, id=”sidebar” 这样的命名方式非常常见, 那好吧, 那我就给你们一些这样的标签!
<section>,<article>,<aside>,<nav>,<header>,<footer>,<details>,<figure>
看代码:
<body>
<div id="header"></div>
<div id="navigation"></div>
<div id="main"></div>
<div id="sidebar"></div>
<div id="footer"></div>
</body>
变!
<body>
<header></header>
<nav></nav>
<div id="main"></div>
<aside></aside>
<footer></footer>
</body>
怎么样? 像模像样了吧?
再看:
<div class="item">
<h2></h2>
<div class="meta"></div>
<div class="content"></div>
<div class="link"></div>
</div>
再变!
<section class="item">
<header><h2></h2></header>
<footer class="meta"></ footer >
<div class="content"></div>
<nav class="link"></nav>
</section>
虽然在这个文档中，我们用这些新元素来替换的是id，但在我个人看来，将它们作为类的替代品更有价值。为什么这么说呢？因为这些元素在一个页面中不 止可以使用一次，而是可以使用多次。没错，你可以为文档添加一个头部（header），再添加一个脚部（footer）；但文档中的每个分区 （section）照样也都可以有一个头部和一个脚部。而每个分区里还可以嵌套另一个分区，被嵌套的分区仍然可以有自己的头部和脚部，是这样吧？
这四个新元素：section、article、aside和nav，之所以说它们强大，原因在于它们代表了一种新的内容模型，一种HTML中前所 未有的内容模型——给内容分区。迄今为止，我们一直都在用div来组织页面中的内容，但与其他类似的元素一样，div本身并没有语义。但section、 article、aside和nav实际上是在明确地告诉你——这一块就像文档中的另一个文档一样。位于这些元素中的任何内容，都可以拥有自己的概要、标 题，自己的脚部。
其中最为通用的section，可以说是与内容最相关的一个。而article则是一种特殊的section。aside呢，是一种特殊的section。最后，nav也是一种特殊的section。
最重要的是它们的语义；跟位置没有关系。
这里，请注意，最重要的还不是我用几个新元素替换了原来的div加类，而是我把原来的H2换成了H1——震撼吧，我看到有人发抖了。我碰到过不少职 业的Web开发人员，多年来他们一直认为规范里说一个文档中只能有一个H1。还有一些自诩为万能的SEO秘诀同样说要这样。很多SEO的技巧其实是很教条 的。所谓教条，意思就是不相信数据。过去，这种教条表现为“不行，页面中包含两个以上的H1，你就会死掉的。”在HTML5中，只要你建立一个新的内容 块，不管用section、article、aside、nav，还是别的元素，都可以在其中使用H1，而不必担心这个块里的标题在整个页面中应该排在什 么级别；H2、H3，都没有问题。
这个变化太厉害了。想一想吧，这个变化对内容管理是革命性的。因为现在，你可以把每个内容分区想象一个独立的、能够从页面中拿出来的部分。此时，根 据上下文不同，这个独立部分中的H1，在整个页面中没准会扮演H2或H3的角色——取决于它在文档中出现的位置。面对这个突如其来的变化，也许有人的脑子 会暂时转不过弯来。不要紧，但我可以告诉你，我认为这才是HTML5中这些新语义标记的真正价值所在。换句话说，我们现在有了独立的元素了，这些元素中的 标题级别可以重新定义。
- e. degrade gracefully 优雅降级
HTML5中设计了这么些新玩意：
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”就会得到一个带小箭头图标的微调控件呢？
当然，你还可以设置最小和最大值属性，它们同样可以平稳退化。这是问题的关键。
HTML5还为输入元素增加了新的属性，比如placeholder（占位符）。有人不知道这个属性的用处吗，没有吧？没错，就是用于在文本框中预 先放一些文本。不对，不是标签（label）——占位符和标签完全不是一回事。占位符就是文本框可以接受的示例内容，一般颜色是灰色的。只要你一点击文本 框，它就消失了。如果你把已经输入的内容全部删除，然后单击了文本框外部，它又会出现。
使用JavaScript编写一些代码当然也可以实现这个功能，但HTML5只用一个placeholder属性就帮我们解决了问题。
当然，对于不支持这个属性的浏览器，你还是可以使用JavaScript来实现占位符功能。通过JavaScript来测试浏览器支不支持该属性也非常简单。如果支持，后退一步，把路让开，乐享其成即可。如果不支持，可以再让你的JavaScript来模拟这个功能。
再来看一个比较极端的优雅降级方案:
<video>
<source src="movie.mp4">
<source src="movie.ogv">
<source src="movie.webm">
<object data="movie.swf">
<a href="movie.mp4">download</a>
</object>
</video>
上面的代码中包含了4个不同的层次。
1、如果浏览器支持video元素，也支持H264，没什么好说的，用第一个视频。
2、如果浏览器支持video元素，支持Ogg，那么用第二个视频。
3、如果浏览器不支持video元素，那么就要试试Flash影片了。
4、如果浏览器不支持video元素，也不支持Flash，我还给出了下载链接。
不错，一开始就能考虑这么周到很难得啊。有了这几个层次，已经够完善了。
- f. Priority of constituencies 最终用户优先
事先声明, 这是条很哲学的设计原则, 没有代码可以看.
它的意义就是: 一旦遇到冲突，最终用户优先，其次是作者，其次是实现者，其次标准制定者，最后才是理论上的完满。
在有人建议了某个特性，而HTML5工作组为此争论不下时，如果有浏览器厂商说“我们不会支持这个特性，不会在我们的浏览器中实现这个特性”，那么 这个特性就不会写进规范。因为即使是把特性写进规范，如果没有厂商实现，规范不过是一纸空文，对不对？实现者可以拒绝实现规范。
嗯, 要学会辩证的去看这些问题, 别钻牛角尖就好.
设计原理是Web发展背后的驱动力，也是通过HTML5反映出来的某种思维方式。我想，下面这条原理你绝对不会陌生：
大多数人的意见和运行的代码。
对不对？这句话经常在我脑际回响，它囊括了Web的真谛，触及了HTML5的灵魂。
