HTML5-的真相-全-
HTML5 的真相(全)
零、简介
你好。我是卢克,普通的网页设计师。十多年来,我一直在建立网站,使用 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 规范。两个问题:
- HTML5 到底是什么?
- 谁在负责,现在在当权派(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 规范中的?
-
专家们考虑了各种使用案例,权衡了各种选择和替代方案,并在广泛咨询和仔细审议后,选择了最重要的方案。
-
web 设计者和 HTML 作者的社区(比如你和我)迫切需要某些元素来实现特定的功能,经过大量讨论后,社区提出了一个必要元素的候选列表。
-
采用了一种科学的、基于研究的方法,在这种方法中,标记模式被“在野外”研究,并被编码成一堆新元素。
-
一些标记专家认为这是个好主意,并在 7 年多前就把它们扔进了规范中。
而答案是……(d)。
“但我在[此处插入您选择的 HTML5 书籍]中读到,它更像答案(c)。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>
,你需要知道两件事:
- 它实际上不做任何事情。
- 它的预期用途并不像你想的那样。
<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> | | <a name=Movie><a href=../Movie>Movie</a>: <span class="slot">duration</span>, <span class="slot">director</span>, <span class="slot">actors</span>, <span class="slot">producer</span>, <span class="slot">trailer</span><br> | | <span class="slot">productionCompany</span>, <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"
的输入类型,包括number
range
date
和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/维基/样式化%20Form%20Controls
。
这个属性的另一个重要警告是(正如 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 表单到此结束!*****
九、画布让我(有点)希望我能做 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
-
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。)
音频和视频媒体播放器来拯救
真是一团糟。
幸运的是,人们已经编写了工具,可以将正确的视频(或音频)提供给正确的浏览器。这些媒体播放器在整个编解码器混乱和遗留支持问题中帮助您;提供丰富的定制选项;并且总体上使整个实现过程变得平滑。
这里有几个例子:
媒体元素(视频和音频,免费)
一种流行的音频和视频播放器,允许您使用一个文件(例如,H.264 视频文件)并在所有使用 Flash(或 Silverlight)的设备上部署一致的 UI,以便在 H.264 本身不支持的地方播放。它附带了一个 jQuery 插件,以及 Drupal 和 Wordpress 的插件。
VideoJS(视频,免费)
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 通过两种方式之一实现这一点:
- 通过给
<html>
元素添加一个类名(对 CSS3 特性特别有用),这样我们就可以为.coolfeature {}
编写 CSS 或者为.no-coolfeature {}
编写后备样式。 - 通过包含每个 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】
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战