微软的“本地化HTML5”究竟意味着什么？

微软在近日的演讲中，自豪地展示了IE10的首个平台预览版。但在其大肆宣扬性能提升的同时，却忽略了一个更为重要的问题。所谓的“本地化HTML5”究竟指的是什么？仅仅是硬件加速而已吗？我们可不这么认为。

与此同时，在IE博客上发表的新闻稿中尽管大量谈论了关于标准的话题，但从前三段的表述中仍旧可以嗅探到一些微软未来的发展规划。

首个IE10平台预览版，今日已提供下载，这是迈向未来支持本地化HTML5过程的第一步。在针对终端操作系统进行过优化的浏览器上，以本地化的方式运行网站和HTML5，可获得更快速的操作体验。

我们在IE9的基础上，构建了对HTML5的支持，同时通过Windows来传递更多的本地化HTML5体验，以及windows上最好的浏览体验。IE10延续了IE9的路线，直接使用了Windows提供的组件，规避了由抽象、层，以及会降低浏览速度和体验的类库等。

目前为止，这种本地化的Web和HTML5体验只能通过Windows 7和IE9来实现。IE9可借助于操作系统提供的便利来达到最大的性能、可用性以及可靠性——从底层的图形堆栈到交互界面中的跳转列表（Jump List）等。四周前，我们面向全球的企业和用户，发布了一款快速、整洁、可靠并且交互良好的IE9，以此来传递最佳的HTML5体验。最好的HTML5相对于操作系统来说是本地化的，因此Web站点使用的传输层也是最少的。最好的HTML5允许站点在不同浏览器下使用相同的标记——相同的HTML、CSS和脚本。最好的HTML5可以为开发者节省时间，同时通过相同标记即可将支持HTML5功能的站点，与使用其他不稳定技术的站点区分开。

显然跳转列表与硬件加速和性能是无关的。所以，真正要发生的是，微软要把HTML5与本地化的Windows应用绑定在一起。跳转列表只不过是冰山一角，后续还有更艰难的工作有待完成。

为了看得更明白一点，我们首先要区分出本地应用与Web应用究竟有哪些不同？然后除去HTML5标准中所涵盖的内容。举例说来，Web版的文档编辑器需要具备哪些特性？

1.文本编辑

2.格式化

3.字体

4.本地或网络驱动器加载或保存文件

5.由Web加载或保存文件

6.拼写和语法检查

7.最近访问文档的支持

8.从开始菜单中启动

9.支持离线操作

前两项很容易实现。CSS3中的字体组件很容易满足第三项。第四项是我们首先要解决的。将文件保存到本地或网络设备很容易实现，打开它们却并非易事。不能通过简单的文档双击操作在浏览器中打开一个网站，紧接着再在网站中加载和展现文档。因此，将文档类型与Web应用关联的特性是首要解决的问题。

接着往下看，从网页中加载和保存文档不用费什么脑子。拼写和语法检查，正确的做法是通过HTML5的Web Workers实现。对最近访问文档的支持，是我们的下一步重点。虽然这个功能不是每个人都会用到，但如果列表不支持动态更新的话，会给使用此功能的用户带来很大困扰。

从开始菜单中加载是所有应用程序都期望做到的。通过IE9，可将网站“钉”在开始菜单中，这个通过拖拽一个快捷方式即可实现。如果传言属实的话，Windows 8将会引入一个名为AppX的包部署结构来让这件事变得简单。依照@LongZheng的说法，通过AppX能够将网站描述为目标而不是被编译过的应用。

最后一项是真正的挑战。要具备像本地应用一样的“性能、可用性以及可靠性”，Web应用需要具备在未取得服务器授权情况下的运行能力。以前有很多种办法实现这个功能，但是由于各种原因，大多数的尝试都失败了，其中包括太多的对服务端处理的依赖，以及浏览器缓存的不稳定性等。眼下借助于流行的JavaScript增强的功能及性能，类似于这种的大部分的服务端处理都可以被转移到客户端来实现，这也是理所当然的。浏览器缓存也可以通过配置或增强，从而达到防止“已安装的Web Apps"被误删除的效果。

以此概括出我们的功能清单如下：

1）件类型与Web Apps的关联

2）期访问的文档

3）始菜单集成

4）eb Apps的持久缓存

我们尚不清楚微软何时或是否会实现其他特性，也没有人知道那些许多应用都想变得和本地应用一样的功能是否会实现。但可以肯定的是，微软要想成功提供“本地化HTML5”的支持，就需要借助于网站开发人员，当然这些都不是免费的。开发人员需要在其网站上明确的使用它。而且到目前为止，其他浏览器厂商也明确表示对提供以Windows为中心的特性没有兴趣，开发人员也只能针对IE用户来开发特性。