HTML5 Ready?我的HTML5整理贴

在 Apple、Goolge 等大头 IT 公司的推广下，HTML5 正走向我们的技术生活中。回顾历史，这是业界继 AJAX 和 Web 2.0 之后，又一出现的鲜活的名词儿（buzzword）。HTML5 下面的技术林林总总，依据不同的 W3C 的规范所构成，但并没有一个严格的标准说明此技术就是 HTML5 的家族成员之一。所谓 HTML5，更像一个多种技术（包括 CSS、JavaScript）的大杂烩。当然，对于 HTML 本身，它是一次重要的升级，比 HTML4/4.2 提供的大得多的新内容、新技术、新感受。

HTML标准

涉及 HTML 的一些 tags……

一些元素

HTML5 出来了，毫无疑问先是对 HTML4 本身的标准升级一下，就是增加一批新 tag：section: 、header、footer、nav、article 等有明确语义的元素。以前什么事情都要 div 来做，好了，header 等的就可以代替 div 了。另外取消掉了 <center> 、<font>的标签，Frames 也取消了，不过我觉得 Frames 还是有多少用途，用起来挺方便的。

form

Form 的 action 不是 POST 就是 GET，一般使用 POST 方法。而 HTML5 明确提出，你可以使用 PUT、DELETE 的 action，支持其余的 HTTP 方法，从而更为完整。此外还有一个表单功能比较神奇的，就是动态修改表单元素，竟然不需要 JS 的帮忙。

video、audio

这个问题比较棘手，围绕 HTML5 视频编码标准本身就有比较大的争议，双方有各自的阵营和所坚持的道理，Google、Apple、Microsoft 支持 H.264 标准，Mozilla 和 Opera 支持 ogg 格式，——总之公说公有理，婆说婆有理。最乐的当然是渔翁 Adobe，心想，视频播放方面还是靠我的 Flash 吧，我的占有率还不至于节节败退吧～

关于视频格式之争，可以参见一下小弟之前翻译的《非常HTML5预览：Video/Canvas/Ext JS》 。

HTML 标准为我们还提供了像鼠标拖放 API、跨 document 对象通信、内容缓存（cache）和指定可编辑区域（user-editable content）等等细节的功能。

CSS 3

我们已经对 CSS 比较熟悉了，懂得如何为页面修改美轮美奂的样子。CSS 3 在CSS2.1 的基础扩展出更绚丽的 2D 动画和过渡特效，如此一来省去我们为此而编写脚本的功夫，使得也可以制作媲美 GIF 动画甚至 Flash（再沾点 Flash 的光 ^_^）的变形动作（CSS Transform），像 scrolling marquess / CSS选择器 / gradient() / border-image / box-shadow / text-shadow / border-radius 等的这些新样式对网页制作应该是很受欢迎的。在过去，我们必须编写JavaScript的方式制作页面特效或者动画，使得网页的浏览速度变慢，而且代码写得不好还会容易耗费资源。相较之下，HTML 加上 CSS，只需要以简单的陈述指令，就可以呈现一样的效果。

在布局模型上，CSS 3 正式提出了箱子模型的概念及实现，有关此方面内容可参考我之前写过的博文《箱子布局攻略 (HBox/VBox Layout) 》，Ext 的 BoxLayout 与 CSS 的 Box 理论均一致的。至于提需求提得烂得不能在烂的圆角实现，也正式提供支持！此外，就连针对视觉障碍而提供的音频播放也考虑到，我们只需在那段 Selection 加入音频文件即可！

CSS 作为一个独立的技术，其自身地位应该是与 HTML 等量齐观的。也就是说，如果我偏要在 HTML4/XHTML上 使用 CSS 3 的什么滤镜，特效啊，也不是说不可以的，跟HTML 的版本没有什么必然联系。或者这样说，HTML5 本身似乎没有一个官方的 doctype，说，我这份 HTML 是 HTML5，我该用的就是 CSS 3 没有，没这规定。只要浏览器能支持 CSS3 满足这一条件就行。所谓“外观与内容分离（decorrelate the content from it’s presentation）”，亦盖因于此道。

从 CSS 2.1 到 CSS 3，CSS 变得越来越复杂，但目标依然很清晰，就是为了更方便地设置样式，更流畅的人机交互，更多的设计兼容性，CSS 都提供了相应的标准规范。这一点，无论是架设一般 Web 网站，还是 Web 应用程序，大抵都是相同的。

Web Storage

从定义上讲，cookies 也算“客户端储存（Local Storage）”的范畴内。不过限制很多，储存容量也小。要带入一个真正的离线储存方案至浏览器中，这个使命就留在 HTML5 身上的了。Local Storgae 在客户端上的，自然没有网络的时候可以也使用。这也是被称作离线浏览的原因。以前的离线储存的方案不是没有，而是很多，IE的自己有（userData），Flash也有，FF 就使用 SQLite 作为离线储存，AIR 的也都有！俺也曾经想写一个通用方案，——幸好只是想而已，不然又在笑我喜欢做轮子了。

尽管 W3C 也搞过类似的Web SQL Database ，但毕竟 Web SQL Database 还是 SQL 语法操作的，而 key/value 的方式似乎更适合 Web Storage。原因嘛，我倒觉得这无关乎语法的问题，真的，——SQL 本身就是一门很简洁优雅的可读性很好的DSL语言，而是 key/value 可认为是一种终极的、通用的“设计模式”，在通用与语法之间当然选择的是前者，这就是选择 key/value 的原因了。Web Storage 有两种，一种是类似与服务端的 Session 的，顾名思义 sessionStorage，域只在会话发起到会话结束之中。也可以认为与  Cookies 相似，限当前域所用；另一种是 localStorage，就是没有域限制的了。如果用 web storage代替了 cookie，那么每一次的 Request 就不用携带全部的 cookies 了，没那么浪费带宽。

Web Socket

话说浏览器作为客户端本身就是一个瘦客户端，所以才有后来相对的“富 Rich”Web App。客户端的权限与地位能否被拉高，估计这个 WebSocket 就是重要的标准之一，也就是解决了有态的长连接才能真正可靠的通信问题，polling或XHR的都不算。那么怎么理解 WebSocket 诞生的前因后果呢？小弟不才，一时半刻无法说出个所以然，先给出一些有用的连接，其实还是蛮有趣的话题，容日后再细究：

http://whatis.techtarget.com/definition/0,,sid9_gci213051,00.html

http://www.yafla.com/dennisforbes/-Web-Apps-Suck-Because-HTTP-is-Stateless-/-Web-Apps-Suck-Because-HTTP-is-Stateless-.html
http://developer.ccidnet.com/art/322/20021202/32324_1.html
http://nthucad.cs.nthu.edu.tw/~yyliu/personal/nou/04ds/fsm.html
http://www.cis.nctu.edu.tw/~is83039/discret/discrete83.html

HTTP 是面向资源的，无关乎具体状态的，如果要考虑状态的，那又要作重新的考虑。直接提供 Socket 的方案是一个快捷的方法。 WebSocket 与网络协议密切相关，这是一种非 HTTP 的协议，所以也必须得 IETF 批准通过。对于浏览器模型而言，必须暴露 Socket 的相关 API 直接让 JS 操控。呵呵，还是一位朋友说得好，作为我们的结案陈词吧！

……有了 Web Socket 之后 WebApp 终于可以实现发布订阅模型了。这个技术对于需要实时数据的应用比如：股票程序，在线 IM（现在 WebQQ 是内嵌  Flash），交互性游戏等，都是至关重要的。……之前的 AJAX 实现我觉得有比较浓厚的 Hack意味，因为 HTML 的设计者设计 HTML 时就不是为这样使用的。貌似到了 HTML5 之后，AJAX 才正了名分。

Canvas 与 WebGL

<canvas>的作用是什么？<canvas>的作用在于浏览器的矢量绘图，以及一系列相关的 API。一般图片我们可以图片 jpg、png、gif 搞掂，这一点地球人都知道，但矢量就比较麻烦，一句话，仍然是跨浏览器的问题导致。非 IE 浏览器很早就支持了 <canvas>了，它们是 Apple， Firefox 1.5，Opear9，其中 Apple 就是 <canvas>的发起者，率先在 Safari 1.3中支持了 <canvas>。IE 方面还是老样子，我行我素的可以，居然到 ie9 才支持这个 <canvas>。当前可以说将 <canvas> 派上用场无望，除非使用一些折衷的方案，例如就是使用兼容库 http://excanvas.sourceforge.net ，通过 VML 变相支持 canvas。其实很早就有了，好像 2006 年的时候 Google 就将其开源了。最低可支持到 IE6，也是最多人使用的 IE 版本。

除此之外，我们不但可以使用 div tag 作一些简单的图像，甚至再细磨一点，用 1x1 的像素点阵法也可以，但终究比较迂回和 hack，所以期待 <canvas> 便是一件很顺理成章的事情了。W3C 所表现的态度，也与大众的呼声趋于一致，把 <canvas> 纳入 HTML5 中，成为标准 Tag 中的一员。虽然此时尚在草案当中，但群众呼声高，什么报表图形、饼型图、柱形图都很需要这些矢量元素的，所以只要标准化后，连 IE 都无缝支持了，那么 <canvas> 应该很受欢迎。

显然，流行 <canvas> 的话对于 Flash 他们来说不是什么好消息。一句话，既生 Falsh，何须 <canvas>，呵呵。不一定说它们俩互为“天敌”这样的程度，但至少不可能和谐共存就对了。那么，不是还有一个 SVG 标准的么？SVG 本身是与 VML 对于的，似乎随着 <canvas> 的成熟，SVG 倒好像有点多余，或者适合高端场合吧，一般 <canvas></canvas> 都够用了的。SVG 早已是标准，不算 HTML5 的一员。许多人觉得 HTML5 与 Flash 之间会斗得你死我活，但 HTML 的优势是：跨平台、零部署、符合标准即刻整合第三方程序、数据，易于搜索和结构化数据，而 Flash 的优势是在高端应用，包括在线游戏、动画和视频，如果 HTML5 不染指视频，本来这场斗争其实可以避免的。

关于 Canvas 推荐 Mozilla 官方的教程：https://developer.mozilla.org/cn/Canvas_tutorial

WebGL 则跑得更远了。因为 <canvas> 充其量只支持渲染 2D 的，如果加多一维，来 3D 的，就非这个 WebGL 莫属了。以前我们不是有 OpenGL，……那时候好像只有 Quake等少量游戏的 Native API，但影响力很大。现在的 WebGL 也想继承 OpenGL 的遗风，说明他是一个免版税的、公开的 API。可是咱对 WebGL 比较朦胧，只知道在浏览器搞这些 3D 的，很好，很强大……

W3C 的搞头很多，很多，地理位置定位 ，File API ，控制硬件（摄像头、蓝牙、甚至手机）的 Device API……

小结

新东西看上去总是很美好的，但至少可以肯定的是，在项目还不会那么快地应用到 HTML5，不过移动平台却是个例外（参见拙文《InfoQ访谈：用HTML5开发移动Web应用程序：阅读笔记》 ），相信 HTML5 会随着手机浏览器的升级而迎接它大放异彩的时代的到来。

Edit：完成本文后看到 Abel Avram，《Deploying HTML5》 一书的作者如此认为：

有组织地采用 HTML5 需要时间，我觉得除非你是 YouTube 这样的“大腕”，否则你无法要求用户安装新的浏览器，或者你是微软/ Apple /RedHat/Ubuntu，在系统上直接预装支持 HTML5 的浏览器就行。我觉得 HTML5 会有市场，但到今年十二月份或明年第一季度左右，热潮才会袭来，到时候你可以留意下大家接的项目类型和 HTML5 的发展势头。

那么可以认为，HTML 的到来决不是渐变而是突变……

参考：《CSS之父也批 Flash：HTML 5好多了》