有关HTML5的流言与真相

　　英文原文：HTML5: The Facts And The Myths

　　你是免不了的。每个人都在谈论HTML5。自众人开始滥用圆角和渐变效果以来，HTML5或许是最热炒的技术。然而，许多人眼中所谓的HTML5实际上只是老式的DHTML和Ajax。有关HTML5的诸多信息中鱼目混珠，因此,JavaScript专家雷米·夏普（Remy Sharp）和Opera公司的布鲁斯·劳森（Bruce Lawson）着眼这些流言，对其中的常见谬误和事实做了分类整理。

　　首先，一些事实。

　　很久很久以前，世上有一门叫做HTML的可爱语言，这门语言简单易学，用它写网站真是轻而易举。因而，所有人都用这门语言，从此，Web也从一堆物理论文的链接变成了今天我们所熟知和喜爱的模样。

　　大多数页面并不遵循这门语言的简单规则（因为写这些网页的人对内容本身要比媒介形式更为关心），因此所有浏览器都必须忽略错的代码，尽最大努力猜测作者到底是想怎样展示内容。

　　1999年，W3C决定终止HTML的制定工作，转而制定XHTML。一切都很完美，直到少数人注意到从XHTML升级到XHML2的升级工作几乎脱离实际。XML的标准要求浏览器一旦碰到错误，就停止工作。另外因为W3C正在起草一种比老式、简陋的HMTL更出色的语言，它不赞成（deprecate）使用img和a标签这类元素。

　　Opera和Mozilla开发人员不认同这种做法，并于2004年给W3C提交了一份报告，该报告称：“我们认为网页应用（Web Applications）是一个极为重要的领域，但当前技术并未为这一领域提供充分的支持。在多方制定的规范出来之前，单一厂商的解决方案存在的潜在风险在不断增大。”（译注：暗指Adobe的Flash技术？）

　　这份报告提了7条设计原则

1. 向后兼容，并有一个清晰的迁移路线（migration path）
2. 明晰（Well-defined）的错误处理机制，类似CSS（比如，忽略未知内容，继续执行），相比之下XML错误处理机制过于“苛刻”。
3. 编程错误不应直接暴露给终端用户。
4. 实用性：所有最终进入网页应用技术规范的性特性都必须有实际的应用案例支撑。但反之则不成立：即所有类似的应用案例并不必然会将新特性加入到技术规范中。
5. 脚本支持已经已得到公认（但是当有更方便的标签可满足需求时，应避免使用脚本。）（译者：类似表单输入数据验证。）
6. 避免针对特定设备的规范。
7. 制定过程必须开放。（网络本身从开放式发展中受益颇多。邮件列表，存档，规范草稿应一直对公众开放。）

　　该报告遭W3C的拒绝，因此Opera和Mozilla以及后来的苹果继续维护着一个叫做网络超文本应用程序技术工作组（Web Hypertext Application Technology Working Group，简称WHATWG）的邮件列表（Mail list），继续制定他们用以验证概念（ proof-of-concept）的规范内容。这份规范对HTML4表单规范进行了扩充，在伊恩·希克森（Ian Hickson）的不断校订中，这份规范最终成为一份名叫网页应用程序1.0（Web Applications 1.0）的规范。后来伊恩·希克森离开Opera，加入Google。

　　在2006年，W3C终于意识到自己的错误，决定重新启用HTML，向WHATWG索要它的规范，并将其作为HTML5规范的基础。

　　上面这些是史事资料。现在我们来看看一些流传甚广的流言。

　　流言

　　“在2012（或2022）年之前，俺是用不上HTML5的了。”

　　这一流言是从HTML5进入到W3C流程的候选推荐阶段（Candidate Recommendation，简称REC）的项目日期所误传开来的。官方Wiki上写道：

如今一个规范要成为候选推荐标准（REC），它需要具备百分之百的可实施性（interoperable implementations），只有成功通过上万项的测试案例（Test Case）后才能验证这点（据保守估计，整个规范可能需要进行2万项测试）。当你在心里默算写这些测试案例需要多少时间，实施每个新特性又需要多少时间时，你就会明白HTML5规范制定的时间跨度为什么这么长了。

　　因此，按此说法，在你能在两大浏览器中用上所有的功能之前，HTML5的规范是没有最终定稿的。

　　当然，真正重要的一小部分HTML5的特性已得到浏览器的支持，任何浏览器的支持情况汇总表单都会在一周之内过时，因为浏览器制作厂商的创新速度非常之快。另外，许多HTML5的新特性也通过JavaScript脚本在不支持HTML5的老浏览器中得以重现。Canvas属性在所有新浏览器中得到支持，其中包括IE9，另外在老的IE浏览器中，通过excanvas库，我们也可以模拟Canvas的特性。而音频和视频标签效果，我们则可以通过Flash在旧的浏览器中实现。

　　HTML5在设计上就可以优雅降级，因此运用一些JavaScript代码和创意，HTML5的所有功能都可以在老浏览器上实现。

　　“俺的浏览器支持HTML5，你的不支持。”

　　这一流言认定HTML5是一个整体不可分割的标准。但实际上不是。正如前文所说，HTML5是一组新特性的组合。因此，短期来讲，你不能说一个浏览器支持了HTML5的所有内容。而当浏览器能做到这点时，浏览器本身已经无关紧要了，因为那时我们将被新一代的HTML语言所震撼。

　　感觉HTML5乱的一塌糊涂，是吧？看看CSS2.1，这么多年了它都是一个尚未最终完成的标准，但是我们每个人无时不在用它。我们用CSS3轻松添加圆角，这点很快就会得到所有浏览器的支持，虽然CSS3的其他特性尚未得到所有浏览器的支持。

　　要提防那些浏览器“评分”网站。这些网站测试的内容经常与HTML5无关，比如CSS，SVG，甚至是网页字体（web fonts）。你手头需要完成的工作才是要紧的，你客户受众浏览器所支持的技术才是用得上的技术。

　　HTML5实际上正式认可了一些常见的书写错误（Tag Soup）

　　HTML5在语法方面要比XHTML松散很多：比如，你可以用纯大写或小写字母书写标签，甚至大小写混用也无妨。你无需对img这类的标签做自封闭处理（self-close），因此下面这两种写法都是合法的：

　　<img src=”nice.jpg”/>

　　<img src=”nice.jpg”>

　　标签属性也无需用双引号括起来，因此下面这两种写法都是合法的：

　　<img src=”nice.jpg”>

　　<img src=nice.jpg>

　　使用大写或小写（甚至混用）字母都可以，所以下面三种写法也都是合法的:

　　<IMG SRC=nice.jpg>

　　<img src=nice.jpg>

　　<iMg SrC=nice.jpg>

　　这与HTML4毫无差异，但是如果你用习惯了XHTML，你碰到这种写法时还是会很震惊的。现实中，如果你使用HTML和文本内容书写页面，而非使用XML（你极有可能是混用文本和HTML书写页面的，因为IE8并不能真正的渲染XHTML页面），那么上述细微差别也无关紧要：浏览器会忽略尾部的斜杠，双引号，以及大小写。

　　HTML5语法看似松散，但实际的解析规则要严格的多。因而HTML5中，常见的书写错误（Tag Soul）将不复存在;HTML5的规范对这些无效标记做精确的描述和定义，因此所有遵循规范的浏览器都会生成同样的文档对象模型（DOM）。如果你曾写过JavaScript来遍历DOM，那么你就会对DOM不一致所带的恐怖经历有所体会。

　　但这种修正不应导致无效代码泛滥。HTML5为你创建的DOM可能并不是你想要的那个，因此对书写的HTML5代码进行验证仍然至关重要。随着新特性的大量涌入，对细小语法错误的忽视会让你的脚本失效，或是CSS样式出错，这也是我们为什么需要HTML5验证器的原因之所在。

　　HTML5远不仅仅只是让一些常见的书写错误合法化，而且让这些常见错误（Tag soup）成为历史。赞！

　　“我需要把我的网站从XHTML转换HTML5。”

　　HTML5对松散语法的包容性是敲响了XHTML的丧钟吗？制定XHTML2规范的工作组已经解散，对吧。

　　没错，XHTML2的工作组在2009年年末的时候解散了。他们起草的这个规范是用来与HTML5竞争的，但尚未得到执行实施，然而，同时保留两队人马是对W3C组织资源的一种浪费。另外XHTML1已经是一个业已完成的规范，得到所有浏览器的广泛支持，并在必须的时限内仍将得到所有浏览器的支持。因此你用XHTML书写的网站也将免受折腾之苦。

　　HTML5将会干掉XML

　　根本不会，如果你需要使用XML，而不是HTML，你可以选用XHTML5，它几乎包含所有HTML5的优点，只是要必须遵循严格XHTML语法（比如，要标签属性中的双引号不能省，自封闭元素的末尾斜杠不可省，必须用小写字母书写标签等等诸如此类。）

　　现实情况是XHTML5并不完全包含所有HTML5的特性。譬如<noscript> 就失效了。但你想想，这古董玩意儿还有人在用吗？

　　HTML5会干掉Flash和插件

　　<canvas> 标签可以让脚本根据键盘输入操纵图像实现动画效果，因此在一些简单的应用场景下可以与Adoble Flash竞争。HTML5还有对Video和Audio播放的原生支持。

　　正因为CSS Web字体尚未得到广泛支持，以Flash为基础的sIFR技术将会填补这一空白，Flash也因逆向兼容HTML5视频内容而挽救局面。因为HTML5设计时“照顾”了老浏览器，Video标签之间的其他标记将会被支持HTML5的浏览器所忽视，因此可以用老式的<object>或<embed> 标签，用Flash嵌入所有浏览器支持的视频内容，克罗克·卡门（ Kroc Camen）在他的《全兼容的视频》一文中就倡导这种做法。（见下面截图。）

　　但也并是不所的应用场合都是可以用HTML5取代Flash的。比如HTML5中就没办法进行数字版权的管理。Opera，Firefox和Chrome这类浏览器允许简单的右键点几下就将视频保存的本地电脑上。如果你不想用户保存视频文件，你就需要使用插件。另外捕捉麦克风或是摄像头的信号就只能通过Flash实现。（不过<device> 元素已经出现到HTML5以后的规范中），因此如果你想写一个可以终结聊天轮盘（Chatroulette）网站的东西来，那么HTML5并不适合你。

　　HTML5在可访问性（Accessibility）方面做得比较差

　　关于HTML5的讨论中有不少是唠叨HTML5可访问性的。这点很好，应该欢迎：因为网络的基础语言已经做了太多了的改变，因此确保网页对于那些残障人士的易访问性极其重要。另外，更为重要的是在技术方案的制定过程中就将其考量进入，而非事后修补。毕竟大多数开发人员甚至没有为图片标签添加Alt属性，所以提供现成可用的易访问性（accessibility）相比人们手动添加更容易成功。

　　这也是为什么HTML5添加了类似滑块（<input type=range>，目前仅Opera和Webkit内核的浏览器支持）原生控件和日期选定控件（<input type=date>，仅Opera支持）——因为之前，我们只能用JavaScript和图片来模拟，并添加键盘支持和WAI-ARIA的Role属性。

　　而Canvas标签则又是另一番情况，该标签原本是苹果独创的，后遭其他浏览器厂商的逆向工程破解，继而被吸纳为HTML5规范的一部分，因此Canvas技术本身在可访问性方面并未做考量。如果你只是用它制作一些视觉美化，那问题不大，你大可把它看成图片，只是不能添加ALt属性来指定替换的文本内容（已有人建议在规范中作此增添，但目前尚未得到实施）。因此，确保Canvas之中的信息在页面的其他地方有替代信息，从而增强页面的可访问性。

　　Canvas中的文本变成了像素，如图片中的文本。因此，辅助技术和屏幕阅读器来可以读出其中的信息。可考虑用W3C的可缩放适量图像标准（SVG）替代，尤其对于动态图像和文本内容来说。SVG目前得到了主流浏览器的支持，其中包括IE9（IE8及以下的浏览器不支持，不过SVGWeb库通过Flash技术可以在老式浏览器中模仿SVG。）

　　<video> 和<audio>标签也很有前途。尽管这两个标签的规范尚未完全确定（而且许多浏览器还不支持）。HTML5已经添加了一个新的<track> 的标签，可以包含带时间轴的文本（歌词和外文媒体的字幕），你可以在视频下面用JavaScript来添加时间轴字幕，并与视频内容同步。

　　“当我第一次用HTML5的时候，HTML5的大师会助我一臂之力”

　　如果是真的那该多好。不过保罗·艾瑞士（Paul Irish）和迪维亚·梅丽亚（ Divya Manian）打造的HTML5模板文件对你来说就足以很好。模板文件包含一系列的文件，你可以作为模板用在你的项目中。模板文件包含了你所必须的JavaScript，方便在IE中添加新元素；它从Google的CDN上引用jQuery，另外如果Google服务器出问题了，还可降级引用你自己服务器上的JS库。

　　它也添加了适用iOS，Android和Opera手机版的标签，并用一个易于理解的CSS reset文件搭建了一个基本的CSS骨架。它甚至还一个.htaccess文件，以便为HTML5视频提供正确的MIME类型。如果你不需要全部的内容，你可删除对你项目无用的内容，精简文件。

　　深入阅读材料

　　HTML5的话题很宽泛。下面是是我们手工挑选的几个链接。披露提醒（Disclosure）：本文的作者参与了下面的一些项目。

• W3C规范：HTML5

  写网站的同学都应该看看的资料。

• HTML5的演示例子

  HTML5 API在浏览器中的实际效果示范例子

• HTML5 Doctor

  这个博客上都是些短小精悍的文章，“帮你马上运用HTML5技术”

• html5-shims

  上面会分享一些脚本，教你如何在浏览器中模仿再现HTML5的功能特性。

　　英文原文：HTML5: The Facts And The Myths