图目录
1. 背景及现状
HTML 标准自1999年12月发布的 HTML 4.01 后，后继的 HTML 5 和其它标准被束之高阁，为了推动web标准化运动的发展，一些公司联合起来，成立了一个叫做 Web Hypertext Application Technology Working Group （Web 超文本应用技术工作组 - WHATWG） 的组织，HTML5草案的前身名为 Web Applications 1.0，於2004年被 WHATWG 提出，于2007年被 W3C 接纳，并成立了新的 HTML 工作团队。HTML 5 的第一份正式草案已于2008年1月22日公布。该团队为HTML5建立的规则如下：
新特性应该基于 HTML、CSS、DOM 以及 JavaScript。
减少对外部插件的需求（比如 Flash）
更优秀的错误处理
更多取代脚本的标记
HTML5 应该于设备
开发进程应对公众透明
总的来说，HTML 5有两大特点：首先，强化了 Web 网页的表现性能。其次，追加了本地数据库等 Web 应用的功能。
由图1-1可以看出，在2012年，将会由W3C发布候选推荐版，这个版本的发布就代表着HTML5的规范编写已经完成了。而2022年推出的计划推荐版，则意味着至少会有两个浏览器会完美的支持HTML5的所有特性。2022年听起来似乎很遥远，但通过观察现阶段chrome, firefox , safari，IE等浏览器对HTML5的支持程度，可以看出各大浏览器厂商都非常积极。应该不需要到2022年就会有至少两个浏览器支持HTML5。因此现在关注和讨论HTML5，了解HTML5的新特性，为以后的产品规划并非毫无意义。
11 HTML5版本发布时间
2. HTML5新特性
2.1. worker 多线程
在过去很年多里面HTML的一个就是多线程，所有运算和展示都在主页面一个线程中，预算稍微大一点网页就卡，对整个用户体验、性能的影响很大。有了HTML5这个问题完全解决了。多线程支持，在与主页面分开的线程中运行处理过程，保留页面以用于主要的功能，并可以同时算多个东西，充分利用了CPU资源。
HTML5的多线程是worker模式，大体的概念是：线程的创建由一个worker来决定，维护了一个线程池。Web Workers 是 HTML5 提供的一个javascript多线程解决方案，我们可以将一些大计算量的代码交由web Worker运行而不冻结用户界面。
HTML5的多线程的特性：
1.在线程中是不能操作DOM节点的（想要操作的话只能发送消息给worker创建者回调函数）；
2.多线程的本质其实是真正的系统线程；
3.能使用setTimeout()，clearTimeout()，setInterval()，clearInterval()等函数；
4.能进行IO操作（ajax）。
2.2. 双向通信WebSocket
WebSockets是在一个(TCP)接口进行双向通信的技术，PUSH技术类型。使用ws或wss协议。WebSocket目前由W3C进行标准化，已经受到Firefox 4、Chrome 4、Opera 10.70以及Safari 5等浏览器的支持。
2.2.1. 当前的Web通信——轮询（Polling）
通常，当浏览器访问一个网页时，会向托管该网页的Web服务器发送一个HTTP请求，Web服务器识别这一请求，并返回响应。例如，新闻报道，门票销售等，在浏览器渲染页面时，响应可能会过期，如果你想获得最新的“实时”信息，你可以不断地手动刷新页面，但显然这不是最好的办法。
目前提供的实时Web程序主要是围绕轮询和其它服务器端推送技术进行的，最著名的是Comnet，它推迟了HTTP响应的结束，基于Comnet的推送通常是使用JavaScript结合长轮询(Long Polling)或流连接策略实现的。
使用轮询时，浏览器定期发送HTTP请求，并立即收到响应。这种方式比不断刷新好一些，浏览器不用一闪一闪的重新加载了，而且只传送感兴趣的那一小部分数据，占用带宽变小。
使用长轮询时，浏览器向服务器发送一个请求，服务器在既定期限内保持请求处于打开状态，如果在此期间收到通知，向客户端发送一个包含消息的响应，如果在此期间没有收到消息，服务器发送一个响应终止打开的请求。长轮询相对于一般轮询的优点在于，数据一旦可用，便立即从服务器发送到客户机，因此没有延时，但是服务器有大量消息要推送的时候，长轮询与轮询相比，实际并没有什么本质的提高。
使用流时，浏览器发送一个完整的请求，服务器发送一个响应，并保存打开状态，然后不断更新使其一直保持打开（或在一段时间内保持打开），无论何时消息准备好发送时，响应就更新，但服务器不会发送一个结束的响应，因此连接就一直保持打开状态，后面发送的消息就可以继续使用这个连接。但流仍然是封装在 HTTP中的，阻扰了防火墙和代理服务器选择缓冲区中的内容进行响应，因此消息传递的时间就延长了。许多流式Comnet解决方案都转向了长轮询，另外，TLS（SSL）连接可以用来屏蔽来自缓冲区的响应，但在这种情况下，每个连接消耗的服务器资源更多了。
最终，所有这些方法都提供了实时数据，包含HTTP请求和响应头，其中包含许多额外的，不必要的头数据。为了模拟基于半双工HTTP上的全双工通信，目前的许多解决方案都使用了两个连接：一个下行连接，一个上行连接。维护和协调这两个连接需要大量的系统开销，并增加了复杂性。简言之，HTTP不是为实时的，全双工通信设计的，如图2-1所示，它显示了轮询和WebSocket 应用程序之间的网络吞吐量。
21轮询和WebSocket 应用程序之间的网络吞吐量
2.2.2. HTML5 WebSocket
WebSocket通过一个单一的Socket实现一个全双工，双向通信的信道，实现了服务端完美的PUSH。与Ajax相比，Ajax技术需要客户端发起请求，而WebSocket服务器和客户端可以彼此相互推送信息；XHR受到域的，而WebSocket允许跨域通信。HTML 5 Web Socket提供了一个真正的标准，可以使用它构建可扩展的实时Web应用程序。此外，由于它提供了一个浏览器自带的套接字，消除了Comet解决方案的许多问题，Web Socket显著降低了系统开销和复杂性，减少不必要的网络流量和延迟。
浏览器通过JavaScript 向服务器发出建立WebSocket 连接的请求，连接建立以后，客户端和服务器端就可以通过TCP连接直接交换数据。
HTML 5 Web Socket在实时Web应用扩展性方面朝前迈出了一大步，HTML 5 Web Socket可以提供5000：1或1000：1的比例（根据HTTP消息头大小）减少不必要的HTTP头流量和3：1的比例减少通信延迟，这不是一个渐进式的改进，而是一次性的飞跃。
2.3. 视频音频支持
目前，在网页上嵌入音频或视频，最常用的是Flash等格式。这需要Adobe Flash插件，并且结合和标签，除此之外，Flash具有不开放，耗电，占用系统资源大等缺点。大多数用户已经安装了Flash插件（事实上，大概95%的上网用户都装有Flash的某个版本），但HTML 5的支持者正在推动一个开放的，不需要任何插件的多媒体标准。这就是HTML 5的新标签和带来的新特性，他提供了一个嵌入音频或视频（以及与其交互）而不需要类似Flash的私有插件的方法。然而，多媒体并非那么简单。不仅仅是浏览器需要理解这些标签，而且需要一个必要的编码译码器来播放音频或视频。明显的解决方法只能是HTML 5规范的设计者们选择一个编码译码器，并且让每一个浏览器执行。2.3.1. 支持格式
audio 元素目前支持三种主流的音频格式，分别是mp3、wav及ogg；
video元素目前支持三类视频格式，分别是ogg、mpeg4、webM，这三种类格式代表的视频文件为：
Ogg = 带有 Theora 视频编码和 Vorbis 音频编码的 Ogg 文件
MPEG4 = 带有 H.2 视频编码和 AAC 音频编码的 MPEG 4 文件
WebM = 带有 VP8 视频编码和 Vorbis 音频编码的 WebM 文件
2.3.2. HTML5视频音频应用
Google宣布推出开发者预览版的WebRTC，这是一个可让网友之间通过音频和视频实时交流的开放工程，只要是支持Real-Time Communications (RTC)的浏览器都可实现实时音频和视频聊天。
这个新的技术使用了HTML 5和简单的Javascript API，开发者可以很轻松的创建RTC应用，只要浏览器支持，就可在不安装任何扩展和插件的前提下进行实时音频和视频聊天。Google希望用这个开源工程击败微软的Skype和苹果的Facetime。
2.4. 图像绘制
到目前为止，基本上想要直接在网页上进行绘图还是不能轻易完成的，即使是几何图形也不可以。在浏览器当中直接能跟图片的交互操作也很有限，多数是保存和点击。如果希望能够跟图片进行更多的操作或者在浏览器当中画出图形，就需要flash, silverlight 这类插件来帮忙。
2.4.1. Canvas标签
HTML5通过引入canvas标签使用户可以动态的生成各种图形图像，图表以及动画。canvas 元素本身是没有绘图能力，其功能是创建一个画布。所有的绘制工作必须在 JavaScript 内部完成。
HTML5也赋予图片图形更多的交互可能，HTML5的canvas标签还能够配合javascript来利用键盘控制图形图像，这无疑为现有的网页游戏提供了新的选择和更好的维护性和通用性，脱离了flash插件的网页游戏必然能够获得更大的访问量，更多的用户。一些统计数据表格也可以通过使用canvas标签来达到和用户的交互，例如某网站对2009年德国的大选情况统计就全部通过了HTML5来实现用户点击和数据的变更，点选某个区域就可以实时的看到该区域各党派选票率，大大增强了统计图表的可读性。
通过HTML5对图形图像的新特性，未来可能会有在线绘图的工具和应用，人们将不再需要安装painter这类基本的绘图软件，而直接使用基于浏览器的应用。而对用户体验人员和开发者来说，将能够在用户毫不知情的情况下收集和生成用户鼠标的浏览轨迹，从而生成一部分可用的热点图，这对于找出网站的不足，提升用户体验有着重要作用。
2.4.2. 图像绘制应用
示例网站http://www.theshodo.com/Write展示了不通过插件，使用HTML5直接绘制图片的功能，图2-1是示例网站效果截图：
22 HTML5图像绘制应用
2.5. 位置服务
HTML5提供了一组API用来获取用户的地理位置，如果浏览器支持且设备具有定位功能，就能够直接使用这组API来获取当前位置信息。
该API是navigator对象的一个属性 – Geolocation。目前除了ie内核浏览器外，其他浏览器的最新版本基本都支持Geolocation。同时，移动设备IOS 3.0+ 和 Android 2.0+ 系统也支持它，现在很多移动设备的应用加入了地理定位的元素。navigator.geolocation有三个方法getCurrentPosition()、watchPosition()和clearWatch()，其功能分别是检索但只检索一次用户的当前位置、定期轮询用户的位置，查看用户的位置是否发生改变、终止正在进行的watchPosition()。
HTML5的Geolocation API主要特点在于：1. 本身不去获取用户的位置，而是通过其他三方接口来获取，例如IP,GPS,WIFI等方式。2. 用户可以随时开启和关闭，在被程序调用时也会首先征得用户同意，保证了用户的隐私。
2.6. 本地存储
本地持久化存储一直是本地客户端程序优于 web 程序的一个方面。在 web 早期就发明了 cookie，目的是在本地持久存储少量数据。但是，cookie 有三个致命缺点：
cookie 会包含进每一个 HTTP 请求，因此会减慢 web 应用程序，产生不必要的重复数据；
cookie 会包含进每一个 HTTP 请求，因此网络上发送的数据就不能加密（除非你的整个应用都是用的 SSL）；
cookie 数据大小为 4 KB——这已经足以降低你的应用程序的速度，但是 4 KB 的大小有时候确实会捉襟见肘。
我们真正想要的是：
更大的存储空间；
在客户端上的；
不受页面刷新的影响；
不需要提交到服务器；
“HTML5 存储（HTML5 Storage）”，也就是标准上说的 Web Storage，这曾经是 HTML5 标准的一部分，后来由于某些不和谐的政治因素从 HTML5 分离，成为一个的标准。有些浏览器厂商也称为“本地存储 Local Storage” 或者 “DOM 存储 DOM Storage”。
简单来说，HTML5 Storage就是一种让 web 页面能够以键值对的形式，在客户端web浏览器中将数据存储在本地的方法。就像 cookie 一样，这种数据在你离开 web 站点、关闭标签页、退出浏览器等等的时候依然保存。不同于 cookie 的地方是，这个数据不会被发送到远程 web 服务器（除非你自己手动发送）。另外，不同于我们前面所说的那些解决方案，这种机制是 web 浏览器原生提供的，所以不需要第三方插件的支持。
2.7. 离线缓存以及速度
相对传统的应用,web应用不需要安装，所占空间小的特性使其具备传统软件应用所不具备的优势，然而，目前制约web应用最大的问题在于网络连接不能够无时无处，连接断了，数据也就没了。在飞机上，汽车上，火车上，有很多地方都无法被网络信号所覆盖，因此web应用也就无法使用。
HTML5的离线存储使得这个问题迎刃而解。HTML5的web storage API 采用了离线缓存，会生成一个清单文件（manifest file），这个清单文件实质就是一系列的URL列表文件，这些URL分别指向页面当中的HTML,CSS,Javascrpit,图片等相关内容。当使用离线应用时，应用会引入这一清单文件，浏览器会读取这一文件，下载相应的文件，并将其缓存到本地。使得这些web应用能够脱离网络使用，而用户在离线时的更改也同样会映射到清单文件中，并在重新连线之后将更改返回应用，工作方式与我们现在所使用的网盘有着异曲同工之处。
缓存的强大并不止在于离线应用，同样在于对cookies的替代，目前我们经常使用的保存网站密码，使用的就是cookies将密码信息缓存到本地，当需要时再发送至服务器端。然而，cookies有其本身的缺点—4KB的大小和反复在服务器和本地之间传输，并且无法被加密。对于cookies的反复传输，不仅浪费了使用者的带宽、供应商的服务器的性能，更增加了被泄露的危险。
Web storage API 解救了cookies, 据现有的资料，web storage API将至少支持4M的空间作为缓存，对于日常的清单文件和基础信息，应该已经足够使用了，毕竟4KB我们不是都使用了这么多年了？速度的提升方式在于，webstorage API 将不再无休止的传输相同的数据给服务器，而只在服务器请求和做出更改时传输变更的必须文件，这样就大大节省了带宽，也减轻了服务器的压力。
