现在的 HTML5 就像当年崭露头角时的 Ajax，有人在做，但不知道叫它什么。最近，苹果在 HTML5 上大做文章，而著名的 Web 设计师 Eric Meyer 则提出了 Web Stacks 的概念。Alex Kessinger 是 Yahoo 的一名前端工程师，本文是他对 HTML5 应用现状与前景的思考。

开源模式带来转变

O’Reilly 创始人，Tim O’Reilly，一位开源的支持者，曾在《Open Source Paradigm Shift》中如是说：
“IBM 对个人电脑设计的商品化使利润从硬件转移到软件这一层面，而开源将带来新的财富”
价值在不同的层面转移，HTML5 将成为新的层面，商品的价值在下降，现时的浏览器已经成为商品，但这并没有问题，只要它们都遵守标准。人们说，我们可以将操作系统置入浏览器中，但这行不通，如果我们可以从过去的经历中学到些什么，那就是，不能简单照抄过去的模式，好比广播到电视的变迁，你不能简单地在一个播音员面前放台摄像机完事，将操作系统置入浏览器未必比 HTML5 离线应用本身更有价值。

发布渠道的重要
诸如 苹果应用商店，Android 应用商店一类的渠道将成为主导，另外，一些新的，象 Valve 游戏渠道，Netflix 电影渠道一类的东西将会出现，在”云“时代，这些发布渠道将像桌面时代的操作系统一样用来对用户进行组织和归类。

我们是如何到达现在这个阶段的?
有两个关键的因素。

感谢 Web 标准
尽管浏览器市场并不统一，但至少他们都运行 HTML，JavaScript 和 CSS。当我们希望通过 Web 推出一些东西的时候，我们知道，无论如何，用户都能看到，然而你能想象人们都自己定义 Web 时的情景吗，假如有人不使用 HTTP协议，或者不使用 HTML，那才是世界的末日。W3C 一类的组织让各个浏览器厂家都保持同一个方向。

还好，我们并没有很多渲染引擎
浏览器并不好做，数十亿的网页，参差不齐的代码，这些东西让独立开发者没有机会单独设计浏览器，因此，有能力设计浏览器的始终是那么一小撮厂商，事实上，时至今日，我们只有四种主要的浏览器渲染引擎，Trident (IE), Gecko (Mozilla, Firefox), WebKit (Chrome, Safari), 以及 Presto (Opera)，而众多浏览器都是建立在这些渲染引擎之上的。这意味着，不管在什么样的设备上，我们不用太担心它使用什么样的浏览器，不管什么设备，只要它有一个浏览器，就有一个可以运行 HTML5 的环境。

标准何日面世？
关于 HTML5 成为标准的时间，Ian Hixie 的说法最受认可:

“根据估计，HTML5 直到 2022 年才会形成 W3C 推荐标准“

然而，虽然标准的形成尚待时日，但浏览器厂商已经在实现各种 HTML5 功能。

功能探测 vs 浏览器探测
如果你是开发者，你可以使用那些高级功能，但需要进行功能探测并提供渐进式设计。坊间有大量的功能探测库，如 Modernizer ，另外，Mark Pilgrim 有一个清单，它可以让你探测任何功能。

离线 API
离线 API 是一切 HTML5 应用的基础，不单单是离线数据的事，对开发者来说，拥有本地存储（localStorage）自然很好，但如何让程序完全离线运行？Application Cache 是答案。如果不能离线保存源文件和数据，我们就无法实现离线的 HTML5 应用。

我们目前有几种离线存储机制，简单的如 localStorage 和 SQL 存储引擎，已经有一些浏览器在支持了，而最新的明星是 Indexed Database，它得到了所有主流浏览器支持。这些离线保存应用和数据的能力，是 HTML5 的基础，目前，Webkit，Firefox 已经可以实现，而 IE9 也即将实现。即时 IE9 的支持还需要等待，想一下，最需要离线应用的场合是哪里，自然是智能手机和上网本，智能手机多数都是用 Webkit。

W3C Web 应用工作组：HTML5 应用的下一步
W3C WebApps 标准已经做了大量工作，包括 API 及 HTML5 Web 程序细则。

HTML5 应用的打包部署

HTML5 apps – QuirksBlog 博客文章中说，”对于本地/离线 HTML5 应用，W3C Widget packaging and configuration 是首选机制，并将成为事实标准，很多厂商已经开始对之进行实现。W3C Widgets 支持任意平台的 Vodafone S60 和 Samsung 手机, Opera 桌面与移动浏览器，Bolt 浏览器 以及 Windows Mobile 6.5。BlackBerry 也支持，不过需要特殊的 Java 包。“

这些都是标准，本质上讲，如果你有一个 HTML5 应用，它就会包含 HTML, CSS, 以及 JS，这些标准只不过偶是帮助开发者将他们的程序打包发行，如果你熟悉 PEAR, 它们是很相似的概念。你可能需要一些元数据，告诉系统你的程序是如何打包在一起的，在支持这些标准的平台上，你就可以保证你的用户可以顺利运行这些程序。

其它
HTML5 还有更多 API 可以帮助开发者创建应用，这些 API 可以让你的程序访问诸如本地文件，摄像头，SOCKET 通信服务，以及硬件动画加速等。这些 API 仅仅是开端，这样的 API 后期会越来越多。

HTML5 程序可以应用在哪里？
当然是浏览器，如果一个设备拥有一个浏览器或渲染引擎，而且这个引擎是现代引擎，它就可以运行 HTML5 程序。HTML5 程序会应用在以下几种场合。

桌面
如果你拥有一个符合 Web 标准的浏览器，就可以运行 HTML5 应用。桌面仍然很重要。

指定站点浏览器
诸如 Gmail 一类的站点可以看做一个应用，使用专门的浏览器运行，这样的浏览器没有地址栏，是专门用来运行指定站点应用的，甚至可以制作一个安装包来分发。以下资源值得一看，Prism, Fluid/Fluidium 以及 NativeHost。

移动领域
这是 HTML5 最热门的运行场所。iPhone 可以和很多程序集成，将你的程序显示在它的今日桌面（这里有一个教程），Android 也支持需要的 HTML5 API，但集成不够好。未来几年，支持 HTML5 的移动浏览器将如雨后春笋，将你的应用向 HTML5 迁移是很明智的，因为 HTML5 将很好地运行在这些设备上。

跨界领域
已经有公司即将发布电视平台，Google TV 以及 Apple TV，Google 表示，他们的 TV 平台将支持 HTML5，我们不知道苹果的 TV 平台将支持什么，鉴于他们最近对 HTML5 的一系列炒作，很有可能也支持。另外一些电视盒厂商，如 Boxee 业已开始支持 HTML5，如果你想为 Boxee 开发应用，与其专门为它开发，不如直接使用 HTML5。

跨界领域拥有大量的平台，那些可以连接电脑的电视的数量在不断增长，我们已经可以在电视上全屏观看 YouTube，而备受欢迎的 Wii 则内置了 Opera。所有这些，都将借助 HTML，CSS 与 JavaScript。

HTML5 应用商店
Eric Meyer 讲到了 HTML5 应用程序问题，他将 HTML5 应用成为 Web Stack Apps， HTML5 要获得更多关注，可以建立 HTML5 应用商店。Chrome 正在这样做，而 Palm 已经有了一个这样的东西。

应用商店是很好的东西，开发者可以直接得到报酬，而无需像现在这样靠广告维持，同时，用户也将有一个地方去为他们的设备寻找程序。

HTML5 市场前景
HTML5 在快速成长，值得所有人密切关注，最近的一两年，会有很多公司进入这个领域，我们或许会在 Chrome 应用商店看到一些重量级厂商，我们也有希望在 Google TV 和 Apple TV 领域看到一些应用商店的出现。HTML5 会像传统的 Flash，Flex，Silverlight，Objective-C 那样，形成自己的生态系统。HTML5 将比 Flash, Flex, Silverlight 以及 Objective-C 更容易出现在任何设备。

对于年轻一代开发者，HTML5 应当是他们首选技能，HTML5 会形成很大的市场，很有很多公司需要这方面的人才。
延伸阅读

• HTML5 到底是什么？

盒子模型
下图就是一个典型的盒子模型示意图

在内容区外面，依次围绕着 padding 区，border 区，margin 区，这一模型结构在所有主流浏览器都是一致的。通过盒子模型，我们可以为我们的内容设置边界，留白以及边距，盒子模型最典型的应用是这样：我们有一段内 容，可以为这段内容设置一个边框，为了让内容不至于紧挨着边框，可以设置 padding ，为了让这个盒子不至于和别的盒子靠得太紧，可以设置 margin。

到目前为止，一切都很完美，直到当我们想为这个盒子设置一个尺寸的时候。

IE6 和 W3C 标准浏览器对盒子模型的不同诠释
当我们试图为一个盒子设置尺寸的时候，问题出现了。IE6 和 W3C 标准浏览器对盒子模型有不同的解释，这个不同解释表现在盒子的尺寸上，下图是两种类型的浏览器对盒子尺寸的不同解释示意图：

可以看出，IE6 盒子模型中，盒子的尺寸包含了 内容区，padding， border 和 margin 这四个部分，而 W3C 的盒子模型中，盒子的尺寸只包含内容区，padding，border 和 margin 被排除在盒子尺寸之外。

为什么 IE6 的盒子模型更合理
在现实世界中，我们描述一个物理盒子的时候，如果谈到尺寸，是不会只计算其盛放的物体的尺寸的，我们还会算上空隙与盒体本身。拿集装箱装箱为例，我 们有 100 只花瓶，每只花瓶用1个纸盒包装，为了防止花瓶破碎，我们在花瓶周围塞上泡沫，这相当于 padding，纸盒的外围纸板相当于 border，在装集装箱的时候，为了防止纸盒之间相互碰撞，纸盒之间塞上稻草，这相当于 margin，很显然，我们向货运公司报告我们货物尺寸的时候，是要将整个纸盒的尺寸，连同纸盒之间需要塞稻草的空隙都告诉他们的，倘若只报告花瓶的尺 寸，货运公司是没有办法装箱的。

再举一个例子，假若我们有一面墙，要在上面挂10幅油画，油画是用相框裱糊的，相框的边框相当于 border，油画和边框之间的距离相当于 padding，相框之间的间隔相当于 margin，这个例子和 Web 布局设计已经很接近了，对任何人来说，使用 IE6 的盒子模型，将整个相框，包括油画当做一个整体更容易布局，当你知道了整个相框的尺寸后，不必再去考虑 padding, border, margin 这个因素的影响，每个相框就是一个整体，至于 padding, border 与 margin，这是浏览器自己事，不需要设计者去关心。

在具体的 Web 设计中
在具体 Web 设计中，尤其牵扯到复杂网格布局的时候，IE6 的盒子模型更容易控制，我们不妨看看以下几个设计场景。

1. 面板式界面设计
页面上包含几个面板，比如一个登录面板，一个最新新闻面板，一个投票面板，这类设计典型的做法是，用背景图的方式，首先逐个设计出这些面板的外观 图，将需要用具体内容替换的地方空着，这些面板，无非就是一些使用面板外观图片做背景图的盒子，然后，在这些盒子里面，放上具体的内容，使用 padding 控制内容的摆放位置，使用 margin 调整面板本身的摆放位置，由于面板的尺寸是固定的，我们依此确立了盒子的尺寸之后，就无需再关心尺寸问题，然后，不论你怎样调整 padding 和 margin，都不会影响面板本身的结构。这是 IE6 盒子模型。

而在 W3C 的盒子模型中，调整 padding 和 margin ，都会影响盒子的尺寸，你在调整内容摆放位置的同时，极有可能打乱面板本身的结构。

2. 百分比级尺寸 + 像素级边界问题
W3C 盒子模型在设计中最让人头疼的是，假如你有一个不确定宽度的容器，想在里面放置两个同样大小的盒子，最合理的的做法当时是设置每个盒子的宽度为 50%，这样，不管你的容器宽度为多大，这两个盒子总能自动适应这个宽度，然而，前提是你不要设置任何 padding 或 border，而，现实中，为了防止两个盒子中的内容互相挨得太近，你肯定要设置 padding，一旦设置了 padding，就会发现你的容器被撑破了。

当然你会说，每个盒子的宽度不要设为 50%，可以设为 45%，然后为每个盒子再加一个 5% 的 padding，这是一个解决办法，但我们在设计中经常有这样的习惯，虽然一段内容的宽度可能不确定，但我们总喜欢它拥有固定 padding，我们并不希望 padding 自动适应，况且，在很多时候，我们希望为一个自适应宽度的盒子，设置一个 1 像素的 border，在这种情形，W3C 盒子模型将陷入困境。

而遇到这种情形，IE6 盒子模型不需要任何周折，你只管将每个盒子的宽度设置为 50%，它们会自动适应容器的宽度，然后，不管你你怎样设置 padding 和 border，都不会撑破你的容器。

W3C 在盒子模型上迷途知返
虽然 W3C 永远都不会承认，但他们显然意识到了这个问题，重新定义盒子模型是不可能了，所以，在 CSS3 中，我们看到了下面这个属性：
box-sizing
box-sizing 有两个可选值，一个是默认的 content-box 一个是 border-box，选用后者，盒子模型将按 IE6 的方式进行处理。

W3C CSS验证服务是由W3C制作的一个免费软件，用于帮助Web设计者检查层叠样式表(CSS)。你可以在W3C提供的免费在线服务中使用，也可以下载后作为一个 Java程序或者Servlet运行在自己的机器上。