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>,并表示如果不喜欢浏览器提供的控件,完全可以实现自己的控件。

http://developer.51cto.com/art/201104/256672.htm

健壮性法则,博斯塔尔法则,【发送时要保守,接受时要开放】,这是对开发者很高的要求,首先要让自己严格按规范来做,其次要尽可能容忍别人的不够标准的东西,这周设计上尤其重要,我们不能严格别人按标准来做,但要尽可能让他们的输入得到最好的处理,因此要更多的考虑各种异常情况,以及对异常情况作出取舍处理。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之间再有多大的分歧——确实相当多——至少他们还有这份文档中记录的共识。这一点才是至关重要的。正因为他们有了共识,才有了这份基于共识描述设计原理的文档。

https://kb.cnblogs.com/page/79308/

原文地址:https://www.cnblogs.com/doit8791/p/9219911.html

时间: 2024-10-03 14:55:45

HTML5设计原理的相关文章

深入浅出 Viewport 设计原理

Viewport 是 HTML5 针对移动端开发新增的一个 meta 属性, 它的作用是为同一网页在不同设备的呈现,提供响应式解决方案.这篇文章尝试通过循序渐进的方式,逐层探索 Viewport 的设计原理,希望能给读者带来更加清晰.更加全面的技术认知. 一.引言 在PC时代,我们用 css 设置 1px 边框,显示器会用1个物理像素进行渲染.而进入移动应用时代后,我们原来设置1px边框,在手机上可能需要用 2 个或 3 个物理像素来渲染. 那么,手机为什么要这么做?解决了什么问题?以及我们开发

kafka入门:简介、使用场景、设计原理、主要配置及集群搭建(转)

问题导读: 1.zookeeper在kafka的作用是什么? 2.kafka中几乎不允许对消息进行"随机读写"的原因是什么? 3.kafka集群consumer和producer状态信息是如何保存的? 4.partitions设计的目的的根本原因是什么? 一.入门 1.简介 Kafka is a distributed,partitioned,replicated commit logservice.它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现.k

Atitit.ioc&#160;动态配置文件guice&#160;设计原理

Atitit.ioc 动态配置文件guice 设计原理 1. Bat启动时注入配置文件1 2. ioc调用1 3. Ioc 分发器 配合 apche  MethodUtils.invokeStaticMethod2 1. Bat启动时注入配置文件 SET JAVA_HOME=C:\Program Files\Java\jdk1.8.0_71 set  RESIN-HOME=c:\resin-4.0.22 set classpath=%classpath%;%RESIN-HOME%\lib\jas

BigPipe设计原理

高性能页面加载技术--BigPipe设计原理及Java简单实现 1.技术背景 动态web网站的历史可以追溯到万维网初期,相比于静态网站,动态网站提供了强大的可交互功能.经过几十年的发展,动态网站在互动性和页面显示效果上有了很大的提升,但是对于网站动态网站的整体页面加载架构没有做太大的改变.对于用户而言,页面的加载速度极大的影响着用户体验感.与静态网站不同,除了页面的传输加载时间外,动态网站还需考虑服务端数据的处理时间.像facebook这样大型的用户社交网站,必须考虑用户访问速度问题, 传统we

Atitit.异常的设计原理与&#160;策略处理&#160;java&#160;最佳实践&#160;p93

Atitit.异常的设计原理与 策略处理 java 最佳实践 p93 1 异常方面的使用准则,答案是::2 1.1 普通项目优先使用异常取代返回值,如果开发类库方面的项目,最好异常机制与返回值都提供,由调用者决定使用哪种方式..2 1.2 优先把异常抛出到上层处理..异常本身就是为了方便把异常情况抛出到上层处理..2 1.3 对于 HYPERLINK \l _Toc6222 方法调用结果异常情况返回策略,最终会有四种策略状况,2 1.4 返回null  还是异常??2 2 异常的由来与设计3 2

Atitit ati&#160;licenseService &#160;&#160;&#160;设计原理

Atitit ati licenseService    设计原理 C:\0workspace\AtiPlatf\src_atibrow\com\attilax\license\LicenseX.java V1 更具时间超是 V2   按照时间慢的百分率.. V3 草案.. Laicense file ,hto sh aes time.. Invoke System.out.println( licenseX.isCanUse_byUsePercent("2016-05-01") );

以属性为核心驱动的 全领域通用架构设计原理 (简称:属性架构原理)

以属性为核心驱动的全领域通用架构设计原理 (简称:属性架构原理) 联系方式:13547930387 Email:[email protected] 一.个人声明 我,参加工作也有5年多了,是一名普通的不能在普通的程序员,一直在使用公司自己的产品进行开发,因此技术比较菜,此设计完全是按照自己天真的想法而设计的,如果有不合理或很搞笑的地方,请轻拍,由衷的希望大家能提出宝贵的意见: 根据此设计原理我也做了一个简单的(demo)架构来支撑和验证此理论的可行性,由于技术功底不太好,有不合理之处请大家谅解,

深入理解kafka设计原理

最近开研究kafka,下面分享一下kafka的设计原理.kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力. 1.持久性 kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂

BeanFactory容器的设计原理

XmlBeanFactory设计的类继承关系 1.BeanFactory接口提供了使用IoC容器的规范.在这个基础上,Spring还提供了符合这个IoC容器接口的一系列容器的实现供开发人员使用. 2.我们以XmlBeanFactory的实现为例来说明简单IoC容器的设计原理. 3.可以看到,作为一个简单IoC容器系列最底层实现的XmlBeanFactory,与我们在Spring应用中用到的上下文相比,有一个非常明显的特点:它只提供最基本的IoC容器的功能. 4.理解这一点有助于我们理解Appli