HTML5 的真相（二）

原文：The Truth About HTML5

协议：CC BY-NC-SA 4.0

九、画布让我（有点）希望我能做 Flash

Canvas 让我们可以在网页的特定区域以编程方式进行绘制。它可以做一些非常酷的事情:设计增强、可视化、绘图/绘画应用、图像处理和游戏(至少在视觉方面)。

稍后我们将进入画布的具体细节。但是，首先让我们看看一些大的东西，以及与闪存不可避免的比较。

Canvas 不是 Flash，将(主要)用于 2D 图形的单一 web 技术与功能丰富、得到广泛支持的客户端环境和一个成熟的开发工具生态系统相比，有点风马牛不相及。然而，除了 HTML5(和相关技术)之外，正被吹捧为 Flash 的有力竞争者。但是探索 Canvas(和整个 HTML5)让我希望我可以用 Flash 做一些令人惊奇的事情。这不是一个流行的观点——我在写关于 web 标准的文章，难道我不应该讨厌 Flash 吗？这也不是我认为我会有的——我已经十年没有使用 Flash 了，作为一个刻板的设计师/苹果粉丝(同义反复？)我经常经历 Flash 在 Mac 上占用内存、崩溃、消耗资源的痛苦(并大量应用 Flashblock)。

然后我看了看人们今天在 Flash 中实际构建的东西，我对桌面 Flash 网站上那些大预算、最好的、随处运行的纯粹的酷因素感到一阵设计师的嫉妒。说真的，看看 http://thefwa.com 的和像乐高星球大战 III(www.lucasarts.com/游戏/乐高星球大战 III/index.jsp)这样的游戏网站。如果说 Flash 确实适合某些类型的网站，那就是这些。这些网站是网络互动的基准。我们已经研究了 HTML5 在交互式网络方面的现状，我们还有很长的路要走。

Flash 正在消亡，HTML5 是我们的全部

然而，我们很难回避 Flash 正在消亡的事实。

众所周知，iOS 设备上没有闪光灯，这一点已经被广泛讨论过。(参见已故史蒂夫·乔布斯 2010 年 4 月的文章《关于 Flash 的想法》，了解为什么苹果选择不支持 Flash:【http://www.apple.com/·hot news/Thoughts-on-Flash/。)

但未来的安卓设备上也不会有任何 Flash 插件。2011 年 11 月，Adobe 宣布他们将完全停止对移动设备上的 flash 插件的支持(见:arstechnica.com/小工具/新闻/2011/11/Adobe-据报道-规划-去内脏-移动-Flash-player-策略. ars )，将他们的重点转移到 Flash 驱动的本地应用程序，并最终转移到 HTML5。

Windows Phone 也从未支持过 Flash 插件。

iOS 设备上(至少)没有 Flash 使得提供一个移动的、纯 HTML 版本的网站成为大多数网站的必需品。如果你打算建立一个 HTML 版本的网站，你需要一个很好的理由来建立一个额外的基于 Flash 的桌面网站。但是在某些情况下仍然有正当理由——一个简单的移动 HTML 站点，或者一个丰富的桌面 Flash 站点。

然后微软投下了一颗重磅炸弹。

2011 年 9 月，微软宣布，对于 Windows 8，IE10 的 Metro 版本将不支持任何插件(【http://blogs.msdn.com/】b/b8/archive/2011/09/14/Metro-style-browsing-and-plug-in-free-html 5 . aspx)。没有闪光灯，没有银光，什么都没有。默认的地铁界面什么都没有。Windows 8 实际上将有两个独立的界面——一个是传统的熟悉的桌面模式，另一个是新的触摸友好的默认地铁模式。如果你想使用 Flash 网站，你将被踢出 Metro 体验，回到桌面模式，IE10 仍将运行 Flash 和其他插件。这可能会像听起来那样笨拙。

用于移动浏览器的 Flash 并没有成功，但是微软的这一声明也标志着 Flash 在桌面上的终结。

Flash 的写作就在墙上。旗舰操作系统将在全球数亿台台式机上运行，其默认体验不会支持 Flash(或任何其他插件技术)。

Flash(插件)快死了，我不是轻描淡写的说。一段时间以来，许多技术预言家一直在预测它的消亡，但现实现在是不可否认的。苹果没有 iOS 支持，Adobe 没有未来的 Android 支持，现在微软也没有 Metro 支持。

Canvas 和 HTML5 能填补空白吗？

Windows 8 将于 2012 年底推出，网站所有者将会突然争先恐后地寻找 HTML5 来替代他们目前对 Flash 的使用。数百万用户将首次体验无闪存桌面体验。考虑一下其中的含义:

• 广告:网站所有者和广告商不会坐视他们的广告收入和点击率下降，他们也不会回到动画 gif。HTML5 支持的(和移动可视的)横幅广告将会有一个巨大的转变，Canvas 将会在那里扮演一个重要的角色。
• **媒体交付:**音频和视频内容将需要使用 HTML5 来交付，但正如我们将在下一章中看到的，这并不像听起来那么简单。
• 游戏: HTML5 游戏也将严重依赖于画布，我们将在本章稍后探讨。
• **站点:**最后，将会有大量的传统 Flash 站点无法在 Metro IE10 中运行，更不用说在移动设备上了。餐馆网站，我在看你。(在转换基于 Flash 的餐厅网站方面，有一个利基市场在等着某人！)遗憾的是，这也意味着像乐高星球大战 III 这样的交互式网站将无法在 Metro IE10 中运行，但希望这能鼓励有进取心的设计师和开发者将网络标准推向绝对的极限。

flash:html 5 IDE？

Adobe 多年来一直在研究 Flash 到 Canvas 的导出——首先是在 2009 年，当时他们在 MAX conference 上演示了这种功能(见演示:youtu.be/ v 69s 22 zbqa)，然后在 2012 年初宣布了一个他们正在开发的扩展，名为“用于 CreateJS 的 Adobe Flash Professional Toolkit”(见声明和视频:blogs.adobe.com/ creative layer/2012/02/28/html 5-Flash-Professional/)。(错误的报道在 2010 年中期流传，Flash CS5 将根据 MAX 2009 视频重新浮出水面导出到 Canvas，但事实并非如此。)最新的演示展示了一个简单的动画，从 Flash 跳到 Canvas，并在 PC 和 iPad 上流畅地播放，但这个工具对大多数网络专业人士来说是否足够复杂(当它最终发布时)仍有待观察。

html 5 IDE flash 在术语上可能听起来矛盾，但几年前将 Internet Explorer 等同于尖端的 web 标准支持也是如此。Canvas 已经存在很长时间了，它在现代浏览器中的支持已经相当成熟，所以 Flash 作为 HTML5 内容创建环境的未来仍然完全掌握在 Adobe 手中。

(同样值得注意的是，2010 年 Adobe 还发布了一个名为 Wallaby 的实验性 FLA-to-HTML 工具(labs.adobe.com/科技/ wallaby/ )，它严重依赖于 SVG 和仅支持 WebKit 的 CSS3。2011 年，Adobe 发布了 Edge 的预览版(【http://labs.adobe.com/】科技/ edge/ )，这是一款简单的 HTML 动画工具，主要依赖于 JavaScript，尽管它声称自己是“HTML5”。然而，Adobe 表示“我们从社区中清楚地听到了他们使用 Edge 在 canvas 和 SVG 中制作动画内容的愿望”，并且“在 Edge 产品储备中已经有了对这些功能的实现请求”，因此基于 Canvas 的动画可能会以各种形式从 Adobe 获得。问题是 Adobe 是否不只是在 HTML5 的水里摸摸脚趾头。)

然后应用程序出现了

由于一些重要的 HTML5 功能(尤其是音频和视频，我们将在下一章中看到)的不成熟，以及缺乏 Canvas 等成熟的设计工具，一些网站所有者可能别无选择，只能在未来几年坚持使用 Flash，特别是作为一种传统技术。或者，他们会开始推应用。

我们正在进入网络的一个奇怪时期。

一方面，就技术而言，web 标准已经赢了，而且赢得很漂亮。他们坚持面对来自专有技术(Flash、Silverlight 和许多其他已经半途而废的技术)、实现者冷漠(例如，微软让 IE 在 2000 年代停滞不前)和规范死胡同(W3C 的 XHTML 2 崩溃)的众多挑战。对于网络纯粹主义者来说，这是一个不可思议的胜利，几年前这似乎还不确定。毕竟微软— 微软！——正在发布其桌面版浏览器，只有的支持网络标准，不仅加入了实现尖端网络技术的队伍，而且做得特别好。

另一方面，HTML5 的 web 标准以及相关的开发工具仍然不是很好。正如我们将看到的，Canvas 有它的用途，但 Canvas 和最广义的 HTML5 在开发、采用和工具集方面仍有很长的路要走，才能与当今 Flash 的成就相媲美。那么当开发者想做一些很酷的事情，但是在浏览器中做不到的时候会发生什么呢？

他们会开发应用程序。

iOS 应用。安卓应用。地铁应用。具有讽刺意味的是，特定平台的应用程序让我们远离了网络的真正承诺——所有人都可以从任何平台获得网络。随着台式电脑变得普遍，我们在 90 年代看到了特定平台软件的爆炸，然后在 00 年代开始出现 web 应用程序——从任何特定平台供应商那里解放出来的软件。现在我们有一个激烈的竞争环境，主要平台供应商(即苹果、谷歌和微软)将拥有最好的应用视为竞争优势，和其中两家供应商正在尽自己的努力使 Flash 成为一个相关的 web 技术平台。

这让我们陷入了一个奇怪的境地:应用程序市场正在爆炸，网络标准环境正在迅速成熟，但网络技术平台却存在一些漏洞，这些漏洞被广泛标记为“HTML5”。

Adobe 深知这一点。我小心翼翼地在上面强调了一个事实，那就是他们放弃了 Flash 插件用于移动浏览器；手机上完全没有 Flash。相反，他们正专注于将移动 Flash 作为原生应用程序开发的环境(这要归功于 Adobe 的 AIR runtime ),并且我们很可能会看到一些由于 Flash 插件而在网络上可用的内容(特别是游戏和流媒体视频和音频)完全从网络上移除，并作为应用程序重生，至少在网络技术赶上来之前是如此。在匆忙填补 Flash 留下的空白的过程中，我们也有可能看到特定于供应商的 web 技术的推出，以及“最佳观看方式”的糟糕旧时代的回归消息。网络上的 Flash 可能正在消亡，但它正在带走一些网络。

对网络来说，这是一个有趣的时代——网络标准赢了，但是到目前为止还没有技术让网络成为一个无处不在的平台。相反，我们看到了 90 年代式的特定平台应用的爆炸，以及特定供应商的“围墙花园”将使网络成为二等公民的威胁。

然而，并非一切都完了——首先，许多“原生”应用在很大程度上是由表面下的网络标准驱动的。就 Adobe 而言，它也在投资 HTML5 开发工具，并参与网络标准进程。浏览器制造商正在以惊人的速度改进他们的浏览器，弥合网络标准和本地应用程序开发之间鸿沟的新规范一直在出现。我们将在第十二章讨论 HTML5 和网络应用时对此进行更多的探讨。

让我们用闪光埋葬闪光主义

如果 Flash 正在网络上消亡，我们应该致力于用它埋葬一些 Flash 主义。让我们确保记住 Flash 时代的教训，特别是当涉及到闪屏、加载屏幕、无意义的动画、烦人的小部件以及过度工程化、过度设计的“体验”时。他们大多是可怕的想法。有些事情根本不值得重复，无论是在 Flash、大量 JavaScript、高级 CSS3、Canvas 中完成，还是以上的一些不虔诚的组合。

我们也要小心对一项技术的判断太快。Canvas 目前正在经历尴尬的青春期——充满了潜在的、令人尴尬的错误、实验、单音节的咕哝，最后(希望如此！)成熟。每当新技术进入网络领域，它通常会以一系列实验性或不适当的方式作为噱头展示，然后才进入它的凹槽并被适度和适当地使用。希望画布很快找到它的凹槽。

我们已经不在画布上了

这就是背景。现在让我们看看 Canvas 元素实际上是做什么的。

<canvas>元素定义了一个位图区域——或者“canvas”——您可以用 Canvas 的 JavaScript API 对其进行编程和绘制。Canvas 元素自 2004 年以来一直存在，并被集成到 HTML5 中。所有现代浏览器都原生支持它(包括 IE9，尽管 IE6-8 需要使用仿真)，现代移动浏览器也是如此。

实际的元素如下所示:

<canvas id="mycanvas" width="500" height="200">     Sorry, your browser doesn’t support canvas. </canvas>

像 HTML5 中的其他东西一样，不理解<canvas>标签的浏览器只是将它们视为通用元素(像<mymadeupelement>)并忽略它们，暴露它们之间的文本。

这就是 HTML 的全部内容。其他一切都是通过 JavaScript API 完成的，它让我们:

• 绘制形状、渐变和阴影
• 处理图像和文本
• 创建动画(通过每秒重画足够次数的画布)。

使用画布就像在 Photoshop 中的单一图层上绘图。你只有一层像素可以处理，一旦你在上面画了，它们就没了。因此，为了制作动画(例如在游戏中)，我们需要为每一帧重新绘制画布。Canvas 没有管理和操作对象的意识(这是 SVG 的事情，我们将在第十一章中讨论)，但是各种各样的库(特别是用于可视化和游戏的库)已经涌现出来帮助处理这一问题。

假设 Canvas 是通过它的 JavaScript API 来操作的，那么您想亲自动手的程度将取决于您对 JavaScript 和以编程方式绘制图形的兴趣。下面是一个我们如何绘制一个基本正方形的例子(使用上面的<canvas>元素和<body onload="draw();">):

function draw() {     var canvas = document.getElementById('mycanvas');     var context = canvas.getContext('2d');     context.fillStyle = "rgb(200,0,0)";     context.fillRect (10, 10, 100, 100); }

这个函数获取我们的mycanvas Canvas 元素(使用我们上面看到的 500 x 200px 的例子)，将填充颜色设置为红色，然后使用fillRect(*x, y, width, height*)函数绘制一个实心的红色矩形。正如你在下面看到的，我们画了一个红色方块，它在 x 轴偏移 10px，在 y 轴偏移 10px，宽 100px，高 100px。(我用 CSS 在我们的<canvas>周围添加了一个 1px 的边框，这样你可以看到元素本身的大小。)

图 9.1。我们非常简单的画布例子。

我们不会深入研究 Canvas API 的工作原理，因为网上有大量可靠的资源，包括:

• Mozilla 的开发者网络画布教程是一个很好的起点，因为它涵盖了基础知识，并且在每个部分都有一堆到其他资源的链接:developer.mozilla.org/ en/Canvas _ tutorial。
• Opera 在这里有一个关于画布基础知识的简短介绍:dev.opera.com/文章/查看/ html-5-canvas-the-basics/ 。
• 马克·皮尔格林的《深入 HTML5》有一个很长的章节是关于画布入门的:diveintohtml5.info/·canvas.html。
• 这里有一个用画布创建突围克隆的教程:billmill.org/静态/ canvastutorial/ 。
• 这里有一个专门的画布教程网站:www.html5canvastutorials.com/。
• web 开发人员的 HTML5 规范(没有浏览器供应商的所有实现细节)在这里简要介绍了 Canvas 的特性:developers.whatwg.org/·the-canvas-element.html。

Canvas 在游戏和可视化方面有很大的潜力，还有更普通的用途，比如创建图表甚至工具提示。但也许 Canvas 最令人兴奋的用途是通过 WebGL 以一种迂回的方式将 3D 带到网络上。

我们一会儿再看。首先，让我们看一些画布的例子。

用帆布做酷的东西

你可以用画布做很多很酷的事情，从动画到成熟的游戏。让我们从更简单的东西开始:工具提示。

工具提示

简陋的工具提示能证明 Canvas 比最先进的 CSS3 更受支持吗？

镶齿的

图 9.2。提示示例。

我也这么认为 tipped(projects.nickstakenburg.com/ tipped)是使用画布来增强页面的一个很好的例子。通过 JavaScript API 以编程方式绘制工具提示，无需担心图像。使用 Canvas 及其 JavaScript API 可以轻松创建新的皮肤和主题，以及圆角、阴影和渐变等效果。此外，通过 ExCanvas 提供的 IE6-8 兼容性(我们很快就会看到)，我们可以获得完全支持 IE 的所有 CSS3 风格的效果。

图表

稍后我们将涉及一些基于 SVG 的图表工具(包括 gRaphaë和优秀的 Highcharts)。但是也不缺少基于画布的图表选项。这里有一个小选择。

RGraph

图 9.3。图表。

这里有一个画布图表，它是用强大的，如果不是那么漂亮的 RGraph(www.rgraph.net/)构建的。基于画布的图表的美妙之处在于它在 iOS(和 Android)中的坚实支持，而 Flash 不是一个选项。(如果你需要更好的跨平台支持，付费的www.zingchart.com/会做 Canvas、Flash 和 SVG。如果你在寻找更简单的东西，Flot 是一个流行的、免费的、基于 jQuery 和画布的制图工具:【http://code.google.com/】p/Flot/。)

设想

图 9.4。想象行动。

Filament Group 的 Visualize 插件也提供了一个可访问的画布制图解决方案，它给出了上面的结果。在他们的网站上有详细的讨论:www.filamentgroup.com/实验室/update _ to _ jquery _ visualize _ accessible _ charts _ with _ html 5 _ from _ designing _ with/。

人类福利

图 9.5。亨伯兰斯复杂的帆布动力图表。

humble fence(www.humblesoftware.com/金融/指数)是一个 HTML5 驱动的谷歌金融风格的图表演示。因为 Canvas 只是另一个 HTML 元素，所以您可以很容易地在它上面放置其他的<div>(或任何其他 DOM 对象), HumbleFinance 在这里已经为图表标签和其他文本做了这样的工作。

佩蒂

图 9.6。小例子。

peity(【http://benpickles.github.com/】peity/)是一个 jQuery 插件，它可以将元素内容转换成迷你饼图、条形图或折线图。它获取像<span class="line">5,3,9,6,5,9,7,3,5,2</span>这样的元素中的值，并将其转换为呈现适当图表的<canvas>元素。jQuery 迷你图(【http://omnipotent.net/】jquery.sparkline/)采用了类似的基于画布的方法，并且有更多的选项。

形象化

Processing.js

图 9.7。Processing.js 示例 Fizz。

一些最好的画布例子使用 Processing . js(processingjs.org/)，这是处理可视化编程语言的 JavaScript 端口。例子从简单的游戏到抽象的数字艺术，再到可视化。

“隐私在脸书的演变”

图 9.8。“脸书隐私的演变”可视化。

使用 Processing.js 的基于画布的可视化的一个最实际的例子是交互式“脸书隐私的演变”可视化(mattmckeon.com/ Facebook-Privacy/)。因为它是在 Canvas 中实现的，所以它可以在 iOS 设备上工作，但我们仍然需要担心与(目前)更大的 IE6-8 组的兼容性。

画布、Twitter 和音频混搭

图 9.9。这个 mashup 引入了 HTML5 相关的 tweets，其中一些非常合适。

从实用到…嗯，漂亮。这个 HTML5 Canvas 实验使用 Processing.js 进行粒子渲染，使用<audio>元素播放音乐(但它不是音频可视化工具)。自己看:9elements.com/ io/projects/html 5/canvas/。这些粒子实际上是 100 条与 HTML5 相关的推文，它们的内容在文档中呈现为普通的 HTML。(看这里写的:9elements.com/ io/？p = 153。)

纸张. js

图 9.10。Paper.js 在动态中看起来很棒——一定要看看网站上的例子。

Processing.js 并不是唯一的游戏。paper . js(paperjs.org)自诩为“矢量图形脚本的瑞士军刀”，并展示了基于位图的画布元素如何用于高级矢量图形脚本，以及“矢量图形的文档对象模型”和键盘鼠标交互。更多请看他们的例子:【http://paperjs.org/例子】/。

(Smashing Magazine 还发布了 Processing.js、Paper.js 和基于 SVG 的 raphal:coding.smashingmagazine.com/ 2012/02/22/we B- drawing-throw down-paper-processing-Raphael/。)

比赛

各种各样的(大多是复古的)游戏都是用 Canvas 构建的。我们将在这里看一看少数几个，然后看看下面一些令人惊叹的基于 WebGL 的游戏。

生物实验室灾难

图 9.11。生物实验室灾难是一个有趣的小平台。

Dominic Szablewski 的 biolab Disaster(playbiolab.com)是使用<canvas>作为视觉效果的复古游戏的一个很好的例子。这是一个有趣的小平台游戏，在这里你可以奔跑、跳跃和射击。

帆布骑士

图 9.12。帆布骑士上瘾。

帆布骑士(canvasrider.com/)是另一个有趣(也很难)的例子！)可以用画布搭建的浏览器游戏。(警告:极易上瘾。)

割断绳子

图 9.13。《割断绳子》将基于画布的图形提升到了一个新的高度。

从小游戏实验到巨大的国际成功。格外受欢迎的手机游戏《砍断绳子》从最初的 iOS 代码移植到 HTML5，并于 2012 年初发布。该项目由微软赞助，旨在展示 IE9 的 HTML5 功能，包括其硬件加速的 Canvas 实现。你现在就可以在你的浏览器中播放:www.cuttherope.ie/。

该项目展示了游戏 web 标准的潜力:使用 Canvas 等工具进行开发，然后在现代浏览器中轻松实现您的游戏，并将其捆绑为原生 iOS、Android、Windows Phone 和/或 Metro 应用程序——基本上，只要 HTML5 得到良好支持。在这一章的后面，我们将更仔细地看看游戏和画布。

想象操纵

画笔

图 9.14。画笔可以完成一些令人印象深刻的类似 Photoshop 的效果。

使用 Canvas，我们可以进行一些令人印象深刻的图像操作，正如戴夫·谢伊的 PaintbrushJS 库巧妙地展示的那样(mezzoblue.github.com/·paint brush js/demo/)。PaintbrushJS 允许我们应用高斯模糊，添加噪声，渐变为灰度(或棕褐色)等等。这都是在客户端用 Canvas 和 JavaScript 完成的。

Mozilla 图像编辑器

图 9.15。Mozilla 的图像编辑器和上传器结合了许多 HTML5 技术。

Mozilla 将一系列 HTML5 功能整合在一起，创建了一个 HTML5 图像编辑器和上传器(hacks.mozilla.org/ 2010/02/an-html 5-offline-image-editor-and-uploader-application/)。画布用于图像处理。我期待着这种功能能够融入到我们的内容管理系统中。

画布驱动的 Web 应用程序

墙！墙

图 9.16。Muro 是一个强大的绘图程序，就在你的浏览器中。

一些真正的、真正的网络应用程序使用 Canvas，它显示了浏览器中现在可能发生的事情。它们大多与绘画或绘图相关(毕竟这是画布)，没有什么比 deviantART 的 Muro 更好地说明了这一点——一个免费的 HTML5 驱动的绘图/绘画应用程序。试试这里:muro.deviantart.com/或阅读更多这里:news.deviantart.com/文章/ 125373/ 。

画板

图 9.17。Sketchpad 展示了画布驱动的绘画程序的可能性。

画板是另一个很棒的 HTML5 绘画应用，你可以在这里玩:mugtug.com/画板/ 。

无尽的壁画

图 9.18。无尽的壁画网站让你创作上述艺术品的变体。

无尽的壁画(www.endlessmural.com/)是“一个互动的、合作的艺术网站”，由 Canvas 提供支持，并由微软赞助他们的 IE9 发布。该项目是自动机工作室和约书亚·戴维斯工作室(约书亚·戴维斯是早期的 Flash 和数字艺术先驱)的作品。代码已经以 Okapi 的形式发布，这是一个“在 HTML5 中构建数字生成艺术的开源框架”，可以在这里获得:【http://okapi.visitmix.com/】??。

卢奇德哈特

图 9.19。LucidChart 让你只需点击几下鼠标就能进入主题，所以试试吧。

虽然不全是艺术绘画。一些成熟的制图(付费)网络应用也使用 Canvas，比如 LucidChart，你可以在这里测试一下:www.lucidchart.com/。

绘图界面元素

Flash 风格的界面效果

图 9.20。“拉力赛互动”展示了多块画布巧妙运用可以产生令人印象深刻的效果。

Rally Interactive 制作了一个非常令人印象深刻的三角形到圆形的动画效果来展示他们的工作，截图和统计数据来自 Dribbble。我最初以为它是一堆花哨的 CSS3(这本身就很酷)，但实际上它们使用的是 Canvas。查看它的运行:beta . rallyinteractive.com/(并查看源代码以了解他们是如何做到的)。

背景动画

图 9.21。谷歌音乐网站上由画布绘制的背景元素会在你浏览网站时带你踏上一段旅程。

Google Music 的旅游页面使用画布来渲染背景动画，当你从一个部分移动到另一个部分时，背景动画上有粗粗的彩色线条在涂鸦。看它在行动:music.google.com/约/游/ 。

液体画布的界面背景

图 9.22。这些例子可能并不漂亮，但液体画布展示了一些有趣的可能性。

给我们网页设计师一个建议:用画布来绘制界面元素的背景怎么样？我们可以将<canvas>元素放置在标记中我们喜欢的任何位置，甚至可以适当地将它们层叠(使用 position 和 z-index ),然后用少量的 JavaScript 渲染所有的图形——不需要图像。

这种方法可以大大加快开发速度。不再需要从 Photoshop 中导出挑剔的图像来为客户调整配色方案。只需更改一些 JavaScript 变量，我们就完成了。有了 ExplorerCanvas for IE，我们甚至可能拥有比当前 CSS3 更好的浏览器兼容性。另外，硬件加速只是让 Canvas 在手机和桌面上运行得更快。

最好的(也许是唯一的)例子是 2008 年的 Liquid Canvas JavaScript 库。(你可以在这里读到:www.ruzee.com/内容/液体画布，在这里看到它的行动:【http://www.ruzee.com/档案/液体画布/demo.html。)演示并不是最漂亮的，但可能性肯定是耐人寻味的。例如，使用液体画布，您可以使用画布在 div 后面绘制带有阴影、圆角、渐变和斯托克斯的背景。(这里有一个教程:【http://www.caffeinedi.com/】2009/11/02/using-jquery-and-liquid canvas-to-add-drop-shadows-borders-rounded-corners-and-other-effects-to-your-website-even-in-ie6-and-ie7/。)

如果再多一点对设计的热爱，这可能是 A/B 测试布局的某些美学处理的好方法，全部只使用 JavaScript 同样，不需要在 CSS 中导出和维护图像。当然，这种方法总会有局限性，而表示显然应该是 CSS 的长期目标。(实际上，大多数人会坚持使用 CSS3。)但是 Liquid Canvas 无疑给了我们一种非常新颖的绘制界面元素的方法。

在一些(非 IE)情况下，我们也不一定需要使用液体画布。从 2008 年开始就可以在 WebKit 中使用 Canvas 元素作为 CSS 背景了(！)如这里所述:www.webkit.org/博客/ 176/ css-canvas-drawing/ 。火狐 4 在 2011 年增加了类似的支持(【http://hacks.mozilla.org/】2010/08/mozelement/)，其他浏览器也有变通办法(针对静态画布’)，如这里的回答所述:stackoverflow.com/问题/3397334/use-Canvas-as-a-CSS-background。随着硬件加速的到来和使用 Canvas 作为 CSS 背景的能力，我们有了一些快速的、以编程方式生成的界面元素的有趣选项。

考虑一下响应式网页设计的可能性——我们可以根据设备的分辨率以编程方式重绘 CSS 背景(至少在 iOS 中)。无需下载桌面大小的图像并缩小；或者为不同的设备维护不同的艺术作品集；就让一个剧本来为我们做这些繁重的工作吧。(如果您创建了这样的脚本，请告诉我！)

虽然我们有一些想法，但我很想看到像 Photoshop 风格的 CSS3 效果图层面板这样的东西(这本身就很酷——见:layerstyles.org/·builder.html)为画布而建。它可以生成液体画布风格的 JavaScript，然后您可以将它放入您的页面，并在几乎所有浏览器上呈现效果。见鬼，如果 Photoshop 本身能导出到 Canvas 就太酷了。

Canvas 可能不是 Flash 的替代品，但这些例子表明它确实打开了一些有趣的大门。

IE6-8 的有时好有时坏的画布仿真

图 9.23。这个万花筒 FlashCanvas 示例演示了令人印象深刻的画布效果甚至在 IE7 中也是可能的；他们只是太慢了。

虽然 IE6-8 不支持 Canvas，但并没有失去一切。几个仿真选项可以给这些浏览器至少一些支持使用 IE 的本地、传统矢量标记语言(VML)、微软的 Silverlight 插件或 Flash。

每种方法都有其优点和缺点。VML 很慢，会将元素加载到 DOM 中。(Canvas 元素被重新创建为 vector 元素，所以加载的越多，速度越慢。)但是动画流畅，画布整体上还是停留在 DOM 里。

Flash 和 Silverlight 都更快。但是(在撰写本文时)只有大约 40%的人安装了 Silverlight，而且 Flash 和 Silverlight 都不能在 DOM 中操作。

(这里有一个更详细的比较:uupaa-js-spinoff.googlecode.com/ SVN/trunk/uuCanvas.js/ README.htm，虽然它主要是日语，所以你需要让谷歌翻译做它的事情。)

再加上交互性问题、对 Canvas API 特性的混合支持，以及处理器密集型应用程序的性能问题，你就有了一个大杂烩。您仍然可以渲染一些令人印象深刻的动画效果(尽管很慢)，或者渲染静态图像并在 DOM 中提供它们(这对于图表等非常有用)。但是，如果性能达不到要求，或者某个关键特性得不到支持，这可能就是“差之毫厘，失之千里”的情况。

这是做模拟的工具。查看他们在 IE 6、7 或 8 中的演示，感受一下他们的表现(例如，在 IE 中尝试这些:code.google.com/ p/flash canvas/wiki/Examples)。在某些情况下(如静态画布渲染)，您可能永远不知道它正在被模拟，而在其他情况下，您可能会得到可以接受但并不完美的模拟。请记住，画布仿真可能是一个非常模糊的领域——它很少是一张免费的完美 IE6-8 支持卡。

画布仿真实用程序:

• ExplorerCanvas(又名 ExCanvas)是最著名的。它使用 VML，还有一个不受支持的 Silverlight 选项。请前往:excanvas.sourceforge.net/查看。
• FlashCanvas 是一个正在积极开发中的基于 Flash 的 Canvas 实现(见code.google.com/ p/Flash Canvas/和flashcanvas.net/)。)也有 Pro 版本。
• fxCanvas 是另一个基于 Flash 的 IE Canvas 实现(尽管不太成熟)，也在积极开发中:code.google.com/ p/fxcan vas/
• 最后(也是最有趣的)是日本的 uuCanvas，它声称提供 VML、Silverlight 或 Flash 渲染。在这里阅读:uupaa-js-spinoff.googlecode.com/ SVN/trunk/uuCanvas.js/README.htm。(还是那句话，谷歌翻译会有帮助。)

Web 标准的杂乱世界，或者说，我们是如何以 Canvas 告终的？

让我们接触一下画布的历史，因为它说明了这些功能是如何随意发展的。(HTML5 的大部分内容也是如此，它在某种程度上只是一个已经存在多年的技术大杂烩。)

“HTML5”只是一个流行词，代表了 7 年来的好东西。
—戴夫·巴尔默，www.slideshare.net/·巴尔默/摇滚之星-图片-与-html 5-媒体-英国

你使用 OSX 的仪表板功能吗？早在 2004 年，画布就起源于此。苹果希望 Dashboard 小部件易于编写，所以他们基于 HTML、CSS 和 JavaScript(如果你愿意，也可以是本机代码)的良好 ol’ web 堆栈，并使用 WebKit 来呈现它们。(WebKit 是 Safari 和谷歌 Chrome 背后的渲染引擎。)

但苹果认为用于呈现仪表盘小部件的 web 堆栈有局限性，所以他们给 WebKit 添加了一些功能，主要是 Canvas。Safari 使用 WebKit，所以 Safari 现在支持 Canvas。瞧，画布在网络上诞生了。

这在传统的新网络技术中引起了相当大的关注。

供应商在没有任何标准流程的情况下将浏览器特有的特性添加到 HTML 中，这正是 web 标准运动试图让远离的地方。如果微软和 Mozilla 在 Canvas 之类的东西上做出不兼容的尝试，我们将会陷入一片混乱。

因此，伊恩·希克森对苹果的 Canvas 实现进行了逆向工程，并将其放入 WHATWG 网络应用 1.0 规范中。Canvas 在 2005 年的 Firefox 1.5、2006 年的 Opera 9 以及 2011 年的 IE9 中获得了支持。正如我们在第一章中看到的，WHATWG Web Apps 1.0 规范变成了 HTML5，Canvas 现在是 HTML5 的官方部分。向希克森致敬，感谢他把它带入了规范。

(更多关于画布的历史，请参见peter.sh/ 2010/06/thank-you-Microsoft-html 5-Canvas-is-a-go/。)

画布元素和可访问性

就可访问性而言，Canvas 可能有点像噩梦。对于屏幕阅读器来说没有什么可读的——只有一个黑洞和设计者放在<canvas>标签之间的任何文本(如果有的话)。

供应商正在努力解决这个问题。例如，IE9 向辅助技术公开了<canvas>标签之间的回退内容。这里的想法是，当浏览器支持canvas，但视力受损的用户看不到它时，他们仍然可以通过他们的屏幕阅读器以替代文本的形式获得一些有用的东西。(嗯，理论上是这样。目前，他们会得到很多错误的“你的浏览器不支持画布”的消息，因为这就是迄今为止回退内容的使用方式。)要了解更多信息，请参见易访问性大师 Steve Faulkner 对此功能的讨论:www.paciellogroup.com/博客/2010/09/html 5-canvas-accessibility-in-internet-explorer-9/。

至于 Canvas 元素本身的可访问性，这是一个已经讨论了年的棘手问题，至今仍未解决。这里有一个过去几年讨论的总结:【http://www.paciellogroup.com/博客/2011/12/html 5-canvas-accessibility-discussions-2009-2011/但是我们已经到此为止了。

让我们不要用<canvas>重复过去几十年的可访问性错误。理论上，我们可以渲染漂亮的文本，或者整个网页，或者网络应用程序(已经完成了！)，JavaScript 在一个<canvas>区域。但是这是一个可怕的想法，并且和把我们的设计作为一个巨大的图像一样有用(从可访问性的角度来看)。

(你可以在画布上做一些疯狂的事情，正如本教程所示:www.html5rocks.com/教程/画布/ texteffects/ 。因此，我们仍然可以使用这种技术进行文本替换。)

画布的当前状态

技术(网络或其他)并不存在于真空中。他们的成功往往取决于他们周围有一个有利的环境。人们对画布当然有很大的热情，但是它周围的环境(??)怎么样呢？

原始开发环境

值得记住的是，Canvas 周围的环境仍然相当原始，因此几乎没有开发工具。(Flash 之所以成功，不仅仅是因为 Flash 播放器无处不在，还因为开发人员可以使用成熟的工具。)

情况正在发生变化。HTML5 游戏引擎(例如用于 Biolab 灾难的impactjs.com/)通常对 Canvas 有一些支持，但它们非常面向小众和开发者；这不是我们一般网页设计所需要的。

在设计师的工具方面，有一个来自微软麦克·斯旺逊的 Adobe Illustrator to Canvas 插件(visitmix.com/实验室/ ai2canvas/ )。正如我们前面所看到的，Adobe 自己也在致力于 Flash 到 Canvas 的导出。(他们也一直在试验更通用的“HTML5”导出，但他们相当宽松地使用术语“HTML5”。当我们在第十一章讨论 SVG 时，我们会更多地关注 Adobe 的立场。)

表演

Canvas 令人兴奋的一点是，你可以在任何东西上查看它，从 Flash 不是一个选项)到桌面。在简单、静态的情况下，如图形和图表，这是一个现实。但是对于任何处理器密集型的东西(比如动画和游戏)，最新的移动设备除了最简单的任务之外，还没有强大到足以做任何事情。

不过这种情况正在改变，特别是随着移动设备变得更快，Canvas 获得了硬件加速(正如微软承诺并为 IE9 mobile 演示的:www.gsmarena.com/ internet _ explorer _ 9 _ on _ wp7 _ aces _ html 5 _ drawing _ test-news-2524 . PHP)。苹果的 iOS5 也极大地提高了画布的性能，正如格兰特·斯金纳在 2011 年 10 月所记录的那样(plus.google.com/ 111971493588974288901/posts/ARX 5k 8 lmn Bt——我已经把 iPad 2 的结果一个挨着一个移动到了下面):

简单比较 HTML5 canvas 在移动设备上的性能，以恒定的每秒 20 帧(即通过 drawImage 从 sprite 工作表图像获得 80x80 帧):

RIM Playbook: 24
Desire Z(安卓):60
Galaxy Tab 10.1(安卓):200
IP ad2 w/IOs 4:40
IP ad2 w/IOs 5:1750

Sencha 还报告了大幅提升的画布 iOS5 速度:www.sencha.com/博客/苹果 IOs-5-html 5-开发者记分卡/ 。(顺便说一下，Sencha 的 HTML5 博客帖子在保持功能支持方面非常出色。)

硬件加速带来了巨大的变化。但目前，任何画布密集型的东西都可能很快在你并不先进的手机或平板电脑上变成一场相对的狂欢(正如上面的 iOS4 和 Android 设备结果所示)。

有限的 IE 兼容性

正如我们所见，IE6-8 可以不同程度和不同方式支持 Canvas(VML、Flash、Silverlight)。如果你开始使用画布，这可能是一个天赐良机。但与 Flash 相比，它可能是一个令人头痛的问题，并限制 Canvas 的吸收，直到 IE9 成为设计和开发的新基线。(请记住，IE8 是 Windows XP 用户的底线，所以我们需要等到 Windows XP 最终消失后才能假设原生 Canvas 支持。)

与移动设备一样，虽然简单或静态的 Canvas 实现对于仿真来说可能是完全可以接受的，但复杂的动画和游戏可能是不可能的。当 Flash 风格的交互性是必要的时候，这就产生了一种奇怪的情况——我们可以通过基于 Flash 的体验来支持 IE8 和更低版本，但不能在 Metro IE10 或移动设备上工作，或者为 Metro IE10 和其他不能在 IE8 和更低版本上工作的现代浏览器创建一些东西。一些糟糕的设计人员和开发人员可能会两者兼而有之，具有讽刺意味的是，他们可能会为传统的桌面浏览器创建更高级的 Flash 体验，而为现代浏览器创建更简单的基于画布的版本。为 IE8 的迅速消亡和新网络标准的快速发展、采用和成熟干杯。

又是玻璃的比喻

这是 HTML5 的另一个玻璃杯半满，玻璃杯半空的情况。人们正在用 2004 年的 OSX 仪表板功能做着令人惊讶的事情——从漂亮的设计功能(如工具提示)和互动实验到游戏和成熟的网络应用。Canvas 的设计并没有考虑到这些事情；事实证明，在这种情况下，它非常有用。这是玻璃半满透视。但是，如果您正在等待一个成熟的、一次编写、可在桌面上任何地方运行的环境，如 Flash，它可能看起来像是半空的玻璃杯。我们还要等很长时间。

HTML5 游戏:画布还是不是？

在讨论 HTML5 和游戏时，Canvas 经常被提到，所以让我们简单看看 HTML5 游戏的状态。你能利用现有的网络技能，用 HTML 和 JavaScript 编写能在任何现代浏览器上运行的游戏吗？当然，如果你习惯用 JavaScript 开发的话。这个游戏会有什么好处吗？嗯，那要看情况…

近年来最大的趋势之一是休闲游戏，无论是在浏览器还是在 iPhone 等移动设备上。脸书的社交游戏创造了数十亿美元的公司。(FarmVille 和 CityVille 的开发商 Zynga 的估值高达 100 亿美元:www.develop-online.net/新闻/37066/New-speculation-values-Zynga-at-100 亿美元)。随着 Rovio 及其《愤怒的小鸟》系列的崛起，休闲手机游戏也大受欢迎。

因此，从务实的商业角度和理想主义的“开放平台”角度来看，一个用于创建休闲社交游戏的开放的跨设备平台非常有吸引力，HTML5 非常符合这一要求。举例来说，脸书无疑正在其开发者社区中大力推动这项工作。

关键是要理解我们在这里谈论的是什么类型的“游戏”。从图形上看，这些通常是简单的 2D 游戏，类似于 90 年代早期的游戏。从这个意义上来说，这很像“回到未来”——我们在非常现代的移动社交网络世界中，使用最新的网络技术来创建 20 年前的风格游戏。

这是帆布吗？

尽管 HTML5 大肆宣传，但出于性能原因，其中一些 HTML 游戏和游戏引擎已经明确避免了 Canvas 等功能，而是依赖 DOM 脚本和 CSS3(在 iOS 设备上部分硬件加速)来完成工作。以下是一组开发人员从一个快速的技术演示中发现的东西，该演示采用了 HTML 游戏引擎方法(【http://sebleedelisle.com/】2011/04/HTML 5 JavaScript-platform-game-optimized-for-ipad/):

那么在 iOS 上获得性能的答案是什么呢？忘记 HTML5 canvas 吧，这个游戏中所有移动的对象都是 HTML div 元素，我们只是通过用 JavaScript 控制 CSS 属性来移动它们。

当讨论“HTML5”时，我们需要仔细看看人们实际使用的技术和技巧。你认为是画布的东西很可能不是。随着性能的提高(硬件加速成为常态)，Canvas 可能会在基于网络的游戏中得到更广泛的应用，但值得记住的是，“HTML5”这个术语是如何被随意使用的。

不要误会我的意思:演示和端口已经向我们展示了 HTML5 游戏现在在桌面上的可能性，以及在不太遥远的将来在移动浏览器上的可能性。请记住，浏览器中的休闲游戏现象与最新技术关系不大，而与社交网络等大创意关系更大，传统网络堆栈可以用非常有趣的方式利用社交网络。也就是说，由于 WebGL，硬件加速的 3D 游戏也通过 Canvas 进入浏览器，我们很快就会看到这一点。

画布游戏开发入门

尽管如此，如果你想亲自动手使用 Canvas 进行游戏，可以看看这个教程和概述(忽略文章中的宣传):www.html5rocks.com/教程/案例研究/onslaught.html或者这个绝对初学者教程:www.lostdecadegames.com/ how-to-make-a-simple-html 5-Canvas-game/。别忘了我们之前看过的游戏例子，包括《割断绳子》(【http://www.cuttherope.ie/】)这可能是迄今为止最相关的纯 HTML5 端口。

对于“HTML5”游戏可用的所有不同技术的详细介绍(广义上)，以及它们的交付和货币化选项，请查看 2012 年 1 月的这篇优秀文章:“HTML5 游戏开发的现实和从中赚钱”(www.photonstorm.com/档案馆/2759/The-Reality-of-html 5-Game-Development-and-making-money-from-it)。

HTML 游戏:超越 HTML5

也有很多开发人员对超越 HTML5 的 web 平台感兴趣，包括像操纵杆 API、环绕声支持和 CSS 扩展之类的东西。请参阅 W3C 的详细报道:“关于 HTML.next for Games 研讨会的报告”(www.w3.org/ 2011/09/Games/)。我们将在第十二章谈到后 HTML5 网络平台。

画布:我有什么好处？

网页设计师的画布

画布对你有多重要取决于你在哪里工作和你做的项目。如果你在一家大预算机构工作，脸书组件对于大规模的全国或全球营销活动是强制性的，你可能会发现新的游戏功能非常有趣。

如果你是一名自由职业者，在预算紧张的情况下做客户工作，我们看到的现成图表工具可能不那么吸引人，但仍然非常有用。面向 IE6-8 的 Canvas emulation 作为一个跨设备解决方案(相对于基于 Flash 的工具)可能会非常方便，它涵盖了 IE6+ 和 iOS 设备。

用于内容管理系统的基于画布的图像编辑工具也可能开始涌现，如果你喜欢修补，有巨大的实验空间。您可能想尝试用 Canvas 呈现界面元素(正如 Liquid Canvas 和 Tipped libraries 演示的那样)，或者看看像 Rally Interactive 这样的工作室演示的那样，您可以将 Canvas 推进多远。

学生和业余爱好者的画布

一个免费、开放、相对简单的平台，比如 HTML、JavaScript 和 CSS，可以为那些想尝试简单游戏设计的孩子创造一个肥沃的环境。随着教程和开发库遍地开花，他们有足够的信息开始制作简单(也不那么简单)的游戏。在学校里看到这种情况会很棒，而且不需要太多资源——只需要一台不太像样的个人电脑(或者 35 美元的树莓派:www.raspberrypi.org/)和一个现代风格的浏览器。

Flash 设计师的画布

Canvas，以及其他非 HTML5 但很酷的特性，如 jQuery、CSS3 和 SVG，可能会吸引更多的 Flash 设计师去探索 HTML 和 web 标准。Flash 设计者拥有 Flash 成熟的 IDE、先进的特性和广泛的支持。(我相信当缓慢的 HTML5 横幅广告也开始出现时，他们会笑的。)只要记住微软的举动，Flash 的写作就在墙上。

在任何情况下，HTML 中的交付越多(即使动画是在 Flash 中创建的)，就越好。我们需要 Flash 设计师的创造力来尽可能地推动 HTML5 和新 web 技术的界限。希望 Adobe 能做更多来实现他们的出口到画布的承诺和其他“HTML5”创作工具。

试试看

我们有很大的空间以微妙(或不那么微妙)的方式将<canvas>元素编织到我们的网页中。但是 Canvas 是否会成为一个主要的网页设计工具，或者仅仅是我们这个时代的 Java 小程序，取决于我们自己。让我们试一试，看看我们能想出什么。

2D Canvas’ 3D Future: WebGL

我把最好的留到了最后——与 Canvas 相关的最激动人心的发展之一是 WebGL(基于 Web 的图形库)。尽管 Canvas 表面上源于 2D，但新的 WebGL 标准为 Canvas 提供了一个由 OpenGL 支持的硬件加速的 3D 环境——如果浏览器(和底层硬件)支持的话。这为您的浏览器开启了现代 3D 游戏之门。

(WebGL 规范不是由 W3C 或 WHATWG 开发的，而是由非盈利技术联盟 Khronos Group 开发的，该联盟从 Mozilla 发展而来。所以它本身不是 HTML5，但它仍然很酷。)

WebGL 工作组包括苹果、谷歌、Mozilla 和 Opera。(详见维基百科条目:en.wikipedia.org/维基/ WebGL 。)注意到名单上少了谁吗？是的，微软。当其他主要的浏览器供应商正在推进实际的或实验性的支持时，安全问题让微软非常胆怯。例如，2011 年 6 月，微软的安全研究博客发布了一篇名为“WebGL 被认为是有害的”的文章，文章称:

我们相信 WebGL 将很可能成为一个难以修复的漏洞的持续来源。从目前的形式来看，WebGL 不是微软从安全角度认可的技术。

翻译:不要对 IE 中的 WebGL 抱太大希望。

这也不仅仅是微软对竞争技术过于谨慎或怀有敌意。在(twitter.com/ #)发表博文后不久，约翰·卡马克(id Software 创始人，备受尊敬的游戏开发者)发了一条微博/ID _ AA _ Carmack/status/81732190949486592):

我同意微软的评估，WebGL 是一个严重的安全风险。gfx 驱动程序文化不是安全文化。

担心安全问题的不仅仅是微软。出于类似的原因，苹果尚未在 iOS 设备的浏览器中启用 WebGL(如果黑客新闻的这些评论是准确的话:news.ycombinator.com/ item？id = 3252777)。然而，苹果正在 IOS 5 中为 iAds 启用 WebGL，因此基于 WebGL 的营销可能迟早会成为现实(无论是好是坏)。

网络上的 3D:Web GL 替代方案

WebGL 也不是镇上唯一的游戏。

Flash 11 于 2011 年 10 月推出，最近以其“Stage 3D”技术(以前称为“Molehill”)为浏览器带来了硬件加速的 3D。你可以在这里看到演示:www.adobe.com/发展网/flash player/stage3d.html。Epic 已经将他们的虚幻引擎 3 移植到 Flash 11，所以游戏潜力肯定是存在的:【http://www.anandtech.com/秀/4933/Flash-11-supports-虚幻引擎-3。

微软 2011 年 12 月发布的 Silverlight 5 也引入了硬件加速 3D，但鉴于微软对 Metro IE 10 的无插件计划，Silverlight 在浏览器中似乎不太可能有未来，可能会成为 Metro 应用的开发环境。

有趣的是，Unity Technologies 开发了流行的跨平台(非常适合移动设备)3D 引擎 Unity，该公司一直在分发自己的浏览器插件，他们声称该插件的下载量已达 6000 万次。他们还推出了导出到 Flash 的选项，这样用户就不需要下载 Unity 浏览器插件了。

因此，无论如何，我们将在未来几年内看到更多的 3D 内容，特别是游戏内容，这些内容可能仍然足以吸引使用 Metro 界面的 Windows 8 用户切换到桌面模式来运行 Flash。我们正处于 2D 基于浏览器的游戏爆炸时期(CityVille 在 2011 年每月活跃玩家达到 1 亿)，基于浏览器的 3D 游戏热潮即将到来。

WebGL 也有老派前辈。在网络上显示 3D 并不新鲜——例如 VRML(“虚拟现实建模语言”)可以追溯到 1994 年(见:en.wikipedia.org/维基/ VRML )。但是，随着硬件加速的 3D 现在几乎可以在任何平台(包括智能手机)上使用，3D 在网络游戏和其他领域(例如，3D 模型产品预览、医学模型、地图等)的潜力无限增大。

谁知道呢？也许我们最终会拥有我们一直渴望的 3D“虚拟”购物中心体验的技术…

给我看看演示！

说到 WebGL，眼见为实。所以，启动最新版本的 Firefox、Chrome 或 Opera，看看这些很酷的演示吧。记住:这一切都发生在<canvas>中——只是 DOM 中的另一个元素(我们可以用 CSS3 来推动它)。

愤怒的小鸟

图 9.24。多亏了 WebGL,《愤怒的小鸟》风靡网络。

是的，浏览器中的愤怒的小鸟(chrome.angrybirds.com)。WebGL 还提供硬件加速的 2D 图形。(花点时间考虑一下 2D、WebGL 驱动的网站界面的含义，而不仅仅是游戏。)亲自尝试一下网上的《愤怒的小鸟》，网址:【http://chrome.angrybirds.com。有趣的是，当 WebGL 不可用时，这就退回到 DOM 动画(包括四处移动 2D 画布元素)，所以你可以比较性能以及像愤怒的小鸟这样的 2D 游戏从硬件加速中受益多少。(由于浏览器中游戏的音频状态不佳，你仍然需要 Flash 来播放声音。)

罗马“三个黑色的梦”互动音乐视频

图 9.25。罗马的经历是绝对不容错过的。

这个为 Danger Mouse 的罗马项目制作的令人难以置信的音乐视频是一个很好的例子，展示了 WebGL 的交互性。在 Chrome 中查看它: www.ro.me ，尽管它应该在最新的 Firefox 版本中也可以看到。这是一种令人惊叹的体验，甚至还有用户提交的沙漠中的 3D 模型。

你可以在这里观看这部电影背后团队的视频(尽管“电影”并没有公正地对待它)，以及体验的剪辑:www.youtube.com/手表？v=ReH7zzj5GPc 。

看到未来设计师、艺术家和工程师用这种技术能做出什么将是令人兴奋的。(我只希望它不会变成太多的营销工具。想象一下，在一个主流新闻网站上阅读新闻，突然一个巨大的画布元素被覆盖，你被推入一个 3D“品牌体验”。)

glfx.js 图像处理

图 9.26。glfx.js 中的倾斜移动效果是许多 Photoshop 风格的效果之一。

早些时候，我们看到了 Canvas 如何在 2D 处理图像，但 WebGL 由于其硬件加速而释放出更大的能量:evanw.github.com/·glfx.js/。WebGL 支持的 glfx.js 图像效果库允许我们应用硬件加速的、类似 Photoshop 的滤镜，如亮度/对比度、曲线、去噪、色调/饱和度、反锐化掩模、镜头模糊、倾斜偏移、三角形模糊、缩放模糊、彩色半色调、透视变换、漩涡等等。查看演示以了解它的运行情况:【http://evanw.github.com/·glfx.js/·演示/

地震二

图 9.27。在浏览器中运行的雷神之锤 II 只使用了网络技术。

Quake II 也被移植到了 WebGL 上，使用“WebGL、Canvas API、HTML 5 <audio>元素、本地存储 API 和 WebSockets 来展示纯 web 应用在 Safari 和 Chrome 等现代浏览器中的可能性”。更多见:code.google.com/ p/quake 2-gwt-port/。(你需要下载并编译代码来实际播放它，但这里有一个它在运行的视频:www.youtube.com/手表？v=fyfu4OwjUEI 。WebGL 里还有一个雷神之锤 3 的试玩关卡在这里:media.tojicode.com/ q3bsp/。)

在一条推特的回复中说:

不确定 2010 年 JS 引擎速度的最佳代言是否是 1997 年的游戏端口…

乔尔·韦伯是港口的工程师之一，他写道(blog.j15r.com/ 2010/04/quake-ii-in-html5-what-does-this-really.html):

有什么意义？这段代码目前证明了在 WebGL 上构建一个“真正的”游戏是可行的，包括复杂的游戏逻辑、碰撞检测等等。它还出色地暴露了当前规范和实现中的弱点，我们可以并将使用这些信息来改进它们。[…]

人们可以想象这样一个世界，游戏开发者可以像我们现在部署网页一样轻松地部署他们的游戏，用户也可以轻松地玩游戏。这是一个非常吸引人的想象世界。

发个链接。玩游戏。这就是 WebGL(和其他新兴的 3D 技术)将实现的。或者说，其实就是使能。

GT 赛车:汽车学院

图 9.28。在 Google+上的浏览器中玩 GT 赛车直播。

2011 年 12 月，Gameloft 在 Google+(plus.google.com/ u/0/games/777131296458)上推出了他们的游戏 GT Racing: Motor Academy 的 WebGL 版本，该版本可以在 Chrome 和 Firefox 上运行。这不仅是对浏览器游戏技术未来的有趣观察，也是对社交网络分销的有趣观察。(Gameloft 的 Baudouin Corman 在这里与 Gamasutra 讨论了这些问题:www.gamasutra.com/ view/news/39273/Gameloft _ enchances _ html 5 _ With _ 3D _ Game _ GT _ racing . PHP。)

滑行赛车

图 9.29。这款类似游戏机的赛车可能代表了现代 3D 网络游戏的第一步。

GT 赛车也不是唯一一款基于 WebGL 的赛车游戏。Skid Racer 是一款基于 WebGL 的原创“卡丁车”,可以在 Chrome 网上商店(chrome.google.com/网上商店/detail/bhoaojooagiaaiidlnfhkkafjpbbnnno)买到。(讽刺的是，一个基于网络的，只有 Chrome 的游戏应该被注意到，但我们会给开发者一个好处，把它归结为发行问题。)

更多 WebGL 演示

以下是更多的 WebGL 演示和示例:

• Mozilla 的航海家之旅演示(videos-cdn.mozilla.net/服务器/ mozhacks/航海家之旅/ )是一个有趣的新网络技术混搭。它主要是一个带有 HTML5 音频的 WebGL fly through，但带有实时 Flickr 和 Twitter 集成。一些效果(广告牌上的交错、自动收报机显示、音频可视化)是用 Processing.js 和 2D 画布(我们之前看过)完成的，然后用来纹理化 3D WebGL 对象。太疯狂了。(点击这里了解更多:【http://vocamus.net/·戴夫/？p = 1233。)
• Google MapsGL 是他们无处不在的地图服务的 WebGL 版本，其中 WebGL 用于增强体验。阅读更多相关内容，并在这里观看演示:【http://support.google.com/maps/·宾/answer . py？HL = en&answer = 1630790。
• CycleBlob 是一款有趣的 3D 表面灯光循环游戏:【http://cycleblob.com/】??
• 坦克世界是一个很棒的小坦克射手:【http://www.playtankworld.com】??
• Süperfad 的 Mission Control ，他们的“全球交通可视化工具”，是他们的谷歌分析交通的美丽的 3D 可视化。在这里看直播:【http://superfad.com/ mission control/在这里看:superfad.com/博客/帖子/ mission_control 。
• 更多的 WebGL 演示请看这些实验:www.chromeexperiments.com/ webgl或者这个传统画布以及 web GL 游戏的列表:www.netmagazine.com/特色/ top-20-html5-games 。

WebGL 仍处于早期阶段

WebGL 游戏和演示展示了不可思议的前景，但目前 WebGL 开发并不完全是吃喝玩乐。《黑客新闻》的一名开发人员评论了硬件不兼容、软件错误和不一致的问题，这些问题会使小团队的开发环境变得困难，他说(news.ycombinator.com/ item？id = 3253016):

我们在不同的硬件和不同的浏览器上发现了如此多的不一致，以至于暂时不值得去做一个 WebGL 项目，尤其是对于一个小团队来说。我们写了一些运行时检查，但是我们仍然不能解释所有的错误，或者找到解决每一个错误的方法。

然而，正如上面的演示所示，令人惊奇的事情是可能的。如果你对 WebGL 的原始性能细节感兴趣，请查看这篇内容丰富的帖子:“HTML5 游戏制作工具 Construct 2 的开发者 Scirra 的 HTML5 2D 游戏性能分析”(www.scirra.com/博客/58/html 5-2d-游戏性能分析)，其中总结道:

硬件加速的 2D 画布很快，但 WebGL 更快。它属于原生引擎领域，坦白地说，考虑到 Javascript 的设计效率是如此之低，这是令人惊讶的，也证明了浏览器开发者在为 Javascript 编写 JIT 编译器方面所做的令人惊讶的工作。

希望微软和苹果很快找到一种方法在他们的桌面和移动平台上启用 WebGL，因为 WebGL 在浏览器中广泛传播的硬件加速 3D 的可能性确实非常令人兴奋。

十、听不见<audio>，看不见<video>

<audio>和<video>都是 HTML 规范中受欢迎的新增内容。我们不使用专有工具(如 Flash)来显示图像，那么我们为什么需要它们来播放音频或视频呢？

不要误解我:我不是来抨击 Flash 的。没有它，我们就不会有 YouTube、Vimeo 和过去几年发生的视频革命。Flash 仍然提供高级视频功能(如直播、全屏播放和 DRM，尽管 DRM 很烦人)，这些功能要么没有开放标准的实现，要么只是非常初步的实现。

尽管如此，HTML5 <video>和<audio>几乎已经成为媒体交付的必备工具，原因只有一个:iOS。鉴于苹果决定不允许在其移动设备上使用 Flash，嵌入视频和音频以便 iPhone、iPad 和 iPod Touch 用户可以使用的唯一方法是使用这些新的 HTML5 元素。

但并不止于 iOS。正如我们在前一章中看到的，2011 年末，Adobe 宣布他们将完全放弃移动设备上的 Flash 插件，并将重点转移到原生应用和 HTML5 上。另外，微软 Windows 8 新的默认 Metro 界面中的 ie 浏览器不会支持任何插件。(关于 Flash 插件消亡的更多信息，请看上一章的讨论。)

我们正朝着后闪存的未来前进。不幸的是，我们的开放式技术还不能取代所有的闪存产品。Web standards 赢了，如果我们不小心的话，就会被抓个正着。这就让应用程序来填补空白，用特定于平台的软件把我们带回到 90 年代。

我们将很快回到我们的后闪光灯未来的问题。现在，让我们看看目前新的 HTML5 音频和视频元素。虽然这些元素的指定非常简单，但是规范之外的问题决定了它们的实现…有趣，退一步说。首先，我们来看一下基础。

原生和

在行动

那么我们如何使用这些新元素呢？理论上，这很简单。先说<audio>。

元素

对于音频，我们可以使用:

<audio controls autoplay loop muted preload="auto">     <source src="myaudio.ogg" type="audio/ogg">     <source src="myaudio.mp3" type="audio/mpeg">     <!-- Fallback content, such as a Flash player, here --> </audio>

这将给出一个类似 Chrome 的例子(注意，浏览器会随意渲染<audio>元素，播放器大小可能会有相当大的差异):

图 10.1。默认 Chrome 音频播放器。

好吧，我们来过一遍。首先，如果你愿意，你可以在开始的<audio>标签中添加src属性，而不是使用<source>元素。但是由于编解码器支持令人难以置信的恼人问题(我们将很快深入研究)，我们经常需要指定两个源文件来实现最大的 HTML5 兼容性。

这就是<source>元素的用途。浏览器遍历<source>元素列表，直到找到它们支持的文件格式，或者(如果我们已经包含了)得到一个后备选项——可能是文件的链接，或者(更常见的)一个 Flash 媒体播放器。(有关实现快速回退的教程，请参阅下面的参考资料。)

<audio>和<video>都是以向后兼容的方式实现的，因为旧的浏览器(如 IE8)会完全忽略<audio>和<source>元素(IE8 只是将这些元素视为通用标签，如<mymadeuptag>)。这意味着我们包含的任何后备内容对旧的浏览器都是可见的，但被现代浏览器忽略了。

我们也可以使用脚本来给支持<audio>(或<video>)元素但不支持我们使用的编解码器的浏览器一个 Flash 后援。在这一章的最后，我们将看看为我们做了大量工作的媒体播放器。

属性

回到<audio>元素。属性controls、autoplay、loop和muted是布尔属性——包含它们使它们成为true，不包含它们使它们成为false。(但鉴于autoplay和loop是魔鬼的工具，我们或许应该永远把它们排除在外。)属性使浏览器的播放器默认为静音(尽管对它的支持可能是不完整的)，属性告诉浏览器使用它的本地控件。(这些元素也可以通过 JavaScript API 来控制。)

还有一个preload属性是不是布尔值，而是可以是none、metadata(仅预加载文件的元数据)或auto，这通常意味着浏览器将预加载它。但这一设置只是一个提示——iOS 永远不会预加载数据，因为用户可能在昂贵的移动数据网络上。(浏览器对preload的支持相对较新。)

您可能还注意到了<source>元素上的type属性，例如:

<source src="myaudio.mp3" type="audio/mpeg">

这个属性告诉浏览器使用了什么样的容器格式，因此它可以判断出它是否支持该文件格式，而不必开始下载来检查。可悲的是，现代浏览器中的音频格式支持有点混乱，我们很快就会看到。

这只是对<audio>元素的简单描述。对于实现，我建议你使用 HTML5 友好的、基于 JavaScript 的媒体播放器。这将有助于解决实现问题，并避免你重新发明轮子，考虑到当前浏览器中不成熟的<audio>实现，这尤其有帮助。我们将在本章末尾讨论我们的媒体播放器选项。(但如果你想要一些简单的东西，你可以现在就去，试试 audio . js:【http://kolber.github.com/】audio js/。)

然而，对于音频文件的准备，你需要理解关于编解码器的问题，我们将在看完<video>元素后讨论这些问题。在这一章的后面，我们还会看看游戏的 HTML5 音频，并触及<audio>的缺陷和未来。

有一个操纵<audio>和<video>的 JavaScript API(允许你滚动自己的控件来播放、暂停、调节音量等。)，这在下面的参考资料和教程中有所介绍。

有关更多<audio>资源，请参见:

• 关于<audio>和<video> JavaScript API 的基础，参见:【https://developer.mozilla.org/】en/DOM/HTMLMediaElement。

• 谷歌的 HTML5 Rocks“实现 HTML5 音频标签的快速指南(回退到 Flash)”:www.html5rocks.com/教程/音频/快速/ 。

• 戴夫。Opera 的“一个 HTML5

  电台播放器”:dev.opera.com/文章/查看/html 5-音频-电台-播放器/ 。

• Neutron Creations 的“用 jQuery 构建定制的 HTML5 音频播放器”:neutroncreations.com/博客/Building-a-Custom-html 5-Audio-Player-with-jQuery/。

• Safari 和 iOS 实现见 Safari 开发者库:developer.apple.com/库/Safari/# documentation/Audio Video/Conceptual/Using _ html 5 _ Audio _ Video/Introduction/Introduction.html。

• SoundManager 2 目前是“单一 JavaScript API 下可靠的跨平台音频”的首选开源音频库:www.schillmania.com/项目/ soundmanager2/ 。

将<audio>和<video>元素作为普通 HTML 提供的好处是，您可以用 CSS(包括高级的 CSS3)来设计它们的样式。检查出美丽的禅宗音频播放器(播放女孩说话没少)，看看有什么可能:【http://lab.simurai.com/】禅宗播放器/。

图 10.2。Zen 音频播放器真的是一个美丽的东西——一定要看到它的行动。

理解<audio>的关键是编解码器的情况，所以请继续阅读，我们将在简单浏览<video>元素后深入研究。

元素

对于视频，我们可以使用:

<video controls autoplay loop muted preload="auto" poster="myvideobackground.jpg" height="250" width="300">     <source src="myvideo.webm" type="video/webm">     <source src="myvideo.mp4" type="video/mp4">     <!-- Fallback content, such as a Flash player, or a link to the file here --> </video>

(如果你想知道与<video>的实现到底有什么，包括浏览器问题、设置 MIME 类型等等，请看 Kroc Camen 精彩透彻的“人人视频”文章:camendesign.com/代码/人人视频。)

如您所见，这与<audio>示例的设置相似。事实上，controls、autoplay、loop、muted和preload属性的行为都是一样的。但是它们不像音频那样是魔鬼的工具。在这里，我们可以有一个自动播放，循环播放的视频广告是静音的，直到用户另有决定。

就像<audio>一样，我们必须通过指定多个视频文件来处理编解码器支持问题，以实现最大的 HTML5 兼容性。我们使用<source>标签给浏览器一个视频文件列表，浏览器要么使用他们支持的第一个视频文件，要么使用后备内容(比如 Flash 播放器)。type属性提示浏览器应该尝试播放哪个文件。我们将在查看编解码器的情况后讨论这一点。

元素有几个自己独特的属性。主要的一个是poster，它是静态图像，一直显示到视频的第一帧可用。在某些情况下，这可能只有一两秒钟，但在移动设备(如 iOS)上，海报会一直显示，直到用户开始播放。

(至少理论上是这样。IE9 对poster图片的处理很古怪，伊恩·德夫林发现:www . iandevlin . com/blog/2011/12/html 5/the-problem-with-the-poster-attribute。iOS 3 中的一个 bug 阻止了使用poster和<source>元素时的视频播放。运行 iOS 3.x 的 iPad 会忽略除第一个<source>元素之外的所有元素。Android 2.x 的整个<video>实现似乎是一个巨大的错误。更多信息，请参见上面的人人视频文章。)

height和width属性也是特定于<video>元素的。但是同样，因为<video>元素只是 HTML 的另一部分，它可以用 CSS 进行样式化和操作，包括高级的 CSS3。您可以对视频本身进行变换和制作动画，添加阴影等等。这是<video>成为 DOM 中另一个元素的最酷的事情之一。你甚至可以使用<canvas>元素来操作你的视频源，正如这里所讨论的:html5doctor.com/视频-画布-魔术/ 。

视频可访问性

媒体无障碍也在发展之中。规范中增加了一个<track>元素来提供字幕。或者，正如规范所说:“track 元素允许作者为媒体元素指定明确的外部定时文本轨道”(dev.w3.org/ html 5/spec/Overview.html # The-track-element)。<track>元素位于<video></video>标签之间，如下所示:

<track kind="subtitles" src="moviecaptions.en.vtt" srclang="en" label="English">

您可以在这里找到关于这些问题和建议解决方案的介绍和讨论:blog.gingertech.net/ 2011/03/29/web vtt-explained/和这里:www.iandevlin.com/博客/2011/05/html 5/web vtt-and-video-subtitle。

目前只有 IE10 和 Chrome 18(在我写的时候是测试版)支持<track>。有关更多信息，请参见“HTML5 track 元素入门”(www.html5rocks.com/·恩/教程/ track/基础/ )。

API 和资源

新的 HTML5 JavaScript API for media 还处理视频回放，这让您可以滚动自己的控件。这在下面的参考资料和教程中有所涉及。

有关更多<video>资源，请参见:

• “人人视频”值得一读和/或收藏:camendesign.com/代码/人人视频
• 谷歌的 HTML5 Rocks HTML5 视频文章涵盖了基础知识和一些非常不错的例子，包括 SVG 和视频:www.html5rocks.com/恩/教程/视频/基础知识/ 。
• 马克·皮尔格林关于视频的 HTML5 章节有关于编解码器(以及编解码器和容器文件之间的区别)、编码、浏览器支持、服务器 MIME 类型等所有血淋淋的细节:diveintohtml5.info/·video.html。
• 戴夫。Opera 有一个关于 HTML5 视频的广泛指南，乐观地题为“你需要知道的关于 HTML5 视频和音频的一切”:dev.opera.com/文章/查看/你需要知道的关于 html5 视频和音频的一切/ 。
• 《Safari 开发者库 HTML5 音视频指南》有 Safari 和 iOS 相关实现的全部来龙去脉:developer.apple.com/库/Safari/# documentation/Audio Video/Conceptual/Using _ html 5 _ Audio _ Video/Introduction/Introduction.html。

<video>的救星是独立的 JavaScript 播放器，它让我们使用一个文件，HTML5(和一个给定的编解码器)在它支持的地方，Flash 在其他地方。

我们稍后将讨论媒体播放器。同时，抓一把头发，准备拉。

编解码器，你要杀了我

好了，HTML5 适用于现代浏览器，Flash 作为老浏览器的后备。明白了。

没那么快。这就是 HTML，与其说是“任何可能出错的东西都会出错”，不如说是“任何可能引起分歧的东西都会引起分歧”。这里的分歧在于音频和视频的编解码器。

如果你使用图像标签，所有的浏览器都可以显示图像，无论是 JPEG、GIF 还是 PNG——没有强制的格式。

HTML5 规范(不情愿地)对<audio>和<video>标签采取了类似的观点，没有为音频或视频指定特定的格式(即编解码器)。您指定想要使用的格式，这取决于浏览器是否支持它(或者不支持，我们将会看到)。

现在，如果浏览器供应商都同意一种格式(或几种格式)，我们将在所有现代浏览器中拥有通用的 HTML5 音频和视频。不幸的是，这并没有发生。下面是 HTML5 编辑伊恩·希克森对 2009 年年中情况的报道(lists.whatwg.org/·皮珀梅尔/whatwg-whatwg.org/ 2009-6 月/020620.html):

在公开和私下对 HTML5 中的和

的编解码器的情况进行了大量的讨论后，我很不情愿地得出结论，没有一个合适的编解码器是所有供应商都愿意实现和发布的。

因此，我已经删除了 HTML5 规范中需要编解码器的两个小节，并保留了未定义的内容，就像过去对其他功能所做的一样，如和图像格式、和插件 API，或 Web 字体和字体格式。

专利问题

就编解码器达成一致的问题归结于专利。一些媒体格式—包括用于音频的 mp3(是的，不起眼的. MP3)，以及用于视频的流行的 H.264 格式(通常用于. mp4 和。mkv 文件)——拥有专利，使得公司支付许可费来使用他们产品中的解码器。

对于苹果、微软和 Adobe(使用 Flash)这样的大公司来说，这不是问题——他们支持 MP3 和 H.264。但出于意识形态和财务原因，Opera 和 Mozilla 不支持 MP3 音频，也不支持 H.264 视频。(2011 年初，谷歌威胁要在桌面上放弃 Chrome 对 H.264 的支持，但截至 2012 年初，这种情况还没有发生。见帖:blog.chromium.org/ 2011/01/html-video-codec-support-in-chrome.html。)

是的，这是一场格式战。而且这个问题不太可能很快得到解决。

有哪些替代方案？在音频领域，Mozilla 和 Opera 支持无专利的 Ogg 格式(视频也是如此，但被认为是次等的)。2010 年中期，谷歌发布了理论上无专利的 WebM 视频格式(花了整整 1 亿美元购买)，以提供一种“我们就不能和睦相处吗？”每个人都可以使用的视频解决方案，从而解决了僵局。

所以每个人都可以换成那些，对吗？不完全是。对于真正“无专利”的东西，通常必须在法庭上得到证明。因此，微软和苹果采取了一种“更好的魔鬼你知道”的方法，并为他们使用的编解码器支付专利费，特别是视频和 H.264。他们认为这样做比选择所谓的“无专利”技术更好，这种技术可能并不那么无专利，可能会在未来使他们承担责任。事实上，已经有人提出了潜在的 WebM 专利侵权问题，所以这些是合理的担忧。(那是浓缩版，无论如何！)

H.264 是在

即使每个人都可以用 WebM 看视频，苹果或谷歌(安卓系统)也不可能发布软件更新，让每个人都用 WebM 看视频(特别是在手机上)。

为什么不呢？

H.264 在移动设备(以及桌面和其他设备)中使用硬件加速，这是我们如何在低功耗设备上观看高质量视频而不破坏电池寿命的方法。

再加上其他问题，比如围绕 H.264 构建的行业工具链，情况就变得更加模糊了。你可以明白为什么即使苹果、微软和其他公司决定向这个方向发展，从 H.264 大规模转变也是困难的(至少在中短期内)。正如一位黑客新闻评论者所说(【http://news.ycombinator.com/】item？id = 2106285):

数字视频世界运行在 H.264 上，它有深厚、复杂、昂贵的内部工具链来支持它，传统的档案编码在其中，基本上整个业务都围绕它建立。视频制作世界比你想象的要大得多，也复杂得多。

对于所有的供应商来说，在可预见的将来，移动设备上的 H.264 是一个不争的事实。

谷歌威胁说只采用 Chrome WebM，但后来没有这样做

我们来看看谁支持什么。

如前所述，谷歌在 2011 年初宣布，他们将从 Chrome 中移除对 H.264 的支持，专注于 WebM(见公告:【http://blog.chromium.org/】2011/01/html-video-codec-support-in-chrome.html)，但截至 2012 年初撰写本文时，这还没有实现。谷歌旗下的 YouTube 正在将他们所有的视频转码为 WebM，这样他们就可以同时服务于 WebM 和 H.264。是的，他们(据称)正在复制他们的整个 YouTube 库。2011 年 4 月，他们宣布他们“已经对视频进行了代码转换，这些视频占据了网站 99%的浏览量或者所有视频的近 30%”(【http://youtube-global.blogspot.com/】2011/04/mmm-mmm-good-youtube-videos-now-served.html)。

(有趣的事实:他们还提到，截至 2011 年年中，每天有六个年的视频被上传到 YouTube*。)*

至于微软，他们分享苹果的立场，坚持使用 H.264(见:www.fastcompany.com/ 1723373/微软-站在苹果一边-在谷歌上-h264-视频)。如果用户安装了编解码器，他们允许本地 WebM 播放，但是没有发货支持。*

谷歌和微软随后发布了针锋相对的插件。谷歌为 IE9 发布了一个 WebM 插件(tools.google.com/ dl page/webmmf)，尽管它是否被大量采用还有待观察。微软反过来发布了 Chrome 的 H.264 插件(见:blogs.msdn.com/ b/inter operability/archive/2011/02/01/greater-inter operability-for-Windows-customers-with-html 5-video . aspx)和 Firefox(见:blogs.msdn.com/ b/inter operability/archive/2010/12/15/html 5-video-and-interop-Firefox-add-on-provides-h-264-support-on-Windows . aspx)

Opera 和 Mozilla 拒绝支持 H.264，分别在 Opera 10.6+和 Firefox 4+中加入了 WebM 支持。(Firefox 3.x 及更早的 Opera 版本只提供 Ogg Theora 支持。)Mozilla 对 H.264 的立场似乎正在转变，我们将在下面看到。

Adobe 已经表示，他们将在 Flash 的未来版本中支持 WebM，但尚不清楚何时会出现全面支持。(见本故事中的简短提及:news.cnet.com/ 8301-30685 _ 3-2006 13 15-264 . html。)Flash 11 于 2011 年末发布，不支持 WebM。

即使将来某个版本的 Flash 支持 WebM，它也没什么价值。苹果在 Safari 中不支持 WebM，iOS 上不支持 WebM 和 Flash 未来的 Android 设备不会支持 Flash(鉴于 Adobe 已经放弃了移动设备上的 Flash 插件),并且所有当前的 Android 设备都不支持 WebM 微软不会在他们的 Windows Phone 平台上(或实际上在 Metro 上)支持 Flash，这意味着 H.264 将是移动视频的必要条件(至少是)以支持传统和未来的设备。

关于浏览器和设备兼容性的进一步分析，请看这里的图表:mediaelementjs.com。

编解码器:做什么？

唷！那我们该怎么办？

如果你想要最大限度的原生 HTML5 支持——包括 Firefox 和 Opera——你需要存储两份音频文件(MP3 和 Ogg Vorbis)，可能还有三份视频文件(H.264、WebM 和 Ogg Theora 用于 Firefox 3.x 的传统支持)。必须编码和存储这么多不同的版本是一个皇家的屁股痛，但你去那里。

或者，您可以:

• 将 MP3 用于音频，它原生适用于 Safari、IE9 和 Chrome(包括 iOS 和 Android)。
• 视频使用 H.264，在 iOS、Safari 和 IE9 中可以原生工作。
• 如果 Flash 可以在任何支持 Flash 的浏览器或设备上播放 MP3 和 H.264，那么可以为旧的和不支持编解码器的设备使用一个使用 Flash 播放器的媒体播放器(或自己编写脚本)。

鉴于我们需要 H.264 用于 iOS(以及一般的移动设备),这种情况——我敢打赌这将是最常见的——意味着 Firefox、Opera 和 Chrome(用于视频)最终将采用 Flash。没错——那些支持自由开放软件的人最终会得到专有的、封闭的 Flash。这比潮人的胡子还讽刺。

(或者，如前所述，您可以对您的视频进行双重编码，并在第二个<source>元素中提供一个单独的 WebM 文件，以便在现代浏览器中提供广泛的原生 HTML5 支持。)

现实咬人

然而现实可能有些不同。首先，谷歌还没有放弃对 H.264 的支持，而且(在撰写本文时)Mozilla 正在重新考虑他们反对支持这种编解码器的立场。

2012 年 3 月，Mozilla 公司的研究主管 Andreas Gal 在 Mozilla 邮件列表上发起了这场辩论，他建议 Mozilla(groups.google.com/论坛/ #！msg/mozilla.dev.platform/-xte i5 ry thu/dk M9 aibknnij):

支持解码系统上现有解码器支持的任何视频/音频格式，包括 H.264 和 MP3。确实没有理由阻止我们的用户使用设备上已经存在的系统解码器，所以我们不会过滤任何格式。

这意味着 Mozilla 可以将 Firefox(特别是针对移动平台的)与对操作系统的授权解码器(如果有的话)的支持一起发布；避免数百万美元的许可费；并至少保持意识形态纯洁性的外表。这实际上不仅仅是 Firefox——Mozilla 正在开发他们自己的基于网络的移动平台,名为 Boot to Gecko(或 B2G，我们将在第十二章中介绍)，但是如果它不能像其他主要平台一样播放 H.264 视频(和 MP3 音频),它就不会有太大的机会。(注意，Gal 在 Mozilla 公司的职位并没有让他对 Firefox 或 Mozilla 项目的方向有任何特别的影响力，他只是作为一个贡献者。)

但是谷歌不是应该已经用 WebM 解决了这个问题吗？又是这个女孩(groups.google.com/论坛/ #！msg/mozilla.dev.platform/-xte i5 ry thu/iz 767 iw v1 juj):

谷歌承诺了很多事情，但他们没有坚持到底，我们的用户和我们的项目正在为此付出代价。H.264 不会消失。再坚持一会儿我们什么也买不到。

正如火狐开发者 Justin Dolske 在邮件列表讨论(groups.google.com/论坛/ #！msg/mozilla.dev.platform/-xtei 5 ry thu/3d6e-Sgo _ ZQJ):

但我认为，如果 Mozilla 要在开放视频标准上做一个大转变(这是一个大转变)，那么应该就此进行一些严肃的讨论。当然不只是简单的几句话，说这是毫无希望和显而易见的。这让它听起来更像一个半心半意的通知，一个已经是最终决定。

至少，需要对其进行足够的解释，以便社区能够理解这种变化。我们花了很多时间，写了很多博客，讨论 H.264 为什么对网络有害。让那些支持我们的人突然陷入困境感觉不是一件正确的事情。

H.264 势头强劲，而 Mozilla 面临着实用主义和意识形态之间的艰难抉择。尽管 H.264 是非免费的，但它是事实上的标准(很像 MP3 ),他们需要支持它，否则就会落后。(更多内容参见 Ars Technica 的报告:arstechnica.com/小工具/新闻/ 2012/ 03/理想主义-实用主义-Mozilla-辩论-支持-h264-视频-回放. ars 。随着 Ars 的发展，关注它们的更新。)

Mozilla 的首席技术官布伦丹·艾希(Brendan Eich)在《视频、移动和开放网络》(hacks.mozilla.org/ 2012/03/Video-Mobile-and-the-Open-Web/)中支持了 Gal 的提议，他写道:

我可以确定的是:H.264 现在绝对需要在手机上竞争。我不认为我们可以在安卓或 B2G 的 Firefox 中拒绝 H.264 内容，并在向手机的转移中幸存下来。

输掉一场战斗是一次痛苦的经历。我不会粉饰这药。但是，如果我们要在我们的移动计划中取得成功，我们必须吞下它。移动领域的失败很可能会让 Mozilla 走向衰落，变得无关紧要。所以我完全赞成安德里亚斯的提议。

如果这是 Mozilla 采取的路线，很难想象 Opera 会无限期地坚持下去。这实际上意味着，从长远来看，用 H.264(带有针对旧浏览器的 Flash 后备)和 MP3(同上)编码媒体就足够了。

视频类型…天哪

现在，您(希望)了解了编解码器情况的复杂性，以及浏览器对每种编解码器的支持方式的不同，让我们看看如何告诉浏览器我们正在使用哪些编解码器，以便他们可以就加载哪些视频做出明智的决定。

这就引出了我们还没有讨论的一个视频属性——<source>元素上的type属性，例如:

<source src="myvideo.mp4" type="video/mp4">

该属性告诉浏览器什么容器和编解码器用于在src属性中指定的视频。在上面的例子中，我们仅通过列出 MIME 类型(即媒体格式类型)来指定使用什么容器格式。上面的 MIME 类型告诉浏览器“这个文件是使用 mp4 容器格式的视频”。像 mp4 这样的容器格式有点像 zip 文件，因为它们只是一个用于实际的视频和音频文件的容器，这些文件使用特定的编解码器进行编码，并打包成最终的视频文件。(type属性也可以用在<video>元素本身上，而不仅仅是嵌套的<source>元素上，如果你只使用一个文件的话。同样的道理也适用于<audio>。)

我们放在 type 属性中的信息只是给浏览器的一个提示，但浏览器并不一定要播放视频*。**所需要的*就是编辑你的。htaccess 文件，以确保您的服务器以正确的 MIME 类型发送这些文件，正如这里的说明所描述的:【http://mediaelementjs.com/】，并在其他地方有所涉及(例如前面提到的“人人视频”文章)。

我们还可以指定使用的容器格式和编解码器，例如:

<source src="myvideo.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>

这里我们指定了容器格式，和源文件中视频和音频的编解码器。(视频编解码器是 H.264 的一种风格，还有 AAC 音频编解码器。注意，我们还必须在这里对type属性使用单引号，因为编解码器参数使用双引号。)

这一切有什么意义？嗯，指定type属性意味着浏览器不必开始下载每个列出的文件，只是为了检查它是否可以播放。它可以扫描标记，并可能开始预加载它支持的视频文件。然而，忽略它并不是世界末日。摘自长尾视频 2012 年的“HTML5 视频现状”(www.longtailvideo.com/ html 5/):

每个浏览器都支持标签来加载多个源。我们的测试表明，包含 type 属性会阻止一些预加载，但会破坏与 Android 2.2 的兼容性。在“类型”属性中设置编解码器对任何浏览器都没有影响。

注意 Android 2.2 兼容性问题。关于编解码器的评论表明，从 LongTail 的测试来看，我们(总的来说)只需要指定容器，浏览器就会加载它。

用 JavaScript 查询支持的视频类型

我们还可以使用<video> JavaScript API 及其canPlayType()方法查询浏览器，以查看浏览器支持哪些格式。例如，对于我们上面指定的编解码器(“avc1.42E01E，mp4a.40.2”)，支持这些格式的浏览器(Safari 和 IE9+)将会以probably响应，这与我们在 HTML5 中获得的“是的，我们支持此文件”非常接近。如果我们只指定容器格式(’ video/mp4 ')，Safari 和 IE9+(比如)用maybe响应，因为它们知道自己可以读取那个容器格式，但不知道里面是什么编解码器。不支持给定容器或编解码器格式的浏览器只会返回一个空字符串。

然而事情变得非常复杂。以下是我们必须处理的三个变量:

• **浏览器回应:**由于编码媒体(尤其是视频)的复杂性，浏览器只能确定它们不能播放它们不理解的格式。在这些情况下，它们返回一个空字符串(当通过canPlayType()方法查询时)。除此之外，HTML5 规范规定，他们必须返回maybe或probably，这取决于浏览器是否有信心根据我们提供的信息播放某个文件。
• **容器和编解码器:**有 mp4 等容器格式，有实际编解码器，更准确的说是实际编解码器的口味(如 avc1.42E01E)，可以查询。
• **浏览器支持:**最后，正如我们所看到的，主流浏览器的编解码器支持是一个相当复杂的情况。

因此，我们有多种浏览器，支持多种容器/编解码器(针对音频和视频)，并给出三种响应之一。幸运的是，WHATWG 维护了一个浏览器响应表，因此我们可以看到对于给定的容器格式，或者容器和编解码器组合，我们应该从给定的浏览器:【http://wiki.whatwg.org/】wiki/Video _ type _ parameters # Browser _ Support 获得哪个响应。微软有一个小脚本演示了这是如何工作的:【http://msdn.microsoft.com/ de-de/library/hh 325437(v = vs . 85)。aspx 。

(还要注意的是，我们实际上得到的浏览器响应可能是错误的，正如 2010 年中期的这篇略显陈旧的帖子所暗示的那样:【http://rakaz.nl/】2010/06/problems-with-html5-video-codec-detection.html。)

音频和视频媒体播放器来拯救

真是一团糟。

幸运的是，人们已经编写了工具，可以将正确的视频(或音频)提供给正确的浏览器。这些媒体播放器在整个编解码器混乱和遗留支持问题中帮助您；提供丰富的定制选项；并且总体上使整个实现过程变得平滑。

这里有几个例子:

媒体元素(视频和音频，免费)

mediaelementjs.com

一种流行的音频和视频播放器，允许您使用一个文件(例如，H.264 视频文件)并在所有使用 Flash(或 Silverlight)的设备上部署一致的 UI，以便在 H.264 本身不支持的地方播放。它附带了一个 jQuery 插件，以及 Drupal 和 Wordpress 的插件。

VideoJS(视频，免费)

videojs.com

VideoJS 是一个漂亮的 HTML5 视频播放器，它提供了一些熟悉的基于 CSS 的皮肤，以及类似的对 HTML5 视频的广泛支持。它为每个人使用来自视频的标记(我们之前链接过这个)，并添加了 JavaScript 以获得更广泛的兼容性和 CSS 皮肤选项。

Flowplayer(视频、免费和商业)

http://flower player . org

带有 Flowplayer 品牌的免费开源播放器。还有一个不带品牌的商业产品(带支持选项)。

更多媒体播放器

还有各种各样的其他参与者，包括:

• jp player(【http://www.jplayer.org】??)，一个免费的开源音频和视频播放器(带有方便的播放列表支持)
• 打开标准媒体(OSM)播放器(www.mediafront.org/项目/ osmplayer )，这是一个用 jQuery 编写的免费音频和视频播放器，有一个可视化播放列表
• JW 播放器(【http://www.longtailvideo.com/】玩家/ )，另一个支持 HTML5 的选项
• SublimeVideo(【http://sublimevideo.net/】)一款付费托管的 HTML5 播放器解决方案。
• Popcorn . js(【http://popcornjs.org/】)是一个“JavaScript 事件框架”，是 Mozilla Popcorn 项目的一部分:mozillapopcorn.org/。如果您想要触发页面上其他内容的更新与视频同步，这将非常有用。

(当然，您可以随时使用 YouTube 或 Vimeo，让原生 iOS 播放自行处理！)

有了这些解决方案，就不需要推出您的定制解决方案。从货架上随便拿一个，尽情享受吧。

HTML5 视频美中不足的还有:DRM、流媒体和全屏视频

我们已经有了基本的<video>和<audio>嵌入，但即使有了我们方便的、随时可用的媒体播放器和它们的 Flash 后备，仍然有一些 HTML5 视频缺乏的(或非常不成熟的)功能，而 Flash 支持这些功能。请记住，微软将而不是在 Windows 8 的 Metro 界面中支持 IE10 中的 Flash(如果用户想使用 Flash，它会将用户踢出“桌面”界面)，因此迟早会有相当大的压力来添加这些功能。说到 DRM，这可能不是一件好事。

数字版权管理

2012 年 2 月，来自谷歌、微软和网飞的代表向 W3C 的 html 工作组提交了加密媒体扩展 v0.1 提案草案(dvcs.w3.org/ Hg/HTML-Media/raw-file/tip/Encrypted-Media/encrypted-media.html)。该提案的摘要称:

这个提议扩展了 HTMLMediaElement，使其能够回放受保护的内容。所提出的 API 支持从简单的明文密钥解密到高价值视频(给定适当的用户代理实现)的用例。许可证/密钥交换由应用程序控制，有助于开发支持一系列内容解密和保护技术的强大回放应用程序。HTML5 规范中没有添加“DRM”，只需要简单的明文密钥解密作为公共基线。

也就是说，这将通过扩展它们的 JavaScript API(HTMLMediaElement接口)为<audio>和<video>提供一种在 HTML5 之上进行 DRM 的机制。HTML5 的编辑伊恩·希克森回应道(lists.w3.org/档案馆/Public/Public-html/2012 feb/0274.html):

我认为这个提议是不道德的，我们不应该追求它。

在这里，希克森也声明了“DRM 是邪恶的”，并进一步阐述了他断然拒绝该提议的理由:www.w3.org/ Bugs/Public/show _ bug . CGI？id = 10902 # c24。Mozilla 也表达了担忧，因为 DRM 和开源浏览器通常是相互排斥的(更多信息请参见这篇 Ars Technica 文章:【http://arstechnica.com/商业/新闻/ 2012/ 02/不道德-html-视频-复制-保护-建议-被标准批评-利益相关者. ars )。

我基本上同意希克森的观点。DRM 是邪恶的。还记得 PlaysForSure 吗？没有吗？没错。

视频 DRM 和音频 DRM 有一个重要的区别，那就是流媒体。我们有流媒体(和租赁)视频的文化，在某种程度上，当音乐 DRM 战争肆虐时，我们没有音频。当 DRM 应用于你购买的音乐时，它很糟糕，因为如果 DRM 平台死了(他们确实死了)，你的音乐收藏也会死。流媒体的时间特性缓解了这些担忧，但只是在一定程度上。(如果它可以在流媒体上实现，不难想象媒体巨头也会坚持对购买的内容进行 DRM。)

围绕“受保护”内容流的这些问题解释了为什么网飞有兴趣在使用网络标准时看到某种 DRM 可用。在可能的情况下(正如他们在这里讨论的那样:techblog.netflix.com/ 2010/12/why-we-choose-html5-for-user.html)，网飞热衷于使用 HTML5(广义的“网络平台”意义上)，但他们显然认为他们需要某种 DRM 系统来传输他们通过 HTML5 许可的内容。(他们还需要一个实际的流协议，我们接下来会看到。)谷歌和微软的一些人显然也觉得这是必要的。(请注意，希克森也为谷歌工作，所以这不是一个全公司的职位。)

微软处于一个特别有趣的位置，因为他们不会在 Metro 的 IE10 中支持 Flash，但显然会希望提供一些机制，以便他们的用户仍然可以在 Metro 的 IE10 中访问“受保护的”流媒体视频服务。当然，另一种选择是流媒体视频公司将其服务实现为 Silverlight 驱动的 Metro 应用，并为这些用户完全从网络上移除。

这可能是另一个后 Flash web 导致的不是开放标准乌托邦，而是特定平台应用的回归的例子。也就是说，考虑到实现 DRM 的成本，这可能是标准运动愿意承受的代价。

当我写这篇文章时，W3C 邮件列表上的争论正在激烈进行，这里有一个摘要:lists.w3.org/档案馆/Public/Public-html/2012 mar/0087.html。

但是这种争论可能没有实际意义。2012 年 3 月，W3C 的 Philippe Le Hegaret 写道(lists.w3.org/档案馆/公共/公共-html/2012 mar/0097.html):

[L]让我们明确一点:W3C 有许多参与者对寻找媒体内容保护的解决方案感兴趣。因此，我们确实对这个领域感兴趣，不管 HTML 工作组是否对开发一个解决方案感兴趣，也不管它是否在一个单独的小组中完成。无论我们选择什么，我们都将尽最大努力在生产者和消费者之间取得适当的平衡。

也就是说，无论有没有你，我们都将实现 DRM，因为我们的付费会员需要它。不祥的东西。

流动

我们已经谈到了流媒体的 DRM 方面，但是其他的技术挑战呢？在 2010 年末，网飞讨论了一些他们已经确定的关于流媒体和 HTML5 的问题，并一直忙于这些问题:techblog.netflix.com/ 2010/12/html5-and-video-streaming.html。在 2011 年末，Ars Technica 发表了一篇优秀的文章《HTML 视频在后 Flash 时代的考验和磨难》(arstechnica.com/商业/新闻/2011/11/The-trials-and-trivities-of-HTML-video-in-The-post-Flash-era . Ars)详细阐述了其中的一些问题，包括流媒体。Ars 的文章还指出:

将浏览器中的视频交付从 Flash 转换到 HTML5 也将给内容创作者带来一些重大挑战。这些标准还没有完全成熟，仍然有许多功能不被支持或不能在各种浏览器中广泛使用。

为了说明问题有多严重，你只需要看看 Mozilla 的 Firefox Live 推广网站，该网站宣传该组织对开放网络的承诺，并展示了诺克斯维尔动物园小熊猫幼崽的直播视频。视频是用 Flash 流传输的，而不是使用基于标准的开放网络技术。

在该网站的一个常见问题中，Mozilla 表示，它根本找不到基于开放编解码器和开放标准的高容量直播解决方案。如果 Mozilla 不知道如何用开放标准流式传输它可爱的吉祥物，这意味着还有工作要做。

流媒体标准已经在工作中有一段时间了:HTTP 上的动态自适应流媒体(DASH)，它得到了微软的支持，但在支持实现之前还有一段路要走。DASH 也是编解码器不可知的——它不能解决我们之前讨论的编解码器僵局。(有关更多信息，请参见“什么是 MPEG DASH？”:www.streamingmedia.com/文章/ ReadArticle.aspx？ArticleID=79041 。)

苹果目前有自己的流媒体协议，HTTP Live Streaming (HLS)，用于向其 iOS 设备提供内容。谷歌在 Android 3.0+中增加了支持，它允许加密数据，并与第三方 DRM 解决方案配合使用。(参见“什么是 HLS (HTTP 直播流)？”更多:www.streamingmedia.com/文章/社论/现状-.../What-is-HLS-% 28 http-Live-Streaming % 29-78221 . aspx。)

DRM、编解码器僵局、对新技术标准的支持以及现有标准的竞争。在基于标准的流媒体成为现实之前，有许多问题需要解决。

全屏幕

最后，我们对 Flash 视频做的最常见的事情之一是全屏显示。这在 HTML5 中是不可能的。然而，有一个全屏 API W3C 规范(dvcs.w3.org/ Hg/full screen/raw-file/tip/overview . html)在 Firefox 10+和最近的 WebKit 浏览器(Chrome 15+和 Safari 5.1+)中有实验支持。目前还不清楚 IE10 是否会支持该功能。有趣的是，全屏 API 可以让任何元素全屏显示，包括(例如)<canvas>元素，例如，它也可以用于全屏阅读模式。

有关全屏 API 的更多信息，请参见:

• Mozilla Hacks 博客有一个教程(包括样式信息)和一个演示，您可以使用。教程:hacks.mozilla.org/ 2012/01/using-the-full screen-API-in-web-browsers/及演示:robnyman.github.com/fullscreen/。
• 这里还有一个教程:tutorialzine.com/ 2012/02/enhance-your-website-full screen-API/。
• 请留意caniuse.com/ # feat =全屏的浏览器支持统计和更多资源。

HTML5

准备好游戏了吗？

关于<audio>及其游戏潜力的最后一点说明。

Dominic Szablewski 发布了一个史诗(和亵渎！)关于 HTML5 音频的状态，与开发 HTML5 游戏的关系。它非常值得一读，具有娱乐价值，并给出了 HTML5 音频支持(im)成熟度的一些指标，特别是对于交互目的。Szablewski 说。

令人惊讶的是，在所有优秀的桌面浏览器中，谷歌的 Chrome 对 HTML5 音频的支持最差——这是除 IE 之外的所有浏览器。我不是音频工程师，但在浏览器供应商尝试之前，我对数字音频的印象是这是一个已经解决的问题。我很惊讶，经过这么多次迭代后，HTML5 音频仍然是坏的。

移动浏览器(iOS 和 Android)上的音频支持充其量是可笑的。即使是最简单的任务，它也完全不能用。你可以绕着圈子问得很好，但还是很糟糕。

(详见文章:www.phoboslab.org/日志/2011/03/the-state-of-html 5-audio。我喜欢卑鄙的史蒂夫帽。)

简短的回答？不，它还没准备好玩游戏。

事实上，鉴于伊恩·希克森对这个问题的看法，高级音频 API 是否会很快成为 HTML 规范还是有争议的。2011 年 6 月，他写道(lists.w3.org/档案馆/公共/公共-音频/2011 prjun/0118.html):

我不相信音频 API 真的是 Web 平台上下一个最重要的工作。[…][M]也许在不久的将来，Web 平台最好的音频 API 根本就不是 API。

与此同时，Flash 仍然是游戏高级、跨浏览器音频支持的必要条件，正如 Pixel 实验室的团队在他们出色的 Canvas-powered 版本《割断绳子》中发现的那样

Robby Ingebretsen 描述了 Pixel 实验室团队如何努力让 HTML5 音频适用于所有浏览器，但是(nerdplusart.com/为什么在 html5 版本中有闪光):

我们面对的不仅仅是功能支持，还有浏览器的怪癖和漏洞。换句话说，即使浏览器支持 HTML5 音频，我们也不能保证它能可靠地处理游戏中复杂的声音需求。

微软赞助将游戏移植到 HTML5，以展示 IE9 的标准支持，幸运的是，对于 Ingebretsen 来说，他们在 IE9 中单独使用<audio>就可以获得音频，因为显然 IE9 的<audio>实现非常好。然而，在其他浏览器中，这些错误很难克服。因此，他们选择使用“非常强大”的 SoundManager 2 库，该库带有一个他们可以依赖的 Flash 后备。SoundManager 2 网站描述了该项目(【http://www.schillmania.com/】项目/ soundmanager2/ ):

SoundManager 2 为您提供了一个强大的 API，支持新旧版本，在支持的地方使用 HTML5 音频，在需要的地方使用可选的基于 Flash 的后备。理想情况下，当使用 SoundManager 2 时，音频“正常工作”

Flash fallback 意味着用户在玩游戏时仍然可以获得很好的音频体验。它不仅仅是纯粹的 HTML5，而是为了一个伟大的端口向团队脱帽致敬，并尽一切努力获得 100%的 HTML5 支持(并在 IE9 中实现)。然而，他们的经历凸显了 HTML5 游戏的<audio>实现的弱点。

音频的未来

这并不是说浏览器中的<audio>静止不动，或者音频 API 必须是 HTML5 的一部分。

一些聪明的变通办法已经出现，例如 Remy Sharp 的 Audio sprites(remysharp.com/ 2010/12/23/Audio-sprites/)，谷歌复杂的网络音频 API 目前是 W3C 的提案，并在 Chrome 中发布。Firefox 4+有自己的音频数据 API，这两个 API 都用于新兴的 JavaScript 音频库(参见:【https://wiki.mozilla.org/】Audio _ Data _ API # JavaScript _ Audio _ Libraries)。然而，目前还没有 Safari、IE 或 Opera 对这些 API 的支持。

虽然看到这种创新的发生令人兴奋(尽管在 HTML5 规范之外)；为游戏等应用提供广泛、成熟、一致的音频支持还有很长的路要走。

包扎

对<audio>和<video>的原生支持是受欢迎的，尤其是对移动设备来说是必要的。但是要记住，技术还是有些不成熟(尤其是在 Android 上)。

编解码器问题不会很快得到解决，iOS 仍然需要 H.264 视频。所以我们需要小心行事。不要仅仅因为它符合规范就认为它会完美地工作。

我的建议？留意你最喜欢的媒体播放器支持什么，让它来做最困难的工作。*

十一、Flash 的挑战者

当我们在第九章看 Canvas 时，我们触及了挑战闪存技术的概念。但在过去十年中，Flash 最大的挑战者可能是可伸缩矢量图形(SVG ),这是一种用于 2D 图形和动画的 XML 格式，现在又卷土重来了。让我们简单地看一下 SVG 这种死而复生、不那么死的技术。

SVG，SVG…

哦，SVG(可缩放矢量图形)。我们能说你什么？你是一个独立的 W3C 规范，从 1998 年就开始开发了。你不是 HTML5 规范的一部分，但是 HTML5 将让你与其他标记一起出现。你对矢量图形了如指掌，这让你成为了 Photoshop 中的插画师。你承诺了这么多，这么久——2002 年，人们写了 1000 多页关于你的书(SVG Unleashed，2002 年，Sams)。但是你从来没有进过大联盟。发生了什么事？

SVG 既是过去 web 标准的遗留物，也是一种最终几乎到来的技术。它是矢量图形的 XML 格式(可以把 SVG 看作图形，就像 HTML 是文本)，这意味着它看起来像一堆尖括号——标签和属性。还记得我们看 HTML 的历史，以及它是如何变成全 XML 的吗？SVG 是这个愿景的一部分——这个愿景没有实现。

下面是基本 SVG 的样子:

<svg id="mysvgexample" height="200" width="300" >     <rect id="myrectangle" width="200" height="100" fill="red" x="20" y="20" /> </svg>

这使得:

图 11.1。我们激动人心的 SVG 演示。

是的，一个红色的长方形。我给你一点时间恢复。

快速解释一下这里发生的事情:我们已经将<svg>元素设置为 200px 高和 300px 宽，它充当我们想要呈现的形状或线条的透明容器。(我用 CSS 给了它一个边框，这样你就可以看到它的边界了。)然后我们用<rect />元素创建一个矩形，给它一个height和width，以及一个从容器<svg>元素偏移的x和y。添加一个fill(我使用了关键字red，但是您也可以使用十六进制值)我们就完成了。

在 HTML5 中，你可以将这段代码直接放到你的 HTML 文档中，支持的浏览器(IE9+，FF4+，Safari 5.1+，Chrome 7+，Opera 11.6+，iOS 5+，Android 3+)会适当地呈现它。

SVG:浏览器支持终于到来

SVG 再次变得有趣，因为浏览器支持终于到来了。目前，所有现代和不太现代的浏览器，包括 IE9(但不包括 IE6-8)，都支持使用<embed>或<object>元素嵌入 SVG。(Android 2.x 是唯一的坚持者。)不过，IE 的情况并不像听起来那么糟糕，我们接下来会看到。

浏览器也开始在标签中支持 SVG 图像，甚至作为 CSS 背景(特别是 IE9+，FF4+，以及所有最近发布的 Safari，iOS，Chrome 和 Opera)。

甚至有一些支持应用高级 SVG 功能，如过滤器(如高斯模糊)，剪辑和非 SVG 对象的变换。Firefox 对此的支持特别好；见people.mozilla.com/ ~ prou get/demos/mashup/video . XHTML在 FF4+进行粗略演示。除了 Firefox，对它的支持是不完整的。就类似 Photoshop 的滤镜而言，Chrome 和 Opera 提供了很好的支持，但 SVG 滤镜将只在 Safari 版本 6 中提供，目前没有 iOS 5 或 Android 4 支持。IE9 也不支持它们，但是 IE10 提供了硬件加速的 SVG 滤镜效果(参见:【http://blogs.msdn.com/】b/ie/archive/2011/10/14/SVG-filter-effects-in-IE10 . aspx)。

这就是在 SVG 支持的最前沿发生的事情(最新的支持统计见:caniuse.com/ # search = SVG)。但是我们现在可以在任何浏览器中使用的真实世界的跨浏览器 SVG 呢？

是的，我们现在就可以使用真实世界的 SVG

Dmitry Baranovskiy 出色的 raphal JavaScript 库让我们可以用 SVG 做一些简单、酷、像 Flash 一样的事情。经过几年的积极开发，它提供了低至 IE6 的浏览器支持(感谢 IE 中的 VML 翻译)。你可以在这里查看:raphaeljs.com/。(请确保您还查看了姐妹图形库 graph al:【http://g.raphaeljs.com】??。)

我们一会儿将看看 raphal(和 SVG 本身)能做什么，但现在值得记住的是，由于 raphal，简单的 SVG(包括动画)可以与广泛的浏览器支持一起使用。

想象一下，如果突然之间，我们不得不支持各种分辨率大小和密度的设备，其中一些不支持 Flash。矢量图形——在任何分辨率下都清晰，并且可以缩放到任何尺寸——难道不会让生活变得更容易吗？保持这种想法…

SVG 的许多方面

让我们看看 SVG 的不同面貌。有:

• SVG，这个巨大的规范已经存在了十年(并且还在成长)。
• 先进的 SVG，因为它正在先进的浏览器中实现。
• SVG，因为我们今天可以在现实世界中使用它与工具，如拉斐尔和 jQuery SVG(keith-wood.name/ svg.html)。

SVG 现在可以(并且正在)用于各种具有可靠交叉支持的情况，包括 iOS 设备，所以它的时代可能终于到来了。而且来得正是时候，考虑到 Adobe 在移动浏览器中放弃 Flash，以及微软在 Windows 8 的默认 Metro 界面中拒绝允许 IE10 中的插件。(关于 Flash 之死的更多信息，请参见第九章中关于画布和 Flash 的讨论。)更不用说对界面元素的迫切需求了，这些元素可以从手机扩展到 iPad“retina”显示屏，再扩展到 27 英寸或 30 英寸的屏幕。

2000 年代的 SVG 不是很大的希望

SVG 已经走过了一段漫长的旅程。在其全部盛况中，它给人留下了极其深刻的印象，并且目前做的和当前的 CSS3 实现一样多(如果不是更多的话)。完整的 SVG 支持做一切事情，从动画，到我们前面提到的类似 Photoshop 的滤镜效果(参见 Chrome，Opera 或 Firefox 中的这个例子:svg-wow.org/滤镜效果/chicked . SVG)，到自定义字体，遮罩，视频，当然还有绘制矢量形状。一切都在那里(至少在规范中——浏览器支持严重滞后)。所以在某种程度上，它很像 Flash。

基本的 SVG 就像十年前的 Flash，但是没有浏览器支持或者开发工具。事实上，在 Adobe 收购 Macromedia(开发 Flash 的公司)之前，Adobe 一直支持 SVG 作为一种开放的替代方案。在 2002 年，大约有 1.6 亿人在使用他们的 SVG 浏览器插件(自从停止使用以来，见www.xml.com/ pub/a/2002/07/03/adobesvg.html)。

为了让你感受一下 21 世纪初围绕 SVG 的大肆宣传，这里引用了 2002 年 Digital Web 上一篇题为“SVG:新的闪光”(www.digital-web.com/文章/ svg_the_new_flash/ )的文章:

SVG 应该很快就会普及，它的非专有性质将有助于加速这一进程。由于其庞大的客户群，Flash 将在相当长的一段时间内继续成为主导标准。然而，SVG 正在迅速崛起。通过浏览器制造商分发 SVG 插件将会迅速增加用户群，就像 Flash 一样。各种浏览器的未来版本将包含 SVG 查看器作为标准，有些已经这样做了。

但是 SVG 从未真正起飞。(可以说，它的“非专有性质”在过去十年里并不重要。)它无法触及 Flash 的安装基础，也从未有过像 Flash 这样对设计师友好的开发工具。当 Adobe 在 2005 年收购 Macromedia 时，就网络上的矢量图形而言，它是闪光或破产。

尽管如此，SVG 也从未真正消亡。随着浏览器支持的迅速改进，以及 Flash 的前景，SVG 可能会再次卷土重来。

SVG 浏览器支持:安卓，什么鬼？哦，还有…

目前的一个症结是，Android 2.x 甚至不提供基本的 SVG 浏览器支持，尽管谷歌在其他地方推出了 SVG(见:http://googlecode.blogspot.com/ 2009/10/svg-at-google-and-in-internet-explorer.html)。它已经在 Android 的浏览器背后的引擎 WebKit 中了，它只是“为了节省空间”而被有意冷落在了 Android 2.x 中(见这里的评论和讨论:code.google.com/ p/Android/issues/detail？id=1376#c4 )。去想想。(Android 3.0 中的浏览器，Android 的平板电脑版本，是否支持基本的 SVG，在统一的 4.0 版本中，SVG 支持终于也适用于移动 Android 设备。)

*幸运的是，IE6-8 有几个库可以尝试将 SVG 翻译成它能理解的东西。

Raphaë是我们前面提到的用于 SVG 的 JavaScript 库，为了兼容性，它回到了 IE 的老版本 VML (Vector Markup Language)。(它类似于我们在第九章中看到的画布仿真，也有类似的限制，即 VML慢。)

还有 SVG Web(code.google.com/ p/SVG Web/)，它把 SVG 翻译成 Flash，供不支持 SVG 的老浏览器使用，包括 IE。(可悲的是，这仍然没有帮助我们解决 Android 2.x 的问题。参见:groups.google.com/集团/SVG-web/browse _ thread/thread/77fb 6970 f 5f 01 e 97。)

还有 canvg(code.google.com/ p/canvg/)，它在画布中渲染 SVG，并为 Android 提供一些 SVG 支持，作为 Android 4.0 普及之前的权宜之计。这里讨论一下这个方法:【http://www.kendoui.com/博客/团队博客/帖子/12-02-17/using _ SVG _ on _ Android _ 2 _ x _ and _ kendo _ ui _ dataviz . aspx。(Fabric.js 可能也有帮助:【http://fabricjs.com/】??。)

虽然这些工具使基本的 SVG 在几乎任何浏览器上都成为现实，但请记住这只是基本的 SVG，而不是已经成为 SVG 规范一部分的疯狂的类似 Photoshop 的滤镜。

SVG 演示:它有什么好处？

矢量图形在很多情况下都很有用——地图、图表、插图、徽标、可视化、独立于分辨率的界面等等。Flash 的成功无疑证明了对动画矢量图形的需求。原本可以在 Flash 中交付的内容有可能在 SVG 中完成，因此可供 iOS 用户使用。

让我们看一些 SVG 演示，看看它有什么能力。我们先看几个一般的例子，然后看几个真实的拉斐尔例子。

SVG 女孩

图 11.2。动画 SVG 女孩短是短暂的，但令人印象深刻。

SVG Girl 是一个“SVG 动画视频”，微软委托它展示 IE9 中的硬件加速 SVG 支持(尽管它可以在任何现代浏览器中工作)。这是一个用 SVG 制作的简短但非常复杂且令人印象深刻的动画片段。看到这里:jsdo.it/事件/ svggirl/

这种复杂动画的 SVG 性能过去很差，但是硬件加速让世界变得不同。向 IE 团队的硬件加速 SVG 致敬。(你可以在这里了解更多:blogs.msdn.com/ b/ie/archive/2011/03/08/comparing-hardware-accelerated-SVG-cross-browsers-with-Santa-s-workshop . aspx。)

SVG Edit

图 11.3。SVG Edit 是一个 SVG 驱动的绘图程序，它输出…SVG。

SVG Edit 展示了单独使用客户端 web 技术可以完成什么。这是一个基于 SVG 和 JavaScript 的应用程序，用于编辑 SVG。在这里下载:code.google.com/p/svg-edit/或者在这里现场试用:svg-edit.googlecode.com/ SVN/branches/2 . 5 . 1/editor/svg-editor.html。

谷歌文档

图 11.4。SVG 用于一些非常引人注目的场合，比如 Google Docs 绘图程序。

谷歌文档的绘图程序使用 SVG 和 VML 后备。(谷歌也在 2012 年初开始在谷歌分析中使用 SVG。)

SVG 小游戏

图 11.5。SVG-oid 可能很简单，但是它展示了 SVG 的交互可能性。

您可以用 JavaScript 在 SVG 中创建游戏，但是 SVG for games 并没有像 Canvas 那样流行起来。作为 IE9 技术演示的一部分，微软发布了几个非常简单的复古游戏示例:

• SVG 中的小行星:ie.microsoft.com/ test drive/Graphics/SVG OIDs/default . XHTML
• 一个简单的直升机游戏:ie.microsoft.com/ test drive/Performance/Helicopter/default . XHTML背景让我想起了雅达利 2600。

D3.js

图 11.6。值得在线探索令人印象深刻的 D3.js 示例，比如这个“streamgraph”。

D3 . js(mbostock.github.com/ D3/)是一个“基于数据操纵文档的小型免费 JavaScript 库”，它使用 SVG 来实现一些令人印象深刻的数据可视化。查看更多示例:【http://mbostock.github.com/】D3/ex/。另请参阅 D3 创建者迈克·博斯托克的 D3 研讨会的 150 多张带注释的幻灯片:【http://bost.ocks.org/·迈克/ d3/workshop/ 】。它以对 D3 和 SVG 的简单介绍开始，以一些令人印象深刻的例子结束。

带高图表的图表

图 11.7。Highcharts 有很多粉丝，其灵活的、有据可查的 API 使其易于使用。

对于一个全功能的 SVG 图表库来说，很难超越 high charts(www.highcharts.com/)——一个 SVG(以及对传统 IE 支持的 VML)JavaScript 驱动的图表库。(这里他们解释了为什么使用 SVG:【http://www.highcharts.com/】组件/内容/文章/2-新闻/ 12-highcharts-goes-svg 。Highcharts 也得到了很多开发者的喜爱:【http://news.ycombinator.com/】item？id = 1847569。)

Raphael.js 支持的演示

当前现实世界中使用 SVG 的大部分工作都是通过 Raphaë完成的，正如我们前面看到的，Raphaë提供了一种简单的、跨浏览器的方法来生成基本的 SVG。

十三 23

图 11.8。thirteen23 的动画圆形导航展示了少量的 SVG 可以做什么。

thirteen 23(thirteen23.com)是得克萨斯州奥斯汀的一家设计咨询公司，它利用现代网络技术成功地设计了一个令人印象深刻的工作室网站。他们弯曲的、平滑的动画导航是使用拉斐尔字体构建的。点按四周以查看运行中的导航(并观察背景的变化)。还要注意，尽管 URL 发生了变化，但没有使用/#/模式，也没有进行完整的页面刷新。这就是 HTML5 历史 API 的作用，我们将在下一章谈到。

日产聆风

图 11.9。曾几何时，日产 Leaf 网站可能只是一个 Flash 事件，但它在这里都是本地网络技术。

日产 Leaf 网站(www.nissanusa.com/ Leaf-电动汽车/ )是一个很好的例子，展示了少量 SVG(使用 Raphaë)和许多现代 JavaScript 可以做什么。界面或风格可能不符合每个人的口味，但关键是技术和执行。我们现在可以做这种 Flash 风格的互动——不需要插件。

Markup.io

图 11.10。多亏了 Markup.io，用 SVG 在你的页面上乱涂乱画

markup . io(markup.io/)可以让你用一个简单的书签工具在任何网页上画矢量线(并添加注释)。您还可以发布和共享您的注释页面。绘图工具是由 Raphaë支持的 SVG。

DrawAStickman.com

图 11.11。面对一条喷火的龙，我的坚持者仍然保持着镇定自若的心情。

Hitcents 的DrawAStickman.com机构宣传片，用创作者的话说，是一个“互动网站，游客在这里画一个棍子人，并参与他的动画冒险”，它“一夜之间成为病毒式的成功，吸引了来自全球各地的数百万游客，并赢得了众多奖项”(www.hitcents.com/博客/帖子/making-drawastickmancom-part-1-birth-idea)。这个绝妙的创意已经有超过 2000 万次的访问，并且使用拉斐尔作为图形。

选举结果

图 11.12。SVG 对于静态、交互式矢量图形(如地图)特别有用。

在他们的 2012 年美国选举地图中，华尔街日报使用了拉斐尔:newsapps.wsj.com/选举 2010/ 。

形象化

图 11.13。纽约时报的交互式可视化是 SVG(和 Raphaë)擅长的另一个很好的例子。

《纽约时报》使用 SVG 和 Raphaë制作了一幅关于 2011 年欧洲债务危机的精彩互动图。SVG 在这类可视化方面非常出色，让 NYT 和《华尔街日报》等大公司使用它是一种认可。

使用 SVG

鉴于尖端的浏览器现在支持在<img>标签中的 SVG 文件，甚至作为 CSS 背景，很快我们将开始使用 SVG 文件作为背景渐变，标签背景(见本演示:helephant.com/ 2009/08/12/SVG-images-as-CSS-backgrounds/)，以及其他图像元素，其中单个文件可以根据需要重用和缩放。将 SVG 的灵活性与 CSS3 的多种背景结合起来，可能会出现一些有趣的可能性。例如，SVG 非常适合为媒体播放器的<video>或<audio>元素设计控件。

这不仅仅是理论上的——设计者开始认真考虑 SVG，并提供教程来帮助我们跟上速度。例如，在《告别 CSS3 渐变》中，Alex Walker 着眼于对 CSS3 渐变的零散支持；建议我们考虑将 SVG 作为一种替代方案；并为此提供了一个方便的教程:designfestival.com/ a-告别 css3-gradients/ 。

响应式网页设计和 SVG

矢量图形在响应式网页设计中也很有帮助，我们希望在从手机到桌面的任何东西上显示清晰、轻量级的界面元素(尤其是在超高分辨率的 iOS 和 Android (3.0 以上)屏幕上)。这也不是理论上的。设计师们现在正在用这个弄脏他们的手。在 Smashing 杂志 2012 年 1 月的文章“SVG 的分辨率独立性”中，David Bushell 着眼于将 SVG 用于界面元素:coding.smashingmagazine.com/ 2012/01/16/Resolution-Independence-With-SVG/。

然而，Vector UI 元素不是免费的响应午餐。虽然很容易认为它们可以毫不费力地放大和缩小(它们是向量！)，这不一定。大的艺术作品缩小到非常小的尺寸会变得模糊不清，而小的艺术作品放大后会看起来单调乏味，缺乏细节，正如这篇关于图标和 SVG 的长篇文章所展示的:www.pushing-pixels.org/ 2011/11/04/about-those-vector-icons.html。

(当然，CSS3 对渐变、圆角、变换和动画的支持可能会像第三次从生命支持中出来一样，将众所周知的枕头放在 SVG 的脸上。事实上，SVG 滤镜效果正在被移植到 CSS，并且已经进入 WebKit，正如本文所解释的:updates.html5rocks.com/ 2011/12/CSS-Filter-Effects-Landing-in-WebKit。另外，看看这些受 SVG 启发的 CSS 着色器的疯狂演示:【http://www.adobe.com/ devnet/html 5/articles/css-shaders.html。)

尽管事实上 SVG 已经存在了十多年，但是 web 设计社区并没有真正对它进行彻底的测试，看看有什么可能。因此，随着对所有 web 标准的重新关注，Flash 的衰落，响应式 web 设计的兴起，以及浏览器支持的合理基线，也许是时候再次进行实验了。

SVG Gotch

不过，有两个关键问题。首先是性能:复杂的 SVG 很慢。浏览器制造商通常不太关注 SVG 的性能，因为它一直是 web 标准的红发继子。然而，事情开始发生变化。首先，硬件加速非常有帮助，正如微软用 IE9 和 IE10 所展示的那样。(是的，微软不仅迎头赶上，而且现在在网络标准实现的某些领域处于领先地位。你告诉我。)

另一个问题是工具。没有人愿意无所事事地手工编写 SVG 标记。但是，有一些绘图工具可用，例如:

• Inkscape ，一个原生使用 SVG 的开源跨平台矢量绘图程序:【http://inkscape.org】??。
• Adobe Illustrator 支持 SVG，你可以在这里阅读更多关于将文件保存为 SVG 的内容:【http://quintaldesigns.com/】articles/SVG-files-in-Adobe-Illustrator。(Adobe 还为 Illustrator CS5 提供了 HTML5 包，扩展了其 SVG 支持:【http://labs.adobe.com/科技/ illustrator_html5/ 】。它甚至允许你指定一些元素被栅格化为画布元素，如下所述:rwillustrator.blogspot.com.au/ 2010/09/web-designers-rejoice-adobe-releases.html。还有一个为 Adobe Creative Suite的付费 SVG 工具包插件:svg.scand.com。)
• SVG-edit ，这是一个“快速的、基于网络的、Javascript 驱动的 SVG 编辑器”,它是免费和开源的，我们之前已经讨论过了。你可以在这里现场试用:【http://svg-edit.googlecode.com/】SVN/branches/2 . 5 . 1/editor/svg-editor.html，或者从code.google.com/ p/SVG-edit/下载(也可以看浏览器插件的链接)。
• 还有其他各种各样的工具列在这里:en.wikipedia.org/ wiki/Scalable _ Vector _ Graphics # Software _ and _ support _ in _ applications。

也可以使用 Raphaë或 jQuery SVG 等 JavaScript 库，用 JavaScript 绘制 SVG。然而，大多数网络矢量绘图和动画都是在 Flash IDE 中完成的。如果 Flash 可以导出 SVG 会怎么样？

Flash 为 SVG 注入了活力？

有趣的是，Adobe 最近发布了一个 Flash-to-HTML5 转换工具，该工具从 Flash FLA 文件中提取基本动画，并将其转换为 SVG、CSS3 和 JavaScript。这是一个名为 Wallaby 的实验性 FLA-to-HTML 工具，它严重依赖 SVG 和仅支持 WebKit 的 CSS3:labs.adobe.com/科技/ wallaby/ 。

当然，这并不是真正的 HTML5，但是我们会给他们一个时髦的说法——通过这个。下面是 Adobe 的约翰·纳克(【http://blogs.adobe.com/】jnack/2011/03/wallaby-flash-to-html 5-conversion-tool-now-available.html):

Adobe 的工作是帮助你解决问题，而不是纠结于一种技术对另一种技术。

数百万人在 Flash 中磨练了他们的 Web 动画技能，现在他们的客户希望内容可以在任何地方运行，包括在不支持 Flash 的设备上。因此，Adobe 发布了“Wallaby”，一个实验性的 Flash 到 HTML5 的转换工具。

Flash 导出到 SVG 可能是 Flash 推动新 web 标准采用的另一个例子。这是有道理的，这种情绪已经存在一段时间了(Jonathan Snook 在 2009 年表达了类似的希望:snook.ca/档案馆/观点/ adobe-html5-canvas )。正如约翰·纳克所说，Flash 是数百万人制作网络动画和矢量图形的地方。这是设计师让他们的(基本)Flash 动画在 iOS 上工作的一种方式，很快就会在 Metro IE10 和所有未来的 Android 4.x 设备上工作。

但是这假设从 Flash 到基本 SVG 的转换在相似性和性能方面都是可以接受的。目前这只是 Adobe 的实验性技术，所以我们不应该期望太高。但是，如果没有其他事情，当性能变得可以接受时，我们最终可能会看到针对 iOS 和 Android 设备的 SVG(或 Canvas)动画横幅广告。哦，太好了。

问题不在于 SVG 能否取代 Flash，而在于它能否开拓出自己的市场。Raphaë无疑帮助它开拓了这个市场，在接下来的几年里，我们将能够在 SVG 上做更多的事情。

在经历了 21 世纪初的“狼来了”之后，SVG 能在设计界引起足够的兴趣吗？具有讽刺意味的是，分散 web 社区对 SVG 注意力的可能不是 Flash，而是其他 web 标准。如今，围绕着 web 标准开发的活动如此之多，它已经开始了一场引人注目的战斗。SVG 是不是注定永远是伴娘，永远不是新娘？或者，那些多年前在 SVG 上写了大量书籍的人会为了一个迟来的第二版而重新开始他们的工作吗？时间会证明一切。

同时，拉斐尔很容易上手，为什么不试一试呢？看看 http://raphaeljs.com 的。*

十二、Web 应用、移动、接下来是什么

这本书主要是关于网页设计师的 HTML5。HTML5 为我们提供的是……嗯，混合的。

但是用这种印象来描述整个 HTML5 规范是不公平的。现在 HTML5 中的许多特性开始于 Web 应用程序 1.0 规范(www.whatwg.org/规范/ web-apps/ 2005-09-01/ )，并且它显示。HTML5 并不是真正为设计师而写的。相反，它更多的是为开发人员编写的。从开发的角度来看，HTML5 看起来更有趣，即使对我们这些设计师来说也是如此，我们马上就会看到。

因此，在这一章中，我们将快速浏览 HTML5 的一些重要的面向 web 应用程序的功能，在某些方面，这些功能是 HTML5 的真正核心。

不过，首先让我们快速看一下 HTML5 web 应用程序开发的(快速变化的)浏览器环境。

HTML5 Web 应用浏览器支持

尽管大肆宣传，HTML5 浏览器对 web 应用功能的支持(至少在桌面上)仍然有点令人沮丧。但我们不能把这归咎于规范。伊恩·希克森和 WHATWG 竭尽全力让 HTML5 尽可能对实现者友好，以一种前所未有的方式记录浏览器行为。

遗留的 IE 版本(尤其是 IE 8——IE for XP 的最后一个版本)在未来几年仍将伴随着我们。(IE 用户并不急于升级——参见 Ars Technica 对浏览器升级模式的分析:arstechnica.com/ web/news/2011/06/may-browser-market-share-Microsoft-And-mozillas-continuing-chrome-conundrum . Ars。IE8 正在迅速成为(谢天谢地，现在已经死了)I E6——难以摆脱的，我们集体落后的痛苦，它将像 Windows XP 一样顽固地存在。(以下是世界范围内的操作系统趋势，但请经常检查您自己的分析数据，看看哪些与您的受众相关:【http://gs.statcounter.com/ # OS-ww-monthly-2011 02-2012 02。)

但是下一个十年实际上比上一个十年要好得多。Chrome 和 Firefox 现在的发布周期是在周内。正如杰夫·阿特伍德在他的文章《无限版本》(【http://www.codinghorror.com/博客】/2011/05/the-infinite-version.html)中所说:

Chrome 是如此的流畅，以至于它已经超越了软件版本控制。

微软，不顾一切地不想落后，他们不仅尽可能快地赶上来，他们也在创新——从硬件加速的 Canvas 和 SVG，到 IE10 中适当的 CSS 布局系统。(IE10 将是第一个拥有 CSS 网格布局的浏览器——查看这里的规范:dev.w3.org/ csswg/css3-Grid-align/。)微软也在加快他们浏览器的发布速度，旨在进行年度版本更新(见:【http://www.computerworld.com/】s/article/9215766/Microsoft _ quickens _ browser _ pace _ with _ IE10 _ goes _ for _ annual _ upgrades)，并在 Windows 8 中为 Metro 风格的应用大力推广 HTML5。他们还在推动自动升级，让 Windows 用户使用他们操作系统的最新浏览器(正如 Ars Technica 在这里讨论的那样:arstechnica.com/微软/新闻/ 2011/ 12/微软-新-自动-更新-计划-可能-最终-拼写-ie6.ars 的结尾)。

与此同时，HTML5 polyfills 将不断完善和增强，以尽我们所能填补空白，直到传统 IE(和 WinXP)消亡:github.com/ Modernizr/Modernizr/wiki/html 5-跨浏览器-Polyfills 。

浏览器更新和创新与规范本身一样重要。正如伊恩·希克森所说，没有实现的规范只是虚构的。但这也引发了其他问题:当“现代”浏览器每隔几个月就更新一次时，你如何为它们开发软件？部分答案是特征检测，我们很快就会看到。

然后是手机…

移动 html 5:WebKit 及其他

如果此时此地的 HTML5 web 应用程序开发有一个可取之处，那就是移动(特别是 iOS 和 Android) web 应用程序开发。WebKit(iOS 和 Android 浏览器背后的骚娘们)对 HTML5 特性的支持是稳固的，并且一直在改进。但我们不能假设移动网络意味着 WebKit 即使它占主导地位，就像即使它占主导地位，我们也没有专门为桌面 IE 开发一样。

事实上，我们甚至不能假设“WebKit”指的是一个一致的平台。在 List Apart 2010 年 12 月的“智能手机浏览器前景”文章中，彼得-保罗·科赫写道(www.alistapart.com/文章/智能手机-浏览器-前景/ ，强调在原文中):

移动设备上没有 WebKit。我测试了九个基于移动 WebKit 的浏览器，它们的表现都不一样。不完全是这样:基线 CSS 支持很好，JavaScript 肯定是可行的。尽管如此，每一个都有它的问题和优点。

由于这种可变性，在尽可能多的基于 WebKit 的浏览器中测试您的网站非常重要。不要因为你的网站可以在 Safari 上运行，就认为它可以在基于 Android 或 BlackBerry WebKit 的浏览器上运行。

当时是这样，现在也是这样，如果不是更是这样的话。例如，谷歌有两种不同的 Android 浏览器用于 Android4.0——股票浏览器应用程序和新的 Android Chrome 浏览器(见:【http://googleblog.blogspot.com.au/ 2012/02/introducing-chrome-for-android.html)。这还没有考虑 Android 操作系统的碎片化，这本身就是一个噩梦。

即使谈论“移动”就好像它是 iOS 和 Android 的同义词也是有问题的。移动世界如此广阔——包括“智能手机”市场，其中有大量廉价、功能不足的 Android 设备和传统的 iOS 设备——一概而论是错误的。还有 Opera Mobile 和 Mini，以及 Firefox for Mobile。(事实上，有一个完整的 Mozilla 移动平台即将到来，我们将在下面讨论。)然后还有 Internet Explorer Mobile。

移动是一个移动的目标:微软的大推进

尽管目前的移动浏览器格局很复杂，但至少可以说，它也处于不断变化的状态。大玩家——嗯，特别是一个大玩家——正在大举进军这个市场，那就是微软，他们与诺基亚合作开发了 Windows Phone。

微软的 Windows Phone 7 平台于 2010 年末推出，并与我们的老朋友——我说的朋友是不共戴天的敌人——IE7(嗯，ie7.5)一起发布。令人欣慰的是，微软在 2011 年末开始推出 IE9 Mobile，作为其 Windows Phone 7.5(又名“芒果”)更新的一部分。

IE9 Mobile 与桌面版的 IE9 或多或少有些相同，它有很多好的方面——硬件加速画布就是其中之一(更多信息，请参见此处的列表，包括 CSS3 和 SVG 支持:windowsteamblog.com/ windows _ phone/b/WP dev/archive/2011/09/22/IE9-Mobile-developer-overview . aspx)。

微软已经统一了其桌面和移动浏览器代码库，鉴于他们正在全面推进 HTML5(特别是在 IE10 中)，和可以非常有效地推出移动浏览器升级(不像桌面)，我们有望在不太遥远的未来看到 IE Mobile 在 HTML5 支持方面与 WebKit 不相上下。

然而，与此同时，IE9 Mobile 是另一个例子，表明现代移动世界不仅仅是 iOS 和 Android。它还为移动 web 应用程序引入了一组新的假设，即什么可以支持，什么不可以支持。例如，没有 HTML5 应用程序缓存(即离线模式)。IE9 Mobile 缺少的东西和桌面版 IE9 缺少的东西差不多(见:people.mozilla.com/ ~ prou get/IE9/)。

我们还需要正确看待手机的使用。移动的，特别是响应性强的网页设计可能现在很热，但是如果只有 8%的用户使用智能手机访问你的网站，你需要权衡一下你如何为这 8%和其他 92%的用户花费时间。(另一方面，如果你的数字正好相反，那就发疯吧！)在 Google Analytics 中查看你的统计数据，或者(无耻的 plug ahoy！)http://itsninja.com的谷歌分析忍者，这是我为网页设计者和开发者设计的，这样你就可以在你的指尖找到相关的谷歌分析数据。

从 Boot 到 Gecko: Mozilla 雄心勃勃的移动平台和 WebAPI

当像微软这样的公司试图推出他们自己的平台时，其中一部分涉及到网络，Mozilla 一直在努力将网络本身变成一个移动平台，特别是通过它的 Boot to Gecko (B2G)项目。用他们自己的话说(hacks.mozilla.org/ 2012/02/mozillas-boot-to-gecko-the-web-is-the-platform/):

Mozilla 的 Boot to Gecko (B2G)旨在为开放网络构建一个完整的独立操作系统。它的目标是使 web 技术成为桌面和移动应用程序的首选，我们相信它可以取代专有的、单一供应商的应用程序开发堆栈。我们已经取得了一些激动人心的进展，希望与您分享！

这个雄心勃勃的项目旨在提供“HTML5”(我不严格地使用这个术语)设备，尤其是手机:

支持在开放网络上运行的 HTML5 设备，能够以功能手机的价格提供智能手机的功能。

这是“HTML5”营销术语；作为所有事物“开放网络”的同义词。它实际上是一个后 HTML5 项目，使用了 HTML5 规范中详细描述的一些功能，Mozilla 一直在他们的 WebAPI 旗帜下开发更多的功能(更多信息请参见hacks.mozilla.org/ 2011/08/introducing-WebAPI/和hacks.mozilla.org/ 2012/02/Mozilla-and-the-mobile-we b-API-evolution/)。

WebAPI 项目的目标很高，旨在填补将 web 技术用作移动平台的许多巨大空白，包括电话拨号器、SMS 功能、地址簿、摄像头访问、设备设置、游戏等 API。

这意味着你可以拥有一部完全由网络应用驱动的手机，你可以简单地通过查看源代码来了解它们是如何运行的，就像任何其他网络应用或网站一样。Mozilla 已经提供了这种手机的实际演示。例如，The Verge 在 2012 年 2 月的世界移动通信大会(www.theverge.com/ 2012/2/27/2827659/mozillas-boot-to-gecko-project-The-internet-is-your-phone-hands-on)上报道说:

Gecko 本质上是一个完全基于 web 和 HTML5 的手机操作系统。从你打开手机的那一刻起，你看到的一切都是 HTML5。甚至连拨号器都使用 Mozilla 的“电话 API”，而且它本身也是基于网络的。没有原生应用，只有一系列你见过的最令人印象深刻的书签。[…]

发送信息、拍照、玩割绳子、浏览网页，以及我们尝试的几乎所有其他事情都正常工作，即使不总是优雅的。事实上，很难相信我们使用的是一个完全基于网络的设备——我们不停地问他们是否在撒谎，而这并不是真正的 HTML5。当然，有一个简单的方法可以证明这一点:你可以在任何时候看到任何应用程序的源代码，以了解你所看到的东西背后的确切内容。

同样，这是现有的和新的(特别是 Mozilla 发明的)web 技术的最广义的“HTML5 ”,而不是 HTML5 规范本身。然而，它展示了 web 技术超越 HTML5 的不可思议的潜力，以及 web 本身作为一个平台的力量。

这也表明 web 技术的发展不仅仅是 WHATWG 和 W3C 之间的事情，正如我们在第一章中所看到的。像 Mozilla 这样的玩家有可能在他们自己的时间里(用他们自己的钱)进行大量的创新，并且(就像 Mozilla 正在做的那样)将他们的工作提交给 W3C，以确保它成为一个所有人都可以使用和实现的无专利标准。

HTML5 移动兼容性

关于 HTML5 移动兼容性的更多现状，Maximiliano Firtman 整理了一个包含 15 种移动浏览器、各种 HTML5 和相关 web 技术和 API 的优秀图表，可在此处获得:mobilehtml5.org/。

这就结束了我们的 HTML5 和移动的快速旅程，现在让我们回到 HTML5 和 web 应用程序开发。

HTML5 支持的内容管理

设计师应该对 HTML5 在桌面和移动设备上的 web 应用功能感兴趣的一个关键原因是内容管理系统。CMSs 是我们所有人在客户或公司工作中所依赖的一类网络应用(广义而言)。

例如，很高兴看到 CMSs 利用 History API 来实现快速页面加载、本地存储(可能用于自动保存表单条目)以及移动博客/内容编辑的离线功能。(我们将在下面谈到这些特性。)还有 Mozilla HTML5 图像上传器(hacks.mozilla.org/ 2010/02/an-HTML5-offline-Image-editor-Uploader-application/)，它使用了一系列 html5 技术，如离线应用程序缓存、本地存储、画布和拖放，并作为 html 5 如何增强我们(和我们的客户)每天使用的 CMS 的一个很好的指标。我们越早提出这些特性，它们就会越早实现。

JavaScript 时代

虽然我们可能会花很多时间在与 CMS 的争论中，但也值得关注大局。这些新特性最重要的主题——也可能是网络本身的未来方向——是它们都是关于 JavaScript APIs 的，本质上不是超文本。从某种意义上说，超文本现在是 JavaScript 狗摇的尾巴，特别是在 web 应用程序方面。

标记文档的问题已经解决了。在未来十年左右，我们将看到编写应用程序方面的重大改进，因为 web 应用程序的 HTML5(及相关)特性将成为基准标准。毕竟，HTML5 很大程度上是 21 世纪中期的网络应用规范。

正如迈克·德里斯科尔在“Node.js 和 JavaScript 时代”(metamarketsgroup.com/博客/node-js-and-the-JavaScript-Age/)中所言，这可能是我们进入 JavaScript 时代的(一小)部分原因:

[我们需要]将我们对服务器的看法从文档信使(HTML 时代)或模板呈现器(LAMP 时代)转变为功能和数据发送器。服务器的主要作用是向客户机发送应用程序(JavaScript)和数据(JSON)，并让客户机将它们编织成 DOM。[…]

JavaScript 时代让我们更接近这样一个网络，它不是一个全球数字图书馆，而是一个全球数字神经系统，我们才刚刚开始理解它的含义。

或者，换一种说法，由杰夫·阿特伍德在《最小权力原则》(www.codinghorror.com/博客/2007/07/the-principle-of-least-power.html)中提出:

阿特伍德定律:任何可以用 JavaScript 写的应用，最终会用 JavaScript 写。

问题是，这对不起眼的网页意味着什么？

JavaScript 扼杀了 HTML 之星

从某种意义上说，自从整个“Web 2.0”开始以来，我们一直在探索这个新的领域。因此，我们不应该对新开发的主旨与 JavaScript 相关感到惊讶。

不起眼的网页已经变得难以置信的健壮和有弹性。随着数十亿、数十亿的病毒出现，数十亿的病毒正在被制造，它们不会很快消失。但是，由于历史应用编程接口等问题，高知名度网站中效率极低的点击-整页刷新-点击-整页刷新模式可能不会存在太久，我们稍后将讨论历史应用编程接口。

我们已经在基本网页上实现了一些相当不可思议的东西。优步书呆子对复杂的功能感到兴奋(就像现在面向 web 应用的 HTML5 功能一样)，然后这些功能被抽象成一个库、插件或框架，对于设计师来说，进入他们的网站变得几乎无关紧要。

虽然这对我们来说很棒，但这确实意味着网页页面和网页应用程序之间的界限将继续模糊。一个现代网站是一个 JavaScript/AJAX/HTML5 驱动的应用来提供内容，还是一组简单的链接页面，或者介于两者之间？现在答案是“以上都有”，但是看看我们网站上的 JavaScript 在什么程度上让它更像“应用”而不是“页面”会很有趣。

例如，考虑一下通过 JavaScript 可以附加到传统网页上的功能数量。动画的 JavaScriptSVG 的 JavaScript(用 Raphaë，正如我们在第十一章看到的)；用于页面状态的 JavaScript(我们将在下面讨论)；测试你的设计的 JavaScript 新 CSS 布局引擎的 JavaScript(例如code.google.com/ p/CSS-template-layout/)；用于 CSS 预处理的 JavaScript 用于图形和游戏的 JavaScript(Canvas 和 WebGL，就像我们在第九章看到的)；音频和视频控件的 JavaScript(第十章)；甚至还有解码 mp3 的 JavaScript(【http://hacks.mozilla.org/】2011/06/js mad-a-JavaScript-MP3-decoder/，它绕过了我们在第九章讨论的专利问题，本身就相当不可思议)。

唷。

JavaScript 是所有这些功能的包装器(或使能器),有些是 HTML5，有些不是。但是，我们要走多远——如果我们真的应该这样做的话——才能推出基本的 HTML 页面，将所有其他内容抽象成一个大的 JavaScript 应用程序？如果一些 web 应用程序现在仅仅作为 JSON 数据和客户端 JavaScript 应用程序交付(正如我们上面提到的)，为什么不是 web 页面呢？

嗯，有搜索引擎优化，但情况正在迅速变化。2011 年 11 月，谷歌的马特·卡茨说，谷歌机器人已经在爬行 JavaScript/AJAX 评论系统，至少(searchengineland.com/ Google-can-now-execute-AJAX-JavaScript-for-indexing-99518)；Google 可以抓取(有问题的)hashbang(！)URL 格式；HTML5 历史 API 提供了新的可能性，我们将在下面看到。(除了 SEO 之外，像维护这样的问题是相当合理的反对意见！)

风向很明显。想想我们已经从 JavaScript 是可怕的 DHTML 和笨重的翻转脚本的代名词的时代走了多远。现在它已经成为事实上的网络编程语言。

然而，我们不应该被科技分散太多注意力。凝视水晶球很有意思，但诸如优秀的文案、出色的用户体验(尤其是当以转化率和/或参与率等硬性指标衡量时)以及设计一般让滚蛋等常青树仍将比一切都重要。有些东西永远不会过时。(当我们在最后一章讨论基于性能的设计时，我们会更多地涉及这一点。)

但在此之前，让我们快速浏览一下这些新的面向 web 应用程序的功能，以及我们如何检测它们(以及一些供进一步阅读的资源)。)

Modernizr，什么时候可以用…、和聚合填充

浏览器的发布变得非常快。正如我们之前提到的，Chrome 和 Firefox 的目标是在周内推出更新。仅仅这一点就使得试图检测哪个浏览器版本获得哪个功能变得非常困难，如果不是完全鲁莽的话。

浏览器检测从来都不是一个好主意。你仍然偶尔会遇到一些过时的网站，告诉你将你最前沿的 Chrome 或 Firefox 版本“升级”到像 Internet Explorer 7 这样的“现代”浏览器，因为这是开发者当时能够预见的所有情况。很难检测到尚不存在的浏览器。

实现现代化

相反，特性检测现在风靡一时，这就是像 Modernizr 这样的脚本所做的。他们不添加任何功能。它们只是告诉你一个给定的浏览器支持哪些功能，这样我们就可以根据需要定制我们的页面。

Modernizr 通过两种方式之一实现这一点:

1. 通过给<html>元素添加一个类名(对 CSS3 特性特别有用)，这样我们就可以为.coolfeature {}编写 CSS 或者为.no-coolfeature {}编写后备样式。
2. 通过包含每个 HTML5(和相关)特性的属性的全局 JavaScript 对象。其中那些属性评估为真或假反映了该特征是否被支持。内置的 YepNope.js 库允许有条件地加载受支持的脚本(是的，该特性是受支持的)和 polyfill(不，它不是，所以加载这个 poly fill)。

请前往:modernizr.com查看。

HTML5doctor.com 上有完整的教程:html5doctor.com/使用-modernizr-to-detect-html 5-features-and-provide-fallbacks/。

我什么时候可以使用…

这对于逐个浏览器地检测功能非常有用，但是我们如何首先知道对给定功能的支持是什么样的呢？为了了解给定功能的全球浏览器支持，我推荐亚历克西斯·德韦里亚的非常有用的caniuse.com(我在前面的章节中已经提到过)。

多填充物

不受支持的浏览器的回退功能可以通过“polyfill”脚本和黑客来实现。这里有一个优秀的、近乎详尽的可用列表:【https://github.com/】Modernizr/Modernizr/wiki/html 5-跨浏览器-Polyfills 。请记住，这些卡很少能免费获得功能；总是有兼容性和性能问题需要考虑。

html 5 web app apis

好了，让我们进入新的 HTML5(及其相关)web 应用程序功能。

(本章的浏览器统计来自caniuse.com，只追溯到 IE 5.5、火狐 2、Chrome 4、Safari 3.1、Opera 9、iOS 3.2、Opera Mini 5、Opera Mobile 10、Android 2.1。Windows Phone 7 目前的浏览器是 IE9，略有不同。为了简单起见，我省略了 Opera 的移动浏览器和 Firefox Mobile，但是要记住我们之前讨论过的广阔移动市场的快速变化。)

历史 API(推送状态)

先说 HTML5 历史 API(也称为“pushState”)。在 AJAX 时代，为了乐趣和利益，URL 被滥用到了极点。对于哈希-bang(！)方法你可能在 Twitter、脸书和 Gawker 等网站上见过。(输入twitter.com/·卢克斯特文斯实际上会返回twitter.com/ #！/卢克斯特文斯，但 Twitter 正在远离这种行为。)

一些人认为这是有史以来最糟糕的事情，而另一些人认为这是进步的代价。请看这场辩论，链接在这里:【http://danwebb.net/】2011/5/28/it ’ s-about-the-hashbangs。(这是负责撤销 Twitter 的 hashbang 网址的丹·韦伯的话，他在这里发推说:twitter.com/ #！/Dan error/status/171680703824662528。)

无论如何，历史 API 应该在某种程度上解决这个问题。使用 History API，我们仍然可以使用 AJAX(或类似技术)向页面中加载大量新内容，但是我们也可以更新用户地址栏中的 URL(和浏览器历史)，使整个过程看起来像一个非常快速的页面请求。

请注意，伪造整个向后/向前页面导航需要一些工作。你可以在这里阅读马克·皮尔格林的详细文章和教程:diveintohtml5.info/·history.html。SEOmoz 还在“使用 pushState()”创建可抓取的、链接友好的 AJAX 网站(www.seomoz.org/博客/Create-Crawlable-Link-Friendly-AJAX-Websites-Using-pushState)中介绍了历史 API。

这将是我们为客户提供的现代 CMS 的一个便利的补充(至少)。我们可以快速加载 AJAX 页面，而不会让不太懂技术的客户感到困惑，他们仍然可以看到新的 URL，并让他们的 back 按钮正常工作。

这也是我们可以考虑以渐进的方式实现的事情。截至发稿时，还没有 IE9 支持(虽然在 IE10 中有)；Chrome 支持不错；Safari 支持漏洞百出；而歌剧支持只到了 11.5+。(在移动端，iOS 4.2-4.3 支持漏洞百出，iOS5 支持稳固，Android 在 4.0 莫名其妙的掉线支持。)

但是有 history . js(github.com/·巴普顿/ History.js )，它旨在为不受支持的浏览器提供后备支持，并消除当前实现中的奇怪现象。History.js 的创建者 Benjamin Lupton 在“智能状态处理”(【https://github.com/·巴普顿 History.js 维基/智能状态处理)中讨论了处理 URL 的不同方法的利弊。

(请记住，hashbang URLs 是永久的，即使只是作为旧浏览器的后备。如果有人使用 hashbang URL 链接到您的站点，那么这个 URL 需要无限期地维护。退回到全页面加载可能是一个更好的方法。)

对于历史 API 的当前浏览器支持统计，见:caniuse.com/ #壮举=历史。

HTML5 Web 存储(和 JavaScript 渲染的 CSS)

Web 存储(也称为“本地存储”)通常被描述为“类固醇上的 cookies”，因为它可以在客户端上存储高达 5MB 的数据(键/值对)。与 cookies 不同，数据不会自动发送回服务器；而且没有明确的有效期。(网络存储最初是 HTML5 规范的一部分，但后来被分拆成自己的规范，仍由伊恩·希克森编辑:dev.w3.org/ html 5/Web Storage/。)

这种存储可以用来在本地保存 web 应用程序数据，无论是保存的游戏状态(这样用户就可以从他们离开的地方继续)，还是用户正在处理的文档。

就 web 设计而言，我们可以使用 localStorage 来保存 CSS 预处理程序的输出。在过去的几年里，CSS 预处理程序(比如 LESS 和 SASS)变得非常流行，提供了高级的 CSS 语法和特性，比如变量、混合和更好的继承。你用新的语法编写代码，软件就会输出浏览器可以理解的普通 CSS。您可以一次性输出 CSS，或者在服务器上自动输出。

你也可以用 JavaScript 和 less . js(lesscss.org/)在客户端完成。Less.js 脚本使用 Web 存储来缓存输出的 CSS，使得对 CSS 的后续请求速度极快(这里有点热情地描述:【http://fadeyev.net/】2010/06/19/less js-will-obsolete-CSS/)。

这是一个相当深远的发展。我们现在可以随时随地使用 JavaScript 生成 CSS，并将其存储在本地。至少在开发过程中，不再需要用服务器端脚本来做解析。(对于生产来说，它应该被编译成普通的 CSS，否则那些没有 JavaScript 的人也不会得到你的 CSS，正如我们在第四章中所提到的，这是一件坏事 ^TM 。)很简单，功能强大，而且马上就能工作。

(顺便说一句，我并不提倡少用任何其他风格的 CSS 预处理器。如果你决定走这条路，用任何能让你漂浮的东西。)

有关 Web 存储的更多信息，请参见:

• 马克朝圣者的章节从潜入 html 5:diveintohtml5.info/ storage.html。
• Opera 的“Web 存储:更简单、更强大的客户端数据存储”文章:dev.opera.com/文章/查看/ web-storage/ 。
• Mozilla 开发者网络的“DOM Storage”文章:developer.mozilla.org/ en/DOM/Storage。
• 这篇 Mozilla 博客文章着眼于保存表单内容的 Web 存储(以避免浏览器崩溃、标签意外关闭等情况下的数据丢失),并触及了旧浏览器的回退:hacks.mozilla.org/ 2011/04/using-client-side-Storage-today/。
• 最近也有关于本地存储利弊的辩论，来自 Mozilla 的克里斯·海尔曼宁写道“本地存储没有简单的解决方案”(hacks.mozilla.org/ 2012/03/There-is-no-simple-solution-for-local-storage/)，约翰·奥尔索普回应道“本地存储，也许没那么有害”(www.webdirections.org/博客/本地存储-也许没那么有害/ )。

目前 IE8+和所有其他现代桌面浏览器(FF 3.5+ Safari 4+，Chrome 4+，Opera 10.5+)以及移动浏览器(iOS 3.2+和 Android 2.1+)都支持 Web 存储。(对于当前的使用统计，请参见:caniuse.com/ # feat = name value-存储。)

数据库存储

对于某些类型的数据来说，网络存储听起来很棒。数据库存储客户端怎么样？

政治，就是这样。

不再维护的 Web SQL 数据库规范(www.w3.org/ TR/Web Database/)已经在一些使用 SQLite 的浏览器中实现(桌面上的 Safari、Chrome 和 Opera)，以及移动 Safari 和 Android。但微软从未实现它，Mozilla 在哲学上反对它(参见:【http://hacks.mozilla.org/】2010/06/beyond-html 5-database-API-and-the-road-to-indexed db/)。

Mozilla 现在正在火狐 4+中推进一个名为 IndexedDB 的替代品。微软已经表达了对它的兴趣(并将在 IE10 中支持它)，谷歌已经开始在 Chrome 11+中实现它。截至发稿时，还没有 Safari 或 Opera 支持，移动支持也不存在。

在 web 上出现任何广泛的、通用的客户端数据库存储还需要很长时间。但是不再维护的 Web SQL 数据库可能是以 WebKit 为中心的移动 Web 应用程序开发的一个选项。

HTML5 脱机(应用程序缓存)

HTML5 允许开发人员即使在客户端离线的情况下也能保持他们的网络应用(或网站)运行——这是移动世界中的一个常见问题，在移动世界中，失去连接只是一个隧道之遥。

怎么做？通过指定浏览器应该(和不应该)在一个清单文件中缓存哪些 URL，您可以通过使用 web 应用程序每个页面的<html>元素上的manifest属性来引用该文件。

这是那些理论上简单但实际上复杂的特性之一，超出了本书的范围。如果你想了解更多，请查看:

• HTML5 规范的 web 开发者版，其中有冗长的解释和教程:developers.whatwg.org/·offline.html。
• 马克·皮尔格林在《深入 HTML5》中的章节相当详细地介绍了这个特性，包括调试信息:diveintohtml5.info/·offline.html。
• 戴夫。Opera 得心应手的介绍:dev.opera.com/文章/查看/离线-应用程序-html5-appcache/ 。
• 鉴于开发人员目前在应用程序缓存(或“AppCache”)方面存在一些非常严重的问题，史蒂夫·索德斯(Steve Sounders)写了一篇关于如何改进应用程序缓存(或“app Cache”)的精彩文章:www.stevesouders.com/博客/2011/10/03/improving-app-Cache/。
• 来自 Mozilla 的 Atul Varma 也在“开发离线 Web 应用程序的挑战”(www.toolness.com/ WP/2011/06/The-Challenges-of-Developing-Offline-Web-Apps/)中写了一篇关于开发离线应用程序的问题的完整文章。

将这些特性结合在一起(以及我们将很快看到的地理位置 API)可以创建健壮的、移动的、HTML5 驱动的 web 应用程序。现在我们只需要等待桌面赶上来。

我说的“桌面”是指“Internet Explorer”，它在 IE9 以下版本中不支持 HTML5 的离线功能，但在 IE10 中支持。其他桌面浏览器确实支持它(FF 3.5+ Safari 4+，Chrome 4+，Opera 10.6+)，同样支持(重要的是！)iOS 3.2+和 Android 2.1+。(关于当前的使用统计，请参见:caniuse.com/ # feat =离线-应用。)

地理定位 API

网络地理定位并不新鲜。许多网站使用您的 IP 地址来确定您的位置(至少在国家一级)，以便他们可以:

• 为您提供特定地区的广告
• 将你排除在某些服务之外(任何生活在美国之外的人都非常清楚这一点！).

甚至可以在客户端加载任何谷歌 AJAX API(你可能已经用它加载 jQuery 了——见googleajaxsearchapi.blogspot.com/ 2008/08/where-is-my-current-user.html)或者在服务器端使用类似www.ip2nation.com/的东西。

好消息是你不需要许可就可以根据你用户的 IP 地址进行老式的地理定位。坏消息是它并不总是那么准确。

另一方面，新的地理位置 API 尝试使用任何可用的位置数据，包括:

• 全球（卫星）定位系统
• 无线网络(由谷歌街景记录)
• 手机信号塔位置
• IP 地址(不知道数据来自哪里)。

然后，它可以提供关于纬度、经度、高度、方向、速度，甚至精度数据(当它可用时)的细节。以前的位置甚至可以被缓存(例如，规划一次旅行)。

但是你可以忘记在没有人知道的情况下得到这些数据。设备必须请求您的许可才能使用它。

地理定位 API 本身并不是 HTML5 的一部分。(这里可以看到规格:dev.w3.org/地理/API/spec-source.html。)但它非常酷，并且为移动网站开辟了一些非常有趣的可能性。规范建议:

• 附有位置数据的博客(或状态更新)
• 在地图上显示用户的位置
• 转弯导航
• 导游 web 应用程序
• 和特定位置的天气或新闻窗口小部件。

记住:这一切都发生在浏览器中。

地理位置 API 在所有现代桌面浏览器(IE9+，Safari 5+，Firefox 3.5+，Chrome 5+，Opera 10.6+)以及 iOS 3.2+和 Android 2.1+中都得到了相对较好的支持。(关于当前的使用统计，请参见:caniuse.com/ # feat =地理位置。)

有关更多信息，请参见:

• 马克·皮尔格林的 HTML5 地理定位章节:diveintohtml5.info/·geolocation.html。
• “使用地理定位 API 的简单行程表”教程www.html5rocks.com/教程/地理定位/行程表/。
• 火狐的“位置感知浏览”用户指南www.mozilla.com/ en-US/火狐/地理定位/ 。

我完全不懂的其他 API，但您可能会感兴趣

用 Remy Sharp(介绍 HTML5，2011，第 216 页)的话说，HTML5 中及其周围的其他新 API 允许开发人员:

现在，您可以使用最简单的基于字符串的通信方法来创建多线程、多窗口、跨域、低延迟、实时的 thingymegiggies。现在去做一些很棒的东西。

这些 API 包括跨文档消息 (IE8+以上，所有现代桌面和 WebKit 移动浏览器)，允许不同域上的文档来回发送信息。对于一个站点上需要从另一个域获取数据的小部件来说，这可能很有用。这篇来自 2008 年的(有点过时的)MSDN 文章提供了对这些问题和技术的有用概述:msdn.microsoft.com/ en-us/library/cc 511311(v = vs . 85)。aspx 。

Web Workers (IE10+，Firefox 4+，Safari 4+，所有最新的 Chrome 和 Opera，有限的 mobile)提供了一个 API 来在后台并发运行脚本，而不是我们现在使用的一次一个，一切都冻结直到完成的方法。维基百科有一个有用的简要概述:【http://en.wikipedia.org/维基/网络工作者。

Web Sockets (IE10+，Firefox 6+，Chrome 14+；其他地方的混合支持主要是由于安全问题)允许浏览器和服务器之间有效的双向通信。在最基本的情况下，这对于聊天室应用程序来说非常方便。更多资源请见:【http://stackoverflow.com/提问/4262543/what-is-good-resources-for-learning-html-5-web sockets。

文件 API(IE10+，Firefox 3.6+，Safari 5.1+，Chrome 6+，Opera 11.1+，无 iOS，Android 3.0+中的实验性或部分支持)让我们读取和写入文件和目录，如这个整洁的音乐播放器所示:【http://antimatter15.github.com/播放器/player.html。这里还有一个有用的教程:【http://www.html5rocks.com/教程/文件/文件系统/。

哦，还有拖放 API (IE5+，Firefox 3.5+，Chrome 4+，Safari 3.1+，Opera 12+，无手机版)，据称，每一个接触过它的人(包括伊恩·希克森，他将它添加到规范中)，都非常可怕。(说真的，有些人真的鄙视它:【http://www.quirksmode.org/博客/档案/2009/09/the _ html 5 _ drag . html。)

拖放(DnD)是微软在 1999 年添加到 IE5 中的，其他浏览器厂商也实现了它。所以希克森逆向工程了它(ala Canvas)，记录了它，并本着记录已经工作的东西的精神把它添加到 HTML5 规范中。所以现在我们已经广泛支持拖放。(你可以在这里看到希克森对这个过程的描述:【http://ln.hixie.ch/】start = % 201115899732&count = 1。)

为什么不用 JavaScript 来拖放呢？对于页面元素，你当然可以，但是(有点脑残的)HTML5-via-1999 DnD API 的问题是，它允许你将各种内容拖放到其他应用程序中。这里有一个基础教程:【http://html5doctor.com/本地人-拖拽/。

包扎

现在你有了它——快速浏览 HTML5 的面向 web 应用的特性。正如你所看到的，HTML5 是关于引入一个本地 web 应用平台的。考虑到该规范始于 Web 应用程序 1.0 和 Web 表单 2.0，这并不奇怪。

HTML5 也只是 web 应用进化的垫脚石；尽管这是非常重要的一步，而且是一个漫长的过程。后 HTML5 开发(尤其是 Mozilla 在移动领域的开发，正如我们之前讨论的那样)正在以惊人的速度继续。它们将继续被称为 HTML5，因为正如(我相信)Mark Pilgrim 所说:

HTML5 将永远流行，因为任何流行的东西都将被称为 HTML5。

对于网络来说，这是一个激动人心的时刻。抓紧了；这将是一次地狱之旅。

十三、Web 设计的未来

我想以对未来的展望来结束这本书——不是 HTML5、CSS3 或任何特定的技术，而是我们职业的未来。(我想在itsninja.com向你推荐我即将推出的网络应用。)

让我们面对现实吧:我们是书呆子。我们热爱科技。它令人兴奋，变化迅速，站在几代人以来最大的技术和社会现象之一——网络——的最前沿是一件非常有趣的事情。

但是酷技术是达到目的的一种手段。当网页设计者和开发者气喘吁吁地宣称一个新网站是“用 HTML5 设计的”时，我会非常恼火好像这意味着什么。技术使设计成为可能，但是更多/更新的技术并不意味着更好的设计——有时恰恰相反。归根结底，网页设计非常简单。用户点击或者离开。他们要么交战，要么反弹。他们要么购买，要么放弃。实际的页面设计(和文案)决定了这种情况发生的频率。

到目前为止，很明显。但是有一点很重要:我们可以衡量用户对我们的设计做了什么。我们可以衡量他们是点击还是购买，是反弹还是退出。这可能是将我们的网页设计实践与其他任何实践区分开来的最深刻的区别。我们可以用设计史上其他学科无法做到的方式来衡量的表现。

俗话说，被衡量的东西会变得更好。以及如何:

• 37signals A/B 测试了他们高层营销网站的设计，提高了 102.5%的转化率:37signals.com/ SVN/posts/2991-幕后-ab-测试-第三部分-最终
• 转换率专家将他们的方法(他们会详细解释)应用到 SEOmoz 的登录页面上，使他们每年额外获得 100 万美元:www.conversion-rate-experts.com/ SEOmoz 案例研究/ 。
• Digital Telepathy(一家看起来真的懂的设计机构)重新设计了 CrazyEgg 营销网站，并提高了 21%的转化率:http://www.dtelepathy.com/案例研究/ crazyegg。

(这只是一个味道，这里还有很多例子:abtests.com/这里:【http://visualwebsiteoptimizer.com/】case-studies.phpT2。)

在黑暗中操作

还好我们可以衡量我们做了什么，因为现在我们是在黑暗中操作的外科医生，因为我们通常不知道我们是否帮助、伤害或不为我们的病人做任何事情。我们经营的网站忽视了设计性能——不管人们是读得更多，还是买得更多，还是跳得更少。我们不仅仅是在黑暗中操作，我们还在用一堆我们刚刚想象出来的疯狂技术做实验，我们都非常兴奋。

这是个可怕的想法。

18 世纪的医生曾经认为肮脏的手是专业的标志，而不是严重缺乏卫生设施。他们认为他们在做正确的事情。(试图告诉他们真相的伊格纳斯·塞梅尔韦斯(Ignaz Semmelweis)真的疯了。)但当他们开始观察和衡量病人身上发生的事情时，他们发现这并不是一件好事。谁知道在我们的职业中有哪些怪异的“最佳实践”可能会被证明是有害的？

性能与生产

然而，这并不完全是悲观的。衡量我们所做的事情的美妙之处在于，我们可以客观地找到任何给定设计的最佳版本。你不讨厌想出一堆很酷的设计，却让客户选了一个你最不喜欢的吗？(或者更糟的是，你相当确定的事情会损害他们的业务。)如果我们能在他们把枪对准自己脚下的时候阻止他们扣动扳机不是更好吗？

我们现在就可以做到，我们可以客观地做到，通过改变我们看待网页设计的方式。我称之为“基于性能的设计”，我认为这是继“基于标准的设计”之后网页设计的下一个篇章。).

基于标准的设计是关于我们如何实现某些设计。是生产，而且很重要。这本书的大部分内容着眼于我们如何在构建站点时改进我们的工作(例如:使用 ARIA 地标、使用新的音频/视频元素、使用一些新的表单功能、尝试 Canvas 和 SVG、实现历史 API 等。).这些是我们在生产方面的重要进展。

然而，现在是时候也是开始考虑什么对我们的用户表现最好了。也就是说，是什么对用户与我们网站的互动产生了真正的、可测量的影响。

重新设计时进行衡量

我想你已经读过这本书，因为你将推出 HTML5 网站功能，或者整个网站的重新设计，作为你日常工作的一部分。也许你也会使用更多的 CSS3。也许你一直在关注响应式网站设计的海啸，并准备推出一个热门的新的响应式网站。

如果是你，请测量发生了什么，并分享结果！

假设你启动了一个“HTML5”网站。多亏了历史 API，速度很快。SVG(或者 Canvas，或者 jQuery，或者 CSS3，或者其他什么)有一些巧妙的动画。主页上的视频现在使用 HTML5 媒体播放器。

你猜会发生什么？

跳出率会降低吗？现场时间是否有所改善？会有更多的人改变信仰或购买吗？我们可以测量所有这些东西。如果他们真的提高了，那太好了！作为一个社区，我们需要知道。我们需要关于什么对用户真正有影响，什么没有影响的数据，这样我们就可以从证据中学习，而不是从想法、猜测、希望、假设或“最佳实践”中学习。

我们有数据，我们只需要开始分享它。

响应式网站也是如此。如果你推出一个响应迅速的移动版网站，你的移动用户会怎么做？他们是否弹跳更少，停留更久，阅读更多？还是发生了相反的情况？还是什么都没有？你知道如何找到答案吗？

也可能是平板电脑网站。响应式平板电脑设计会对用户表现产生任何可测量的差异吗？如果是这样，哪种设计效果最好？更简单还是更复杂？桌面类还是移动类？

有这么多问题，你猜怎么着？我们 *已经有了答案。*他们在你的谷歌分析账户里。我们只需要把它们挖掘出来，分享我们的数据，这样我们就可以知道什么对用户真正有影响，什么没有。

实际上，我已经写了几本关于这个主题的书，以及如何将这些概念整合到你的工作流程中。它们目前还未在我的硬盘上发布，我很想知道你是否想让我把它们放出来，所以请告诉我(luke@itsninja.com 或发推特给我 @lukestevens )。

让我们客观一点

设计师(包括我自己)在重新设计时没有数据前端和中心的问题一直困扰着我，我实际上开发了一个 web 应用程序来解决这个问题。谷歌分析忍者潜入你的谷歌分析数据，并在一个简单、优雅的界面中为你弹出最相关的性能统计:itsninja.com。看看吧，我想你(和你的客户)会喜欢的。

客观地衡量设计性能需要成为我们每个项目的第一要务。它比 HTML5 或其他任何流行的技术都要大(尽管它们很有趣)。当你开始考虑可测量的性能(特别是转化率和参与度)时，你会以一种全新的方式看待网页设计和开发。

在那之前，疯狂使用 HTML5 中的新东西，测量发生了什么，并发布结果！

感谢阅读。

Luke Stevens【http://itsninja . com】
【Luke @ itsninja . com】
【http://Twitter . com/luk estevens】