HTML5设计原则.docx

HTML5设计原则.docx

《HTML5设计原则.docx》由会员分享，可在线阅读，更多相关《HTML5设计原则.docx（16页珍藏版）》请在冰豆网上搜索。

HTML5设计原则

HTML5设计原则

“Beconservativeinwhatyousend;beliberalinwhatyouaccept.–TheRobustnessprinciple”

“对于自己输出要严格;对于他人的输入要灵活.–鲁棒性原则”

一切从鲁棒性原则说起,把鲁棒性原则放在第一位,是为了:

1.让大家带着鲁棒性原则的思考来听这次分享.

2.鲁棒性原则是促成HTML5的设计原则主线.

3.鲁棒性的引申义可以上升到为人处世中去.

一.XHTML2&HTML5之间不得不说的故事

HTMLTag的文档作为HTML诞生的见证,但是HTMLTag这份文档并不是官方的规范.

真正的官方HTML规范是从HTML2开始的,HTML2继承了HTMLTag的成果,继往开来,承前启后,而非另立门户,从头开始.

但是小悲剧的是,HTML2的标准出台的时候恰好是浏览器大战的年代,浏览器厂商各行其道,无视标准的存在,而W3C也在这个时期也不停的将一些浏览器私有特性转换成标准的一部分.（Cowpaths）

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,我印象很深刻的是:

当时还在用Editplus,去官网找了个xHTML1.1的template,结果…

xHTML1.1和xHTML1.0不仅仅是版本号加了0.1这样的差异,1.1居然是要求必须把文档标记成XML?

而当时最先进的IE无法处理接收到XML文档类型的文档,这这太崩溃了.而真正使人不想把文档标注成XML的原因是,如果你在文档中哪怕是只写错了一点点,比如&没有编码成&那整个页面的渲染结果就是黄屏了,没戏了,这个页面中有一个错误,你丫别想看这个网页了.“如果解析器渠道错误,那就停止解析”是的.这就是XML文档的错误处理机制.

依稀记得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的伊恩希克森（google）来?

又一次投票,同意了这个提案.

这就变成了2个工作组都有一份自己的规范,而且看起来基本上一样,那到底那份是真正的规范呢?

实际上这两个标准还是会分道扬镳,W3C最重要制定一个具体的规范,这个规范最终会成为一个workingdraft,然后就定格了,而WHATWG呢?

他们在不断的迭代,即便是现在HTMl5都不能涵盖他们的目标,他们是正在开发一项简单的HTML或者web技术.

这两个工作组的流程截然相反,因为他们的理念完全不同.

WHATWG可以说是一种独裁的工作机制。

我刚才说了，伊恩·希克森是编辑。

他会听取各方意见，在所有成员各抒己见，充分陈述自己的观点之后，他批准自己认为正确的意见。

W3C是一种民主的工作机制。

所有成员都可以发表意见，而且每个人都有投票表决的权利。

这个流程的关键在于投票表决

WHATWG的工作机制让人很不舒服,而W3C的工作机制让人听起来很舒服,但实际情况是WHATWG工作的非常顺畅,主要归功于伊恩·希克森。

他的的确确是一个非常称职的编辑。

他在听取各方意见时，始终可以做到丝毫不带个人感情色彩。

W3C的工作机制很公平，而实际上却非常容易在某些流程或环节上卡壳，造成工作停滞不前，一件事情要达成决议往往需要花费很长时间。

两个截然不同的工作组之所以能够同心同德，主要原因是HTML5的设计思想。

因为他们从一开始就确定了设计HTML5所要坚持的原则。

结果，我们不仅看到了一份规范，也就是W3C站点上公布的那份文档，即HTML5语言规范，还在W3C站点上看到了另一份文档，也就是HTML设计原理。

二.HTML5设计原则

设计原则,是一种信念,一种原则,一种概念,是设计原则涉及的人群行动的动力.

不管是W3C在制定规范,还是通用在制造汽车,还是我们在编写软件,甚至是大牛们在创造编程语言,设计原则也许就是贯穿整件事情的一条主脉,任何矛盾与挫折都可以用他去衡量.

例如离我们最近的Alibaba公司的设计原则就可以认为是:

让天下没有难做的生意.

再例如Jquery的设计原则是:

writeless,domore.

说到这里,我就想起来我们应该问问自己:

1.我们的工业化设计原则是什么?

2.我们的框架的设计原则是什么?

a.avoidneedlesscomplexity

避免不必要的复杂性

举个栗子:

?

1

2

3

4

DOCTYPEhtmlPUBLIC"-//W3C//DTDXHTML1.0Strict//EN""http:

//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

?

1

2

3

4

DOCTYPEHTMLPUBLIC"-//W3C//DTDHTML4.01//EN""http:

//www.w3.org/TR/html4/strict.dtd">

?

1

2

3

4

5

6

xmlversion="1.0"encoding="UTF-8"?

>

DOCTYPEhtmlPUBLIC"-//W3C//DTDXHTML1.1//EN""http:

//www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

//www.w3.org/1999/xhtml"xml:

lang="en"dir="ltr">

上面3端代码片段分别代表着XHTML1,HTML4.01,XHTML1.1的文档类型申明和字符编码申明以及引入JavaScript和CSS时要书写的内容.好吧,谁能把这几段默写出来?

大概有人会说:

”你疯了吗?

为什么不用模板生成呢?

”

好吧,让我们来看一看HTML5的这部分内容:

?

1

2

3

4

5

DOCTYPEhtml>

仅此而已。

好了，就连我也能过目不忘了。

我用不着把这几个字符记在记事本里了。

我得说，在我第一次看到这个doctype的时候——我当然以为这是一个HTML文档的doctype——被它吓了一跳：

“是不是还少一个数字5啊？

”我心里想：

“这个doctype想告诉浏览器什么呢？

就说这个文档是HTML吗？

难道这是有史以来唯一一个HTML版本吗，这件事我得首先搞清楚，HTML今后永远不会再有新版本了吗？

”好一副唯我独尊的架式！

我错了，因为这个doctype并没有这个意思。

为此，必须先搞清楚为什么文档一开头就要写doctype。

它不是写给浏览器看的。

Doctype是写给验证器看的。

也就是说，我之所以要在文档一开头写那行XHTML1.0的doctype，是为了告诉验证器，让验证器按照该doctype来验证我的文档。

浏览器反倒无所谓了。

假设我写的是HTML3.2文档，文档开头写的是HTML3.2的doctype。

而在文档中某个地方，我使用了HTML4.01中才出现的一个元素。

浏览器会怎么处理这种情况？

它会因为这个元素出现在比doctype声明的HTML版本更晚的规范中，就不解释呈现该元素吗？

不会，当然不会！

它照样会解释呈现该元素，别忘了伯斯塔尔法则，别忘了健壮性。

浏览器在接收的时候必须要开放。

因此，它不会检查任何格式类型，而验证器会，验证器才关心格式类型。

这才是存在doctype的真正原因。

而按照HTML5的另一个设计原理，它必须向前向后兼容，兼容未来的HTML版本——不管是HTML6、HTML7，还是其他什么——都要与当前的HTML版本，HTML5，兼容。

因此，把一个版本号放在doctype里面没有多大的意义，即使对验器证也一样。

刚才，我说doctype不是为浏览器写的，这样说大多数情况下没有问题。

在有一种情况下，你使用的doctype会影响到浏览器，相信在座诸位也都知道。

但在这种情况下，Doctype并非真正用得其所，而只是为了达到某种特殊的目的才使用doctype。

当初微软在引入CSS的时候，走在了标准的前头，他们率先在浏览器中支持CSS，也推出了自己的盒模型——后来标准发布了，但标准中使用了不一样的盒模型。

他们怎么办？

他们想支持标准，但也想向后兼容自己过去推出的编码方式。

他们怎么知道网页作者想使用标准，还是想使用他们过去的方式？

于是，他们想出了一个非常巧妙的主意。

那就是利用doctype，利用有效的doctype来触发标准模式，而不是兼容模型（quiksmode）。

这个主意非常巧妙。

我们今天也都是这样在做，在我们向文档中加入doctype时，就相当于声明了“我想使用标准模式”，但这并不是发明doctype的本意。

这只是为了达到特殊的目的在利用doctype。

这是在InternetExplorer中触发标准模式的最少字符数目。

我认为这也说明了HTML5规范的本质：

它不追求理论上的完美。

HTML5所体现的不是“噢，给作者一个简短好记的doctype不好吗？

”，没错，简短好记是很好，但如果这个好记的doctype无法适应现有的浏览器，还不如把它忘了更好。

因此，这个平衡把握得非常好，不仅理论上看是个好主意——简短好记的doctype，而且实践中同样也是个好主意——仍然可以触发标准模式。

应该说，Doctype是一个非常典型的例子。

简短好记。

我能背下来。

同样，这样写也是有效的。

它不仅适用于最新版本的浏览器，只要是今天还有人在用的浏览器都同样有效。

为什么？

因为在我们把这些meta元素输入浏览器时，浏览器会这样解释它：

“元数据（meta）点点点点点，字符集（charset）utf-8。

”这就是浏览器在解释那行字符串时真正看到的内容。

它必须看到这些内容，根据就是伯斯塔尔法则，对不对？

我多次提到鲁棒性原则，但总有人不理解。

我们换一种说法，浏览器会想“好，我觉得作者是想要指定一个字符集……看，没错，utf-8。

”这些都是规范里明文规定的。

如今，不仅那个斜杠可以省了，而且总共只要写metacharset=”utf-8″就行了。

关于省略不必要的复杂性，或者说避免不必要的复杂性的例子还有不少。

但关键是既能避免不必要的复杂性，还不会妨碍在现有浏览器中使用。

比如说，在HTML5中，如果我使用link元素链接到一个样式表，我说了rel=”stylesheet”，然后再说type=”text/css”，那就是重复自己了。

对浏览器而言，我就是在重复自己。

浏览器用不着同时看到这两个属性。

浏览器只要看到rel=”stylesheet”就够了，因为它可以猜出来你要链接的是一个CSS样式表。

所以就不用再指定type属性了。

你不是已经说了这是一个样式表了嘛；不用再说第二次了。

当然，愿意的话，你可以再说；如果你想包含type属性，请便。

同样地，如果你使用了script元素，你说type=”text/javascript”，浏览器差不多就知道是怎么回事了。

对Web开发而言，你还使用其他的脚本语言吗？

如果你真想用其他脚本语言，没人会阻拦你。

但我要奉劝你一句，任何浏览器都不会支持你。

愿意的话，你可以添加一个type属性。

不过，也可以什么都不写，浏览器自然会假设你在使用JavaScript。

避免-不必要的-复杂性。

b.Supportexistingcontent

支持已有的内容

显然，我们都会考虑让Web的未来发展得更好，但他们则必须考虑过去。

别忘了W3C这个工作组中有很多人代表的是浏览器厂商，他们肯定是要考虑支持已有内容的。

再来看几段代码:

?

1

2

3

4

5

6

7

HelloWorld

HelloWorld

HelloWorld

HelloWorld

这几段代码有问题吗?

没有,是的,完全没有问题!

因为我们讨论的只是编码风格或者写作风格，跟哪种语法正确无关.

在JavaScript，你可以在每条语句末尾加上分号，但不是必需的，因为JavaScript会自动插入分号.

当然这并不阻碍我们用XHTML的语法规范来规约大家书写辨识度高的文档,当然也可以借由lint工具来为我们验证整个文档的正确性.

我个人认为，不仅对团队来说，就算是你自己写代码，也要坚持一种语法风格。

从浏览器解析的角度讲，不存在哪种语法比另一种更好的问题，但我认为，作为专业人士，我们必须能够自信地讲“这就是我的编码风格。

”然而，我不认为语言里应该内置这种开关。

你可以使用lint工具来统一编码风格。

现在就来说说lint工具。

大家可以登录，在其中运行你的HTML5文档，它会帮你检查属性值是否加了引号，元素是否小写，你还可以通过勾选复选框来设置其他检查项。

c.solverealproblems

解决现实的问题

这看起来有点像再说废话,谁不是为了解决问题在做事情的呢?

而这条设计原理才是真正要解决今天的人们所面临的现实问题、令人头疼的问题。

好吧,继续看代码:

?

1

2

Headingtext

Paragraphtext.

现在我们需要给这两个文本都加上一个链接,那我们的做法会是什么?

给h2和p分别加上一个a标签？

或许，也有聪明的同学会用a标签来整个包住h2和p，就像：

?

1

2

3

4

Headingtext

Paragraphtext.

这样写有错吗？

没错吧？

只不过是种不太好的习惯,并且通不过严格的校验.

但是这样的应用场景肯定存在的,那为什么不能这样写呢?

这种写法其实早就已经存在于浏览器中了，因为早就有人这样写了，当然以前这样写是不合乎规范的。

所以，说HTML5解决现实的问题，其本质还是“你都这样写了很多年了吧？

现在我们把标准改了，允许你这样写了。

”

d.pavethecowpaths

求真务实

Cowpath：

把一群牛放在地里，然后看牛喜欢怎么走，然后根据牛群踩过的痕迹来铺一条给牛走的路。

很有趣的比喻吧,说的就是把一些既然存在的东西变得更加标准一些.接上地气的标准才是能够被执行的标准.

举个栗子:

WHATWG对抽样对大量网站进行了分析,得出了这样的一个结论:

id=”header”,id=”footer”,id=”content”,id=”navigation”,id=”sidebar”这样的命名方式非常常见,那好吧,那我就给你们一些这样的标签!