HTML 5 是下一代互联网核心标准，最早在2004年6月由 WHATWG (Web Hypertext Application Technology Working Group) 发起，当时叫 Web Applications 1.0，2007年被 W3C 接受为 HTML 5 的基础。标准的第一个 Public Draft 版本2008年1月公布，2009年10月 WHATWG 工作组将标准状态标记为 “Last Call”，WHATWG 认为自己的工作已经接近尾声。
HTML 5 标准的执行编辑是来自 Google 的 Ian Hickson 和来自 Apple 的 David Hyatt。这恰恰是推行这个标准最出力气的两个业界巨头。
目前，WHATWG 和 W3C 网站上的最新版本是2010年2月4日的 draft；Ian Hickson 希望标准文本可以在2012年成为 W3C 建议草案，2022年成为 W3C 正式建议标准。
WHATWG 提出 HTML 5 的基本出发点是构建一个完全开放和自由、更加开发者友好的 Web 应用生态环境，其主要目标是消灭网页上的各种私有专利插件，尤其是和网页富应用（RIA）有关的那些，其中最有来头的是 Adobe 的 Flash，Microsoft 的 Silverlight 和 Sun 的 JavaFX。为此，作为主要策划者的 Google 也毫不犹豫的放弃了自己的插件，例如 Google Gear，而全力在 HTML 5 草案框架内来实现相关的功能。我们后面会看到，正因为这个初衷就包含了对很多其它业界巨头的侵略性，所以它注定不会一帆风顺。
这篇文章试图利用现有的资料粗浅分析以下的几个问题（除注明出处的以外均属个人臆断，请勿轻信）：
1. HTML 5 值得期待吗？或者说，对于开发者和用户有什么价值？
2. HTML 5 有多大的成功机会？进一步的，还要多久？
3. HTML 5 会让以 Flash 为代表的私有专利技术边缘化吗？
Part I HTML 5 的特性和价值
HTML 5 主要引入的变化包括两大方面：HTML 标记语言，和面向脚本的 API。
在标记语言方面：
1. HTML 语法和对应的解析规则发生改变，HTML 不再基于 SGML，浏览器开发者可以开发更适合于 HTML 的解析器，来提供更好的效率、兼容性和错误处理。当然，浏览器应该提供向下兼容的能力。
2. 直接在 text/html 上下文显示 SVG 和 MathML 的能力。
3. 强化的表单元素，包括增加了一些输入类型的支持（例如日期、时间等），和一些更像应用程序的属性（例如输入框的 tab order 全局属性）。
4. 废弃了那些已在 CSS 中完全实现的功能对应的标签，例如 <font> 和 <center>；还有，彻底和 <frameset> 说再见吧。
5. 表单支持 PUT 和 DELETE 行为，以实现对 REST 的全面支持。
6. 通过一组新的标签和属性来支持新的功能，以取代以前必须使用一些私有专利的插件才能做到的事情，这里面最引入注目的包括用于多媒体播放的 <audio> <video> 和用于绘图的 <canvas>。
7. 一组使 HTML 更富语义性的标签：<article> <section> <footer> 等。
在脚本 API 方面：
1. 配合 <canvas> 标签的实时二维绘图，这将使得纯页面脚本的高动态游戏和互动成为可能。
2. 时间精确的媒体播放。
3. 离线数据存储，支持键/值对，也支持嵌入式的SQL数据库。
4. 基于 contenteditable 属性的内容编辑操作。
5. 基于 draggable 属性的拖放操作。
6. 跨文档消息机制提供了一种方式使文档可以互相通信而不用考虑它们的来源域，在某种程度上，这样的设计是为了防止跨站点的脚本攻击。
7. 服务器发送的事件，与新的 event-source 元素配合可以建立页面元素与远程数据源之间的持久性连接，来实现消息 push——而不必轮询。
8. 浏览器历史记录管理以支持 AJAX 麻烦的页面前进/后退问题。
9. MIME 类型及协议处理器的注册（这也是 REST 风格需要的核心能力）。
10. 内置的缓存机制来支持脱机应用。
11. 新的网络 API 支持 Web 应用在本地网络上互相通信，并在它们的源服务器上维持双向通信。
比较明显的是，HTML 5 是一个主要面向开发者的标准，当前 Web 开发者头痛的很多问题可望成为浏览器的标准功能，直接利用简单的标签、样式和脚本即可实现——当然前提是各个浏览器都跟进标准。而不少在开发者中广受欢迎的插件和脚本框架提供的功能都被收编了。这种趋势显然受到这些技术概念的影响：语义网，RESTful，Web 2.0。我个人期待着这些努力能够使 Web 应用开发更加自然、一致和协调。
对于用户来说，又会有什么更好的体验呢？客观的说，不会很明显。对于设计良好的站点来说，用户的体验只会有较小的变化，很多将是不易察觉的小优化；对于设计比较糟糕的站点——我不指望它们能够很快的开始接触 HTML 5 的先进特性。不过一个可以期待的变化，是大屏幕的智能手机上，基于本地存储、内置的媒体播放等能力，可望出现更多基于 Web 技术的强大应用，而不必因为现在先天不足的移动版本 Flash 之类的问题而捉襟见肘。
另外我们也可以看出，对于浏览器的功能的极大加强，而摆脱其它五花八门的插件和非标准化的工具包的依赖，和 Google 关于“一切计算在云端”的模型是高度一致的，Google 在 HTML 5、Chrome 浏览器和轻量级操作系统上的投入是一个完整的战略链条。
Part II HTML 5 的可行性
和 SOA 这样虚无缥缈的概念不同，HTML 5 并不是远在天边的，它的很多技术基础已经存在甚至成熟，所需要的是 Web 应用的服务端和客户端（也就是浏览器）逐步的整合，拿出完整的实现——而其中最重要的，无疑是浏览器。
有了 Google 和 Apple 的大力推动，WebKit 为核心的浏览器势必成为这个进程中的先锋，可以预见的将来，WebKit 将是 HTML 5 事实上的“参考实现”；Microsoft 由于尚未完全评估清楚对其自身战略的影响，所以至今也没有表态，但是“有选择的接纳”将是一个多赢的选择；Mozilla 社区目前表现出了对 HTML 5 的热情，但是由于总体架构设计上的一些问题，它们全面转向新标准将没有 WebKit 那么轻松——当然，一旦社区下定决心，这应该不是问题。
理想状态下似乎一切都很美好，但设想一下，如果 IE 继续无视标准，Mozilla 也三心二意，结果可能是很糟糕的，开发者不得不在两个都很难过的选项中抉择：或者固守老的标准看着 HTML 5 美丽的愿景掉泪，或者花出成倍的代价来做多浏览器兼容性实现。
HTML 5 的工作组从过往历史中已经预计到这个可能的问题，在跨标准、跨浏览器兼容上做了很多的工作，几乎每一个新的功能都包含了自动或者半自动的降级解决方案，从而保证严格遵循规范的网页能够在不支持 HTML 5 的浏览器上得到可接受的结果。这方面的思路无疑是对头的，但是任务也是艰巨的，需要持续的努力才能达到目标。
所以我认为，HTML 5 的技术基础，以它颇有雄心的目标来说，算是非常脚踏实地了，这是一群真正的 Web 开发者弄出来的标准，不会像 SOA 那样，把 WS-* 协议族搞得复杂繁琐几乎没人乐于使用。
至于是不是能够成功，取决于整个业界，尤其是大的 Web 应用提供者的态度，目前暧昧不明的浏览器状况，其实是因为 HTML 5 的杀手级应用还在酝酿（或者说还在暗战），一旦在某几个关键的应用上 HTML 5 带来了至关重要的生产力或者用户体验的提升，那么浏览器的战局就会发生显著改变。在这个领域，Apple 和 Google 无疑能够提供足够的重量级应用——但不是全部——诸如 Facebook、Amazon 之类的重量级第三方的态度将是关键的影响因素。考虑到这些应用提供者先天的开放技术倾向，对于未来我准备抱有稍微偏乐观的态度。
可以预计，今年和明年在几个特定领域（我们下面就要提到的视频播放就是其中之一）会开始第一回合的较量，新生的标准将经受考验——它面临一系列实验室里碰不到的险恶问题；而广大 Web 开发框架已经开始考虑对 HTML 5 的支持（参见这篇文章）。和 HTML 5 正式提交给 W3C 成为草案的时间相当，如果顺利的话，2012年前后将是主流应用和浏览器开始全面转向新标准的关键时间。
Part III HTML 5 的第一批对手
最近 Adobe 已经开始在多个场合进行防御性的宣传，Kevin Lynch (CTO) 强调目前网络视频播放上 Flash 仍然是最好的选择，声称 HTML 5 的媒体播放能力将使 Web 世界 “back to the dark ages of video”，并攻击 HTML 5 的实现将是有问题的，跨浏览器兼容性无法保证。
Kevin Lynch 先生激动的原因很简单，目前 Flash 在 Web 领域应用最广的是前三位是：视频播放、广告、游戏。一旦 HTML 5 的 <video> 标签被普及，前两个应用就和 Flash 没啥关系了，任何网站都一定更喜欢像拿 <img> 标签处理图片一样，拿 <video> 标签来处理视频，Twitter 上的 overboming 朋友用一段生动的描写说明了这种境况：
想象没有 <img> 的世界，如果要看图片，你得用个第三方插件，这东西很慢而且没有标准的方法嵌入页面，你不能随意地复制图片内容，而搜索引擎也没法知道这是个图片或者游戏还是广告，这就是支持用标签取代 Flash “视频”功能的原因。
目前世界上最大的两个视频分享网站 YouTube 和 Vimeo 都推出了自己的 HTML 5 测试，它们实现转换的时间都不长，说明在服务器端进行转换的代价不高——但是它们目前都只支持基于 WebKit 的浏览器，即 Safari 和 Google Chrome，而目前占据最大用户比例的 IE 和 Firefox 都不支持，这是什么原因呢？别忘了，Firefox 是世界上最早宣称支持 HTML 5 的 <video> 标签的浏览器（3.1版本）。
这个问题出在视频编解码器即 codec 的授权上。
目前网络视频分享和播放的事实标准是 H.264，这个标准具有从低到高各种分辨率下良好的表现，对于大容量视频的流播放支持尤其优异，YouTube、Vimeo 还有 iTunes 的缺省格式都是这个，但是很不幸，H.264 标准既不开放也不承诺免费——是的，它目前是免费的，但是专利的所有方有权随时修改授权协议，这种事情历史上发生过多次，如果你不了解，不妨看看当年 GIF 图片格式和 MP3 音频格式上发生过什么故事。
另外一个被 HTML 5 工作组考虑的视频编码格式是完全开源和自由的 Ogg Theora 格式，这个倒是符合 HTML 5 “完全开放和自由的 Web” 的理想，但问题是，这个格式还很不成熟，问题很多，对于大容量视频尤其表现糟糕，所以短期内没有哪个真正营运的视频网站会采用。
所以目前的情况是，因为 H.264 的授权，Opera 和 Mozilla 都不愿意实现它（前者是成本问题，后者则是源码分发协议问题，Firefox 已经支持了 Ogg Theora 格式），事实上 Chrome 的 开源版本 Chromium 的缺省分发也不具备 H.264 实现（以二进制方式分发的 Chrome 则包含，因为 Google 得到了授权），Safari 和 WebKit 的 Mac 版本则没有问题，因为 Mac OS X 的 QuickTime 内置了已获得授权的 H.264 实现。
来自 Google 的 HTML 5 工作组执行编辑 Ian Hickson 认为有两个可能性来最终解决这个问题：要么 Ogg Theora 编码器不断优化开始实现商用，要么 H.264 逐步开放（有个潜在竞争者毕竟是好事啊）。他采取的策略是从 HTML 5 草案中移除关于视频播放的 codec 部分，而把这个问题交给市场去做出选择，他认为最终胜出的一方将是（参见这里）：
- 无需费用就可以实现，而且可由任何人分发
- 拥有可用的硬件解码器
- 使用广泛以弥补额外的专利费用
- 拥有足够高的“每比特质量”（quality-per-bit）以处理大容量视频应用
这个看似麻烦的问题，最终的解决方案倒不少，最坏情况下就是 Google 或者 Apple 拿出一个格式，开源它就行了，别忘了 YouTube 和 iTunes 都是这个领域的重量级玩家。
综合收益和可行性之后，我认为最终 HTML 5 相关标准会将 Flash 逐出视频播放这个领域，而这并不意味着 Flash 就完蛋了，它应该更加专注于互动性、数据性更强的应用领域，比如游戏和教学，还有仪表盘一类的企业级应用，其优势在于工具和已有的开发者群体，Adobe 为了 Flash 而攻击 HTML 5 是不明智的，他们应该好好改进和强化自己的 Web 创作/开发工具——就像当年 Macromedia 做的。
所以与其说使 Flash 边缘化，还不如说：Flash，你该干正事了，作为一个全功能的开发平台，就守着个视频播放应用难道不害臊么。。。（大雾