你的位置:聚盟网 >> 网络学院 >> 入门 >> 详细内容 在线投稿

HTML5设计原则

www.juoooo.com  2011年11月22日08:14  来源: 互联网   查看:   我要评论(0)  收藏  字号: TTT

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

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

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

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

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

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

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

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

但是小悲剧的是, 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最重要制定一个具体的规范,这个规范最终会成为一个working draft,然后就定格了,而WHATWG呢?他们在不断的迭代,即便是现在HTMl5都不能涵盖他们的目标,他们是正在开发一项简单的HTML或者web技术.

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

WHATWG可以说是一种独裁的工作机制。我刚才说了,伊恩·希克森是编辑。他会听取各方意见,在所有成员各抒己见,充分陈述自己的观点之后,他批准自己认为正确的意见。

W3C是一种民主的工作机制。所有成员都可以发表意见,而且每个人都有投票表决的权利。这个流程的关键在于投票表决

WHATWG的工作机制让人很不舒服,而W3C的工作机制让人听起来很舒服,但实际情况是WHATWG工作的非常顺畅,主要归功于伊恩·希克森。他的的确确是一个非常称职的编辑。他在听取各方意见时,始终可以做到丝毫不带个人感情色彩。W3C的工作机制很公平,而实际上却非常容易在某些流程或环节上卡壳,造成工作停滞不前,一件事情要达成决议往往需要花费很长时间。

两个截然不同的工作组之所以能够同心同德,主要原因是HTML5的设计思想。因为他们从一开始就确定了设计HTML5所要坚持的原则。结果,我们不仅看到了一份规范,也就是W3C站点上公布的那份文档,即HTML5语言规范,还在W3C站点上看到了另一份文档,也就是HTML设计原理。

二.HTML5设计原则

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

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

例如离我们最近的Alibaba公司的设计原则就可以认为是: 让天下没有难做的生意.

再例如Jquery的设计原则是: write less, do more.

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

1.我们的工业化设计原则是什么?
2.我们的框架的设计原则是什么?
a. avoid needless complexity

避免不必要的复杂性

举个栗子:

1
2
3
4
<!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>
1
2
3
4
<!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>
1
2
3
4
5
6
<?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的这部分内容:
1
2
3
4
5
<!DOCTYPE html>
<html>
<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是一个非常典型的例子。

第1篇章:HTML5设计原则

第2篇章:HTML5设计原则(2)

第3篇章:HTML5设计原则(3)

第4篇章:HTML5设计原则(4)

第5篇章:HTML5设计原则(5)

编辑: 伊小露
分享到:
顶:100 踩:135
【已经有648人表态】
104票
超赞
67票
震惊
80票
不解
61票
愤怒
93票
支持
77票
高兴
96票
无聊
70票
杯具
发表评论

网友评论仅供网友表达个人看法,并不表明本网同意其观点或证实其描述。

查看全部回复【已有0位网友发表了看法】
糗事吧 牛吧 私房话 经典吧
祝福墙许愿墙
随手记-天天记帐本
邀请达人
2013祝福短信,节日祝福语