Web前端开发全程实战:HTML5+CSS3+JavaScript+jQuery+Bootstrap
上QQ阅读APP看书,第一时间看更新

1.2 HTML5设计原则

为了规范HTML5开发的兼容性、实用性和互操作性,W3C发布了HTML5设计原则(http://www.w3.org/TR/html-design-principles/),简单说明如下。

1.2.1 避免不必要的复杂性

HTML规范可以写得十分复杂,但浏览器的实现应该非常简单。把复杂的工作留给浏览器后台去处理,用户仅需要输入最简单的字符,甚至不需要输入,才是最佳文档规范。因此,HTML5首先采用化繁为简的思路进行设计。

【示例1】在HTML4.01中定义文档类型。代码如下:

     <!DOCTYPE html PUBLIC "-//W3C/DTD HTML4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

HTML5简化如下:

     <!DOCTYPE html>

HTML4.01和XHTML中的DOCTYPE过于冗长,但在HTML5中只需要简单的<!DOCTYPEhtml>就可以了。DOCTYPE是给验证器用的,而非浏览器,浏览器只在做DOCTYPE切换时关注这个标签,因此并不需要写得太复杂。

【示例2】在HTML4.01中定义字符编码。代码如下。

     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

在XHTML1.0中还需要再声明XML标签,并在其中指定字符编码。

     <?xml version="1.0" encoding="utf-8" ?>
     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

HTML5简化如下:

     <meta charset="utf-8">

关于省略不必要的复杂性,或者说避免不必要的复杂性的例子还有不少。但关键是HTML5既能避免不必要的复杂性,又不会妨碍在现有浏览器中使用。

在HTML5中,如果使用link元素链接到一个样式表,先定义rel="stylesheet",然后再定义type="text/css",这样就重复了。对浏览器而言,只要设置rel="stylesheet"就够了,因为它可以猜出要链接的是一个CSS样式表,不必要再指定type属性。

对Web开发而言,大家都使用JavaScript脚本语言,也是默认的通用语言,用户可以为script元素定义type="text/javascript"属性,也可以什么都不写,浏览器自然会假设在使用JavaScript。

1.2.2 支持已有内容

XHTML2.0最大的问题就是不支持已经存在的内容,这违反了Postel法则(即对自己发送的东西要严格,对接收的东西则要宽容)。现实情况中,开发者可以写出各种风格的HTML,浏览器遇到这些代码时,在内部所构建出的结构应该是一样的,呈现的效果也应该是一样的。

【示例】下面示例展示了编写同样内容的4种不同写法,4种写法唯一的不同点就是语法:

从浏览器解析的角度分析,这些写法实际上都是一样的。HTML5必须支持已经存在的约定,适应不同的用户习惯,而不是用户适应浏览器的严格解析标准。

1.2.3 解决实际问题

规范应该去解决现实中实际遇到的问题,而不该考虑那些复杂的理论问题。

【示例】既然有在<a>中嵌套多个段落标签的需要,那就让规范支持它。

如果块内容包含一个标题、一个段落,按HTML4规范,必须至少使用两个链接。例如:

     <h2><a href="#">标题文本</a></h2>
     <p><a href="#">段落文本</a></p>

在HTML5中,只需要把所有内容都包裹在一个链接中即可。例如:

其实这种写法早已经存在,当然以前这样写是不合乎规范的。所以,HTML5解决现实的问题,其本质还是纠正因循守旧的规范标准,现在允许用户这样写。

1.2.4 用户怎么使用就怎么设计规范

当一个实践已经被广泛接受时,就应该考虑将它吸纳进来,而不是禁止它或搞一个新的实践出来。例如,HTML5新增了nav、section、article、aside等标签,它们引入了新的文档模型,即文档中的文档。在section中,还可以嵌套h1~h6的标签,这样就有了无限的标题层级,这也是很早之前Tim Berners-Lee所设想的。

【示例】下面几行代码相信大家都不会陌生,这些都是频繁被使用过的ID名称。

在HTML5中,可以用新的元素代替。

实际上,这并不是HTML5工作组发明的,也不是W3C开会研究出来的,而是谷歌公司根据大数据分析用户习惯总结出来的。

1.2.5 优雅地降级

渐进增强的另一面就是优雅地回退。最典型的例子就是使用type属性增强表单。

【示例1】列出可以为type属性指定的新值,如number、search、range等。

最关键的问题在于,当浏览器看到这些新type值时会如何处理。老版本浏览器是无法理解这些新type值的。但是当它们看到自己不理解的type值时,会将type的值解释为text。

【示例2】对于新的video元素,它设计得很简单、实用。针对不支持video元素的浏览器可以这样写:

这样HTML5视频与Flash视频就可以协同起来,用户不用纠结如何选择。

如果愿意的话,还可以使用source元素,而非src属性来指定不同的视频格式。

上面代码包含了4个不同的层次。

 如果浏览器支持video元素,也支持H264,那么用第1个视频。

 如果浏览器支持video元素,支持Ogg,那么用第2个视频。

 如果浏览器不支持video元素,那么就要试试Flash视频。

 如果浏览器不支持video元素,也不支持Flash视频,还可以给出下载链接。

总之,无论是HTML5,还是Flash,一个也不能少。如果只使用video元素提供视频,难免会遇到问题。而如果只提供Flash影片,性质是一样的。所以还是应该两者兼顾。

1.2.6 支持的优先级

用户与开发者的重要性要远远高于规范和理论。在考虑优先级时,应该按照下面顺序:

用户>编写HTML的开发者>浏览器厂商>规范制定者>理论

这个设计原则本质上是一种解决冲突的机制。例如,当面临一个要解决的问题时,如果W3C给出了一种解决方案,而WHATWG给出了另一种解决方案。一旦遇到冲突,最终用户优先,其次是开发者,再是浏览器厂商,然后是规范制定者,最后才是理论上的完美。

根据最终用户优先的原理,开发人员在链条中的位置高于实现者,假如我们发现了规范中的某些地方有问题,就不支持实现这个特性,那么就等于把相应的特性给否定了,规范里就得删除,因为用户有更高的权重。本质上用户拥有了更大的发言权,开发人员也拥有更多的主动性。