HTML5设计原理
HTML5是Web标准的巨大飞跃，它为什么要包含那些东西，它背后的设计原则是什么？
《JavaScript DOM编程艺术》和《HTML5 For Web Designer》作者Jeremy Keith与大家一起回顾了HTML的发展历程，分享了HTML5的设计原则，并与在场与会者做了精彩互动。
首先，Jeremy回顾了HTML的历史，从HTML 2.0到XHTML 2.0，此处他引用了Postel法则（鲁棒性原则）：
对自己发送的东西要严格，对接收的东西则要宽容。指出XHTML 2.0由于语法解析过于严格，因此不太适合于Web。
Jeremy认为所有的项目都应该有设计原则，HTML5也同样如此，W3C就为此发布了HTML设计原则，他强调了其中的兼容性、实用性与互操作性。
1、避免不必要的复杂性
Jeremy举了DOCTYPE的例子，表示HTML 4.01和XHTML中的DOCTYPE过于冗长，连自己都记不住这些内容，但在HTML5中只需要简单的<!DOCTYPE html>就可以了。DOCTYPE是给验证器用的，而非浏览器，浏览器只在做DOCTYPE切换时关注这个标签，因此并不需要写得太复杂。然后，他又提到如何指定字符集，在HTML5中只需要<meta charset="utf-8">。
规范也许会写得十分复杂，但浏览器的实现却可能很简单，规范有时会去迁就浏览器的实现。
2、支持已有内容
XHTML 2.0最大的问题就是不支持已经存在的内容，这违反了Postel法则。现实情况中，开发者可以写出各种风格的HTML，浏览器遇到这些代码时，在内部所构建出的结构应该是一样的，呈现的效果也应该是一样的。
3、解决实际问题
规范应该去解决现实中实际遇到的问题，而不该考虑那些复杂的理论问题。例如，既然有在<a>中嵌套多个段落标签的需要，那就让规范支持它。
4、用户怎么使用的，就怎么设计规范
当一个实践已经被广泛接受时，就应该考虑将它吸纳进来，而不是禁止它或搞一个新的实践出来。
例如，HTML5中新增了nav、section、article及aside标签，它们引入了新的文档模型，即文档中的文档。在section中，还可以嵌套h1到h6的标签，这样就有了无限的标题层级，这也是很早之前Tim Berners Lee所设想的。
5、优雅地降级
Jeremy在此处举了input的例子，HTML5中input标签的type属性增加了很多类型，当浏览器不支持这些类型时，默认会将其视为text。这就是一种优雅降级。
此外，在谈到HTML5与Flash之争时，他认为很多情况下，这就是<video>和<object>的问题，完全没有必要二者选其一。可以先使用<video>，当浏览器不支持时降级到<object>，反之亦然。如果浏览器对两者都不支持，再降级到<a>，提供一个链接。
6、支持的优先级
在考虑优先级时，应该按照这个顺序：
用户 > 编写HTML的开发者 > 浏览器厂商 > 规范制定者 > 理论
用户与开发者的重要性要远远高于规范和理论。
在最后的问答环节中，有人提到了HTML5的语法过于灵活，会造成一定的滥用，Jeremy表示赞同，并推荐使用类似JavaScript Lint的工具来帮助编写更好的代码。
此外，有人担心<video>外观的可定制性不强，控件不美观，可能会重蹈<select>的覆辙。Jeremy当场演示了一个通过CSS定制样式的<video>，并表示如果不喜欢浏览器提供的控件，完全可以实现自己的控件。
健壮性法则，博斯塔尔法则，【发送时要保守，接受时要开放】，这是对开发者很高的要求，首先要让自己严格按规范来做，其次要尽可能容忍别人的不够标准的东西，这周设计上尤其重要，我们不能严格别人按标准来做，但要尽可能让他们的输入得到最好的处理，因此要更多的考虑各种异常情况，以及对异常情况作出取舍处理。XHTML2要求太严格又不兼容之前的HTML，所以最终没被使用。
HTML5的发展过程也很波折，开始W3C确认XHTML2是未来的方向反对继续发展HTML，于是一些浏览器厂商成立Web Hypertext Applications Technology Working Group（Web超文本应用技术工作组，WHATWG）在HTML基础上添加新东西并逐一做到浏览器中，工作效率很高，不久就有成效，而W3C的XHTML2没有什么实质性进展。2006年，W3C同意和WHATWG一起开发开展HTML5工作。两个工作组理念完全不同，前者是一种独裁工作机制，而W3C是一种民主的工作机制，大家都有投票表决权，但实践上前者的工作机制运行的更好，它主要归功于伊恩·希克森，归功于伊恩·希克森，他在听取各方意见时，始终可以做到丝毫不带个人感情色彩。两个工作组最终能一起合作，主要原因就是HTML5的设计思想，因为他们一开始就确定了设计HTML5所要坚持的原则。
XHTML 2仍然使用XML错误处理模型，你必须保证以XML文档类型发送文档；这一点不言自明：没人愿意这样做。其次，XHTML 2有意不再向后兼容已有的HTML的各个版本。他们甚至曾经讨论过废除img元素，这对每天都在做Web开发的人来说确实有点疯了的味道。但我们知道，他们之所以这样做，理论上确实有充足的理由——使用object元素可能会更好。
因此，无论XHTML 2在理论上是多么完美的一种格式，但却从未有机会付诸实践。而之所以难以将其付诸实践，就是因为像你我这样的开发人员永远不会支持它，它不向后兼容。同样，浏览器厂商也不会，浏览器厂商必须要保证向后兼容。
为什么XHTML 1.1没有像XML那样得到真正广泛地应用，为什么XHTML 2从未落到实处？因为它违反了一条设计原理，这条设计原理就是著名的伯斯塔尔法则（Postel’s Law）。大家都知道：
发送时要保守；接收时要开放。
没错，接收的时候要开放，而这也正是Web得以构建的基础。开发浏览器的人必须敞开胸怀，接收所有发送给浏览器的东西，因为它们过去一直都在接收那些不够标准的东西，对不对？Web上的很多文档都不规范，但那正是Web发展的动力。从某种角度讲，Web走的正是一条混沌发展之路，虽然混沌，但却非常美丽诱人。在Web上，格式不规范的文档随处可见，但那又怎样呢？如果所有人都能够写出精准的XML，所有文档的格式都十分正确，那当然好了。可是，那不现实。现实是伯斯塔尔法则。
作为专业人士，在发送文档的时候，我们会尽量保守一些，尽量采用最佳实践，尽量确保文档格式良好。但从浏览器的角度说，它们必须以开放的姿态去接收任何文档。
有人可能会说XML有错误处理模型，XHTML 1.1和XHTML 2都使用该模型，但那个错误处理模型太苛刻了。它绝对不符合接收时开放这个法则，遇到一个错误就停止解析怎么能叫开放呢？我们只能说它与健壮性法则（也就是伯斯塔尔法则）是对立的。
在2004年W3C成员内部的一次研讨会上，当时Opera公司的代表伊恩·希克森（Ian Hickson）提出了一个扩展和改进HTML的建议。他建议新任务组可以跟XHTML 2并行，但是在已有HTML的基础上开展工作，目标是对HTML进行扩展。W3C投票表决的结果是——“反对”，因为HTML已经死了，XHTML 2才是未来的方向。然后，Opera、Apple等浏览器厂商，以及其他一些成员说：“那好吧，不指望他们了，我们自已一样可以做这件事，我们脱离W3C。”他们成立了Web Hypertext Applications Technology Working Group（Web超文本应用技术工作组，WHATWG）——可巧的是，他们自称工作组，而不是特别小组（task force），这就为HTML5将来的命运埋下了伏笔。
WHATWG决定完全脱离W3C，在HTML的基础上开展工作，向其中添加一些新东西。这个工作组的成员里有浏览器厂商，因此他们不仅可以说加就加，而且还能够一一实现。结果，大家不断提出一些好点子，并且逐一做到了浏览器中。
WHATWG的工作效率很高，不久就初见成效。在此期间，W3C的XHTML 2没有什么实质性的进展。特别是，如果从实现的角度来说，用原地踏步形容似乎也不为过。
结果，一件有意思的事情发生了。那是在2006年，蒂姆·伯纳斯-李写了一篇博客，说：“你们知道吗？我们错了。我们错在企图一夜之间就让Web跨入XML时代，我们的想法太不切实际了，是的，也许我们应该重新组建HTML工作组了。”善哉斯言，后来的故事情节果真就是这样发展的。W3C在2007年组建了HTML5工作组。这个工作组面临的第一个问题，毫无疑问就是“我们是从头开始做起呢，还是在2004年成立的那个叫WHATWG的工作组既有成果的基础上开始工作呢？”答案是显而易见的，他们当然希望从已经取得的成果着手，以之为基础展开工作。于是他们又投了一次票，同意“在WHATWG工作成果的基础上继续开展工作”。好了，这下他们要跟WHATWG并肩战斗了。
第二个问题就是如何理顺两个工作组之间的关系。W3C这个工作组的编辑应该由谁担任？是不是还让WHATWG的编辑，也就是现在Google的伊恩·希克森来兼任？于是他们又投了一次票，赞成“让伊恩·希克森担任W3C HTML5规范的编辑，同时兼任WHATWG的编辑，更有助于新工作组开展工作。”
这就是他们投票的结果，也就是我们今天看到的局面：一种格式，两个版本。WHATWG的网站上有这个规范，而W3C的站点上同样也有一份。
如果你不了解内情，很可能会产生这样的疑问：“哪个版本才是真正的规范？”当然，这两个版本内容是一样的……基本上相同。实际上，这两个版本将来还会分道扬镳。现在已经有了分道扬镳的迹象了。我的意思是说，W3C最终要制定一个具体的规范，这个规范会成为一个工作草案，定格在某个历史时刻。
而WHATWG呢，他们还在不断地迭代。即使目前我们说的HTML5，也不能完全涵盖WHATWG正在从事的工作。最准确的理解是他们正在开发一项简单的HTML或Web技术，因为这才是他们工作的核心目标。然而，同时存在两个这样的工作组，这两个工作组同时开发一个基本相同的规范，这无论如何也容易让人产生误解。误解就可能造成麻烦。
其实这两个工作组背后各自有各自的流程，因为它们的理念完全不同。在WHATWG，可以说是一种独裁的工作机制。我刚才说了，伊恩·希克森是编辑。他会听取各方意见，在所有成员各抒己见，充分陈述自己的观点之后，他批准自己认为正确的意见。
W3C则截然相反，可以说是一种民主的工作机制。所有成员都可以发表意见，而且每个人都有投票表决的权利。这个流程的关键在于投票表决。从表面上看，WHATWG的工作机制让人不好接受。岂止是不好接受，简直是历史的倒退。相信谁都会认为“运作任何项目都不能采取这种方式！”
W3C的工作机制听起来让人很舒服。至少体现了人人平等嘛。但在实践中，WHATWG的工作机制运行得非常非常好。我认为之所以会这样，主要归功于伊恩·希克森。他的的确确是一个非常称职的编辑。他在听取各方意见时，始终可以做到丝毫不带个人感情色彩。
从原理上讲，W3C的工作机制很公平，而实际上却非常容易在某些流程或环节上卡壳，造成工作停滞不前，一件事情要达成决议往往需要花费很长时间。那到底哪种工作机制最好呢？我认为，最好的工作机制是将二者结合起来。而事实也是两个规范制定主体在共同制定一份相同的规范，我想，这倒是非常有利于两种工作机制相互取长补短。
两个工作组之所以能够同心同德，主要原因是HTML5的设计思想。因为他们从一开始就确定了设计HTML5所要坚持的原则。结果，我们不仅看到了一份规范，也就是W3C站点上公布的那份文档，即HTML5语言规范，还在W3C站点上看到了另一份文档，也就是HTML设计原理。而这份文档的一位编辑今天也来到了我们大会的现场，她就是安妮·奇泰丝（Anne Van Kesteren）。如果大家对这份文档有问题，可以请教安妮。
这份文档非常好，真的非常出色。这份文档，可以说见证了W3C与WHATWG同心协力共谋发展的历程。难道你们不觉得他们像是一对欢喜冤家吗？那他们还怎么同心同德呢？这份文档忠实地记录了他们一道做了什么，他们共同拥护什么。
接下来，我想要讲的就是这份文档。因为，既然他们能就这份文档达成共识，那么我相信，HTML5必将是一个伟大的规范，而他们已经认可这就是他们的共同行动纲领。为此，你才会看到诸如兼容性、实用性、互用性之类的概念。即便W3C与WHATWG之间再有多大的分歧——确实相当多——至少他们还有这份文档中记录的共识。这一点才是至关重要的。正因为他们有了共识，才有了这份基于共识描述设计原理的文档。
HTML5设计原理的更多相关文章
- html5设计原理(转)
转自: http://www.cn-cuckoo.com/2010/10/21/the-design-of-html5-2151.html 今天我想跟大家谈一谈HTML5的设计.主要分两个方面:一 ...
- 学习HTML5必读之《HTML5设计原理》
引子:很久前看过的一遍受益匪浅的文章,今天再次转过来,希望对学习HTML5的朋友有所帮助. 今天我想跟大家谈一谈HTML5的设计.主要分两个方面:一方面,当然了,就是HTML5.我可以站在这儿只讲HT ...
- 深入浅出 Viewport 设计原理
Viewport 是 HTML5 针对移动端开发新增的一个 meta 属性, 它的作用是为同一网页在不同设备的呈现,提供响应式解决方案.这篇文章尝试通过循序渐进的方式,逐层探索 Viewport 的设 ...
- Atitit ati licenseService 设计原理
Atitit ati licenseService 设计原理 C:\0workspace\AtiPlatf\src_atibrow\com\attilax\license\LicenseX.ja ...
- kafka入门：简介、使用场景、设计原理、主要配置及集群搭建（转）
问题导读: 1.zookeeper在kafka的作用是什么? 2.kafka中几乎不允许对消息进行"随机读写"的原因是什么? 3.kafka集群consumer和producer状 ...
- 分布式文件系统FastDFS设计原理
原文地址: http://blog.chinaunix.net/uid-20196318-id-4058561.html FastDFS是一个开源的轻量级分布式文件系统,由跟踪服务器(tracker ...
- ApplicationContext容器的设计原理
1.在ApplicationContext容器中,我们以常用的FileSystemXmlApplicationContext的实现为例来说明ApplicationContext容器的设计原理. 2.在 ...
- BeanFactory容器的设计原理
XmlBeanFactory设计的类继承关系 1.BeanFactory接口提供了使用IoC容器的规范.在这个基础上,Spring还提供了符合这个IoC容器接口的一系列容器的实现供开发人员使用. 2. ...
- Spring技术内幕——深入解析Spring架构与设计原理（一）IOC实现原理
IOC的基础 下面我们从IOC/AOP开始,它们是Spring平台实现的核心部分:虽然,我们一开始大多只是在这个层面上,做一些配置和外部特性的使用工作,但对这两个核心模块工作原理和运作机制的理解,对深 ...
随机推荐
- XXE攻击
1.背景 现在很多应用都存在XXE(XML External Entity attack)漏洞,就是xml外部实体攻击,比如facebook,很多XML的解析器默认是含有XXE漏洞的. 2.xml的定 ...
- Linux QtCreator 设置mingw编译器生成windows程序
Qt跨平台,那必须在Linux平台编译一个可以在windows下运行的Qt程序才行,当然还得和QtCreator环境弄在一起才行 工作环境:Centos 7 yum install qt5-qt* m ...
- 为CentOS配置网易163的yum源
Yum (Yellow dog Updater, Modified)是一个基于 RPM 包管理的字符前端软件包管理器.能够从指定的服务器自动下载 RPM 包并且安装,可以处理依赖性关系,并且一次安装所 ...
- ANDROID 推送到底哪家强（转）
之前在群里有同学问我关于推送的一些问题,解答之后我觉得这个话题还挺有用,因为几乎大部分人都会遇到这个问题,那姑且就写篇文章总结给你们吧. 1. 为什么要用推送? 推送功能可谓是现如今任何一个 App ...
- redis启动错误-- Creating Server TCP listening socket *:6379: listen: UnKnown error
前提:windows server 2008.redis 3.x 今天给服务器部署redis环境,文件配置.服务安装都很顺利,可就在启动服务的时候提示 百度老半天也没找到个说到点子上的. 这里记录下解 ...
- 用c++后缀自动机实现最大公共字符串算法,并封装成Python库
后缀自动机的C++代码转自https://e-maxx.ru/algo/suffix_automata,其余封装为自写. 在C++文件同级目录建立setup.py文件,代码如下: # !/usr/bi ...
- MySQL——并发控制（锁）
核心知识点: 1.表锁和行级锁代表着锁的级别:读锁和写锁代表锁定真实类型. 2.读锁属于共享锁,共享同一资源,互不干扰:写锁属于排他锁,为了安全起见,写锁会阻塞其他的读锁和写锁. 3.表锁的开销最小, ...
- 编写你的第一个django应用程序2
从1停止的地方开始,我们将设置数据库,创建您的第一个模型,并快速介绍django自动生成的管理站点 数据库设置 现在,打开mysite/settings.py.这是一个普通的python模块,其中模块 ...
- property 中的strong 与weak
strong关键字与retain关似,用了它,引用计数自动+1,用实例更能说明一切 @property (nonatomic, strong) NSString *string1; @property ...
- 【转】Java中的代码点与代码单元
转载自:http://blog.csdn.net/xujinsmile/article/details/8526387 最近看core java,之前一直不明白,看了不少帖子和博客,总算搞明白了. J ...