HTML5 的真相（一）

原文：The Truth About HTML5

协议：CC BY-NC-SA 4.0

零、简介

你好。我是卢克，普通的网页设计师。十多年来，我一直在建立网站，使用 ExpressionEngine 作为我的 CMS，并且享受内部工作和全职自由职业。

我觉得写一本关于 HTML5 的小书会很有趣。我以为 HTML5 会很简单。我以为写出来会很简单。我认为设计社区中受人尊敬的声音会简单明了地告诉每个人它是什么(不是什么)，尤其是在有太多其他 HTML5 书籍的情况下。

我错了。

幸运的是，这本书(也希望你作为读者的经验！)对它来说是无限美好的。我希望一旦你读了它，你会分享我对基本标记所采取的奇怪方向的关注，和我对新的 HTML5(和相关的)技术的兴奋，这些技术很快就会出现在你附近的浏览器中。这包括 Internet Explorer 10——微软终于真正获得了网络标准。

仅仅几年前看似不可能的事情——包括微软在内的所有浏览器厂商竭尽全力支持尖端网络标准的遥不可及、近乎乌托邦式的理想——现在已经成为现实。web 标准的创新正在以惊人的速度发生，我希望这本书不仅能让你了解 HTML5 的基础知识，还能让你了解 web 作为一个整体的发展方向，尤其是在我们展望后 Flash 未来的时候。

当你阅读下面的章节时，请记住这本书既是对 HTML5 的解释，也是对它的评论。通过批判性地审视为什么事情是这样的，我希望你不必担心无关紧要的事情(特别是当涉及到基本标记时)，从而节省时间，并且你的眼睛睁开了，知道 HTML5 香肠是如何制作的。这可能并不总是美好的，但是如果你花时间在构建网站的战壕里，了解为什么事情是这样的将会以一种非常直接的方式帮助指导你的设计和开发决策。

也就是说，HTML5 中也有很多令人兴奋的技术，所以一定不要错过后面关于 Canvas 和 SVG 等图形技术的章节；HTML5 中音频和视频的状态；以及更面向开发人员的 HTML5 特性，包括一种处理像页面请求这样的基本问题的新方法。

(另请注意，我们将几乎完全专注于 HTML5 规范所定义的 HTML5，增加了 SVG，以及一些其他相关的倡议，如 Schema.org 和 WebGL。“HTML5”已经成为一个时髦的词，它可以表示从 HTML5 规范本身到 CSS3 和现代 JavaScript 的一切，只是“酷和新，而不是 Flash”。我们将主要坚持实际 HTML5 规范中的特性。)

我喜欢网页设计社区，因为那里充满了聪明、兴奋、好奇、固执己见的人，他们会在你的博客上给你打电话。这是一本固执己见的书，不是对技术的干巴巴的解释，我会非常强烈地陈述我的观点。我期待你也这样做。充满激情、深思熟虑的辩论让我们变得更聪明。所以，请把它写在你的博客上，给我发快乐/悲伤/愤怒的电子邮件(luke@itsninja.com)，在推特上和我聊天(@卢克斯特文斯)，或者你喜欢的任何事情。

我期待着讨论。

现在我想请你帮几个忙。

首先，如果你喜欢我的文章，那么请告诉你的朋友、同事、推特粉丝、博客读者，以及几乎所有想听这本书的人。像许多作者一样，我完全依赖像你这样的读者来传播信息(和链接)。如果你能帮我通过传统的口口相传来传播这本书，我会非常感激。谢谢你。

第二，如果你使用谷歌分析(谁没有呢？)并想从中获得更多，我希望你能在 http://itsninja.com 查看我的谷歌分析网络应用 Ninja。谷歌分析是一个庞大而复杂的怪兽，但它拥有关于你的网站实际表现的最佳数据，它只是被埋得很深很深。Ninja for GA 通过一个简单、优雅的界面将数据呈现出来。这是针对网页设计师的网页分析，我想你(和你的客户)会喜欢的。我希望它能让你自己的设计实践(和你客户的网站)更有成效和利润。毕竟，如果你的转换率很低，跳出率很高，世界上所有的 HTML5 都帮不了你。(我们将在本书的最后一章讨论基于性能的设计时回到这个主题。)来看看:【http://itsninja.com】??。

一、架构宇航员和 W3C 如何试图扼杀 HTML

谋杀总是有趣的，所以让我们从那里开始。

1997 年，W3C 发布了 HTML 4.0 的推荐标准。两年后，它差不多以 HTML 4.01 的形式完成了。(不记得了？嗯，你可能正忙着担心可怕的千年虫会毁灭文明。)

对于普通的 HTML 来说，差不多就是这样了。

那么从 1999 年 HTML“终结”(从各种意义上来说)到今天 HTML5 的出现之间发生了什么呢？

向“XMListan”的漫长而失败的进军。

W3C 在 1996 年发布了可扩展标记语言(XML) 1.0 规范(www.w3.org/ TR/1998/REC-XML-1998 02 10)，他们希望这将成为一种更灵活、机器可读、更严格和更可扩展的标记文档和其他数据的方式。它很快就被用来做这件事。但是 W3C 相信网络本身最终会转向 XML。

朝这个方向迈出的第一步是 XHTML——HTML 4 的 XML 格式。

您可能会使用 XML

XML 可能听起来很陌生，但是如果你拥有或者订阅了一个博客，那么你已经在使用它了。博客生成的聚合内容的 RSS 或 Atom 提要只是 XML 的一种形式。如果您查看 Atom 提要的源，您可以看到诸如<author>、<published>、<category>和<summary>这样的标签。这些是*特有的标签，准确地描述了它们所代表的内容。*这只是 XML“可扩展”部分的一个例子，它允许机器(解析器、RSS 阅读器等等)对内容做有趣的事情。

现在，想象一个我们可以用相似的方式描述网页的世界。这就是 W3C 对网络的计划——所有未来网络上的内容都应该用比“??”、“??”、“??”和“??”更准确的术语来描述。有了 XML，我们可以做到这一点。

HTML 仍将作为传统格式存在。但是未来是 XML，宝贝。

XHTML 诞生了，但这意味着什么？

那么，如果 HTML 是过去，XML 是未来，我们该如何实现呢？有了 XHTML 的中间步骤。

通过重新制定 HTML 4.0 以遵守 XML 的规则，XHTML 诞生了。在 2000 年 1 月，勉强躲过了 Y2K 的灾难，XHTML 1.0 规范被采纳为 W3C 的推荐标准(www.w3.org/ TR/XHTML 1/)。我们在去 XMListan 的路上。

在 2002 年初，Jeffrey Zeldman 发表了一篇具有里程碑意义的 XHTML 文章“通过 XHTML 让生活更美好”(http://www.alistapart.com/文章/ betterliving/ )，将 XHTML 描述为:

web 文档的标准标记语言，是 HTML 4 的后继者。这种混合语言是经典(HTML)和前沿(XML)的混合，看起来和工作起来都很像 HTML，但它是基于 XML 的，XML 是 web 的“超级”标记语言，它给网页带来了 XML 的许多好处，正如纽约公共图书馆分馆的在线风格指南所列举的那样。

纽约公共图书馆网站(legacy.www.nypl.org/风格指南/XHTML/benefits.html)列举的这些好处包括:

web 正在转向 XML，这是一种强有力的支持技术。编写格式良好、有效的 XHTML 页面是开始这种转变的最简单的方法。只需要学习一些简单的 XHTML 标记规则。

Web 设计者注意到了这一号召，开始通过 XHTML 向 XML 过渡。2003 年，戴夫·谢伊(Dave Shea)写了一篇名为《语义和糟糕的代码》(http://www.mezzoblue.com/档案/ 2003/ 08/ 26/ semantics_an/ )的文章，他说:

从 HTML 到 XML 的转变需要开发人员思维方式的巨大转变。还有许多障碍需要克服，尤其是对浏览器的支持。我们才刚刚开始，XHTML 是我们到达目的地的途径。

谢伊的观点在当时很流行，考虑到我们对 W3C 专家的信任，这个观点当然是合理的。

但我们从未去过圣诞节。汽车没油了，轮子掉了，引擎在大约两个街区外爆炸了。

严厉的错误处理，或者我为什么不直接揍你的脸？

那些在 21 世纪早期建立网站的人可能还记得拥有一个有效的网页有多重要。人们甚至在自己的网站上贴上小小的“有效 XHTML”徽章，以显示他们有多么超前。(他们现在把同样愚蠢的 HTML5 徽章放在博客和书籍上。)设计呆子甚至会通过 HTML 验证器运行其他人的标记，如果失败了，就写一篇尖刻的博文或电子邮件。(那时候没有推特可以公开指责 140 个字符。)

是的，拥有有效的 HTML 是一件好事。但是当网页设计者采用 XHTML 时，它就变成了——理论上，如果不是实践的话——生死攸关。如果你的 XHTML 中有一个错误，你的浏览器就会伸出手来一拳打在你的脸上。

好吧，不是真的。但是我们可以打你的脸

如果你设置你的服务器告诉浏览器采用 XML 的严格的 XHTML 解析规则(正如马克·皮尔格林在 2003 年所描述的:www.xml.com/出版社/2003/03/19/dive-into-xml.html)，这是很难做到的。Internet Explorer 直到版本 8 都不支持这些严格的 XHTML 解析规则。(讽刺的是，IE9 现在有了，就在大家都不再关心的时候。)

为什么没人做？因为他们不想将“严酷的错误处理”强加给他们的用户(或他们自己)。这真的很苛刻——一个无效字符，比如“&”而不是“&”，会产生致命错误，破坏整个页面。作为用户，你得到的只是一个可怕的错误消息——没有内容，什么都没有。

有鉴于此，web 标准社区采用了 XHTML 的理论,而没有其严酷的现实(或真正的 XML 本质),更喜欢坚持早期温暖、可爱和非常宽容的 HTML 解析。

XHTML 原来是朝着婴儿的一步迈出的一小步。我们可以使用更具描述性(即语义性)的标签，这应该是迈向严格的 XML 格式的第一步，但这只是迈向更严格的旧式 HTML 的一步。这是向前两步，向后一步——回到 W3C 已经宣布完成并希望淘汰的 HTML。

XHTML 仍然意味着更好的 HTML

尽管如此，XHTML 还是给了 web 标准社区一些标准化的东西。它让每个人对我们所写的标记更加严肃，我敢说是专业的。正如 Jeffrey Zeldman 2009 年在他的博客上写的那样(【http://www.zeldman.com/2009/】07/07/为网络开发者辩护/ ):

XHTML 在 2000 年的引入，以及它对构造规则的强调，给了像我这样的 web 标准传播者一个平台，可以在这个平台上钩住语义标记程序，取代当时臃肿而不可持续的标签汤。网络在这方面做得更好，而且永远会更好，还有很多事情要做，因为许多创建网站的人仍然没有听到这一号召。

在 21 世纪的大部分时间里，用网络标准构建的网站继续使用 XHTML。设计师们开始认真考虑将表示与内容分开，并试图编写更多的语义标记。使用 XHTML 也触发了当时主流浏览器的标准模式。都是好事。

但是在 W3C 更宏大的计划中，XHTML 最终被证明是一块没有前途的垫脚石。

但是疯狂才刚刚开始

XHTML 为 web 标准提供了一个有用的目的——尽管这不是最初的目的。但是现在我们步入了 XHTML 2.0 的疯狂世界。

当我们在 web 标准领域愉快地使用和提倡 XHTML 时(尽管有些人坚持使用 HTML 4.0)，W3C 正在研究 XHTML 2.0。听起来像是 1.0 规范的无害更新，对吗？

不是的。

XHTML 2.0 对于 web 来说是第一天。它不能向后兼容 HTML，甚至 XHTML 1.0。这是一个全新的开始。

没有什么是安全的。

在众多变化中，普通的旧表单将被花哨的 XML 风格的 XForms 所取代。随着 W3C 将 web 重新设想为一个更加 XML 化的地方，甚至<img>元素也在砧板上。

在 2011 年 4 月一篇关于软件开发的博客文章中，Joel Spolsky 描述了他所谓的“架构宇航员”(www.joelonsoftware.com/文章/fog0000000018.html):

当你在抽象层面走得太远时，你会缺氧。有时候聪明的思想家就是不知道什么时候停下来，他们创造了这些荒谬的、包罗万象的、高层次的宇宙图景，这些图景都是美好的，但实际上根本没有任何意义。

这些人我称之为架构宇航员。

XHTML 2.0 是架构宇航员工作的经典案例。

Opera 的 HTML5 倡导者、《HTML5 简介》(New Riders，2010)的作者布鲁斯·劳森是这样描述的(news.cnet.com/ 8301-17939 _ 109-10281477-2 . html):

XHTML 2 是哲学纯粹性的美丽规范，与现实世界完全没有相似之处。

就 HTML 而言，这是 W3C 从 2002 年到 2006 年在 8 个草案中所做的工作，W3C 是这种语言的守护者，这种语言在 21 世纪支撑着我们的关系、商业和政府。这不仅会破坏向后兼容性，还会使 web 标准社区中所有关于“向前兼容性”和“面向未来”的言论化为乌有。(可以在维基百科了解更多关于 XHTML 2.0 的内容:en.wikipedia.org/ wiki/XHTML # XHTML _ 2.0。)

XHTML 2.0:无人爱且孤独

当 W3C 在 XHTML 2.0 上辛苦工作时，web 作者、标准倡导者和浏览器供应商是怎么想的呢？

不多。

没有人对实现它感兴趣。甚至工作组成员也对此深感不满。(见 Jeffrey Zeldman 2003 年关于 XHTML 2.0 的想法，在“XHTML 2 和所有那些”下面:www.zeldman.com/日报/ 0103b.shtml 。)

XHTML 2.0 的愚蠢之处并不在于规范本身(如果我们能够回到过去，从头开始重建 web，那就好了)。这是一个想法，你可以做一些革命性的事情，比如打破与数百万现有文档的向后兼容性，为网络创造一个全新的层次。但那是 W3C 早在 1998 年就为自己设定的道路(见“塑造 HTML 的未来”www.w3.org/标记/未来/ )。

但是如果 HTML 的下一次进化仅仅是进化，而不是革命性的，会怎么样呢？一个建立在现实世界上的世界，而不是我们只能希望的乌托邦世界？

HTML5:新的希望…我们希望

HTML5 最初是对 W3C 陷入疯狂标记的反应。W3C 方向的问题并没有被忽视。

2004 年，所谓的“Web 2.0”运动大规模展开，web 应用成为一件大事。网络不再仅仅是通过链接连接起来的网页上的文本和图像的集合。它正在成为一个可以在任何地方运行的应用程序平台。

与 80 年代和 90 年代相比，当你的操作系统决定你可以使用什么样的应用程序时，在任何操作系统上通过浏览器运行应用程序是一个革命性的想法。

没有人真正预测到这一点(当然不是 W3C)，当你想到我们在预测未来方面有多糟糕时，这并不奇怪。(其中是我的飞行汽车？)当未来到来时，我们在反应和发展方面要好得多，这是一些人建议我们对 HTML 所做的。

2004 年，代表 Opera 和 Mozilla 的成员(苹果“在一旁欢呼”，伊恩·希克森回忆道:www.webstandards.org/ 2009/05/13/interview-with-Ian-hickson-editor-of-the-html-5-specification/)提出了 W3C 的替代方案——一个专注于 web 应用的规范。(见“立场文件”原文此处:【http://www.w3.org/】2004/04/web apps-CDF-ws/papers/opera.html。)

W3C 说去死吧

HTML 需要适应网络应用程序的未来，而不是一个完美标记的 XML 化网页的乌托邦世界。因此，这个新的小组提出了一个基于向后兼容性的 HTML 的替代方向。不再有苛刻的错误处理(XHTML 作为 XML 的一个错误就致命的问题)。web 应用程序的新特性。和开放的过程，这与 W3C 的运作方式形成了鲜明的对比。

本质上，他们的哲学是 HTML 已经存在，所以我们应该集中精力发展它。(这在现在听起来可能非常明显，但当时 W3C 并不认同这一观点。)

不管怎样，这个组织向 W3C 提出了他们的想法，W3C 告诉他们去死吧。(实际上，他们只输了两票——11 票对 8 票。但是这个是html 5 的有点耸人听闻的历史。)

由于 W3C 不够通融，那些对开发 HTML 和为 web 应用程序添加特性感兴趣的人，以及那些得到浏览器供应商支持(并为其工作)的人，决定继续前进，并在 W3C 之外工作。他们成立了网络超文本应用技术工作组(WHATWG)，并于 2004 年 6 月在 whatwg.org 成立了公司。

WHATWG 诞生了

于是 WHATWG 诞生了。以下是希克森对这一切的解释(www.thechromesource.com/访谈-html 5-标准-作者-伊恩-希克森/ ):

所以[在 W3C 拒绝后],我们开放了一个名为 WHATWG 的邮件列表，以继续在公共场合进行 Web Forms 2.0 的工作，并在当年晚些时候开始了一个名为 Web Applications 1.0 的新草案，我们在其中加入了许多旨在编写 Web 应用程序的功能，包括一个我们戏称为 HTML5 的新版本 HTML，以及一系列后来成为 Web 存储、Web 套接字、服务器发送事件和各种其他规范的其他功能。[…]

后来，大约在 2006 年或 2007 年，W3C 基本上意识到他们犯了一个错误，他们问他们是否也可以在 HTML5 上工作，所以我们将 Web 应用 1.0 重命名为 HTML5，WHATWG 和 W3C 开始合作。Web Forms 2.0 被合并到 HTML5 中，而 HTML5 中大多数不属于 HTML 的部分被分割成单独的规范。

很讽刺吧？当权派(W3C)是乌托邦式的革命者，而反叛的局外人(WHATWG)则在为渐进的保守主义而战。去想想。

这是一个全新的世界

这里有几点不值一提:

• W3C 在维护 HTML 方面非常失败(当你想到这一点时，这有点可怕)。
• 网络标准极其随意。“HTML5”过去和现在都没有统一的愿景。它只是一堆单独的规范捆绑在一起，并被命名为“HTML5”，这些规范只是对 W3C 失败的反应。
• 像十年前让许多人兴奋不已的向 web XML 进军这样的大胆想法可能会逐渐消失。我们应该从中吸取教训，并对大而大胆的想法保持一定的怀疑态度——包括 HTML5 中的一些变化。
• 权力的天平现在落在了浏览器厂商的一边。

事实上，权力的天平总是倾向于浏览器厂商。如果他们不实现某事，根据定义它是一个不成功的开始。正如 http://www.webstandards.org/希克森所说(2009/05/13/interview-with-Ian-hicks on-editor-of-the-html-5-specification/):

现实是，浏览器供应商对规范中的一切都有最终的否决权，因为如果他们不实现它，规范就只是一个虚构的作品。所以它们有很大的影响力——我不想写小说，我想写一个规范，记录浏览器的实际行为。

我不知道这是否过分。重力对地球上的物体影响太大吗？事情就是这样。

然而，一个独立的标准机构——我们的独立标准机构——悲惨地失败了，这个事实非常令人担忧。

到 HTML5 甚至更远！

长话短说，WHATWG 继续致力于他们自己的 HTML 发展愿景——HTML 发展的唯一愿景。2006 年，万维网之父、W3C 主任蒂姆·伯纳斯·李(点击此处了解更多信息:en.wikipedia.org/·维基/蒂姆·伯纳斯·李)忍气吞声，宣布 W3C 将与 WHATWG 合作，他说(dig.csail.mit.edu/面包屑/ node/ 166 ):

让世界转向 XML 的尝试，包括属性值的引号和空标签和名称空间中的斜杠，都没有成功。

Berners-Lee 说“一蹴而就”，为转向 XML 敞开了大门。但实际上，这看起来很像“让世界转向 XML 的尝试”…没起作用。”

这很好。我们需要伟大的想法和大胆的方向去尝试和努力，如果它们没有成功，那就顺其自然吧。有时候好主意就是不会出现。

由于 WHATWG 势头强劲(并得到了浏览器厂商的支持)，W3C 别无选择，只能与他们合作开发 HTML5。2007 年，W3C 成立了一个小组，与 WHATWG 合作开发 HTML5。2008 年 1 月，W3C 发布了他们的第一份 HTML5 工作草案(www.w3.org/ TR/2008/WD-html 5-2008 01 22/)，采纳了 WHATWG 已经做了好几年的工作。

HTML5 是新的黑色或性感什么的吗

到 2000 年代末，网络技术再次令人兴奋，在多年的停滞和死胡同之后，我们终于到达了一个创新放松的点。(这是一个可怕的形象——抱歉。)

现在是 10 年代初，情况看起来更好。事实上，网络技术正在发生名副其实的寒武纪大爆发。谷歌、Mozilla、苹果和微软都在竞相打造最好的符合标准的浏览器(新版本层出不穷)。周围有一大堆新的有趣的技术。web 开发人员、设计师、软件公司和应用程序开发人员都对 HTML5 及其相关的新技术感兴趣。

想想浏览器制造商——包括微软——现在正试图用他们的网络标准支持在竞争中甚至在市场上击败对方，这是非常不可思议的。就在不久前(90 年代末)，我们还面临着他们都以自己的非标准方式发展的威胁。向所有参与者致敬。

HTML5 是炒作，是实质，还是两者兼而有之？

但是回到 HTML5 规范。两个问题:

1. HTML5 到底是什么*？*
2. 谁在负责，现在在当权派(W3C)和反对派(WHATWG)之间有一种(明显不稳定的)工作关系？

先来处理一下 HTML5 是什么。有:

• HTML5，无所不包的营销术语
• HTML5，它实际上是关于超文本标记的
• HTML5，通过 JavaScript 为 web 应用程序提供的新功能
• HTML5，幕后的东西非常重要，记录了浏览器实际做的很多事情(但你可能不感兴趣)。

所有这些都来自长达数百页的技术规范。

对于我们这些网页设计师来说，HTML5 目前是一个令人困惑的炒作和物质的混合体，我们将在接下来的章节中尝试对其进行分类。

说白了，HTML5 在很多方面都是一团糟。但这是我们很久以来最有序的混乱。(例如，HTML5 的很大一部分是为浏览器供应商编写的，以确保实现的一致性，我们可以相信所有浏览器都做同样的事情。这是前所未有的。)

也许最大的问题是每个人都认为，如果 HTML5 很酷，那么它的所有部分(至少根据网页设计社区的说法)一定很棒，我们应该在没有太多批判性思考的情况下匆忙采用它。这也是我在本书的其余部分急于消除的东西。

Hixie 还是半身像

在我写这篇文章的时候，WHATWG 和 W3C 版本的 HTML5 规范(两者之间的差别很小)都是由一个人编辑的:伊恩·希克森。

HTML 现在基本上掌握在一个人手中。

W3C 的工作组试图建立共识，但在 HTML 上毫无进展。它是封闭的，但是民主的。另一方面，WHATWG 有一个开放的流程，但采用编辑说了算的方式。

编辑是伊恩·希克森。

希克森在 Opera 工作时帮助创建了 WHATWG，现在全职为谷歌开发 HTML5 规范。目前，他是生活的 HTML5(现在只是“HTML”)编辑。理论上，浏览器制造商可以随时否决他或把他踢出局，但这似乎不太可能。这一点在社会上并没有被忽视，而且(在我看来是正确的)引起了一些关注。

这是一个典型的“半杯水/半空的杯子”的情况。如果希克森断然拒绝一个想法(这是众所周知的事情)，那么让一个人负责可能看起来完全是疯狂的。但是对于那些看到 W3C 的民主进程在 XHTML 2.0 中毫无进展的人来说，拥有一个能够掌控一切、推动事情向前发展并真正做出决策的人似乎很棒。

当然，这总是会使人们两极分化。

以下是因《大胆火球》而出名的约翰·格鲁伯(daringfireball.net/链接/ 2009/ 07/ 01/希克森编解码器):

让我们说伊恩·希克森是网络标准的所罗门；他对形势的总结不偏不倚，公正无私，令人难以置信。

这是凯尔·威姆斯，CSSquirrel 漫画的创作者，几年来他一直关注 HTML5 的发展(twitter.com/ #！/cssquirrel/status/58559284224589824):

也…为什么@hixie 仍然是任何改变世界的规范如 HTML 的编辑？Ego 甚至没有开始描述他的滑稽动作

如你所见，希克森有他的粉丝也有他的批评者。

我想象编辑一个 HTML5 那么大的规范，伴随着围绕它的所有争议，将是一个非常吃力不讨好的任务。但是希克森似乎以一种愉快、冷静的方式来处理这件事。

如果这里有一个最重要的主题，那就是:实用主义规则。

W3C 有 XHTML 2.0 的“纯”规范，但失败了——它不实用。它也有自己的规则、成员和民主程序，但是陷入了政治的泥潭并且失败了(至少在 HTML 方面)——它不实用。

WHATWG 让一名编辑负责，虽然这种方法让一些人感到害怕和/或愤怒(你很快就会看到，有时包括我)，但它是实用的(就像他们对待规范的方法一样)。它推动了事情的发展(更重要的是，推动了航运)。只要它保持务实，WHATWG 就可能会保持下去。

XHTML 2.0 已死，皆大欢喜

那么 XHTML 2.0 到底怎么了？它在 2009 年脱离生命维持系统后被宣布死亡(www.w3.org/ 2009/06/xhtml-faq.html)。我听说 XHTML 2.0 的死亡将很快在即将到来的一集“法律&命令:网络标准单元”中被虚构。

而 XHTML 1.0 及其各种风味呢？考虑到它本质上只是 HTML，它将会一直工作下去。(实际上有一个持续的 HTML5 的 XML 序列化，叫做 XHTML5，但是你实际需要使用它的机会几乎为零。)

HTML5，err HTML，等等…HTML .下一个？

为了展示 HTML 规范是如何循环往复的，WHATWG 在 2011 年 1 月宣布他们的 HTML5 规范将是一个“生活标准”，并将其重新命名为“HTML”。(见此处公告:blog.whatwg.org/ html-is-the-new-html 5及其理由在此:wiki . whatwg . org/wiki/FAQ # What _ does _ . 22 live _ standard . 22 _ mean . 3f。)

HTML 的未来会怎样？WHATWG 坚持他们——尤其是希克森——将无限期地维持 HTML 规范作为“生活标准”,而 W3C 则坚持快照流程，并开始接受他们非正式地称之为“HTML.next”的想法(见这里的一些想法:www.w3.org/维基/ HTML/ next )。

(一个 W3C 成员做了一个个人演讲，很好地抓住了 HTML 未来的不同方法:www.w3.org/ 2010/11/HTMLnext-perspectives.pdf TPAC。)

W3C 会想出另一条不着边际的空想之路吗(呼应 1998 年的“塑造 HTML 的未来”研讨会www.w3.org/标记/未来/ )？他们会尝试与 WHATWG 合作，还是放弃 HTML5，做自己的事情？谁知道呢。有些人一直在问 W3C 是否应该存在。

我们应该完全扼杀 W3C，还是拥抱它？

2011 年 9 月，关于 W3C 的目的爆发了一场辩论，出现了三种广泛的观点:改革、破坏和拥抱。

在我们讨论这三种观点之前，让我们考虑一下为什么关于 W3C 的争论仍在继续，就像它已经通过了 WHATWG 成功的 HTML5 规范一样。

简而言之，这是因为世界在不停地转动。WHATWG 在 2000 年代中期开始了 HTML5 的工作，HTML5 的细节(和相关规范)在 2010 年代仍在制定中。移动正在爆炸，“应用”正在把我们带回到 90 年代特定于平台的软件世界，标准开发仍然缓慢，即使在我们现在享受的这个令人惊叹的新环境中。

面对复兴的、特定平台的应用程序开发，网络能跟上吗？W3C 是否已经失去了它的用处，或者说，经过多年的沉寂之后，它现在终于回到了正轨？以下是 2011 年 9 月的三个观点:

改革

在“w3c 应该停止做的事情”(infrequently.org/ 2011/09/Things-the-W3C-Should-Stop-Doing/)中，为谷歌 Chrome 工作的亚历克斯·罗素认为，W3C 需要放弃所有 XML 和企业的东西，重新专注于网络。本质上，大刀阔斧的改革可以让 W3C 免于被边缘化。

是时候让 W3C 抓住网络的衣钵，摆脱自我怀疑，转向一个不以规范和活动的数量，而是以对网络开发者的影响来衡量做得好不好的地方了。

破坏

在“网络技术需要一个所有者”(joehewitt.com/ 2011/09/22/Web-Technologies-Need-an-Owner)一书中，Joe Hewitt 开发了 Firefox 的早期版本，创建了 Firebug，并负责 iPhone 脸书应用程序，他认为网络只是另一个平台，但没有人对其负责(不像 Windows、Android 和 iOS)。

让我们面对事实:网络永远不会成为主导平台。永远会有其他重要的平台争夺用户的时间。为了繁荣，HTML 和它的公司需要其他平台所拥有的东西:一个单一的源代码库和一个好的所有者来驱动它。标准机构不适合扮演这一角色。浏览器厂商正在一些领域进行创新，但他们在如此多的领域受到标准流程的阻碍，以至于不可能创建一个具有一致、统一愿景的平台，就像苹果对 Cocoa 或 Python 对 Guido 那样。

因此，正如休伊特在推特上所说的那样(twitter.com/·乔赫维特/ status/ 116292923288592384 ):

解决 W3C，像开源项目一样运行网络。没有更多的规格，只是提交。Linux 需要一个标准体吗？

拥抱

最后，在“网络是一个不同的问题”(www.webdirections.org/博客/The-web-is-a-different-problem/)中，长期的网络传道者、作家和演讲者约翰·奥尔索普认为，虽然标准的发展在 21 世纪初肯定停滞不前，但我们在过去几年中已经看到了“浏览器层面的创新爆炸”，特别是 CSS3 和更多的模块化规范，我们现在真的要把婴儿和洗澡水一起扔掉吗？

所以，说白了，我觉得这个问题有些言过其实了。我们似乎已经找到了一种方法，既能在浏览器中探索和实现新功能，又能在各种浏览器中广泛采用。[…]

(但)网络是一个不同的问题。将网络生态系统的创新与 iOS、Android 或其他平台的创新进行比较几乎没有任何意义。网络面临的挑战要大得多(目标也重要得多)。[…]

因此，我们不应该笼统地批评 W3C，或者甚至呼吁解散 W3C，而是应该关注它在许多方面如何完成了一项几乎不可能完成的任务——让激烈的商业竞争对手坐下来，一起工作，并就他们每个人都将实现的核心技术达成一致，即使与此同时，这些相同的竞争对手彼此卷入了重大的法律冲突。

无论我们希望什么，纯粹的惰性可能会让 W3C 在未来几年保持其作为 web 标准开发之家的角色(无论是好是坏)，特别是现在它已经将 WHATWG 和 HTML5 纳入了 W3C 的帐篷。

现在新的东西是如何加入 HTML5 的？

HTML5 将会如何发展？WHATWG 将如何在他们的“生活标准”中实现新的 HTML 特性？他们说新的 HTML 特性应该首先出现在浏览器中(至少是实验性的)，然后将和编入规范，假设它们有一个合理的用例并且编辑同意。(详见 WHATWG 常见问题:【http://wiki.whatwg.org/ wiki/FAQ # Is _ there _ a _ process _ for _ adding _ new _ features _ to _ a _ specification . 3f。)

这意味着 HTML 规范将捕捉新出现的功能，而不是从头开始规定新的功能——考虑到 WHATWG 在任何浏览器实现之前在 HTML5 规范中所做的大量创新，这有点奇怪。

WHATWG/W3C 的关系会持续多久？你的猜测和我的一样好。在 W3C 的邮件列表中，希克森不时公开敌视 W3C 的流程(lists.w3.org/档案/公共/www-archive/2012 Jan/0032.html)，他的决定和拒绝仍然是相当多摩擦的来源。

最后，任何一方都可以想出他们喜欢的所有规格。真正重要的是浏览器供应商选择实现什么。就 HTML 而言，WHATWG 与浏览器厂商的密切关系意味着在可预见的未来，他们可能会发号施令。

所以，在所有这些之后，我们又回到了 HTML。这就结束了我们有些耸人听闻的(和高度浓缩的)HTML5 的历史。或者 HTML。或者…你明白了。

TL；速度三角形定位法(dead reckoning)

综上所述，W3C 试图杀死 HTML，带我们踏上了长达十年的无处可去的旅程；一些来自浏览器厂商的人组成了一个对网络应用和 HTML 格式发展感兴趣的团体；他们在 W3C 之外开发 HTML5W3C 意识到他们上当了，同意使用他们的成果；浏览器厂商正在实现(或者他们现有的某些特性的实现已经标准化)；网络标准已经成为微软的市场流行语；地狱还没有结冰。

我们要关注的是

HTML5 是一个庞大的规范，充满了令浏览器厂商麻木的细节。

但是这个细节实际上是最棒的。消除实现的模糊性导致了更可预测的行为，这对设计者和开发者都是好消息。(在此之前，浏览器厂商互相监督，看规范的各个部分是如何解释的。)

这不是什么有趣的工作，而是 WHATWG 多年来的精心记录和澄清，我们都应该对此心存感激。

HTML5 的其他部分很大程度上反映了它作为 Web 应用程序 1.0 和 Web 表单 2.0 的起源。我们将在第十二章讨论 web 应用程序，在第八章讨论 web 表单。

作为设计师，最大的兴趣点是对 HTML 实际标记端的改变和添加。这就是我们将要关注的:语义、形式、图形和音频/视频。

我们还将谈到 HTML5 中 web 应用程序的新特性，我们希望尽快在我们的内容管理系统中看到这些特性。

然而，最重要的是，我们将会看到标记中的思想以及 HTML5 的实践——有时是关键的——该做什么，不该做什么。

让我们开始，看看我们如何在 HTML5 中开始一个文档。

二、适用于各种场合的文档类型（以及其他）

让我们从网页的第一行开始。现在只是:

<!doctype html>

就这样。简短、易记，并在所有主流浏览器(包括 IE6)中触发标准模式。它也是不区分大小写的。

在 HTML5 中，开始的<html>标签也被简化为:

<html lang="en">

没有 lang 属性，浏览器也能处理，但是指定页面的主要语言是一个好习惯——特别是对于非英语页面。(参见这篇关于在 HTML5 中声明语言的有用文章:nimbupani.com/·declaring-languages-in-html-5.html。)

接下来是<head>标签，像往常一样，它将包含我们的<title>、<meta>、CSS 和 JavaScript 标签。如果你想变得极简，你实际上不需要指定<head>标签(参见 Bruce Lawson 的极简 HTML5 文档讨论这里:【http://www.brucelawson.co.uk/】2010/a-minimal-html 5-document/)，但是我们会的。

在我们的<head>标签中，我们有:

<meta charset="utf-8">

这指定了页面的字符编码。同样，它在 HTML5 中被简化为最简单的形式。出于安全原因，你应该总是指定这一点(这里有一个技术讨论:code.google.com/ p/doctype-mirror/wiki/article utf 7)，并且它应该在<title>标签之前。

<meta name="description" content="My HTML5 Website">

这一点没有改变。谷歌和其他搜索引擎有时会在搜索结果页面中使用这个标签，但不用于排名。(不过，你可以忘记所有关于<meta content="keywords">的事情。搜索引擎多年来一直忽略它。我们将在第六章讨论标记和 SEO。)

有关谷歌理解的元标签的更多信息，请参见:www.google.com/支持/网站管理员/ bin/ answer.py？答案=79812 。

<title>标签没有变。

要链接 CSS 和 JavaScript 文件，我们只需使用:

<link rel="stylesheet" href="styles.css">

以及:

<script src="myscript.js"></script>

没有必要再指定type="text/css"或type="text/javascript"了——浏览器已经假定了。

我们现在就可以开始使用这些技术。它们并没有什么害处，它们只是让从内存开始编写我们的文档变得足够简单。(尽管如此，旧技术仍将继续有效——可能永远有效。)

因此，一个基本的 HTML5 页面(包含基本的正文内容)如下所示:

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="description" content="My HTML5 Website">
<title>My HTML5 page</title>
<link rel="stylesheet" href="mystyles.css">
<script src="myscript.js"></script>
</head>

<body>
<h1>My HTML5 Page</h1>
</body>
</html>

如你所见，这和我们习惯的差不多，只是更简单。

HTML5 中的格式更改

关于如何在 HTML5 中编写 HTML，需要注意一些事情:

• **引号是可选的。**不再需要引用属性值，喜欢的话可以写<meta charset=utf-8>或者<div class=myclass>。就我个人而言，我更喜欢引用值，但是 HTML5 让你自己决定。
• **不区分大小写。**如果你真的讨厌你的同事和/或怀念你在 MySpAcE 的古怪时光，你可以用大写或小写，甚至混合使用<DiV ClAsS=VaLuE>这样的字体。
• **反斜杠是可选的。**你不再需要用反斜杠(如<meta charset=utf-8 />)来结束独立标签。正如您可能猜到的，这是转向 XML 的遗留物。同样，<br>和<br />都是完全有效的——这取决于你。

如果你坚持 XHTML 更严格的语法(总是用小写字母书写，引用属性值和结束独立标签)，你可以继续这样做——它总是会得到很好的支持。

新元素的 HTML5 Shim 和 CSS 怎么样？

HTML5 引入了新的元素，如<nav>、<header>、<article>、<section>等等。这些在理论上听起来不错，但在实践中却很糟糕。

为了在 IE6-8 中支持这些元素，其他人建议您包含一个小脚本来告诉 IE6-8 这些元素的存在，并使用您为它们指定的任何样式(否则它们将保持无样式)。我不推荐使用这些新元素，所以我们不需要 HTML5 shim。(如果你真的想使用它们，这里有这样的代码:code.google.com/ p/html 5 shiv/。但是说真的，不要用新元素。你以后会感谢我的。)

您还需要将新的元素设置为display: block;，如这个 HTML5doctor.com 样板文件所示:html5doctor.com/ html-5-样板文件/ 。同样，不要使用这些元素。(在接下来的两章里你会明白为什么。)

HTML5 样板和 Modernizr 怎么样？

如果你想为新的 HTML5 页面准备一个无所不包的样板文件，看看html5boilerplate.com/和标记文档github.com/·保罗·爱尔兰/html 5-样板文件/维基/ The-markup 。(维基中有更多的文档。)

虽然我很欣赏他们为 HTML5 样板所做的努力，但如果你只是在寻找 HTML5 的方法，那就太紧张了。我更喜欢从简单开始，用我自己最简单的方法工作。但是，如果你喜欢从一切开始，然后删除你不想要的东西的方法，HTML5 样板文件可能正合你的胃口。

modernizr(www.modernizr.com/)是一个方便的脚本，用于检测对 HTML5 和 CSS3 特性的支持。(它不加支持，它只检测它。)它已经成为生活在前沿、尝试新功能的设计师的主食，所以如果这是你感兴趣的，就去看看吧。(当我们在第十二章中查看 HTML5 的 web 应用功能时，我们将更多地讨论 Modernizer，以及功能检测而不是浏览器检测的优点。)

嗯，那很容易。几乎太过容易。现在，让我们向左转，进入众所周知的新结构标签的领域。

三、新的结构元素——这不会有好结果（以及争议）

网页设计者最常见的任务之一是标记页面结构，它通常由页眉、页脚、导航、侧边栏和内容区域组成。这是那种你被蒙上眼睛铐在椅子上旋转五分钟后就能做的事情。

HTML5 引入了一些新元素来帮助我们定义给定网页的结构，比如<section>、<article>、<nav>、<aside>、<header>和<footer>。

我们不应该使用它们。它们是 2004 年由一个人心血来潮编出来的，甚至和 ?? 似乎都忘记了它们的目的是什么。

如果你只需要知道这些，很好。继续使用带有有意义的类名和 ID 名的<div>，以及适当的<h1> - <h6>标题。它们将永远有效(或多或少)，你不会错过任何东西。

但是，我建议在标记文档时使用一些非 HTML5 的特性，比如为盲人和视力受损的用户使用 ARIA 属性，为搜索引擎结果使用微数据模式(如果合适的话)。(我们将在后面的章节中详细讨论这些。)

然而，我们将深入处理这些新元素，因为每个人都会犯错误。我们将直接记录它们是如何进入规范的，以及它们真正的目的，这涉及到一种完全不同的组织页面的方式。

一点痛苦的滋味

以下是这些新结构元素带来的一些问题:

• 他们赋予网页设计者已经使用的术语(如页眉和页脚)新的用途，同时声称只是在做网页设计者已经在做的事情。
• 他们引入了一种新的方法来组织模糊、复杂和不必要的文档。
• 它们严重损害了一些用户的可访问性(特别是那些使用 IE6、IE7 甚至是关闭 JavaScript 的 IE8 的用户)。
• 它们引入了宽泛、不清晰、定义不明确的用例，这将使 web 标准更难学习(也更难教授)。

这些都是严重的问题，对网络标准有害无益。标记应该是轻量级的，易于学习和应用。应该不需要精神体操来尝试和解决在哪里使用什么。

但是这些新的结构标签创造了一种奇怪的、准宗教的体验，你必须向高级牧师(HTML5 大师)咨询他们对模糊的宗教文本(HTML5 规范)的解释，只是为了标记一个该死的网页。

“但是，但是…这些元素在官方 HTML5 规范中！肯定有必须是一个很好的理由吗？”

*继续读…

这些元素从何而来？

测验问题:这些元素是如何添加到 HTML5 规范中的？

1. 专家们考虑了各种使用案例，权衡了各种选择和替代方案，并在广泛咨询和仔细审议后，选择了最重要的方案。

2. web 设计者和 HTML 作者的社区(比如你和我)迫切需要某些元素来实现特定的功能，经过大量讨论后，社区提出了一个必要元素的候选列表。

3. 采用了一种科学的、基于研究的方法，在这种方法中，标记模式被“在野外”研究，并被编码成一堆新元素。

4. 一些标记专家认为这是个好主意，并在 7 年多前就把它们扔进了规范中。

而答案是……(d)。

“但我在[此处插入您选择的 HTML5 书籍]中读到，它更像答案©。WHATWG 研究了 ID 和类名的真实用法，这就是它们是如何产生的！”

我们会谈到这一点。

我很好奇是谁添加了这些元素，什么时候添加的，为什么添加。所以我把这些问题问了 HTML5 规范编辑伊恩·希克森，下面是他的回复(经允许转载):

我和其他 WHATWG 贡献者在 2004 年左右[添加了它们]，因为在看到作者如何使用 HTML4 后，它们是显而易见的添加元素。我们后来(2005 年末到 2006 年初)做了一些客观的研究，找出前十名的 HTML 类是什么，结果发现它们基本上与我们添加的元素完全匹配，这很方便。

您可能在其他 HTML5 书籍、HTML5 讲座或关于这些新元素的博客文章中读到过这种“客观研究”。但是几乎每个人都在篡改历史。有时他们说研究是第一位的——事实并非如此。有时这只是暗示研究是第一位的，这仍然是一种疏忽。

(实际上，根据正在讨论的研究——http://code.google.com/·韦伯统计/2005-12/classes.html——主要的发现是，在被抽样的 10 亿个页面中，大约 90%根本没有类。如果希克森和 WHATWG 真的遵循了这里的研究，他们早就完全废除了课程！)

那么，如果这些元素不是来自研究，它们是从哪里来的呢？

在探索 WHATWG 邮件列表的黑暗角落时，我发现希克森在 2004 年 11 月首次提到了这些元素，当时他讨论了他白板上列出的块级元素。(参见:lists.whatwg.org/ htdig.cgi/ whatwg-whatwg.org/ 2004 年 11 月/002329.html。)

在同一个星期，他说“我正在考虑做的是[添加]部分元素[这]将是:<body> <section> <article> <navigation> <sidebar>”。(你可以在这里看到完整的电子邮件:lists.whatwg.org/ htdig.cgi/ whatwg-whatwg.org/ 2004 年 11 月/002362.html。)

当然，在这个过程中的某个地方<navigation>变成了<nav>,<sidebar>变成了<aside>。

所以这些每个人都想弄明白的新的，主要的结构元素可能被包括在内，因为希克森在 2004 年在他的白板上草草记下了它们。它们实际上为“分割”提供了更广泛的用途(我们很快就会谈到)。但是有必要确定它们是如何出现在规范中的，以及它们有多武断。

在第一章中，我们看到 XHTML 2.0 因为过于雄心勃勃而失败。在 HTML5 中，我们取而代之的是几年前编辑心血来潮在白板上画的一些语义元素，以及当时一些 WHATWG 成员的一些输入。

谁在乎呢。

“唉，谁在乎呢？”你可能会想。“如果研究最终支持使用这些元素，那有什么大不了的？”

问题是，在我看来，当希克森说这些新元素“完全符合我们…添加的元素”时，他有点厚脸皮虽然它们与常用元素有着相同的名称，但规范描述了它们在 ?? 的使用方式，与网页设计者和作者所熟悉的方式大相径庭。对于这些网页设计者和作者应该使用的标准来说，这是一个大问题。

当你采用人们使用的术语，重新定义它们应该如何使用(甚至给它们多种用法)，然后告诉这些人不要担心，因为这些术语正是他们已经在使用的，会发生什么？你让他们去混乱之城。

HTML5 新元素的核心矛盾

HTML5 应该是关于编纂我们已经在做的事情，或者“铺平道路”。当谈到这些新标签和标记基本模板时，他们建议你可以用新标签替换当前的<div>结构标签(例如，用<header>替换<div id="header">，就大功告成了。

这无疑是 2007 年 12 月 ALA 文章“HTML 5 预览”中的含义，这个观点在此后的书籍和博客文章中反复出现，通常带有类似下面这样的图形:

图 3.1。这是不对的。不要这样。

用新元素替换旧的看起来很容易，对吗？漂亮、干净的元素取代了一堆随机的<div>，多可爱啊！

不幸的是，这个想法有几个问题:

• **元素太少。**没有足够的新元素来进行合理的 1:1 替换。相信我，s 不会去任何地方。所以，如果你听到有人说“终于，我可以摆脱我的不性感的东西了！”我允许你用枪打他们的屁股。
• **不相等。**虽然元素通常被认为是相等的，但事实并非如此。虽然“切片”元素(<section>、<article>、<aside>和<nav>)可能工作相同，但<header>和<footer>元素旨在在切片元素内工作。这可以产生巨大的差异(我们将很快看到文档大纲)，但是如果你遵循了关于这些元素的大部分讨论，你将永远不会知道。
• **不可替代。当你深入研究 HTML5 规范时，你会发现规范中描述的这些标签根本不是现有标签的一对一替代。它们实际上是用来创建一种新形式的文档大纲。一份文件什么？我们接下来将对此进行探讨。

这些元素有其他问题(它们没有为语义或搜索引擎添加任何东西)，但我们将在稍后针对这两个不会消亡的僵尸神话时讨论它们。我们还将了解“语义”在标记中的实际含义，以及搜索引擎真正想要的是什么。

现在概述什么？

如果你试图理解 HTML5 的新结构元素而不理解文档大纲，你会认为它们是一堆任意的、奇怪命名的元素，具有令人困惑的用例。

然而，一旦你理解了文档概要，你会发现它们实际上是一堆任意的、奇怪命名的元素，有着令人困惑的用例，也有着可疑价值的总体目的。

当然，这是深奥的东西。但是请耐心听我说，你将会看到 HTML5 是如何试图以一种全新的方式来做一些像构建网页这样基本的事情。这与其说是在铺牛道，不如说是在修建一条新的牛公路。

什么是大纲，我为什么要关心？

大纲是文档的一种层次化的要点表示。

实际上，每当我们标记一个文档并使用标题元素时，我们都会制作一个大纲。因此，即使你从未听说过“文件大纲”，你也有可能已经做了一个。很奇怪吧。

我们从来没有听说过它们的原因是因为网页设计师从来不需要使用它们。它们主要被盲人用户用作导航的主要手段。谈到可访问性，轮廓是一个大问题。因此，我们能做的帮助盲人和视力受损的用户浏览文档的最好的事情就是在使用 web 标准时提供一个好的标题结构。(我们将在第四章对此进行更深入的探讨)。

HTML5 试图从根本上改变我们制作这些轮廓的方式…并且维持现有的方式(嗯，有点)。这种新的大纲方法是新 HTML5 标签存在的原因，也是希克森和 WHATWG 最初考虑添加“章节元素”的原因。

我们目前是如何创建轮廓的(甚至没有意识到)

让我们后退一点，看看我们目前的大纲。在(X)HTML 中，文档的层次结构是由标题级别决定的，使用熟悉的<h1>到<h6>标签。

所以你可以这样标记你的页面(作为一个简化的例子)，用标题代表每一部分的“重要性”:

`

My Sweet Blog

    

Latest Posts

        

My Blog Post 1

        

My Blog Post 2

        

My Blog Post 3

Blog Sidebar

        

Blog Archives

        

Popular posts

        

Blog roll

Blog Footer

        

My delicious links

        

My flickr photos

        

My social networks

`

文档的层次结构或“大纲”如下所示:

1\. My Cool Site         1\. Latest Posts             1\. My Blog Post 1             2\. My Blog Post 2             3\. My Blog Post 3             4\. Blog Sidebar                 1\. Blog Archives                 2\. Popular posts                 3\. Blog roll                 4\. Blog Footer                     1\. My delicious links                     2\. My flickr photos                     3\. My social networks

哦哦。我们有麻烦了。我们所有的下级标题都被它们上面的标题“拥有”。“博客侧边栏”不应该是“最新文章”下的标题——它应该开始一个新的部分。

如果我们将“博客侧边栏”的标题级别更改为<h2>(与“最新帖子”相同)，我们将得到:

1\. My Cool Site         1\. Latest Posts             1\. My Blog Post 1             2\. My Blog Post 2             3\. My Blog Post 3         2\. Blog Sidebar             1\. Blog Archives             2\. Popular posts

但是现在我们不再代表标题的重要性。相反，我们试图使用一组有限的标签(<h1> - <h6>)来建立一个逻辑结构，这些标签习惯于“拥有”它们下面的所有东西——即使它们不应该拥有。

这是另一个例子。假设我们有一页写着:

<h2>My HTML5 Book Review</h2>         <h3>Likes</h3>             <p>It explained some elements of HTML5 well.</p>         <h3>Dislikes</h3>             <p>The author had an annoying habit of writing silly, self-referential examples.</p>         <div class="review-body">         <p>I bought this HTML5 book for the low, low price of... </p>         </div>

在这个文档大纲中，整个评审将归入<h3>Dislikes</h3>之下，因为标题“拥有”其下的所有内容，尽管它实际上应该归入<h2>My HTML5 Book Review</h2>之下。通常这种结构性问题会被忽视。然而，让评论文本出现在“不喜欢”下面的视觉问题不会不被注意到，所以出于样式的目的，我们可能会引入一个<div>，以便我们可以在视觉上区分“不喜欢”下面的段落和评论主体本身。

事实上，这通常是我们组织文档的方式——我们使用<div>将它们分成逻辑部分。但是就可访问性而言，这与文档大纲没有关系——大纲仅由标题创建。

如你所见，标题对于创建轮廓是有缺陷的。人们经常使用标题级别来显示不同的字体大小(有或没有 CSS)，或者表示任意的“重要性”而不是结构。有时他们只是将 HTML 直接剪切并粘贴到一个新模板中。

当你考虑所有这些，以及使用<h1> - <h6>的局限性时，很明显大多数网页没有像那样的逻辑轮廓。

但是他们确实有一个大纲，并且使用<h1> - <h6> 给盲人和视力受损的用户提供了一种导航我们文档的方式，研究表明这对于使用屏幕阅读器的人来说是常见的。(我们一会儿会谈到这项研究。)因此，尽管存在缺陷，出于可访问性的原因，我们需要更认真地对待结构标题而不是更少。**

(查看任何网站的轮廓(试试你自己的！)，查看一下谷歌 Chrome 的 html 5 Outliner:chrome.google.com/网上商店/detail/afoibbobkebhgcfnknfndkgemglgomo。)

但是如果有一种方法可以创建任意的轮廓而不依赖标题呢？事实证明，人们已经考虑这个问题很多年了——如果不是几十年的话。

“切片”是个老问题

标题问题，以及如何组织文档，是一个长期存在的问题。早在 2002 年，XHTML 2.0 就在其第一稿中提出了一个解决方案(参见:【http://www.w3.org/】TR/2002/WD-XHTML 2-2002 08 05/)，其中涉及嵌套<section>标签和使用通用<h>元素作为标题。

早在 1991 年，蒂姆·伯纳斯·李就提出了 XHTML 2.0 中的“分段”解决方案，正如 Jeremy Keith 所指出的(见:《http://adactio.com/日报》/ 1683/ )，当时 Berners-Lee 说:

事实上，我更喜欢标题(那些来自 AAP DTD 的)有一个可嵌套的

，而不是

、

等…

元素，还有一个通用的…区段内的任何水平将产生所需的航向水平。

是的，整整二十年前。

HTML5 试图通过遵循与 XHTML 2.0 相似的途径将这种分段概念引入主流 HTML，同时还保持了一些向后兼容性。结果是，我们可以说，混合。

但是在我们开始 HTML5 的实现之前，让我们看看标题对于可访问性有多重要。

如果我们关心盲人用户，我们应该关心标题

正如我们之前提到的，在 HTML4 中，是像<h2>博客侧边栏</h2>这样的标题(而不是像<div class="blog-sidebar">博客侧边栏</div>这样的随机<div>标题)创建了文档大纲。对于盲人用户来说，这些标题很重要。

有多重要？在对 1000 多名屏幕阅读器用户的调查中(其中 80%的人是盲人，16%的人视力受损):

对这个问题的回答给了我们最大的惊喜。很明显，提供标题结构对于 76%的屏幕阅读器用户来说是很重要的，当标题可用时，他们总是或经常通过标题导航。标题导航的使用随着屏幕阅读器熟练程度的提高而增加，90.7%的专家用户、79.3%的高级用户、69.9%的中级用户和 55.4%的初学者经常使用标题导航。

(你可以在这里看到完整的结果:webaim.org/项目/screenreadersurvey/#标题。)

你意识到了吗？我没有，多年来我一直在随意地使用<h1> - <h6>。我想大多数网页设计师都有一些模糊的想法，认为<h1> - <h6>标签很重要，但不知道它们对盲人用户有多重要。

因此，我们有了一个既定的、直接的、易于实现的方法来为盲人和视力受损的用户提供轮廓。也就是说，直到我们击中 HTML5。

HTML5 的“改进”大纲在发布之前就已经死了

我们已经建立了什么是文档大纲(页面的项目符号、目录样式表示)，并且我们已经建立了它们当前是如何创建的(使用<h1> - <h6>元素)。

简而言之，HTML5 建议如何创建文档大纲:

• 大纲中的每个要点或“章节”都使用四个“章节”元素之一来定义:<section>、<article>、<nav>和<aside>；而不是<h1> - <h6>元素。这里的意图是解决<h1> - <h6>的局限性。(我们将在下一章探索这些新元素。)
• 按照 XHTML 2.0，没有通用的<h>元素。但是在纯 HTML5 中，建议我们可以在任何地方使用<h1>作为通用的标题元素。事实上，html 5 中的任何标题元素都将被视为通用标题，其级别由它在 sectioning 元素中的嵌套深度决定。
• 但是没有“纯”HTML5 这样的东西，所以我们需要保持向后兼容性。因此，我们仍然应该在逻辑上使用<h1> - <h6>，这意味着在一个文档中维护两个稍微不同的文档轮廓。

大概就是这个意思。以下是该规范的表述(www.whatwg.org/规范/网络应用/当前工作/多页/章节. html #标题和章节):

节可以包含任何级别的标题，但是强烈建议作者要么只使用 h1 元素，要么对节的嵌套级别使用适当级别的元素。

请不要到处使用<h1>元素！

在我看来，每个人(规范和公开评论中的希克森，社区中的标准倡导者，以及一般的设计师和作者)都在沟通这一点上犯了一个完整的错误。

这种不良的沟通意味着设计者和开发者一直在使用这些 HTML5 元素，而不理解他们所创建的轮廓。这些元素应该带来更好的逻辑文档大纲。相反，考虑到它们实现的随意性，他们创建了 HTML5 风格的文档大纲，甚至比他们打算取代的基于<h1> - <h6>的大纲更加破碎。

HTML5 版本的大纲实际上在任何人理解它之前就已经死了，更不用说正确地实现它了。

具有讽刺意味的是:这种方法，理论上可能会在未来带来可访问性的好处(没有人知道屏幕阅读器何时或者是否会使用这些轮廓)，现在正在摧毁一小部分 IE 用户的页面风格*。因此，它已经造成了伤害，但没有明确的未来利益。(我们将在下一章详细讨论这个问题。)*

*我们仍将在第四章探索这些新的 HTML5 元素，但主要是为了让你明白它们有多糟糕。(记住，很酷的 HTML5 会在后面的章节中介绍。)

偷偷摸摸的大创意会导致死创意

这种新的概述方法的第一个问题是 HTML5 只是“铺路”和编纂现有实践的想法。

很明显，引入一种全新的组织文档的方式，不管沟通多么糟糕，都不是“铺路”。

你不能回头告诉作者和设计师，“这就是你一直在做的！”但是希克森做到了，他说新元素只是为了保存普通的类名。这里只是几个例子。

2009 年，(lists.w3.org/档案馆/Public/Public-html/2009 aug/0717.html)希克森说:

根据最常见的 class= " "属性值，它们或多或少满足了 Web 开发人员最常见的请求。它们的主要目的是简化创作和样式。

而在 2012 年(lists.whatwg.org/皮佩尔梅尔/whatwg-whatwg.org/ 2012 年 1 月/034506.html):

大多数情况下，这些新元素使创作变得更加容易。

因此，如果 HTML5 要引入一个大的新想法，它需要传达这个大的新想法。相反，看起来希克森不记得，或者懒得争论，他和 WHATWG 加入规范的大想法。

HTML5 的拥护者(以及规范本身)需要恰当地传达新元素的目的，或者废除它们。

就像现在一样，他们只是在给网页设计社区施加压力。

我举个例子。规范说<header>和<footer>元素定义了部分中的区域*，但是没有定义部分本身，因此不会出现在文档大纲中。这是大多数人都会犯的错误，包括那些通过书籍和博客教授 HTML5 的人，他们的例子经常显示<header>与<section>不相上下。规范还说<header>和<footer>可以在每个页面上多次使用(例如，每个部分一次)，但是你永远不会从大多数 HTML5 资源中找到这一点。*

这些观点可能看起来很迂腐，不切实际。但是它们说明了一些非常严重的事情——社区正试图以一种与实际的 HTML5 规范没有太大关系的方式实现 HTML5 标记。这是一种不经意间出现的奇怪的标记中间状态，因为这是每个人都认为这些元素应该被使用的。

我们分了规格

在某种意义上，就标记而言，社区已经分叉了 HTML5。这是个大问题。有 HTML5 的“常见(但不正确)理解”分支，还有实际的 HTML5 规范。但是遵循“共识”并用“听起来正确”的元素替换模板中的可视区域对任何人都没有好处。我们只是在误用新元素的时候创造了一个奇怪的、破碎的轮廓。有这么多破碎的 HTML5 大纲，大纲作为一个概念在到达时几乎已经死亡。

一会儿我们将分别探讨每个元素，但现在让我们继续关注全局。

我们应该如何构建一个 HTML5 页面？

目前所有这些可能看起来有点混乱，所以让我们后退一步，看看在 HTML5 中构造页面的一般规则(例如！)，如规范中所述:

• 我们应该使用<section>、<article>、<nav>或<aside>在大纲中创建一个新的部分。(即文件大纲中的新项目符号。)你可以用 Chrome 的 HTML5 Outliner 插件看看你的轮廓是什么样子:chrome.google.com/网络商店/detail/afoibbobkebhgfnnknfndkgemglgomo。是的，这里的术语很笨拙——拥有多个元素，包括<section>,在文档大纲中创建一个部分是相当混乱的！
• 我们在每一节中用<header>或<footer>或来划分该节的页眉或页脚*。该部分可以是从根<主体>部分到单个注释的任何内容。(单个注释应该是一个<article>，我们将在第四章看到，它将在文档大纲中创建一个部分。)*
• 我们使用标题元素(<h1> - <h6>)在大纲中给每个部分一个标题，并提供向后兼容性。(在我写这篇文章的时候，任何地方都没有对 HTML5 大纲的有意义的支持，似乎也不会有。所以“向后”兼容实际上可能是“可预见未来的兼容”。)

你可能认为你可以用<section>代替所有的<div>来创建一个大纲。然而，<section>不会用在你只需要一个样式挂钩的情况下，所以在一个真正的 HTML5 文档中你仍然会有大量的<div>。事实上，一个“正确的”HTML5 文档应该有:

• 一堆<section>、<article>、<nav>和<aside>标签来创建轮廓
• 一堆造型用的<div>
• 多余地使用<h1> - <h6>标签来尽可能好地复制大纲(这是屏幕阅读器将实际使用的)
• 在每个部分中有少量多余的<header>和<footer>标记，它们不做任何事情。

简化创作？用两种方法构建页面，维护两个轮廓，添加一堆多余的标签？

我不这么认为。这还是在我们考虑设计标题样式之前。

HTML5 风格有点疯狂

让我们想象一个纯粹的 HTML5 未来，按照规范的建议，我们可以在任何地方使用<h1>作为通用标题元素，并且我们使用新的 sectioning 元素来创建轮廓。也就是说，如果我们使用三段深度的<h1>，它本质上就是一个<h3>。

假设我们想要将这个三段深度的<h1>设计成一个<h3>。我们怎么把它挑出来？如果四个元素可以创建一个部分，并且可以以任意组合的方式使用，你能想象在级联的任何地方挑选 h1，给它不同的级别不同的风格吗？你会睡不着的。

在标题恰如其分的博客文章《不要使用 HTML5 节来设计标题》(www.stubbornella.org/ content/2011/09/06/Style-Headings-Using-HTML5-Sections/)中，妮可·沙利文谈到了当你试图通过层叠来设计 html 5 风格的<h1>元素时会出现的疯狂，并给出了这个简单的例子:

h1{font-size: 36px} section h1{font-size: 28px} section section h1{font-size: 22px} section section section h1{font-size: 18px} section section section section h1{font-size: 16px} section section section section section h1{font-size: 14px} section section section section section section h1{font-size: 13px} section section section section section section section h1{font-size: 11px}

然而，正如沙利文指出的那样，那是大大简化了的版本。当你必须设计所有(比如说)六层深度的标题时，真正的疯狂就开始了，这些标题可能嵌套在<section>、<article>、<aside>或<nav>的任意组合中。对于喜剧价值，看看这样的样式表会是什么样子:github.com/ cboone/hypsometric-CSS/blob/master/html 5/html 5-defaults . CSS # L426。这太疯狂了。

那么唯一的选择就是依靠类名作为标题，但是在创作时避免类名正是 WHATWG 试图解决的“问题”。

你认为我们的客户和乐于创建和编辑网页的同事会理解正确划分文章的细微差别吗？我对此表示怀疑。

难怪人们会感到困惑。

哦，最重要的是，你的<nav>(以及任何其他新的 HTML5 元素)的风格可能会让大约 1%的用户失望。(我们很快会再次谈到这一点。)

这就是 HTML5 的方式。而且很乱。

毫不奇怪，即使是最有经验的 web 作者也会陷入 HTML5 大纲的泥潭。在这里了解一下罗杰·约翰逊的经历，例如:www.456bereastreet.com/档案/2011 03/html 5 _ sectioning _ elements _ headings _ and _ document _ outlines/。

这不是无关紧要的——人们必须教这些东西

“好吧，也许在这一点上，涨价的书呆子们弄错了。可能这些标签大多是多余的。所以没人用，或者做的不太对。谁在乎呢，加价学究先生？”

事情是这样的，将这些新元素——以及任意轮廓等概念——引入官方 HTML5 规范意味着人们实际上必须教授这些东西。(见鬼，一些设计师甚至教他们的孩子这些东西——例如，看看 Cameron Moll 的很酷的 HTML5 白板磁铁:【http://cameronmoll.tumblr.com/邮报】10688505696/html 5-白板磁铁。)

这对网络标准是不利的。它甚至让基本的 HTML 变得难教、难学、难实现，这是为了什么？构建一个网页应该是我们最不担心的事情——不会让一代学生和专业人士分心。

(那些教学网络标准的注意:如果你真的讨厌你的学生，让他们解释一下<article>和<section>的区别。)

这给我们留下了什么？

希克森和 WHATWG 的意图是好的。理论上，即使不考虑大纲，使用这些标签也可以提高可访问性。(例如，屏幕阅读器可以跳过<nav>标签直接进入内容。)但迄今为止，生产屏幕阅读器的厂商对 HTML5 兴趣不大。而且已经有人支持更好的替代方案，我们接下来会看到这一点。

所以我们不需要 HTML5 的新元素来实现可访问性。事实上，我们应该避免它们对另一部分用户造成的伤害。

人们仍然会使用这些标签，主要是因为他们想“做正确的事情”，希望标准仙女会在他们的枕头下留下零钱和/或苹果产品。但这只是浪费生产时间，这些时间可以更好地用在更重要的事情上。

请记住:最终出现在规范中的往往只是几个(甚至一个)感兴趣的、聪明的普通人在 7 年多前(截至本文写作时)的想法。甚至有可能他们不记得他们为什么想要它。所以我认为我们被允许对什么是最好的有不同意见，并且挑选我们实现的东西。

但是可访问性会怎么样呢？我们只是让视力受损的用户保持现状吗？不，因为幸运的是有更好的选择。

一种合理的可访问性结构化标记方法

有一种方法可以在我们的标记中为盲人和视力受损者添加助手而不用陷入 HTML5 的新结构元素——ARIA roles 的泥潭。

事实上，这是 WAI-ARIA，代表“易接近的人显然不做引人注目的缩写”。或者，正如坚持准确性的人可能会告诉你的，这是“网页可访问性倡议-可访问的富互联网应用程序”。(我们就叫它咏叹调吧。)

这不是 HTML5 规范的一部分。相反，它是一个独立的(巨大的)W3C 规范，兼容 HTML5、HTML 4 和 XHTML 1.x。

ARIA 的秘密是role属性，可以像这样添加到元素中:

<div role="myariarole">

完整的咏叹调规格很大。非常大。(看到这里:www.w3.org/ TR/瓦伊-阿利亚/ 。)但是我们将会看到一个叫做地标的小子集(参见:www.w3.org/ TR/wai-aria/roles # landmark _ roles)。

例如，下面是一个简单页面的四个主要区域:

• 页眉
• 内容
• 补充报道
• 页脚

下面是我们如何用 ARIA 来标记它:

`

    
    

`

别紧张。

当我们讨论 HTML5 元素时，我们将触及我们可以使用的角色，并在第四章中重述。

ARIA 优势

与 HTML5(或以前的 HTML 版本)相比，ARIA 角色有几个好处:

• 角色通常反映了 web 作者如何构建页面。(例如，标题或“横幅”是用于页面顶部的内容，而不是像 HTML5 那样用于页面的每个部分。)
• 它们使我们的标记保持相对干净，因为我们可以使用属性选择器将role属性作为 IE7 和更高版本的样式挂钩，比如div[role="banner"] {border:10px pink;}。(如果需要支持 IE6 用户，还可以包含冗余类。)
• 它们现在可以在支持 ARIA 里程碑的屏幕阅读器中工作，如 JAWS 版本 10 屏幕阅读器、NVDA 2010.1 和 iPhone IOS4+上的 VoiceOver。(详见www.paciellogroup.com/博客/2010/10/using-wai-aria-landmark-roles/。)
• 它们不会像新的 HTML5 元素那样，在关闭 JavaScript 的情况下破坏 IE6-8 用户的样式。

这种技术现在可以帮助盲人用户，不损害网络标准，也不需要你用第二种方式来分割你的文档。

我们将在下一章学习新的 HTML5 元素时，看看合适的 ARIA 标志。

布局建议

在我们结束本章之前，让我回顾一下我认为我们应该如何在 HTML5 时代标记页面:

• 我们不应该使用新标签。(但我们接下来会看到它们，以及我们应该使用的咏叹调地标。)
• 鉴于盲人和视力受损的用户对标题的依赖程度，我们应该更加认真地对待标题。
• 我们应该使用 ARIA 地标来实现可访问性。
• 我们应该否则就像我们一直做的那样使用带有语义类名或 id 的<div>。(如果你想尖叫“但是它们没有语义！”，一定要看完关于语义学的第五章。)**

四、好吧好吧，我去拿标签。但是我告诉你，这一点都不好玩

那么到目前为止我们做了什么？

• 我们已经建立了 HTML5 的结构元素试图改进的广泛(有点模糊)的概念——大纲，这目前是通过标题标签隐式完成的。
• 我们已经确定了大纲的用途——帮助那些非常依赖文档标题的屏幕读者。
• 我们还提到了一种更好的方法，帮助盲人用户使用 ARIA 地标浏览我们的页面。

现在让我们看看 HTML5 规范(whatwg.org/html)是如何描述这些新的独立元素的，从…

关于<header>，你需要知道两件事:

1. 它实际上不做任何事情。
2. 它的预期用途并不像你想的那样。

<header>元素是一个很好的例子，其中一个常用术语在 HTML5 中有了新的含义，同时还被用来“铺路”。你可能一直都在使用<div id="header">,所以称它为<header>会更容易阅读，如果没有别的原因的话，对吗？好吧，这里有一个 HTML5 的每个人都使用它，所以让我们改变意义的时刻。说明书上是这么说的:

header 元素表示一组介绍性的或导航性的帮助。

注意:header 元素通常包含部分的标题(h1–h6 元素或 hgroup 元素)，但这不是必需的。header 元素还可以用来包装一个部分的目录、搜索表单或任何相关的徽标。

该注释具有指导意义——<header>的预期目的是包含一个部分的标题。请记住，sections 是用四个分节元素(article、section、nav、aside)之一创建的，并在 HTML5 中生成一个文档大纲。<header>元素旨在使切片元素内的工作。它不会自己创建一个节(尽管它通常在视觉上被表示为另一个节元素)，也不会添加到文档轮廓中。

可以把<header>看作是包装部分标题的东西，它可以是从文档最顶端的部分开始的任何东西，比如在<body>标签内的标题(也就是，徽标和所有我们通常认为是标题的“标题”东西)，一直到评论的标题。

真的，它什么都不做

元素所做的只是说“这是给定部分的标题”。问题是，虽然你的标记可能会这么说，但目前没有一个浏览器或用户代理在监听。

根据希克森的说法，它们可能永远不会成为(参见希克森在本章后面的“结论:R.I.P. HTML5 结构标签”中的评论)。所以这个元素现在不做任何事情，以后很可能也不会做任何事情。这在语义上相当于一棵树倒在森林里，周围没有人听到。

假定<header>元素没有修改或添加到文档大纲中，那么您在文档大纲中看到的作为项目符号的实际标题(例如“我的伟大博客”)仍然由<h1> - <h6>元素设置。<header>标签只是包装那些标题元素，以及任何其他标题元素，比如日期。所以你可以这样做:

`

My blog post

Published on...

`

无处不在，屏幕阅读器怎么用？

你可能认为屏幕阅读器可以跳过<header>元素，直接进入内容。但是我们(或用户代理)无法确定文档中的第一个<header>是主页面标题。如果你的标记是非标准的顺序(首先是内容，然后是页眉、页脚和侧栏)，文档可能会有许多<header>，其中没有一个我们称之为典型的“页眉”。因此，在处理页面的“整体”标题时，我们又回到了起点。

咏叹调替代:横幅

幸运的是，对于盲人用户来说，还有一个选择。ARIA 标志banner划分了我们目前所知的“标题”。以下是 ARIA 规范如何定义横幅地标(www.w3.org/ TR/wai-ARIA/roles # banner):

主要包含面向网站的内容，而不是特定于页面的内容的区域。

面向网站的内容通常包括网站赞助商的徽标或身份，以及特定于网站的搜索工具。横幅通常出现在页面的顶部，通常横跨整个宽度。

它应该在每个文档中只出现一次，这样屏幕阅读器就可以直接跳到那里，并且相当确定它是什么——这正是我们想要的。

建议

元素太宽泛(也太无意义)而没有用。相反，在适当的元素上使用更具体的 ARIA role="banner"(如果需要的话，为 IE6 使用一个冗余的“banner”类)作为页面的传统“header”。

规格如下:

nav 元素表示链接到其他页面或页面内部分的页面部分:带有导航链接的部分。

并非页面上的所有链接组都需要包含在 nav 元素中——只有包含主要导航块的部分才适合 nav 元素。特别是，页脚通常有一个指向网站各种页面的简短链接列表，如服务条款、主页和版权页面。在这种情况下，单独的页脚元素就足够了，不需要 nav 元素。

<nav>元素确实在你的大纲中创建了一个新的部分，并且受益于:

• 有点不言自明
• 有看似有用的目的。

这个想法是，如果我们用<nav>标签标记我们的导航，盲人可以绕过它，直接进入内容，当他们想去别的地方时，直接跳到导航链接。

无障碍的胜利，对吗？

善意；无障碍灾难

尽管有这些良好的意图，但为一部分人这样做可能会破坏另一部分人的导航:禁用 JavaScript 的 IE 6、7 和 8 用户。

由于 IE6-8 处理“未知”元素的方式，这些用户不会获得该元素的任何 CSS。它可能会影响一百个用户中的一个——比使用屏幕阅读器的人的比例更高——使得使用这一元素的整个想法在中短期内有点不切实际。(这是所有 HTML5 元素的问题，我们将在本章后面进一步讨论。)

ARIA 替代方案:导航

幸运的是，我们可以使用 ARIA 地标navigation，通过在适当的<div>(或<ul>)上包含role="navigation"来使我们的导航更容易访问，而不会损害其他人的可访问性。ARIA 规范将导航地标(【http://www.w3.org/】TR/wai-ARIA/roles # navigation)定义为:

用于导航文档或相关文档的导航元素(通常是链接)的集合。

建议

使用role="navigation"。认为<nav>元素有害，直到只剩下极少数的 IE8 用户。(这实际上是指 Windows XP 用户，因为 IE8 是他们将得到的最后一个浏览器。我们可能要等一会儿。)

和

这些听起来一样(每个人都会把它们搞混)，但是它们有不同的用途。我们先分别看一下，然后比较两者。请试着不要扔无生命的物体或小动物，同时试着用头抱住它们。

规格如下:

section 元素表示文档或应用程序的一般部分。在这种情况下，节是内容的主题分组，通常带有标题。

章节的例子可以是章节、选项卡式对话框中的各种选项卡式页面或者论文的编号章节。网站的主页可以分为介绍、新闻条目和联系信息几个部分。

注意:当联合元素的内容有意义时，鼓励作者使用 article 元素而不是 section 元素。

注意:section 元素不是通用的容器元素。当出于样式目的或者为了方便脚本而需要一个元素时，鼓励作者使用 div 元素。一般规则是，只有当元素的内容在文档的大纲中明确列出时，section 元素才是合适的。

好吧，让我们试着理解一下。<section>元素应该表示文档中的通用部分。因此，如果这一章是一个网页，我们可以用<section>标签把它分成几块。它还可以表示主页的不同区域，从新闻条目到联系信息。但是它不应该被用作样式的通用容器元素——那需要一个<div>。

它也不应该用于页面的内容区域(<article>也不应该)，但是我们在讨论缺少的<content>元素时会谈到这一点。

区段==大纲

同样，理解<section>的关键是理解文档大纲和文档分节的概念。规范提到了这一点(阅读第二条注释的最后一句)，但当<section>是创建文档大纲的主要工具时，这并不多。根据经验，就创建大纲而言，如果它不是<article>、<nav>或<aside>，它很可能是<section>。

这也是为什么你不应该使用<section>对通用容器进行样式化。如果你只是把它们扔进去，这样你就可以设计一个区域而不用考虑你的轮廓，你会得到一个不合逻辑的、破碎的轮廓，这就破坏了使用<section>的全部意义。这是一个常见的错误，表明它们在规范中的解释、专家的提倡以及社区的理解是多么的糟糕(我并不是在责怪社区)。

俄罗斯娃娃

别忘了:你可以嵌套节(不管是由<section>、<article>、<nav>还是<aside>创建的)。正如我们在第三章中看到的，在纯 HTML5 领域，这决定了<h1> - <h6>元素的真正标题级别——而不是你使用的标题级别。在 HTML5 中，用户代理(理论上)只是把它们看作是一个部分中的通用标题元素。

所以我们可以在任何地方使用<h1> s，用户代理会判断它们是否嵌套为<h1>或<h101>。然而，对于屏幕阅读器来说(现在，可能还有很长一段时间)，我们需要恰当地使用<h1> - <h6>标题，不管我们使用什么风格的 HTML。

建议

如果你想以 HTML5 的方式创建大纲，你将主要依赖于<section> s。这个元素花了 20 多年才进入规范(回想一下上一章蒂姆·伯纳斯·李的评论)，而且人们可能还需要 20 年才能正确理解它。

没有对应的咏叹调。

你可能会认为“文章”就像“报纸文章”。嗯，你真可耻，以为一个新的 HTML5 元素会有直观的含义。在这里，它更像是“一件衣服”。是的，另一个有着非直观意义的“语义”术语。

规格如下:

article 元素表示文档、页面、应用程序或站点中的自包含组合，并且原则上是可独立分发或可重用的，例如在联合中。这可以是论坛帖子、杂志或报纸文章、博客条目、用户提交的评论、交互式小部件或小工具，或者任何其他独立的内容项目。

当文章元素被嵌套时，内部文章元素表示原则上与外部文章的内容相关的文章。例如，站点上接受用户提交的评论的博客条目可以将评论表示为嵌套在博客条目的 article 元素中的 article 元素。

以下是 2012 年初 WHATWG 邮件列表上的希克森(lists.whatwg.org/·皮珀邮件/whatwg-whatwg.org/ 2012-1 月/034506.html):

涵盖了广泛的语义:

-论坛文章
-报纸文章
-杂志文章
-书籍
-博客文章
-评论论坛文章
-评论报纸文章
-评论杂志文章
-评论博客文章
-可嵌入的互动小工具
-社交网络上带有照片的文章
-评论社交网络上的照片
-规范
-电子邮件
-回复电子邮件

在 HTML4 中，段落就是段落，段落就是段落。在 HTML5 中,“文章”是论坛帖子，是博客评论，是小工具，是实际的文章。如果一个元素有这么宽泛的含义，怎么才能更有“语义”？就像决定把刀、叉、勺、盘子、电视都叫“叉”。

这不是为牛仔铺路。

同样，最好从轮廓的角度来理解。<article>元素用于在您不想使用<section>时创建一个部分，这通常是在您包装一些内容块(或“交互式小部件”，视情况而定)时。

该规范讨论了如何将一个<article>整合为一个自包含的元素，但是如何以及为什么会这样还不清楚(使用 RSS！)是找问题的解决方案。

规格应说明

<article>的主要问题是它有不同的解释(“原则上”是什么意思可重复使用？").当规范把事情留给你去解决时，它就失败了。规范的全部意义在于明确规定你应该做什么。但是在这里它是开放的，没有明确的好处，并且重复现有的功能(它是有不同名字的<section>)。

文章和评论嵌套

当内容相关时，您还可以将<article>嵌套在<article>中。该规范建议将博客评论包装在<article>标签中，然后嵌套在博客条目的整体<article>中。这就是“叉子”和“勺子”都是“叉子”的问题。如果你有<article class="post">和<article class="comment">，那么article就变成了div的更冗长的形式。

为什么不直接添加一个<comment>元素，至少为标准的文章后接评论模式提供基本的标记，这个模式几乎被网络上的所有博客和出版物所使用？那不是在为牛仔铺路吗？伊恩·希克森不这么认为，他在这个问题的语义上注入了自己独特的观点:文章和评论之间没有区别(lists.whatwg.org/·皮珀梅尔/whatwg-whatwg.org/ 2012 年 1 月/034506.html):

我认为认为网站所有者的言论在某种程度上不同于网站读者的言论是不合时宜的。他们有什么不同？

相反，在网络上没有什么不同。一篇文章不过是被提升到更显著位置的评论。

具有讽刺意味的是，在这些“话语”之间定义至少一个差异，然后宣称没有差异，这显然没有被希克森理解。

当然，这也违背了经常提到的目标，即这些元素主要是为了帮助作者维护他们的文档。如果曾经有过标记模式出现的例子——一篇文章，后面跟着评论——这就是了。然而，既是运动员又是裁判的希克森丝毫不为所动，坚持自己独特的哲学观点，即所有的“评论”都是平等的，仅此而已。我们只能在 HTML5 中嵌套<article> s，而网络上的内容看起来将会一直是<article> s。

搜索引擎不需要

有些人可能认为<article>可以帮助搜索引擎，但是他们不需要标签来知道你的内容在哪里。他们的整个存在依赖于他们能够找到你的内容，而不需要那种帮助。即使<article>被广泛使用，他们如何通过单独的标记知道<article>是指博客帖子、论坛帖子、交互式小工具、评论还是其他什么？这对 SEO 来说太宽泛了，即使他们真的在乎你用了什么标签(他们大多不在乎)。

(我们将在第六章讨论 HTML5 和 SEO 时对此进行更多讨论。)

不为“主要”部分

而<article>不是用来表示页面的内容区域。这里没有实际的元素——这是我们稍后将讨论的缺失的<content>问题。

我还不能确定这种元素的定义中是否包含任何非法物质。

建议

你应该用这个吗？我不会。相反，我会把它归入“在被证明之前毫无用处”这一类。如果一个实用的好处出现了，疯狂吧。在那之前，通过。

像<section>一样，没有对应的咏叹调。

那么

和

有什么区别呢？

你需要知道的一些事情:

• 文章可以嵌套在文章中。
• 文章可以按节分解。
• 一个部分可以分解成文章，文章又可以有单独的部分。
• 人们不擅长一致地使用标记。

你猜怎么着？除了少数标记超级书呆子，任何真正使用这些元素的人(如果有人这样做，我会感到惊讶)只会制造一个巨大的混乱。但是，也许我错了。

就我个人而言，我宁愿拿一个生锈的土豆削皮器去削我的小手指，也不愿去争论<section>和<article>的优点。有争论的事实证明了规范的失败。如果你在实现一个元素时不得不争论它，你就输了。

然而，关于这一细微区别的数千字已经出现在博客帖子(例如，Bruce Lawson 的 take:www.brucelawson.co.uk/ 2010/html 5-articles-and-sections-what-the-difference/)和评论帖子中。

人们可能会希望，当我们只是为了决定使用哪个 HTML5 元素而制作善意但荒谬的流程图时，社区就会明白这种情况的荒谬性(参见:html5doctor.com/下载/h5d-sectioning-flowchart.png)。唉，看来还没有。所有这一切都是因为一个或三个 WHATWG 成员在 2004 年决定将这些额外的<section>味道加入 Web Applications 1.0 规范。

好了，我们撕掉了创可贴，熬过了 HTML5 新元素中最痛苦的部分。但是仍然有一些粘性的残留物，脱落时会有点刺痛，所以让我们看看最终的切片元素。

问:你把引用、附加信息和侧边栏叫做什么？

如果你说，“一段引用、附加信息和侧边栏”，你就输了——呸。你叫他们“靠边站”。很明显，是吧？规格如下:

side 元素表示页面的一部分，它由与 side 元素周围的内容无关的内容组成，并且可以被认为是与该内容分离的。在印刷排版中，这样的部分通常被表示为侧栏。

该元素可用于印刷效果，如引用或侧边栏、广告、导航元素组以及被认为与页面主要内容分离的其他内容。

很难理解为什么引用、广告或博客导航元素(包括博客滚动和归档的<section>——这是规范中的用例)应该被称为相同的东西。但是在 HTML5 结构语义的怪异世界中，它们是存在的，你可以愉快地忽略它们。

在奇怪的地方创建一个大纲部分

先不说是否在文档大纲中创建了一个部分，鉴于其广泛的使用案例，这使得它更加奇怪。(为什么引用应该是它自己的部分？)如果只是为了一个侧边栏，或者甚至叫做<sidebar>(最初的名字)，那可能有意义，但它不是，也没有意义。

*### ARIA 替代:补充

在这种情况下，ARIA 标志性的替代方案是complementary，ARIA spec 将其描述为(www.w3.org/ TR/瓦伊-aria/角色#补充):

文档的支持部分，旨在补充 DOM 层次结构中类似级别的主要内容，但在与主要内容分离时仍然有意义。

有各种类型的内容可以恰当地扮演这一角色。例如，在门户的情况下，这可以包括但不限于节目时间、当前天气、相关文章或要观看的股票。补充角色表示所包含的内容与主要内容相关。如果补充内容是完全可分离的主要内容，使用更一般的角色可能是合适的。

建议

在适当的<div>(或其他元素)上使用role="complementary"作为你的模板中的侧边栏(以及任何其他适当的地方)。

还记得<header>是如何看似显而易见，实则不然吗？嗯，和<footer>也是一样的处理。听起来它应该只是主页脚，但实际上它可以是任何给定部分的页脚。以下是 HTML5 规范:

footer 元素表示其最近的祖先节内容或节根元素的页脚。页脚通常包含有关其章节的信息，如作者、相关文档的链接、版权数据等。

一个部分的作者或编辑的联系信息属于一个地址元素，可能它本身在一个页脚中。

页脚不一定要出现在一节的末尾，尽管它们通常会出现。

像页眉一样，页脚是您在一个节中使用的东西，它们本身不会创建一个节。同样，这令人困惑，因为在 HTML5 书籍和博客文章的例子中，页脚似乎是模板中一个独特的视觉部分，与<article>或<aside>同等重要，而事实上它根本没有出现在文档大纲中。它只是描述了父部分的一部分，无论该部分出现在哪里(无论出现的频率有多高)。

页脚也不做任何事情

和<header>一样，<footer>实际上什么都不做。事实上，<footer>连一个元素的结尾都没有去。规范在<article>部分给出了一个例子，其中注释的元数据(注释作者和时间戳)被包装在一个<footer>中，并放在注释的顶部——等等。显然这个元素还不够混乱。

同样，这里没有牛巴铺路。我当然没有听到一千个网页设计师为页面上的每一部分大声疾呼<footer>元素。是吗？

胖脚？祝你好运！

如果你有一个时髦的“胖页脚”，里面有一堆链接和其他信息，该怎么办？如果是一大块内容，那就应该是一个小节，所以你可以使用四个小节元素中的一个——<nav>、<section>甚至<aside>。

但是，为了保持有趣，你可以在<footer>标签中包装那个切片元素。因此，<footer>既可以将内容限定在文档大纲的部分中，和可以将文档大纲中的其他部分换行，但仍然不能单独创建一个部分。

像泥浆一样清澈，是吧？我不明白为什么会这样，我怀疑大多数网页设计师也不会明白。我见过比这些元素更有意义的日本游戏节目。

能给我一只脚吗，老板？

关于元素的提议已经存在很长时间了。当 2002 年——大约十年前——在 W3C 公共邮件列表上讨论 XHTML 2.0 时，人们很快就开始批评它(见:lists.w3.org/档案/公共/www-html/2002 aug/0257.html)，说它不会提供任何实际的好处。十年后，这种批评似乎仍然有效。

ARIA 替代:Contentinfo

再说一次，就可及性而言，艾瑞亚是救星。它的contentinfo标志反映了传统页脚的内容(即页面底部的一些链接和一些小字)，没有呈现名称。ARIA 规范将其描述为(www.w3.org/ TR/瓦伊-aria/ roles#contentinfo ):

包含有关母文档信息的大的可感知区域。

页面此区域包含的信息示例有版权和隐私声明链接。

与<footer>不同，它应该只在每个文档中使用一次。

建议

我们可以对页脚使用一次<div role="contentinfo">。如果有大量的导航元素，我们也可以继续使用<div id="footer">(或者你喜欢的任何东西)和role="navigation"。

我的元素在哪里？

到目前为止，我们已经讨论了四个分段元素(<nav>、<section>、<article>和<aside>，以及定义这些分段中的区域的两个元素(<header>和<footer>)。

这些元素主要定义了文档大纲中的各个部分，我怀疑许多 web 设计者会为此费心。但是假设你决定使用它们。您开始标记整个模板，用四个切片标记创建切片，并在适当的地方插入<header>和<footer>。

但是等等，少了点什么。实际内容区域使用什么标签？

一个<div>。

不，我不是自作聪明。真的没有<content>或<main>标签。

为什么不呢？伊恩·希克森认为这是多余的。根据定义，一个完美标记的 HTML5 页面中的任何东西，如果不是<header>、<nav>、<aside>或<footer>(可能还有顶级的<section>，但我们不去那里)就是页面的<content>。

以下是希克森在推特上解释这一决定(twitter.com/ #！/Hixie/status/892228541):

任何不在

、

虽然这种逻辑很可爱，但告诉 web 设计人员用显式(通常是多余的)标签标记页面的不同部分，而不用担心实际内容(页面的主要部分)，因为它的标记是隐含的，这是荒谬的。

当事情像这样被暗示时，你必须是“知情的”。不幸的是，大多数网页设计者并不“了解”这个特殊的规则，因此会不知不觉地误用<section>或<article>来填补感觉上的空白。

布鲁斯·劳森解释了他在html5doctor.com(lists.w3.org/档案馆/Public/Public-html/2009 aug/1366.html)上看到的:

不考虑纯度，作者想要有一个

标签。

HTML5 doctor 收到许多关于如何标记主要内容的电子邮件，这可以说是对

的最大误用，因为人们正在使用

来做这件事。(HTML5 doctor 本身是这样做的；我们知道，并计划改变它)

也许我们都被那些邪恶的网络标准人士洗脑了，但是你用他们自己的元素标记外围的东西似乎是不对的，但是主要的内容——页面的目的——仅仅得到一个微不足道的无意义的类属

。

(杰瑞米·基思也附和着支持一个<main>元素:lists.w3.org/档案馆/Public/Public-html/2009 aug/1397.html。)

假设 web 作者将正确使用其他 HTML5 结构元素和理解他们的“主要”内容应该只使用一个<div>而不是一个显式标签是很糟糕的。最好是将标签添加到规范中，这样用户代理就可以直接跳到它上面(假设他们决定支持它)。

尽管在 HTML5 的发展过程中，这种反对意见被提出过几次，但希克森不同意，仅此而已。没有你的汤标签。

ARIA 替代:主

幸运的是，我们还可以使用另一个 ARIA 标志，简单来说就是main。它做我们希望它做的事情，并为我们试图帮助的人服务——盲人用户。

下面是 ARIA 规范如何定义main(www.w3.org/ TR/瓦伊-aria/ roles#main ):

这标记了与文档的中心主题直接相关或扩展的内容。主要角色是“跳转到主要内容”链接的一个不显眼的替代，其中到主要内容(或其他地标)的导航选项由用户代理通过对话或辅助技术提供。

建议

在页面的主要内容区域使用一次<div role="main">。

其他 ARIA 地标

这里有更多的 ARIA 标志，在标记你的页面时可能会有用:

• application用于页面上的软件小部件。
• form对于表单，除了搜索之外，哪些会得到…
• search用于页面上的搜索表单。

他们和我们看过的其他人一样:

• banner为整体表头。
• navigation因为，你猜对了，导航。
• complementary为侧栏。
• contentinfo为页脚。
• main为主要内容区。

(注意，banner、main和contentinfo在每个文档中只能使用一次。)

有关这些地标的更多信息，请参见 Steve Faulkner 对 HTML5 元素的精彩对比:www.paciellogroup.com/博客/2010/10/using-wai-aria-landmark-roles/。

关于 ARIA 的更多信息，请参见 Mozilla 的 ARIA 文档:developer.mozilla.org/·恩/ aria 。

有趣的事情发生了…优雅的退化消失了，JavaScript 变成了强制性的

在前几章中，我已经多次提到这些元素会对另一小组用户造成伤害。对于一些用户来说，如果他们关闭了 JavaScript，这些标签会在 IE6、7 或 8 中破坏你的页面(由于个人选择和过于热心的安全考虑，这比你想象的更常见)。

问题是 IE 6-8 如何处理“通用”元素。对 IE6-8 来说，通用标签是它不能识别的任何东西，不管它是完全虚构的元素，像<mymadeuptag>还是 HTML5 的<nav>。鉴于 IE6-8 根本不识别通用元素，我们无法在不使用少量 JavaScript 告诉 IE6-8 它们存在的情况下设计它们的样式。

这个聪明的 JavaScript 变通方法是由 Sjoerd Visscher 发现的，并由 Remy Sharp 在 2009 年推广(参见:html5doctor.com/ how-to-get-html 5-working-in-ie-and-Firefox-2/)。现在我们可以用一点点 JavaScript 告诉 IE6-8 特定的元素确实存在，我们可以愉快地离开了…或者我们可以吗？

不，我们不能。

但是我们可以吗？

号码

(声明一下，有问题的 JavaScript 可以在这里找到:code.google.com/ p/html 5 shiv/。正如我们在第二章中提到的，你还需要告诉其他浏览器用 CSS 把新元素当作块级元素。)

现在我们遇到了一个大障碍:关闭了 JavaScript 的 IE 6-8 用户没有得到 HTML5 的修复。

坚持住。现在真的有人关闭 JavaScript 吗？有什么数据可以给我们一些启示吗？

是的，有。

雅虎的 JavaScript 研究

2010 年，雅虎公布了他们对这个问题的研究结果——有多少访问者禁用了 JavaScript？结果显示，访问雅虎美国网站(包括大量非美国流量)的访问者中有 2.06%禁用了 JavaScript，英国、法国和西班牙的这一比例分别为 1.29%、1.46%和 1.28%。(巴西是个例外，只有 0.26%。).

*所以，除非你是为巴西用户设计，否则你仍然需要考虑禁用 JavaScript 的用户。

你可以在这里阅读这项研究:developer.yahoo.com/博客/ ydn/ posts/ 2010/ 10/多少用户禁用 JavaScript/以及雅虎 ydn 博客上的developer.yahoo.com/博客/ydn/posts/2010/10/follow-up-多少用户禁用 JavaScript/。

让我们假设美国主要网站的高流量为 2 %, IE 6-8 用户占你的受众的 50%。这意味着每一百个用户中至少有一个关闭了 IE6-8 和 JavaScript。即使是千分之一，对于一个中等繁忙的网站来说，每天至少也有一个人。

那么如果使用 HTML5 结构化标签，这些访问者会怎么样呢？

如果你在现有的标记周围使用<section>标签(或任何其他标签),而不使用样式，什么都没有。如果你真的想的话，你仍然可以用那种方式创建轮廓，只要你记住盲人用户仍然依靠标题来浏览你的页面。

但是如果你使用<header>、<footer>、<nav>、<aside>或者<article>(或者<section>)，而你很可能使用它们，坏事情 ^TM 就会发生。

具体来说，禁用了 JavaScript 的用户会看到你的站点样式正常，除了使用 HTML5 元素的设计部分的。当这些元素包装我们的导航、标题、侧边栏或文章时，我们就有问题了。这些元素——不像页面的其他部分——不会应用我们的 CSS 样式，因此可能会以非常严重的方式中断。

事情是这样的…

例如，这是我的一个客户网站的主导航，首先用<div id="nav">包装一个普通的<ul>链接列表:

图 4.1。禁用 JavaScript 且没有 HTML5 元素的站点导航。

这是 IE7 中禁用 JavaScript 的一个<nav>元素:

图 4.2。同样的导航使用 HTML5 的

不酷，对吧？这只是一个因素。想象一下，如果标题和侧边栏以类似的方式分解，而正文、包装器和内容区域仍然保持样式。不漂亮。

怎么办？哦，XP…

最安全的做法是根本不给 IE6-8 用户禁用 JavaScript 的样式(这可以通过条件语句和用 JavaScript 编写样式元素来实现)。但是我不提倡这样做——你仍然在不必要地破坏他们的体验。

IE9 及以后呢？令人欣慰的是，IE9 识别 HTML5 元素，并改进了处理一般元素的方式。

也许 IE9 迟早会取代 IE6、7、8，这些非 JS 用户我们就可以忘掉了。啊，那将是一个怎样的世界。不幸的是，Windows XP 用户永远不会得到 I e9——I E8 对他们来说是穷途末路。只要 XP 还在，我们就会有 IE8 访客，他们的体验会因为这些元素而被不必要地破坏。

没人应该忍受这些。

像<nav>这样的元素应该(理论上)帮助视力受损者。但是当我们按照规范中的意图使用<nav>(例如)时，正如 HTML5 倡导者教导的那样，作为现有结构标记的替代，我们以一种非常真实的方式不必要地伤害了另一个少数群体。

哦…网页设计社区，发生了什么？

网页设计界对 HTML5 大肆宣传的最不幸的一点是，我们很快就忘记了优雅退化的传统。当然，我们不想局限于最小公分母。但是 IE8 离这还有很长的路要走，给那些禁用 JavaScript 的人一些更简单的东西和给他们一些简单的东西是有很大区别的。

让我澄清一下，如果您的特定网站需要 JavaScript，我没有问题(关闭 JavaScript 会以不同的方式破坏 IE6-8)，这是您明智的选择。但是我确实有一个问题，这个问题在 web 设计社区中几乎完全被忽略了，不知情的设计者和开发者给一小部分用户带来了不必要的痛苦。

光是这个问题就削弱了这些新元素的有用性，所以我建议坚持使用<div> s 作为结构，ARIA roles 作为可访问性。ARIA 角色至少可以帮助解决一个少数群体的可访问性问题，而不会破坏另一个群体的网站。

正如 http://lists.whatwg.org/·皮佩尔梅尔/whatwg-whatwg.org/ 2012 年 1 月/034506.html 所说的那样:

自然，如果你对

的一切都满意，欢迎你继续这样做。

结论:R.I.P. HTML5 结构元素

也许最奇怪的是，我不确定规范编辑伊恩·希克森是否清楚这些新元素的用途，或者其他专家认为它们会有什么用途。

在与 Opera 的布鲁斯·劳森(2010 年《介绍 HTML5(新骑手)》的合著者)在 2009 年 WHATWG 名单(lists.whatwg.org/·htdig.cgi/·whatwg-whatwg.org/ 2009 年 3 月/018888.html)的交流中，劳森说(着重部分由作者标明):

毕竟，据我所知，还没有用户代理可以使用 time、section、footer、datagrid 等功能，但我们大多希望很快会有。

以下是希克森的回答:

我没有。大多数新元素只是为了使样式更简单，这样我们就不必使用类了。

这就是希克森的基本原理——不需要使用类——我们前面已经提到过了。但有趣的是，他并不期望用户代理会用它们做什么。他已经放弃了剖切和勾勒吗？这不就是为什么这些元素被放在第一位的原因吗(记住它们早于任何研究)，这不就是希克森在他编辑的规范中描述它们的方式吗？

这些元素是一个失败的原因。如果人们仅仅使用这些元素而不是类(他们已经是了)，他们不会考虑他们将要创建的大纲。他们可能假设<header>创建了一个部分(它没有)，或者使用<aside>作为引用(并且在这样做的时候创建了一个新的部分)，这将意味着很多破碎的 HTML5 大纲。

因此，用户代理(尤其是屏幕阅读器)将很少有动力使用 HTML5 大纲——这些元素的要点——作为导航手段，因为它们将会(并且已经)是一团乱麻。

很悲哀，不是吗？蒂姆·伯纳斯·李在 1991 年提出的分段愿望最终使它成为了一个可发布的 HTML 规范(在 XHTML 2.0 项目流产之后)，二十年后却遭到了误解和滥用。

这是之前的我们考虑了规范中的歧义，事实上它们破坏了 IE6-8 中的样式，以及它们使标记一个基本的 HTML 页面变得多么复杂，所有事情中的*。*

下面是约翰·奥尔索普(2009 年《用 Web 标准开发》的作者)在杰弗里·泽尔德曼的博客(www.zeldman.com/ 2009/07/13/html-5-nav-ambiguity-resolved/# comment-44699)上对新元素的评论:

当我深入研究规范时，将我的注意力主要集中在新的“语义”元素上，如 section、article、header、footer 等等，我发现了许多含糊不清、解释不清的特性，以及令人困惑的包容规则[以及]近乎拜占庭式的复杂性。

[…]最近，XHTML2 的死亡让很多人欢欣鼓舞。但是对 XHTML2 的许多合理批评也可以归咎于 HTML 5。和许多其他的，特别是规范本身也可以被拉平。是时候解决这些问题了。

我们有标记页面的解决方案:

• 对类使用<div>(和/或如果需要，在页面上出现一次的单个id)
• 使用适当的标题元素
• 适当添加 ARIA 地标，就大功告成了。

现在描述结构化标记就是这么简单。

HTML5 已经失去了这种简单性。

这是坏消息。好消息是，一切都还没完。我们可以借此机会尝试以更好的结构化方式使用标题，让盲人和视力受损的用户生活得更轻松一些(出于同样的原因，开始使用 ARIA 地标)。我们可以高兴地知道，我们现有的 HTML 结构标记技术将在未来许多年里很好地为我们服务。

让我最后说，尽管我批评 HTML5 规范的这一特定部分(以及 web 设计社区对它的支持)，如果没有伊恩·希克森和 WHATWG，就不会有我们今天所知的“html 5”——我们仍然可以等待 W3C 一起行动。我的目的不是恩将仇报——只是咬它的手指一点点。

接下来，我们来谈谈这个‘S’字:语义。**

五、我们来谈谈语义学吧，宝贝。

关于新 HTML5 结构元素的一个常见说法是它们“更具语义性”。

在我看来，新元素“更有语义”，就像水果味的糖果棒“更有营养”一样——一点也不。

然而，HTML5 中的语义问题给了我们一个很好的借口来快速浏览一下“语义”标记的全貌。我们将看看语义标记从何而来；语义标记承诺提供但从未真正提供的东西；最后，我们将快速浏览一下你现在可以使用的东西——由主要搜索引擎公司(谷歌、微软和雅虎)提出的新模式，有望改善你的搜索结果的显示。

到本章结束时，你的标记书呆子 dar 将被调整得如此之好，你将能够把那些把“语义”作为一个时髦词汇的标记装腔作势者与那些仍然在等待语义网到来的铁杆标记书呆子区分开来…

简而言之，语义学

说到 web，实际上有两种“语义”——给定网页的本质标记和所谓的语义 web。让我们从我们作为网页设计师每天练习的语义标记开始。

“语义标记”是网络标准运动的基石之一。2003 年，Jeffrey Zeldman，也许是语义标记和网络标准最著名的倡导者，在他的博客(www.zeldman.com/日报/ 0303a.shtml )上写道:

CSS 与精益语义标记的结合使得网站更快、更易移植、更易访问。这种结合有助于站点在更多的现有环境中工作，并且是为尚未开发的环境做准备的最好希望。

对于网页设计师来说，这是理论和实践上的一个重大变化。正如 Zeldman 所说，我们会将页面的所有样式信息保存在一个单独的 CSS 文件中，并用“精简的语义标记”来描述内容。

下面是 Zeldman 在 2002 年的一篇数字网络文章中使用的语义标记的一个例子(www.digital-web.com/文章/999 _ of _ websites _ are _ obsolete/)。首先，Zeldman 从一个电子商务网站上借用了一些“不具意义”的标记来展示我们正在远离的东西(当你读它的时候不要害怕):

<td width="100%"><font face="verdana,helvetica,arial"``size="+1" color="#CCCC66"><span class="header"><b>Join now!

然后，用 CSS 处理样式，标记就变成了:

<h2>Join now!</h2>

瞧，它就在那里:精简的语义标记，我们现在几乎认为是理所当然的。在实践中，这是一个巨大的、非常值得的转变。

但是是什么让这个例子“语义化”而不是第一个呢？“语义”只是“有意义”的一种奇特说法，通过使用标题标签(<h2>)，它现在对浏览器(和屏幕阅读器)来说意味着一些东西——“这是一个标题”。屏幕阅读器可以(也确实)使用这些标题在文档中导航，浏览器可以为这些元素提供默认样式(例如，使其成为块级元素)。

它也让我们人类阅读起来很容易。当我们浏览标记时，毫无疑问这是一段文字——它是一个标题。简单吧？

这突出了“语义标记”中的两个关键群体:人和机器(浏览器、屏幕阅读器、搜索引擎等)。)它应该是“人类可读的”和“机器可读的”——语义标记 101。

“机器可读”语义标记还有其他好处。搜索引擎可以扫描、索引和搜索我们的内容，这种方式在 Flash 网站或纯粹由图像组成的网站(印刷设计师偶尔会粗制滥造)中要困难得多(如果不是不可能的话)。

也就是说，谷歌不太在乎你使用什么标记。

这些问题已经解决了

事情是这样的:这些问题的解决方案已经存在十多年了，不管你用的是什么风格的 HTML。搜索引擎可以索引我们的内容，屏幕阅读器可以理解它，我们精简的语义标记使它易于阅读和维护。

然后学究们接手了。

网页设计圈的人开始想“嗯，如果语义好，那么更语义一定更好，对吧？”

不完全是。

除了人类可读性和基本的机器可读性之外，“更多的语义”没有任何意义(讽刺！).但这并没有阻止人们讨论哪些元素更具语义性或更合适，这十有八九与讨论它是“splade”(或者更准确地说，对你们这些坚持己见的人来说是“splayd”)还是“spork”一样有用。(显然是 Splade。)

没有“更多”语义这回事

我谦卑地提议，在关于 HTML 元素的网页设计讨论中，禁止无限制地使用“更多语义”。

每当你听到有人说某事“更有语义”，问他们这个简单的问题。

“给谁的？”

如果他们只能说“但是…更有语义！”，他们只是无中生有地含糊其辞。但是如果他们说类似“对屏幕阅读器来说更有语义性”这样的话，那就是一个我们可以评估的有效声明。

屏幕阅读器真的为这些“更多语义”的元素做了什么不同的事情吗？它们是否得到支持？或者它们会像 HTML5 元素第一次使用时那样导致错误吗？(见:【http://www.accessibleculture.org/ ?? 博客/2010/11/html 5-plus-aria-sanity-check/)

(记住:由于没有 JS IE6-8 的问题，使用 HTML5 元素实现可访问性就像用一个孩子来娱乐另一个孩子。)

同样，如果他们说“但是对于搜索引擎来说，它更有语义*，我们可以评估这个特定的声明。谷歌的开发者指南是怎么说的？SEO 社区怎么看？等等。*

但是，请不要在讨论 HTML5 的时候再提出“但是它的语义更加丰富”这样的非限定性说法。这些可疑的假设多年来一直像藤壶一样附在 good ship Web 标准上，现在是我们加速高压软管并清理它们的时候了(假设藤壶实际上是这样被清除的)。

好了，迷你咆哮结束。人类可读性和基本的机器可读性问题已经解决，这就是我们的现状，我们可能希望 HTML5 将带我们前进。但是在我们讨论 HTML5 的方法之前，让我们先来谈谈语义标记背后的重要思想。

语义标记的伟大构想——语义网

如果我们能进一步发展语义标记的“机器可读”部分会怎么样？如果机器(尤其是浏览器)可以读取我们的标记，不仅知道出现了什么内容，还知道给定的内容块实际上意味着什么，那会怎么样？

这是语义标记背后的重要思想。如果我们能准确地描述我们页面的内容，特别是 ?? 的内容，那么机器就可以用这些数据做很酷的事情。

这是(或者可能曾经是)部分“语义网”背后的思想——一个由 XML 化的网络驱动的大而广的概念。(在这里了解更多:en.wikipedia.org/维基/语义网。)网络将是一个完美描述的文档库，用 XML 极其详细地标记出来。许多有影响力的人都相信基于 XML 的未来。事实上，在 2002 年的早期标记示例和<h2>的使用中，Zeldman 将 web 标准描述为一种我们可以“从过去的 Web 语言 HTML 过渡到未来的语言 XML”的方式。

然而，正如我们在第一章中所看到的，向 XML 的转变已经死亡，真正的“语义网”的梦想也随之破灭。相反，网络成为了一个奇妙的应用平台，走向了社会化，并继续成为我们所熟知和喜爱的网络。但这并不是人们所希望的首都语义网。

当人们在任何情况下谈论“语义”元素时，无论是 HTML5 还是任何未来的 HTML 发展，我们都需要记住这段历史。他们指的是哪种“语义”——我们每天都在使用的人类和机器可读的基本语义，还是 XML 驱动的语义网的死胡同？

语义:还没死，或者，Google & Co 抛出了一个微语义炸弹

实际上，在我们现在使用的精益语义标记和空想语义 Web 之间还有第三种选择——微数据(和微格式),它给我们的标记增加了一层元数据。

(各种方法在这里竞争，特别是微格式、微数据和 RDFa。但是我只是将整体概念称为“微语义”，也称为“结构化数据”。)

使用微语义，我们只需将语义数据嵌入到现有的 HTML 文档中。让我们看看微语义学如何帮助网络上的日常生活。

具有真实(微观)语义的电子商务

我们以网购为例。在这里，真正的语义标记理论上可以帮助桌面浏览器(即我们所有人)、使用屏幕阅读器的视障人士和搜索引擎。

桌面浏览器:假设我们正在网上购买一台新电视，并通过访问一些网站来比较特定型号的功能和价格来进行研究。在大多数情况下(好吧，如果你像我一样痴迷于研究)，这意味着将每个网站的相关信息复制并粘贴到一个单独的文档中——这既繁琐又容易出错。

现在，想象一下，如果这些电子商务网站都用一个<productdetail>标签和嵌套的<price>和<specs>标签来标记它们的页面。我们的浏览器可以很容易地找到页面的产品细节部分，只需点击一下，我们就可以将价格和规格添加到比较购物列表中。有了特定的、有意义的标签，你的浏览器——一台机器——可以很快地为你找到、编辑和分类某些信息。毕竟这是他们最擅长的。

**屏幕阅读器:**它也可以帮助盲人或视力受损者。想象一个盲人为一个新的音响系统做同样的研究。如果电子商务页面标有这些<price>和<specs>标签，理论上它们的屏幕阅读器可以读出价格和产品规格。然后，他们可以将这些细节保存到他们的比较购物清单中，继续前进。但在此之前，他们必须尝试通过向他们朗读标题和内容来浏览高度复杂的页面。

搜索引擎:通过正确标注价格和规格，谷歌、必应和其他搜索引擎可以在搜索结果中相当可靠地显示产品价格，改善整体搜索体验。(这实际上现在是可能的，我们将会谈到。)

它们只是当我们拥有真正的语义标记时可能发生的事情的几个例子。机器——浏览器、屏幕阅读器和搜索引擎——可以很容易地挑选出有用的信息，并用它们做一些很酷的事情(比如创建一个比较购物清单)。

问题是，要使用不同的标签来描述这些数据，HTML 规范需要大量不同的标签。每种内容——从诗歌到产品到政策文件——都需要自己的标签，这样机器就知道内容是什么。随着越来越多的标签被添加到规范中，HTML 标签列表实际上是一个小字典，或者说是一个非常大的字典。写 HTML 的作者很可能会失去理智。

好消息是我们可以标记我们的内容，使这种比较购物成为可能(特别是搜索引擎例子),而不需要更多的 HTML 标签。我们只是用机器可读的属性和值来注释现有的 HTML。(这个我很快会再讲。)

然而，添加少量 HTML5 风格的新元素并不是通向“更多语义”文档的途径。它们不能帮助机器处理数据，我们的标记变得更加混乱——很难让它更可读。

相反，我们需要一种新的机制来描述这些数据。希望这就是 HTML5 将引领我们的方向。

真正的语义学请站出来好吗？

我知道你在想什么。“如果我们有办法添加不污染整个规范的标签就好了。某种可扩展标记语言。”但是正如我们在第一章中看到的，我们尝试了，但失败了。

很明显，我们需要一种方法来扩展 HTML，而不涉及 a)向规范中添加相当于字典的元素，或者 b)尝试 XML 化 web。

还有第三种选择，一群人已经研究各种解决方案好几年了。

简单地说，这个想法是这样的:只需将带有一组约定的术语值的属性附加到我们现有的 HTML 中。下面是一个例子(我已经编好了属性和值):

<div class="myclass" semanticdata="mysemanticvalue"> ... content ...</div>

如你所见，这很简单。但是梳理一下术语是值得的，因为不同的术语和实现会使一个简单的想法看起来比实际复杂得多。

我们需要区分微观语义的几个部分:

• **基础设施:**当向文档添加语义数据时，我们可以采取不同的技术方法(例如，我们使用什么 HTML 基础设施)。归结起来就是我们使用哪些属性——现有的class属性(微格式)，新的 HTML5 属性，比如itemprop(微数据)，或者属性，比如property和content (RDFa)。毫不奇怪，对事实感兴趣的人会为哪个最好而激动不已。但是是我们说什么，而不是我们怎么说，那就有趣多了。
• **词汇:**我们所说的——我们在这些属性中坚持的类数据——是橡胶上路的地方。我们需要共同努力让它发挥作用。实现数据的人(网页设计者)和可能使用数据的公司(例如搜索引擎)需要就一组稳定的术语——词汇表——达成一致，以描述一篇评论、一个人或一件事，这样每个人都在同一页上。
• **概念:**然后是围绕不同的方式构建的社区来实现这个基础设施和词汇表，并利用它做一些很酷的事情。

一个一直在用微语义数据做很酷的事情的团体是微格式社区。他们有一个活跃的社区(microformats.org/)，一种使用 HTML 作为基础设施的微格式方式(class属性)，以及特定的微格式词汇表。这些是微观语义的不同部分，并展示了社区如何能够在网络上以一种有意义的方式来研究语义。

您可能听说过，并且可能在过去实现过微格式。不幸的是，正如我所写的，它的未来或多或少被搜索巨头扼杀了，他们提出了微语义或“结构化数据”的新方法。

为什么要关心微观语义？

当我写这篇文章时，谷歌、微软和雅虎！发起了可能是 web 历史上最大的一次将真正的语义引入 HTML 文档的努力。

他们是如何发射的？在匆忙的午休时间，我写了一篇博文，创建了一个拥有“我的第一个 HTML 页面”模板的网站。他们还成功地单枪匹马地激怒了已经投入到这个过程中的每个人，这些人多年来一直在宣扬微语义学。不是一个好的开始。

图 5.1。Schema.org。谁说语义不性感了？哦…所有人。对吧…

schema . org—语义的未来？

2011 年中期，谷歌、微软和雅虎的一些工程师。决定他们不喜欢当前社区驱动的方法，并宣布他们选择 HTML5 的微数据作为获胜的基础设施(即我们应该用来添加微语义数据的 HTML 属性)。因此，他们发布了 Schema.org(schema.org/)——一个词汇表，或“模式”，主要搜索引擎将使用它来显示更丰富的搜索结果。

这样，微语义派的三个部分都被改变了。基础设施(HTML5 的微数据)、词汇(Schema.org)和驱动因素(公司，而不是社区)都是全新的。

(你可以在这里阅读谷歌的公告:googlewebmastercentral.blogspot.com/ 2011/06/introducing-schemaorg-search-engines.html和微软的公告:www.bing.com/社区/网站 _ 博客/b/search/archive/2011/06/02/bing-Google-and-Yahoo-unite-to-build-the-web-of-objects . aspx。)

下面是一个更丰富的搜索结果的例子:

图 5.2。谷歌“iPhone 评论”，你会得到类似的结果。请注意包含了多少元数据——评级、审核者、日期和面包屑都在这里。

我们以前不能这样做吗？

这类似于谷歌在 2009 年推出的“丰富片段”微语义倡议，你可能听说过(甚至实现过)。但是 Rich Snippets 只支持少数现有的词汇表，并且允许作者在微数据、微格式和 RDFa 之间进行选择。(另外它只得到谷歌的支持。)

现在我们有了一个“认可的”实现基础设施(微数据)，一套集中的词汇表，以及实现它们的一个重要原因:在 Google、Bing 和 Yahoo！。

这是一件大事。

(记住这纯粹是为了搜索结果显示，而不是搜索排名。我们的客户知道这两者的区别是很重要的。)

值得注意的不是搜索巨头选择了一种基础设施，而是 300 多种词汇，它们可能会在未来几年定义 web 上的语义。这一切都是在没有任何标准流程(或社区参与)的情况下闭门完成的。

我们期待已久的语义网？

毫无疑问——这是自很久以前以来，语义在网络上发生的最大的、得到实际支持的事情。

回到第一章，我们看了 XML 应该如何转换 web 上的语义，但是没有。(那只是架构宇航员在工作。)我们还看了 HTML5 是如何添加一些语义元素的，这些元素要么是有害的，要么加起来很少。(向 HTML 本身添加更多元素不是语义的解决方案。)

这种微语义的方法承诺了一条中间道路，感兴趣的社区已经探索了一段时间。让我们先浏览一下现有的方法，然后再来看看 schema.org 的发射(以及它的所有糟糕之处)。

微格式

微格式社区在 2004 年启动后，多年来一直在开发和倡导微语义，并取得了一定的成功(参见:microformats.org/维基/微格式历史)。来自 http://microformats.org/关于:

微格式首先是为人类设计的，其次才是为机器设计的，它是一组简单、开放的数据格式，建立在现有的广泛采用的标准之上。微格式并没有抛弃现在有效的东西，而是试图通过适应当前的行为和使用模式(例如 XHTML、博客)来解决更简单的问题。

例如，在 2011 年 2 月，脸书的所有活动都使用微格式发布(见:microformats.org/ 2011/02/17/Facebook-adds-hcalendar-hcard)。使用适当的浏览器扩展(如 Chrome 的 Google 日历扩展),事件旁边会出现一个按钮，你可以点击它将详细信息添加到你的日历中。很漂亮，是吧？

microformats.org 的创始人之一坦泰克·切利克对谷歌和微软 schema.org 公司的声明(twitter.com/ #！/t/status/77083481494142976)作何反应？

#schemaorg 对每个从事 vCard、iCalendar 等开放词汇表工作的人和公司嗤之以鼻。

哎哟。

网页摘要和结构化标记

微格式是一种简单、直接、受设计限制的微语义方法。

RDFa(或 Resource Description Framework——in——attributes)是 W3C 处理机器可读数据的更复杂(但更灵活)的方法，自 1997 年以来一直被称为“RDF”。(RDFa 始于 2004 年。)它从未真正以任何显著的方式引起开发人员的兴趣，但它仍然存在。

六月中旬，当关于 Schema.org 公告的争论激烈时，马克·皮尔格林打趣道(twitter.com/ #！/dive into mark/status/80980932957450240—链接现在 404s 这是在朝圣者的互联网消失法案之前):

W3C:自 1997 年以来未能使 RDF 变得可口

赞。

但是现实世界中也有一些有趣的用法，比如用于电子商务的 GoodRelations 词汇表(www.heppnetz.de/项目/ goodrelations/ )可以推动我们前面看到的电子商务示例。

比起 RDFa 的灵活性和复杂性，Web 设计者通常更喜欢微格式的简单性。然而，对微语义感兴趣的社区已经围绕 RDFa 成长起来。

W3C RDF 工作组的现任主席 Manu Sporny 对谷歌和微软的 schema.org 声明作何反应？在《Schema.org 的错误选择》(manu.sporny.org/ 2011/False-Choice/)中:

《Schema.org》是三家大公司伪装下的一小撮人的作品。RDFa 和微格式并不依赖成千上万的 Web 开发人员来构建真正的开放标准。这不是我们在网上做事的方式。

呀。

微观数据

最后，我们有微数据，这是 schema.org 使用的新格式。

没有什么比几种相互竞争、略有不同的元数据格式更能迫使 web 作者在他们的页面上添加深奥的元数据了。因此，HTML5 的编辑伊恩·希克森认为微格式太冷，RDFa 太热，于是发明了第三种方法——微数据——他觉得刚刚好(可以这么说)。(以下是希克森在 WHATWG 上介绍这一功能的长篇帖子:【http://lists.whatwg.org/·htdig.cgi/·whatwg-whatwg.org/·2009 年 5 月/019681.html。)

注意，就 HTML5 规范而言，微数据是关于提供用于添加微语义的基础设施(带有新的有效属性)。它没有指定这些词汇表应该是什么，或者谁应该发明或维护它们。例如，它与 schema.org 的实际词汇完全分离。

从科技巨头的角度来看，这是一种获胜的模式。

(关于各种格式的更长的讨论，以及 Schema.org 的含义，见亨利·西沃宁的优秀的“schema . org 和预先存在的社区”hsivonen.iki.fi/ schema-org-and-Communities/。)

微观数据和 Schema.org

现在谷歌，微软，雅虎！不仅在推动单一的格式(微数据)，而且也在推动单一的词汇表集，以在 web 上实现真正的语义。

每样东西都有一个特定的词汇(或“模式”):书籍、电影、事件、组织、地点、人、餐馆、产品、评论，凡是你能想到的。(完整名单见此:schema.org/医生/full.html。)

甚至还有识别网页本身的模式，包括页眉、页脚、侧边栏和导航。我猜 ARIA，HTML5 之类的还不够。

如果这种技术开始流行，这是一个很大的“如果”，它将是我们如何标记页面的一场巨大革命——比 XHTML、HTML5 以及接下来的任何 HTML 风格都要大。

“语义网”终于到来了吗？

如何不启动新的计划

" schema.org…没有什么比扔掉多年的词汇/本体工作更好的了”
—杰·迈尔斯，2011 年 6 月 3 日，twitter.com/ #！/杰·迈尔斯/status/7634419867037696

如果这一新举措的不温不火的推出是值得借鉴的话，那就不会了。这几乎是一个教科书式的案例，告诉我们该做什么，不该做什么。

以下是一些他们本可以处理得更好的事情:

• **咨询:**Schema.org 的公告不知从何而来——没有咨询社区，也没有提前通知，只是希望“有所作为”。

• **拓展:**通常来说，惹恼那些多年来一直倡导与你的计划相似的东西的人并不是一个好主意。Google、Microsoft 和 Yahoo！没有让微格式和/或 RDFa 社区参与进来(或者至少鼓励迁移)。完全无视他们。这让他们很不开心。

• Schema.org 推出时是一个完全普通的网站，几乎没有人性化的一面，只有一个“反馈”按钮。谁编辑的？谁想出来的？我们该和谁谈？流程是怎样的？有流程吗？就网站而言，这完全是个谜。事实上，常见问题是“谁在持续管理 schema.org？”并回答“谷歌、必应和雅虎！正在持续管理 schema.org。”好吧，我想我们总是可以联系谷歌，必应和雅虎！那么。(公平地说，他们最终在这里建了一个 Schema.org 博客:【http://blog.schema.org/】??。)
  ** 新手友好:对于大多数网站设计师来说，微语义是一个相当“另类”的概念。虽然 Schema.org 确实有一本“入门”指南(【http://schema.org/文档】/gs.html)，但如果他们想让除了懂行的超级书呆子之外的任何人学会，它需要一个更友好的解释，说明微语义(包括模式示例)的方式、原因和内容。* **一个不错的网站:**模式列表最初是以 ASCII 艺术风格的列表呈现的，带有如下可怕的标记(schema.org/文档/full.html):

  <br> &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;<a name=Movie><a href=../Movie>Movie</a>:&nbsp;<span class="slot">duration</span>,&nbsp;<span class="slot">director</span>,&nbsp;<span class="slot">actors</span>,&nbsp;<span class="slot">producer</span>,&nbsp;<span class="slot">trailer</span><br>&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="slot">productionCompany</span>,&nbsp;<span class="slot">musicBy</span><br>*

(顺便说一下，那是描述电影的。)当他们甚至不能在自己的网站上使用基本的 HTML 语义时，我们应该如何认真对待这些微观语义呢？(更新:在 2012 年，此标记通过将列表更改为…一个巨大的表格，包含嵌套表格和间隔单元格。去想想。)*

更不用说列出的大量模式(超过 300 个！)，事实上微数据没有被正确执行(见:jenitennison.com/博客/ node/ 156 )，或者关于专利的问题(见:www.seobythesea.com/？p = 5608中途)。真是一团糟。

所有这一切都有可能是自网络诞生以来，网络语义的最大变化。

Schema.org 背后的人是怎么想的？

谷歌的产品经理 Kavi Goel 参加了 SemTech 2011(“语义技术大会”)的一个讨论 Schema.org 的会议。有些回答并不能激发信心。(参见 W3C 的官方记录:www.w3.org/ 2011/06/semtech-bof-notes-smaller.html。)

比如(略有删节):

伊凡·赫曼:Schema.org 就在那里，…你如何设想未来 schema.org 可能成为一个发展新词汇的地方？我[原文如此]的地方，使它成为一个更加开放的社会进程？

卡维·戈尔:我现在还没有一个很好的答案。我不认为任何一家公司想完全拥有它。通过选择 3，我们表明我们(谷歌)不仅仅是在这么做。[…]

然后它留下了一个问题，哪里是完全开放的讨论…我们还没有答案，但这很重要。我们需要整理外面的东西。

凯文·马克斯:我们的微格式有一个编辑按钮，你们的有一个反馈按钮。微格式的核心是我们达成一致。你说“我们在封闭的房间里做的”。你还没有展示你的作品，你的证据，别人怎么能参与进来。这才是最让人担心的。

卡维·戈埃尔:这个观点完全正确。微格式在创建开放社区方面做得很好。

对于我们为什么没有那样做，没有一个好的答案。

带着一大堆新事物来到微格式可能是一种选择。我们确实想在那里得到一些东西。

在讨论的早些时候，Goel 说:

成就是得到了一些东西。我们知道它并不完美。我们可以做得更好。我们希望这是迈向更广泛采用的一步。

希望如此。在这个阶段，急于“弄点东西出来”似乎弊大于利，但他们可以挽回自己。我们现在有了一种格式和一套词汇表用于 web 上的微语义。如果谷歌(和/或微软)真的投入一些资源，并且两家公司中的某个人真的获得了这个项目的所有权，这确实是一件大事。

值得赞扬的是，在 Schema.org 参与的人终于进行了协商，有关各方正在讨论前进的道路。例如，参见:“schema . org Workshop-A Path Forward”semanticweb.com/ schema-org-Workshop-A-Path-Forward _ b 23387。

另请参见 Schema.org 博客的零星更新，了解进一步的拓展努力:blog.schema.org/。

总结:语义和 HTML

当我写这篇文章的时候，Schema.org 声明的影响仍然在网上回荡。但即使如此，我们仍然可以说一些关于语义、HTML 和我们应该做什么的事情:

• **语义问题:**描述含义的真实语义，而不仅仅是结构，发生在 HTML 之上的一层。这似乎是解决网络上长期存在的语义问题的方法。XML 不会给我们带来真正的语义，更多的 HTML 标签也不会。它是我们现有 HTML 之上的一层微语义。
• 微格式和 RDFa 可能是死路一条:微格式这些年做得非常好，我喜欢它的简单格式。但谷歌和微软的决定让这些格式看起来像是死胡同，微语义生态系统(包括浏览器插件和验证器)可能会转向微数据和 Schema.org 词汇表。当然，Schema.org 也可能彻底失败，微格式社区(就其一而言)可以继续努力。(无论如何，谷歌不会放弃对的任何支持。)
• **参与进来:**阅读并尝试已经存在的微格式工具(如浏览器扩展和 bookmarklets)来体验微语义的可能性是值得的。但 Schema.org 似乎是未来的事实意味着我们作为一个社区需要研究各种模式并提供反馈。
• **问题依旧:**关于流程的很多问题(会有吗？)和 Schema.org 的未来仍然没有答案——正如卡维·戈尔所证明的那样，这些问题甚至连煽动者也无法回答。关于它的广泛使用还有更大的问题。主流采用会导致垃圾搜索引擎的尝试吗？(人家当然会去尝试。)会不会都变成“metacrap”(【http://www.well.com/】?? ~多克托罗/metacrap.htm)？我们拭目以待。
• **蓄势待发:**谷歌和微软对 Schema.org 的“请求原谅比请求许可更好”的态度意味着标准化进程将不会持续数年——最好现在就开始。如果它被广泛采用，我们的网上购物的例子可能最终会成为现实。现在，这里是 2012 年 2 月宣布使用 Schema.org 微语义来描述视频，这是“现在推荐的描述网络视频的方式”:【http://googlewebmastercentral.blogspot.com/】2012/02/using-schemaorg-markup-for-videos.html。
• 它现在正在被使用:像易贝、 IMDB 、烂番茄和其他公司已经实现了 Schema.org 的语义，并且正在从他们的搜索引擎结果的改进显示中受益，正如本文所展示的:www.seomoz.org/博客/ schema-examples 。

归根结底，Schema.org 是一个半满的玻璃杯，半空的玻璃杯。我们现在有了一套支持良好的标准语义模式，可以轻松地添加到任何 HTML 结构中。如果我们用谷歌、必应或雅虎搜索。我们可以取得切实的成果。添加语义数据的先有鸡还是先有蛋的问题已经解决，格式已经选定，模式已经发布。

但是匆忙的发布(至少可以说是乏味的)，放弃词汇表的任何标准过程，践踏多年的现有工作是一个沉重的代价。*

六、标记和 SEO 神话

书籍和博客中流传的一个奇怪的神话是，新的(甚至旧的)HTML 元素将有助于搜索引擎优化(SEO)。让我们现在就把这个问题搁置起来(把 phasers 设置为“咆哮”)，并考虑更广泛的标记和 SEO 问题。

SEO 就是给定的搜索项在搜索引擎(通常是谷歌，但也可能是必应，甚至是中国的百度)的索引中排名靠前。例如，我可能希望这本书在“HTML5 book”(嘿，我可以做梦)中排名靠前。但是这个排名和标记没有什么关系——不管是语义上的还是其他方面的。(我在这里做了很大的简化——像searchengineland.com和searchenginewatch.com这样的行业网站展示了现代 SEO 的广阔世界，但我们在这里将保持简单，并专注于标记和排名的问题。)

黑暗时代的 SEO

一百万年前，搜索引擎仅仅通过查看你的页面内容来对你的页面进行排名——使用了什么关键词，在哪里使用，以及出现的频率。直到今天，人们仍然认为他们需要“关键词”元标签(<meta name="keywords" content="redundant, page, keywords">)，因为谷歌在它的排名中使用它。

它没有。谷歌多年来一直忽视它，因为人们滥用它。(参见:googlewebmastercentral.blogspot.com/ 2009/09/google-does-not-use-kewords-meta-tag.html。)今天，关键字元标签只是作为一个有用的指标，看看哪些 SEO“专家”仍然停留在 90 年代。

填充你的关键词

还记得那个老笑话“换一个灯泡，灯泡，灯，灯泡，灯，照明，灯开关，开关，能源需要多少 SEO 专家”？

谷歌并不像我们想的那样关心我们网站上的关键词，因为当涉及到他们控制的数据时，人们会撒谎、捏造和欺骗。(要更广泛地了解这种元数据现象，请参见“元捕获”:en.wikipedia.org/维基/元捕获。)

谷歌的突破性创新是通过查看指向某个网站的链接的质量、数量和内容来了解其他网站对该网站的评价。也就是说，“离页”因素比“在页”元数据更能决定你的网站在给定搜索项中的排名。(这也是垃圾评论兴起的原因——人们试图通过到处张贴垃圾链接来游戏谷歌的排名，认为更多的链接会导致更好的排名。)

HTML 和 SEO

新的 HTML5 元素是元数据的一种形式——关于数据的数据——谷歌真的不在乎你是否使用<article>、<footer>、<div>，甚至是<table>来构建你的页面。

(不是真的，谷歌不在乎你是否用表格来布局。这并不是说你应该这样做，但它让你知道他们在处理什么。这里看马特·卡茨的解释:www.youtube.com/手表？v=fL_GZwoC2uQ 。)

谷歌必须理解网络的本来面目——光荣而丑陋的无效标签汤——尽可能把最好的信息反馈给用户。换句话说，对网络进行排名的责任落在了谷歌(以及必应和百度)身上，而不是落在每一个网络作者(包括那些使用首页的作者)身上，让他们提供完美标记的网页，让排名仙女保佑。

使用有效 HTML5 的 0.000001%的页面很大程度上是无关紧要的。谷歌不会抓取你的页面，然后说“哇，有一个<article>标签，我肯定会把这个页面排得比下一个更高！”(但如果你相信这一点，请参阅我的下一本书“30 个难以置信的 HTML5 SEO 秘密保证增压你的排名！”)

但是如果有帮助呢…不知何故？

SEO 可能是一个竞争异常激烈的行业，其基本策略通常是获得比你的竞争对手更多更好的链接(参见这篇文章和关于“链接建设”的现代方法的讨论:www.seomoz.org/博客/战略链接建设-为什么你不需要超越狮子)。

如果我们认真对待 SEO，这就是我们需要关注的事情。然而，尽管一个网站的链接简介意义重大，一些人仍然坚持认为，也许，只是也许，使用新的 HTML5 元素将“帮助”搜索引擎解析你的内容，并因此提高你的搜索排名。但是这就像说科比可以得到一些关于如何打篮球的建议。你可以假设他们现在已经在谷歌总部找到了答案。

同样，这并不意味着我们应该编写草率的标记——远非如此。毕竟还是要维护的。只不过新的、花哨的标记和搜索引擎排名关系不大。

当搜索引擎要求时，我们应该为搜索结果的显示提供更多的元数据。(正如我们在前一章所看到的，Schema.org 在这方面可能会有所帮助。)用于搜索结果显示的元数据不太可能被滥用，因此它应该仍然有用。我们只是不应该相信更多的元数据意味着更好的排名。

但假设我错了，谷歌确实看好 HTML5 标签。猜猜会发生什么？人们会滥用这些标签，试图获得优势，而谷歌会从一开始就取消这些标签带来的任何好处。这就是致力于高质量搜索结果的工程师大军与致力于操纵它们的网站所有者和 SEO 顾问之间的军备竞赛。

(请注意,“操纵”并不总是坏的——通过产生人们链接的伟大内容来增加价值，以良好的方式提高你的搜索排名，这是可能的，也是更可取的，正如 Matt Gemmell 在《非阴茎 SEO》中所描述的那样mattgemmell.com/ 2011/09/20/SEO-for-Non-dicks/。)

僵尸神话必须消亡…最后

当 web 标准刚刚起步时，我们可以认为 web 标准对 SEO 有好处，因为它们比 Flash 页面更好，Flash 页面使搜索机器人无法“看到”隐藏在 Flash 文件中的链接和内容。同样，将整个网站导出为图片的印刷设计师也没有给自己带来任何 SEO 好处，因为图片中的文本几乎是无用的。但就谷歌而言，如果有足够多的好链接回到一个网站，那么这与它的排名高度相关——即使它是一个纯粹的 Flash 网站。

这个关于 SEO 和标记的神话可能就是从这些开始发展起来的。如果基本的文本和标记有助于搜索引擎，那么更好的标记一定会帮助他们甚至，对吗？

不，是时候结束这个神话了:HTML5 对 SEO 没有帮助。你和下一个人之间排名的差异不是因为你在给定页面上使用的标签。HTML5 带来了许多有趣的东西(尤其是我们将在接下来的章节中看到的)，但改进的搜索引擎排名不在其中。用于 SEO 的 HTML5 和顺势疗法一样有效。

七、其他 HTML5 元素：好的、坏的和古怪的

我们已经比较深入地讨论了结构化标记，现在让我们来深入探讨一下本质。HTML5 重新定义了几个内联和块级元素，并引入了更多元素。我们将浏览一些更改和添加，然后考虑这些元素背后更广泛的哲学。

大胆尝试，否则就去死

让我们从一些看似无关痛痒的元素开始，比如<b>、<i>、<strong>和<em>标签，以及 HTML5 中的变化。

只有在网络标准的土地上，我们才能把像粗体和斜体这样简单的东西变成教条主义、高级理论和破碎的实用现实的复杂混合体。

当网络标准起飞时，我们都努力将表示与内容分开。字体标签和表格不再会扰乱我们的标记。相反，我们会用 CSS 来设计我们的页面，并用适当的标签以一种有意义的(即语义)方式来描述我们的内容。

这使得可怜的老标签<b>和<i>处境艰难。它们表面上是表示性的——它们描述了文本应该是什么样子，而不是它意味着什么——我们正在以手指所能携带的最快速度逃离表示性标签。所以我们都接受了<em>标签而不是<i>(表示“强调”)，以及<strong>标签而不是<b>(表示“强烈强调”)。这些新标签现在描述了文本的含义——它被强调，并且“强调”的文本看起来(或听起来)如何(理论上)取决于浏览器或屏幕阅读器。然后，我们可以出于纯粹的风格原因使用<b>和<i>，出于语义目的使用<strong>和<em>——这是一个微妙的区别，但仍然是一个区别。

我欣然接受了这种变化(你可能也是)，认为这很重要。但事实并非如此。是的，它有助于在表示和语义标记之间划出一条界限，但这是相当狭隘的观点。没有任何实际的好处。例如:

• **我们只是把一个换成了另一个:**给出的<strong>仍然是粗体文本，<em>仍然是斜体文本，我们只是把<b>换成了<strong>，把<i>换成了<em>，就这样。“强调”的内容和没有任何特别强调的粗体或斜体样式的内容之间的区别已经消失了，因为我们一直在用它们来表达。所见即所得的编辑对此尤其感到内疚。差别太微妙了。
• 屏幕阅读器完全忽略了它们:这些“语义”标签(据说)的主要好处是，屏幕阅读器可以“强调”或“强烈强调”地阅读文本。事实上，总的来说，屏幕阅读器完全忽略了它们。(详见:【http://www.paciellogroup.com/博客/2008/02/screen-readers-lack-emphasis/)进一步讨论。)
• **搜索引擎不在乎:**谷歌对待<strong>和<b>，以及<em>和<i> 完全一样。(参见马特·卡茨的视频:video.google.com/视频播放？docid=-1756437348670651505# 。)

因此，对于这些元素的所有教条主义，现实非常简单——使用你想要的任何东西。阅读它的人不会在意，阅读它的机器(屏幕阅读器、搜索引擎)也不会在意。

但是这些元素适合 HTML5 的什么地方呢？

我猜如果你正在写一个规范，你必须尝试弄清楚这些元素是如何被使用的，并强调(双关语)它们应该如何被使用。以下是规范中的内容(重点是附加的):

<i>—i元素表示以替换语音或语气的文本跨度，或者从正常散文偏移的文本跨度。

<em>—em元素代表其内容的重音。

<b>—b元素表示一段文本，该文本在风格上与普通散文有的偏移，但不传达任何额外的重要性。

<strong>—strong元素代表对其内容的强烈重要性。

HTML5doctor.com 有一整篇文章都在讲述这在理论上是如何工作的(见:html5doctor.com/ I-b-em-strong-element/)，但这真的是纯粹的虚构。如果你认为人们真的会用这种方式标记他们的文档，我有 150 亿个网页要给你看。正如伊恩·希克森自己喜欢说的那样(【http://www.webstandards.org/】2009/05/13/interview-with-Ian-hickson-editor-of-the-html-5-specification/):

如果他们(浏览器供应商)不实现它，这个规范只是一个虚构的作品。[…我不想写小说。

如果 HTML5 规范记录了实际的行为(例如，“铺平道路”)，规范只会说<b>和<strong>使文本加粗；<i>和<em>使文本倾斜；屏幕阅读器倾向于完全忽略它们。现实就是这样。其他都是虚构的。

这可能看起来微不足道，但我们已经触及了一个更大的哲学问题:在 HTML 中标记文档有多少是类似文字处理器的格式，标记文本的有多少是表示的？对于大多数网络作者来说——通常是我们的客户使用我们为他们建立的内容管理系统——这是关于文字处理器式的格式，，这没关系。我们很快会回到这个话题。

把你的锚绕在这上面，还有其他一些零碎的东西

让我们快速总结一下 HTML5 中的其他一些特性和元素

在块级元素周围环绕锚点

我们现在可以做一些事情，比如在标题和段落周围包裹一个链接，这对于像博客文章这样的项目是很有用的。我们需要设置 wrapping <a>元素来显示:block(参见:【http://mattwilcox.net/沙盒/html 5-block-anchor/test.html)否则可能会有意想不到的行为。

(有人报告了火狐 3.5 中的问题(见本文讨论www.smashingmagazine.com/ 2009/08/04/designing-a-html-5-layout-from-scratch/# highlighter _ 741571)，所以在块级元素周围包装链接时要彻底测试。)

我们可以使用一个新的<mark>元素来突出显示文本(使用适当的 CSS)，而不是使用<span class="mark">keyword</span>。例如，这可以在搜索结果中突出显示搜索关键词。

和

<figure>和<figcaption>元素让我们标记照片、图表、表格、代码片段或任何其他自包含的内容，这些内容引用自“文档的主要流程”，正如规范所说。所以，我们可能有:

<figure>``<img src="myphoto.jpg">``<figcaption>Yup, this is my photo.</figcaption>

(更多例子见 spec:www.whatwg.org/ specs/we B- apps/current-work/multipage/grouping-content . html # the-figure-element。)

这些元素可能对可访问性有些帮助(例如，屏幕阅读器可以读出图形及其标题)，但这是一个复杂的问题。更多信息请见史蒂夫·福克纳撰写的这篇内容广泛的文章:【http://www.paciellogroup.com/博客/2011/08/html 5-accessibility-chops-the-fig-the-fig-fig caption-elements/。

这些元素也遇到了我们前面讨论过的相同的 IE6-8 no-JS 样式问题。

新的<time>元素主要用于微格式(远在 Schema.org 出生之前),但应该对未来的微语义计划有用。除此之外，<time>复杂得令人迷惑。这是 HTML5 元素的戏剧女王，如果<time>是一个电视节目，它将是大胆而美丽的。

仅在 2011 年，它就被伊恩·希克森取消了，然后在 W3C HTML5 规范中被部分恢复，然后被希克森以一种改进的方式重新添加到 HTML 5-但我们只是称之为 HTML WHATWG 规范中。布鲁斯·劳森(Bruce Lawson)在这里写了关于<time>的移除和重现的博客:www.brucelawson.co.uk/ 2011/goodbye-html 5-time-hello-data/和这里:www.brucelawson.co.uk/ 2011/the-return-of-time/。

在 2011 年的所有戏剧性事件之前，它已经成为 WHATWG 邮件列表上的大量辩论的主题(伊恩·希克森在这里总结了 2009 年的一场辩论:lists.whatwg.org/·htdig.cgi/·whatwg-whatwg.org/ 2009 年 3 月/018888.html)。

值得思考的是，HTML5 编辑器如何能够心血来潮地任意删除一个元素，添加一个新的元素(<data>)，然后在面临强烈反对的情况下重新发明之前死去的元素，这应该是浏览器制造商可以实现的规范。

(如果你喜欢惩罚，或者刚从某种查理·西恩式的狂欢中走出来，并且真的需要睡眠，这里有一个超过 8000 字的关于<time>的 WHATWG 维基条目:wiki.whatwg.org/维基/时代。)

那么，我们如何使用这个新的、从坟墓中复活的<time>版本呢？

在当前版本中，<time>元素允许使用各种字符串，比如年份字符串(2011)、月份字符串(2011-11)、日期字符串(2011-11-12)、带有或不带有秒和微秒的时间字符串(14:54)、日期和时间字符串的组合(2011-11-12T14:54:39.92922)，以及更复杂的带有时区偏移量的字符串(2011-11-12t 06:52

例如，您可以这样使用它:

<p>The Y2K bug destroyed civilization on <time>2000-01-01</time>.</p>

这比最初的<time>元素更加自由，有效字符串的完整列表请参见规范:www.whatwg.org/规范/网络应用/当前工作/#时间元素。

<time>元素还允许一个机器可读的日期时间值，它可以被固定在datetime属性中，在<time>标签中有一些更人性化的东西(或者实际上，什么都没有)，比如:

<p>The Y2K bug destroyed civilization at the <time datetime="2010-01-01"> beginning of this year</time>.</p>

这对微语义很方便，比如 Schema.org 微数据。

您还可以添加一个 boolean pubdate属性来指示一个<article>(或者整个文档，如果它不在<article>中的话)的发布时间:

<p>This Y2k article published on <time pubdate datetime="2000-01-01T01:42">Dec 31, 1999</time>.</p>

(记住一个布尔属性通过包含它简单地表示“是”，即“这是出版日期”，或者通过排除它表示“否”——它不接受值。)

和

新的<details>元素可以作为一个显示/隐藏框，而不需要使用 JavaScript。它有一个布尔属性(即独立的，没有值)为open，它告诉浏览器默认显示打开的框。但是如果属性不存在，它将被折叠，用<summary>元素描述折叠时出现的内容。

这里有一个例子:

`
    Show/hide me
    

You can see this when expanded

`

这将产生以下结果:

图 7.1。

元件关闭(上图)和打开(下图)。

该规范建议它可以用在复杂的表单中(并以 OSX 的文件信息窗口为例),在那里你想要显示或隐藏某些设置或表单输入。浏览器供应商仍在努力解决默认情况下他们应该如何设计这个样式。目前只有 Chrome 支持。

这是对规范的一个奇怪的补充，也是 WHATWG 的一个奇怪的小创新。JavaScript 或 CSS 驱动的行为的常见模式近年来变得非常普遍(想想标签、下拉菜单、弹出框、灯箱等等)，但是没有人希望在纯 HTML 中复制这种功能。然而，显示/隐藏三角形控件被认为值得包含在规范中。这就是 WHATWG 的 HTML5 的小秘密。

一些现有的 HTML4 元素也被重新定义。

例如，<small>元素现在意味着“小字”而不是“视觉上的小”。我觉得在游戏这么晚的时候重新定义一个元素的想法很奇怪，但就是这样。

我甚至不知道是一种<address>元素。它是一个块级元素，在 HTML5 中，是给定部分(例如一个<article>，可能在<article>的<footer>)或文档本身的联系信息。该规范明确表示，对于任意的邮政地址，它是而不是*，应该在<p>标签中。如果 WHATWG 的人发现你把它用作了一个任意的邮政地址，那你就等着被人指指点点吧。*

在 HTML5 中,<cite>被重新定义为*,排除了*以前可以接受的引用人名的用法。现在只对作品开放。这真的惹恼了杰瑞米·基思，他在 24 种方式上写了这件事(见:24ways.org/ 2009/煽动暴乱)。同样，HTML 编辑器可以随心所欲地重新定义元素，这很奇怪。这提出了一个问题，我们是否应该为“内联语义”的这些元素而烦恼，这使我们…

我们甚至应该使用这些晦涩的小标签吗？

如果新的功能出现在浏览器或其他代理中(而不仅仅是 HTML5 规范的内部)，当然，这些元素中的一些可能会不时地被证明是方便的。

但是让我们后退一步，考虑一下纯“语义”文本级元素的更大图景。在讨论<b>和<strong>以及<i>和<em>时，我们已经谈到了简单的文字处理器风格的格式和标记含义的问题。现在让我们以<address>元素为例。2009 年 11 月，杰克·奥斯本在 HTML5doctor.com(html5doctor.com/地址元素/ )上写道:

自从 1995 年起草 HTML3 规范以来，address 元素就一直存在，并且在 HTML5 的最新草案中继续存在。但是在它创建了将近 15 年之后，它仍然在开发者中引起混乱。那么我们应该如何在文档中使用地址呢？

也许，在 15 年之后，是时候重新思考了。我们的目标是什么？我们还要再等 15 年吗？30 年后，网络最终会正确使用<address>吗？如果是，那又怎样？

15 年前，我们可能认为‘有一天’有人会用我们精心标记的页面做一些有用的事情。我们现在更清楚了。是时候重新评估了。我们花了 15 年的时间来试验 HTML，看看在语义和功能方面什么是有效的。是时候评估结果了。

如果 HTML5 真的在这里为 cowpaths 铺路，它将为像<address>和<cite>这样的元素开放定义(而不是收紧定义)，或者更好地让它们完全过时。我们不需要他们。他们什么都不做。HTML 之上的微语义让它们过时了。搜索引擎已经通过 Schema.org(以及更早的如 Rich Snippets)证明了他们想要微语义，而不是重新定义 HTML 元素。作者对它们没什么用。那么为什么要保留它们呢？

当谈到标记的这些更好的方面时，这是我们需要承认的事实。文档的 HTML 除了与格式(标题、段落、列表、链接等)明确相关的基本语义之外，其他方面都很糟糕。)，并提供通用的页面结构(使用<div> s，现在有一些 ARIA 角色随意散布)，但这就是它的美妙之处；正是这一点让它变得如此普遍和容易理解。

深入研究 HTML5 标记的细节揭示了另一个大杂烩。一些有趣的内容，一些令人困惑的内容，许多关于一些难以置信的小问题的争论，以及缺乏真正推动标记和网络向前发展的一致愿景。

话说回来，在这方面对 HTML 的批评并不新鲜。这是 1996 年，克莱·舍基在他的文章《赞美进化系统》中写的一段话(www.shirky.com/写作/evolve.html):

HTTP 和 HTML 是互联网协议的欢呼垫和欢乐蜂鸣器，只有作为精心制作的恶作剧才能理解。对于任何试图在网络上完成任何严肃事情的人来说，很明显，在全球超文本协议的各种实现中，我们有一个最糟糕的可能。

当然，除了其他人。

事实就是如此。

八、把这个放进你的表单里，然后让它冒烟

HTML5 表单是 HTML5 历史的一个很好的例子。W3C 的架构宇航员开发了一种基于 XML 的替代 HTML 4 表单的方法，称为 XForms(en.wikipedia.org/维基/ XForms )，它在 2004 年 10 月被宣布为 W3C 推荐标准。它很强大，但对网络完全没用。

在 2003 年末，提出了一种替代方案来扩展而不是取代 HTML 4 的表单(hixie.ch/规范/ html/ forms/ xforms-basic-1 )。WHATWG 称之为 Web Forms 2.0，并最终集成到 HTML5 中。

注意时间框架:2003 年。

WHATWG 在本世纪初至中期所做的工作是为了扩展基本的 HTML 表单，并解决使用 JavaScript 处理复杂表单交互时经常出现的问题。

但是在 2005 年，JavaScript 库的想法越来越流行，Prototype.js 达到了 1.0(en.wikipedia.org/维基/Prototype _ JavaScript _ Framework)，jQuery 在 2006 年达到了 1.0(blog.jquery.com/ 2006/08/26/jQuery-10/)。

Web 应用程序大规模起飞，对可靠的跨浏览器 JavaScript 库的需求变得越来越迫切。像 Prototype.js 和 jQuery 这样的库(以及其他许多已经开发出来的库，比如 MooTools)满足了这种迫切的需求，并且继续被开发，jQuery 的 UI 库在 2007 年末出现(blog.jquery.com/ 2007/09/17/jQuery-UI-interactions-and-widgets/)。其他成熟的、专注于 web 应用的 JavaScript 框架也已经出现(参见这里的对比:【http://en.wikipedia.org/维基/JavaScript 框架对比】??)。

在许多方面，这些库提供了 WHATWG 想要嵌入 HTML 的所有功能，而且速度更快。

慢慢本土化

尽管如此，原生 HTML5 表单功能开始出现在现代浏览器中，包括 IE10(IE9 及以下版本不支持 HTML5 表单)。虽然浏览器看起来很现代，但功能却不现代。到 IE10 发布的时候，距离 Web Forms 2.0 被提出已经将近十年了，HTML5 表单功能成为主流还需要几年时间(也就是 IE10 的使用变得广泛的时候)。

也就是说，更高级的 HTML5 表单功能也开始出现在移动设备中。例如，在 iOS5 中，一个简单的 HTML5 元素让我们可以访问原生的 iOS 日期选择器小部件。这突出了最好的 web 标准——我们放入一个简单的 HTML 元素，然后浏览器提供适当的小部件。在这种情况下，它是一个基于触摸的小工具，这在本世纪初是不可想象的。

在任何情况下，在未来的许多年里，在桌面上我们仍然会在表单中使用 JavaScript，即使只是为了支持 IE9 和更低版本。现代 JavaScript 库将变得更快，功能更丰富，并提供更多的功能(和样式选项)——所有这一切都发生在 WHATWG 2003 年关于表单的想法被广泛采用之前，这就是近年来浏览器开发的缓慢步伐(尽管有 Chrome)。

尽管如此，今天仍有一些我们可以使用的便利功能(尤其是针对移动设备)，我们将审视其他新功能，看看现在可以使用哪些功能(以及是否应该使用*)。*

*## 表单可以成就一个网站，也可以毁掉一个网站

设计师对形式有着复杂的感情，从模糊的厌恶到彻底的厌恶。(话又说回来，你可能是一个形式鉴赏家和规则的例外。)

然而，我们都需要开始热爱表单——或者至少不那么讨厌它们——因为我们网站的成功可能取决于它。不管人们是想注册、登记、结账还是联系我们，这都可以归结为表单的质量。

糟糕的形式是糟糕的业务，哦，天啊，还有一些糟糕的形式(见:几乎每一个小规模的电子商务网站)。你最不希望看到的是人们在最后一关给你钱，因为你的表现没有达到标准。

另一方面，设计深思熟虑的、人性化的表单(并对它们进行彻底的 A/B 测试)是一笔好生意。有时候是 3 亿美元的好生意:www.uie.com/文章/ three_hund_million_button 。

我提到这一点仅仅是因为表单在网页设计领域似乎被低估了，尽管它对一个网站的成功至关重要。人们已经写了整本关于表单设计的书(见:rosenfeldmedia.com/书籍/网络表单/ )。

但是现在让我们关注 HTML5 的表单特性。

好消息，坏消息

让我们做这个好消息，坏消息风格。

好消息是 HTML5 有了一些新的表单特性，使得表单不再那么依赖 JavaScript 来实现常见的功能，比如客户端验证、范围选择器、日期小部件甚至颜色选择器。

坏消息是 IE9(以及更早的版本)不支持其中任何一个。

好消息是脚本，包括 jQuery 库(例如flowplayer.org/工具/ )将让我们在支持的地方使用 HTML5 表单功能，并在浏览器缺乏支持的地方提供后备。

坏消息是，这些表单小部件的一些原生浏览器 UI 比它们将取代的 JavaScript 替代品更差，更难使用，更难(如果不是不可能的话)设计风格。

好消息是，表单的一些新增功能是向后兼容的，并为 iOS 和 Android 设备提供了一些不错的功能，所以你现在可以使用那些功能了。

坏消息是，当我写这篇文章时，大部分主要的 HTML5 表单功能实现不均衡，甚至在非 IE 浏览器中也是如此。因此，我们在实现时需要小心谨慎。

尽管如此，我们今天可以实现一些小事情。所以很快我们将从“不动脑筋的”方面来看 HTML5 表单功能，有点/有点/可能的功能，以及有趣但还没有准备好的功能。

HTML5 表单资源

在撰写本文时，跟踪哪个浏览器支持哪个表单特性(以及它们实现得有多好)有点像噩梦。随着主流浏览器的快速发布(尤其是 Chrome 和 Firefox ),在这里深入记录谁支持什么没有太大意义，所以在本章中，我们将只是浏览一下主要特性和主要的浏览器支持问题。如果你真的想深入研究 HTML5 表单，请查看下面的参考资料。

如果您正在寻找 HTML5 表单功能的当前浏览器支持和浏览器实现细节的权威细节，请参见 Wufoo 的优秀资源:wufoo.com/ html 5/。在我们进行的过程中，我会在 Wufoo 的 HTML5 表单站点上放置特定页面的链接。他们有:

• 完整演示
• 兼容性图表
• 支持/不支持行为的屏幕截图
• 浏览器怪癖的描述
• JavaScript 回退，等等。

太棒了。绝对值得一试。

其他有用的资源包括:

• 总是得心应手的caniuse.com/有很多关于浏览器支持的信息，有给定特性的更多信息的链接。
• 马克·皮尔格林的《深入 HTML5》一书有一个有用的章节，介绍了 HTML5 的一些新形式:diveintohtml5.info/·forms.html。
• Peter-Paul Koch 有一个方便的新 HTML5 输入和表单属性的兼容性表:www.quirksmode.org/ html 5/inputs.html。
• 维基百科上有一个广泛的(如果不是特别方便读者的话)浏览器兼容性图表，通过渲染引擎对浏览器进行分类:en.wikipedia.org/维基/Comparison _ of _ layout _ engines _(html 5)# Form _ elements _ and _ attributes。
• Opera 的开发者网站对新的 HTML5 表单功能进行了简单介绍:dev.opera.com/文章/查看/html 5 中的新表单功能/ 。
• 在我写这篇文章的时候，IE10 正在进行第四次平台预览。最新版本增强了对 HTML5 表单的支持，所以要小心旧的 IE10 信息暗示某些功能不受支持。先查一下微软的文档:msdn.microsoft.com/ en-us/library/hh 673546 . aspx # html 5 _ Forms。

HTML5 表单:无需动脑

HTML5 引入了一些我们可以马上开始使用的东西，特别是电子邮件地址、URL 和搜索术语的输入框。这些是我们熟悉的<input type="text">的替代品。好消息是，不会识别这些新的输入类型的浏览器会表现得好像这个字段只是type="text"。

HTML5 还为我们的输入字段(如autofocus和autocomplete)引入了各种新的属性，其中一些我们将在这里看到，其他的我们将在下面触及。这里的属性我们通常可以直接开始使用，因为浏览器支持相当好，并且浏览器的缺乏不是特别重要。

新的输入类型:电子邮件、网址、电话号码和搜索

HTML5 引入了一系列新的输入类型，iOS 和 Android 设备目前使用这些输入类型来显示适合该输入类型的键盘。有时这些接触是微妙的(电子邮件输入类型包括“@”键，url 输入类型得到一个“.”。com "键等。)并且有时它们更明显(例如，电话号码输入tel类型得到一个数字键盘)。

具有有用的移动键盘变体的新输入类型(至少适用于 iOS 和 Android)包括:

• 邮箱: <input type="email">
• URL: <input type="url">
• 电话号码: <input type="tel">
• 搜索: <input type="search">

图 8.1。不同输入类型的 iOS 键盘变体。

这些输入类型不仅在移动环境中有用——它们(尽管是搜索)也应该提供客户端验证。因此，在 Firefox 4+、Chrome、Opera 和 IE10 中，如果您使用type="url"作为例子，并且用户没有提供有效的 URL，您将得到一个类似这样的错误气泡(每个浏览器都有自己的变化):

图 8.2。使用新的输入类型还在支持的浏览器中提供了一些输入验证。

对于不同的输入类型和不同的浏览器，验证的实现是不均衡的(例如，tel根本没有指定的默认验证)，所以要小心行事。(当然，客户端验证只是为了方便用户。)

对这些验证错误进行样式化目前是高度实验性的。例如，WebKit 中有一些实验性的 CSS3 伪元素，允许您设计错误气泡。你可以在这个文档的末尾看到语法和结果:trac.webkit.org/ wiki/Styling % 20 form % 20 controls。

搜索输入字段与我们讨论过的其他三个字段略有不同——规范不要求浏览器做任何特殊的事情，但是一些浏览器(尤其是 Safari)在搜索字段的角落，可能会提供以前搜索的列表，并在您输入内容时提供一个清除按钮(一个带 x 的圆圈)。

如前所述，较老的浏览器只是将这些字段视为type="text"，所以现在使用这些输入类型没有坏处。

有关更多信息，请参见 Wufoo 文档:

• 电子邮件:wufoo.com/ html 5/types/1-email.html
• URL:wufoo . com/html 5/types/3-URL . html
• 电话号码:wufoo.com/ html 5/types/2-tel.html
• 搜索:wufoo.com/ html 5/类型/5-search.html

(还有其他新的 HTML5 输入类型，如range、number、date、??、，我们将在下面的“我还不会……”部分。)

属性:自动完成、自动聚焦、只读和拼写检查

自动完成

<input type="text" autocomplete="off">

HTML5 指定了一个autocomplete属性，这个属性对于关闭浏览器自动完成功能*(自动完成功能默认是打开的)特别有用。当浏览器的自动完成建议不合适(例如，规范建议的一次性授权密钥)或令人困惑(例如，当用户应该输入另一个名称时，自动完成建议用户的名称)时，您可能希望这样做。支持只出现在最近的现代浏览器中，根本没有 IE 支持。尽管如此，也没什么坏处。*

*### 自（动）调焦装置

<input type="text" autofocus>

boolean autofocus属性在页面加载时自动将焦点分配给给定的输入。要看到这一点，最快的方法是去google.com——搜索框会自动聚焦，你可以马上开始输入。这通常是用 JavaScript 完成的，但是对于一些用户来说这可能是一件麻烦的事情。例如，我的焦点现在在谷歌的搜索框中，我不能使用 delete 键返回我的历史记录中的一页——它认为我想删除搜索栏中的文本。

为了解决这个(相当温和的)问题，HTML5 将这种自动聚焦功能转移到标记中，而不是依赖于 JavaScript，因此您的浏览器可以(理论上)通过首选项或扩展禁用它。

IE9 不支持autofocus，但是 Mark Pilgrim 在这里详细介绍了一个后备脚本:diveintohtml5.info/ forms . html #自动对焦。

只读

<input type="text" value="You can’t touch this" readonly>

HTML5 指定了一个被广泛支持的(不言自明的)布尔readonly属性。

拼写检查

<input type="text" name="captcha" spellcheck="false">

使用spellcheck属性，我们可以按照autocomplete属性，对默认浏览器行为施加一些控制。例如，我们可以对不适当的字段关闭它，如验证码。你必须指定spellcheck应该是true还是false。

HTML5 表单:有点可能

这里有几个 HTML5 表单特性，在某些情况下可能会有帮助，或者至少可以让你在博客上进行试验。这里的浏览器支持可能是混合的；实现可能有所不同；并且应该考虑回落。

属性:占位符

HTML5 为表单字段引入了占位符文本，这是一个受欢迎的附加功能。设计者喜欢它，因为它允许我们将字段标签(或支持文本)放在字段本身中，并设计更紧凑的表单。在非 IE 浏览器(Firefox 3.7+，Safari 4+，Chrome 4+，iOS4+，Opera 11+)中支持很好，IE10 也会支持。

这个占位符文本的语法也非常简单。只需将placeholder="My placeholder text"添加到给定字段:

<input type="search" placeholder="Hit enter to search!">

图 8.3。活动中的占位符属性。

整洁，对不对？那么，为什么这是在“有点，也许”部分？

• **无样式:**对样式化占位符文本的支持目前还处于试验阶段(参见本讨论:【http://stackoverflow.com/】questions/2610497/change-an-inputs-html 5-placeholder-color-with-CSS)。
• **没有 IE9(及以下版本)支持:**IE9 及以下版本缺乏支持是一种耻辱，因为这在其他方面得到了很好的支持。缺乏对 IE9 的支持意味着我们必须在一段时间内提供替代方案，这可能会引发一些棘手的问题。幸运的是，Modernizr 特征检测脚本(【http://www.modernizr.com/】??)可以在适当的时候帮助提供后备。
• 回落是棘手的:然而，回落并不总是合适的。我们可以退回到 JavaScript，但是 JavaScript 占位符对于一些细节(例如用户名和密码)会干扰浏览器内置的自动完成功能，这会变得很难看。
• 转化率的一致性:这是回退比原生更好的问题。如果(如果！)现代的基于 JavaScript 的占位符文本提高了表单的可用性(从而提高了它的转换率，如果你真的下定决心，你可以通过 A/B 测试来发现),那么它应该用于所有的浏览器，不管它们是否支持 HTML5。事实上，如果 JavaScript 选项给了我们更多的设计灵活性，为什么还要使用原生功能呢？就目前而言，大多数 HTML5 表单功能都是如此。

HTML5 的简单占位符文本在简单的情况下可能是好的(当有支持时)，但是当转化率(和设计灵活性)都很重要时，JavaScript 解决方案通常会提供更多的灵活性(并且看起来更好启动)。

对于一个简单的特性来说，这需要考虑很多。希望占位符文本支持会成熟到这些问题没有实际意义的地步，但我们将等待 IE10 成为主流之前，发生这种情况。

更多信息，请参见:wufoo.com/ html 5/属性/01-placeholder.html

<progress value="77" max="100">77% complete</progress>

HTML5 在规范的 forms 部分引入了一个<progress>元素，它旨在表示“任务的完成进度”。它是为(令人惊讶的)进度条而设计的，通常(但不是唯一)用于 web 应用程序中，并随着任务的进展通过 JavaScript 进行更新。它可以指示上传进度，或者当没有给出值时，它可以指示客户端正在等待来自服务器的响应。

我们可以使用可选属性值和最大值来显示到目前为止取得的进展。对于不支持<progress>的浏览器，我们鼓励以文本形式内嵌进度。

这里的想法是浏览器应该在本地设置这个元素的样式，所以它看起来像一个典型的 OS 进度条(例如，类似于当你复制一个文件时)。截至发稿时，所有现代浏览器都支持<progress>不包括 Safari，但包括 IE10 (IE9 及以下不支持)。

这里有几个来自 OSX Chrome 的例子，来自彼得·贝弗卢的演示，你可以自己尝试一下(peter.sh/举例/？/html/meter-progress.html):

图 8.4。和元素的例子。

其他浏览器只是忽略标签并显示文本(例如“77%完成”)。关于浏览器兼容性的最新消息，请看 Wufoo 的便利图表:wufoo.com/ html 5/元素/2-progress.html。

这似乎是一个奇怪的附加，但当你考虑 HTML5 的 web 应用程序遗产时，它更有意义。

更多内容请见:wufoo.com/ html 5/元素/2-progress.html

<meter min="0" max="100" value="50">50 of 100 people "liked" this</meter>

虽然<progress>是一个‘有点，也许’，<meter>实际上应该归入‘我还不会’，但是它们在一起有意义，所以我们将把<meter>留在这里。

<progress>和<meter>元素听起来相似，但是它们有不同的用例，服务于不同的目的。<meter>元素用于度量，例如捐赠度量表示向 10，000 美元的目标前进了 5，000 美元。它还可以用来表示以某种方式投票的人的百分比，或者“喜欢”某样东西，或者表示某个事件售出的门票数量(正如规范所建议的)，甚至表示硬盘上的磁盘空间。很明显，这不是 ?? 的唯一标准，比如说，5000 美元本身，或者身高和体重。

希克森说他把它添加到规范中主要是为了阻止人们滥用<progress>。

描述量表的属性有六种:value 、 min 、 low 、 high、 max、、、optimum(只有value是强制的，下面我们会涉及其中的一些属性)。

然后事情变得很奇怪。

元素看起来很简单，但是使用 Chrome(如果他们采用了 experiment WebKit 特性，可能还有 Safari)会变得很奇怪。Chrome 应用了原生样式，所以你会得到像这样漂亮的指示条:

图 8.5。Chrome 中的元素。

然而，试图让事情变得简单和自然(把元素放进去，浏览器完成剩下的工作)会把我们带到一条奇怪的路上。如果我们想让<meter>元素的样式完全不同呢？好吧，我们必须撤销所有默认的浏览器样式，然后应用许多实验性的 CSS3，这在现代浏览器中几乎没有支持，正如史蒂夫·沃克曼发现的那样(见:www.steveworkman.com/ web-design/html-5-web-design/2009/my-problem-with-html-5-style-meter/)。

有多疯狂？WebKit 包括一些用于<meter>样式的实验性 CSS 伪类，包括meter::-webkit-meter-even-less-good-value，甚至还有一个内置的星级系统和-webkit-appearance: rating-level-indicator;(详见trac.webkit.org/ wiki/Styling % 20 form % 20 controls)。

一方面，很高兴看到浏览器实际上用 HTML5 元素做了一些事情——欢迎使用它们的实用理由。另一方面，把<meter>当作一个原生样式的表单控件会带我们走上一条非常奇怪的道路，因为有很多 bizarro CSS3。我们真的需要 WebKit 中的本地星级系统吗？现在，把<meter>看作是一个实验性的新事物，尤其是只有 Chrome 和 Opera 支持它。

更多内容请见:wufoo.com/ html 5/元素/1-meter.html

HTML5 格式:“我还不会，但如果你真的想，你可以”

我们先来看一下required和pattern属性，然后是其他几个回退到type="text"的输入类型，包括numberrangedate和color。**

***### 属性:必需

<input type="text" name="musthaveaname" required>

布尔属性required的作用与您所想的完全一样——它告诉浏览器给定的input(或textarea)在提交之前必须有一个值。注意，字段必须有一个name属性，这样required才能生效。

Safari 对该功能的半心半意的实现(见:css-tricks.com/论坛/讨论/11524/modernizr-giving-a-semi-false-positive-with-safari-input-attribute/P1)目前将该功能放在“我还不会……”篮子，当它向特征嗅探工具报告它支持的特征时，当它不支持时，产生一个误报。这使得在不借助浏览器嗅探的情况下很难创建一般的回退。IE9 及以下版本不支持required属性。

当用户试图提交必填字段为空的表单时，浏览器会以不同的方式警告用户。设置这些警告样式的能力也是非常实验性的——这与我们讨论新输入类型给出的验证警告的情况相同(例如，如果您在 URL 输入字段中输入非 URL 值)。如前所述，WebKit 提供了 CSS3 伪元素，让我们可以对错误气泡进行样式化:trac.webkit.org/维基/样式化 Form Controls 。

这个属性的另一个重要警告是(正如 Wufoo 页面所指出的),只有在提交整个表单时才会出现错误。现代的 JavaScript 技术会检查 blur 上的值(即，当您处理表单时)，因此更加用户友好。

更多信息，请参见:wufoo.com/ html 5/属性/09-required.html

属性:模式

<input pattern="[0-9][A-Z]{3}">

pattern属性允许我们指定一个正则表达式，给定字段的值必须匹配该表达式。(上面的正则表达式匹配一个后跟三个大写字母的数字，例如 1ABC。)这可能用于确保用户的邮政编码(或邮政编码)匹配适当的格式，或者提交的 URL 匹配特定的域(例如，如果提供 facebook 个人资料 URL，则它包含 facebook.com)。正则表达式不适合胆小的人。

不幸的是，pattern属性遭遇了我们在 Safari 中为required所遇到的同样的误报问题。它也遭受了我们为required讨论过的同样的可用性问题。

请记住，客户端验证应该只是为了方便用户而使用，而服务器端验证应该是最重要的。这种验证很容易绕过，显然不应该用于安全目的或输入卫生。

还有大量可靠的现代 JavaScript 验证脚本，我们将在一段时间内依赖它们，它们提供了更多用户友好的特性(比如在输入时进行验证，或者至少在浏览表单时进行验证)。

更多信息，请参见:wufoo.com/ html 5/属性/10-pattern.html

输入类型:数字(微调)

<input type="number" name="itemquantity" min="2" max="12" step="2">

前面我们看了电子邮件地址、URL 和电话号码的输入类型。HTML5 还引入了普通旧数字的输入类型。桌面浏览器通常使用这种输入类型来提供增加字段数值的 UI(例如，购物车中的商品数量)。

截至发稿时，只有 IE10、Safari 5+、Chrome 和 Opera 支持这种输入类型。iOS4 只是给你一个数字键盘，Opera 11 让你输入任何字符。number输入类型接受属性min和max来约束可能值的范围，接受属性step来增加一定的数量(例如，如果你买的东西只有一对，就增加两个)。

该字段的浏览器验证是一个大杂烩(更多信息请参见 Wufoo 页面)。然而真正的问题是用户界面。例如，在 WebKit 浏览器中，这是非常残忍的。他们给你这个可怜的“数字旋转器”，我看不出年纪大的人(至少)会如何处理这么小的按钮:

图 8.6。数字输入类型通常给出一个数字微调器。

这是一个浏览器制造商因糟糕的原生界面小部件而失望的例子。有更好的 JavaScript 方法为用户提供向上/向下箭头来增加值，并且您自己设计的任何小部件都将比 WebKit 实现更有用。

UI 问题、较差的浏览器支持和不一致的实现使得实现为时过早。

更多信息，请参见:wufoo.com/ html 5/types/7-number.html

输入类型:范围(滑块)

<input type="range" name="myslider" min="0" max="10" step="2">

type="range"输入给了我们一个滑块，这很好。Firefox 中没有支持，但在 Opera 和 WebKit(即 Chrome 和 Safari)中已经存在很长时间了，IE10 中将会提供支持。iOS5 中也支持。您还可以使用属性min、max和step来约束可能的值，以及滑块可以移动的增量。

图 8.7。Chrome 的范围滑块。

然而，浏览器的实现和样式有点杂乱无章。在我看来，有更好的 jQuery 选项可以提供跨浏览器支持、更多特性和更好、更一致的 UI。

在浏览器支持的情况下，您可以退回到原生的 range 小部件，但是您为什么要这么麻烦呢？只有当原生窗口小部件确实更好时(也就是说，确实有更多的人填写表单)，使用原生窗口小部件才有意义——在没有转化率数据支持的情况下，你不应该这样假设。现在(以及可预见的未来)，使用 JavaScript。

更多信息，请参见:wufoo.com/ html 5/types/8-range.html

输入类型:日期(时间/日历部件)

<input type="date"> <input type="month"> <input type="week"> <input type="time"> <input type="datetime"> <input type="datetime-local">

HTML5 指定了几个与日期和时间相关的输入(date、month、week、time、datetime、datetime-local)，这些输入应该显示日期选择器(用于日期、月份和星期)或数字微调器(用于时间值)。

不幸的是，浏览器对这些输入类型的支持比我们到目前为止看到的任何其他输入类型都要差。目前，Opera 是唯一一个实现日期选择器的浏览器，我们可以说，它具有功能外观。

图 8.8。Opera 相当实用的日期窗口小部件。

实际上，使成为唯一支持日期输入的浏览器。iOS5 已经引入了对其中一些日期输入的支持，为用户提供了用于这些字段的原生日期选择器控件，这确实非常方便。移动设备中的这种标准支持与我在本章中提出的“只使用 JavaScript”的观点形成了鲜明的对比。

如前所述，这是最好的 web 标准——很久以前构思的 HTML 功能以一种巧妙的方式在一个平台上实现，当这个功能被构思出来时，这个平台还不存在。

图 8.9。iOS5 日期选择器。

您是否应该尽可能使用本机功能？对于 IOS5 用户来说，当然可以。对于 Android 和其他移动用户？当他们赶上来的时候。在桌面上？再过几年，一个普遍支持的日期选择器小部件将在非紧急情况下变得很方便。但是当表单对网站的业务至关重要时，就样式和定制功能而言，要放弃很多控制。

相比之下，jQuery UI(举例来说)已经提供了可定制的、主题化的日期选择器小部件，这些小部件提供了多个月份、内嵌显示、键盘快捷键等等。

图 8.10。jQuery UI date 小部件是一个更加灵活的选项。

浏览器支持的极度缺乏意味着在可预见的未来，JavaScript 或日期窗口小部件将会破产，这并没有错。

更多信息，请参见:wufoo.com/ html 5/types/4-date.html

输入类型:颜色(颜色选择器)

<input type="color">

出于某种原因，HTML5 还指定了一个颜色选择器。

图 8.11。Opera 的颜色选择器小部件。

截至发稿时，只有 Opera 11+和(很奇怪)黑莓浏览器支持它。WebKit 支持目前处于试验阶段。有许多更好的 JavaScript 替代品。

更多信息，请参见:wufoo.com/ html 5/types/6-color.html

输入类型和元素:数据列表

<input list="mydatalist" name="phonelist"> <datalist id= "mydatalist">     <option value="iPhone">     <option value="Android">     <option value="Blackberry">     <option value="Windows Phone"> </datalist>

HTML5 引入了一个<datalist>元素，它与list输入属性结合使用，在您键入时在下拉菜单中提供一组建议列表。(如上所示，<input>元素上的list属性与<datalist>元素上的id属性相匹配。)这些只是建议—用户仍然可以输入他们想要的任何内容。它本质上只是一个简单的自动建议功能，比如说，当你在一个电子商务网站上填写你的详细信息时，可以用来选择你的国家。(通常的选择——一个巨大的<select>列表——通常被证明是相当笨拙的。)

图 8.12。Opera 的 datalist 实现相当不错。

不幸的是，完全缺乏 WebKit 支持(即 Chrome 和 Safari)使得目前很难推荐。然而，Firefox 4+，Opera 9+和 IE10 支持它。

对于这种功能，还有更好的 JavaScript 方法。例如，参见《收获》中的非常酷的选择:harvesthq.github.com/选择/ 。它提供了各种各样的列表替换，有非常干净的用户界面，对所有现代浏览器的可靠兼容性，以及对旧浏览器的优雅降级。

(Wufoo 不要提那可怜的老 datalist 了，查查本章开头列出的兼容性表，看看浏览器支持是如何整流的。)

你这个伪君子。我认为需要 JavaScript 是有史以来最糟糕的事情。

可能看起来很奇怪，当我在第四章前面批评 HTML5 的支持者让 JavaScript 成为 IE6-8 用户基本布局的强制时，我却在为表单提倡 JavaScript。这里的区别在于，对于禁用了 JavaScript 的用户来说，仍然可以优雅地降级表单——对于这些用户来说，使用 HTML5 元素时不会有优雅的降级。

可访问性呢？

如果我们将 JavaScript 用于表单，我们仍然应该努力确保表单是可访问的。有一种神话认为，屏幕阅读器可以忽略现代的、不引人注目的 JavaScript，就像 JavaScript 被禁用一样继续工作。不是真的。以下是罗杰·约翰逊(www.456bereastreet.com/档案馆/2010 11/accessibility _ myths _ in _ 2010/):

如果屏幕阅读器真的不支持 JavaScript，或者一般的屏幕阅读器用户禁用了 JavaScript，[那么使用不引人注目的 JavaScript 并且不太考虑可访问性将是]一种合理的方法。然而，屏幕阅读器运行在支持 JavaScript 的 web 浏览器之上，正如我在“不显眼的 JavaScript 不一定是可访问的 JavaScript”中提到的，大多数屏幕阅读器用户确实启用了 JavaScript。

为了让屏幕阅读器访问表单，它们需要适当的标签、描述和结构。(更多信息，请参见本文:webaim.org/技术/表单/ screen_reader )但他们仍然能看到我们的 JavaScript，所以我们需要让盲人用户也能使用它。

HTML5 表单到此结束！*****