上周，我参加了在英国伦敦举行的 伦敦 Ajax 用户聚会，并做了两场关于 HTML5 的演讲。一个是之前在麻省理工学院关于网络多媒体的演讲的重播，另一个是呼吁大家合理使用 HTML5 的号召。您可以访问 Skillsmatter 网站观看这两场演讲 - 但也请务必查看本文中对第二个演讲的笔记。

除了我在这里的笔记之外，Ian Alderson 还撰写了一篇关于当晚活动的 精彩文章，可在网络上找到。

网络多媒体

我们之前在 这篇博文 中介绍过这个演讲，您还可以 在我的博客上阅读整个演讲的详细笔记，包括代码示例。多媒体演讲的 幻灯片在 slideshare 上，这里也有。

您可以在任何支持 HTML5 的设备上 观看“网络多媒体”（由 vid.ly 提供）或将其嵌入到此处。

合理使用 HTML5

“合理使用 HTML5”是我一直想做的一个演讲。与其只是陈述事实，我更想提出一些每个开发者都应该问自己的问题，以及 HTML5 工作组和所有关心的人。我们正处于开发环境的重大变革之中，但很多人没有意识到，我们在没有回退的情况下打破了许多旧的约定。

您可以在 Slideshare 上获取幻灯片或在这里查看：

您可以在任何支持 HTML5 的设备上 观看“合理使用 HTML5”（由 vid.ly 提供）。

“合理使用 HTML5”的笔记

我开始演讲时讲述了 南极雪地巡洋舰 的故事——这是一款 1939 年制造的技术奇迹，旨在让人员能够探索南极洲。雪地巡洋舰的任务是为人员提供所有必要的舒适条件，并让他们能够穿越南极洲，那里既非常寒冷，也存在车辆需要越过的巨大裂缝。巧妙的解决方案是配备巨大的车轮，这些车轮可以缩回巡洋舰内部，以防止它们在夜间变脆，并推动车辆越过裂缝。雪地巡洋舰是在匆忙中建造的，并在前往南极洲港口的途中进行了测试。它受到了媒体和公众的热烈欢迎，人们甚至因此推迟了整个行程，想要与它合影。抵达后，车辆几乎坠入大海，因为为其运送到冰面而建造的坡道不够坚固。更糟糕的是，一旦到达冰面，巡洋舰就无法获得抓地力，车轮空转，几乎导致发动机过热。尽管炒作声不断，但巡洋舰最终以惨败告终。

巡洋舰出现了一些问题

• 它纯粹是工程驱动的
• 它在道路上进行了测试
• 它从未在真实环境中进行过测试
• 在证明其价值之前，它就引起了巨大的媒体关注

这与我们如今处理 HTML5 的方式非常相似。关于 HTML5 的许多信息都是营销驱动的，用于向人们推销特定的环境或浏览器。我们不是创建真实的应用程序和日常使用的网站，而是创建 演示 网站 来展示“HTML5 能为你做什么”。“HTML5”一词变得模糊不清，因为它既用于规范部分的实现，也用于仅在特定环境中有效的特定于浏览器的代码。

这部分原因在于规范以及 HTML5 世界本身中不同的参与者。规范不仅包含标记的定义，还包含 JavaScript API 和关于如何编写渲染 HTML5 内容的浏览器的说明。这很棒，因为它消除了浏览器供应商过去在“创造性地”应用 HTML4 规范方面的自由，但也意味着人们可以专注于规范的某些部分，当然也可以抱怨所有其他部分。您可能看到过一个关于 HTML5 标记惊人的全新语义的演讲，以及另一个关于使用完全无意义的标记的 API 实现的演讲，它们一个接一个地进行。这就是我们现在遇到的情况，因为规范对于实施者来说过于庞大和包罗万象。

HTML5 工作的主要主题之一是实用性——XML 和严格的 HTML 使用了许多我们根本不需要的东西。这在简化普通 HTML 文档中表现得淋漓尽致。在 HTML4.01 严格模式下，它是这样的

  
  
  
  


  
Heading! Everybody duck!
  
I am content, hear me roar!
  
By me!

浏览器从未使用过冗长的 DOCTYPE 定义或 http-equiv。浏览器执行其工作不需要它。在 HTML5 中，这是一个纯净的 Vanilla 文档

  
  
  
  


  
Heading! Everybody duck!
  
I am content, hear me roar!
  
By me!

更简单、更短。除此之外，HTML5 还包括新的语义元素

  
  
  


  
Heading! Everybody duck!
  

    
I am content, hear me roar!
  
  

这为我们提供了样式处理的句柄，并告诉浏览器不同部分是什么。但是，简化程度更深。由于人们似乎从未费心在 HTML 中编写有效的 XML，因此现在完全可以混合使用大小写并省略属性周围的引号（如果属性具有一个值，则多值属性如类在添加多个值后需要在其周围加上引号）

  
  
  

  
Heading! Everybody duck!
  

    
I am content, hear me roar!
  
  

浏览器足够宽容，可以为我们修复这些不一致之处。例如，Firefox 中生成的代码是

  
  
  
  
  
Heading! Everybody duck!
  

    
I am content, hear me roar!

  
  

但是，如果我们在 <section> 中省略闭合 </p> 标记，则生成的代码看起来会有所不同

  
  
  

  
Heading! Everybody duck!
  

    
I am content, hear me roar!
      
    

    
By me!
  

如您所见，<footer> 已移动到 section 内部的段落中。为什么？谁知道呢？问题是我们要求浏览器为我们进行有根据的猜测，而由于浏览器不理解语义，因此我们得到了这样的结果。

这导致我提出了一些我们需要询问并找到答案的问题

• 创新可以基于“人们以前从未正确地做过这件事”吗？
• 是 HTML 还是 BML？（超文本标记语言还是浏览器标记语言）
• HTML 是否只应该存在于浏览器中？转换服务、搜索引擎机器人、内容抓取器呢？

我想要讨论的下一个问题是遗留浏览器，这似乎是 IE6 的委婉说法。IE6 的问题是，当您专门使用新的语义 HTML 元素时，就无法在此浏览器中对其进行样式设置。通过使用应该为我们带来诸多好处的正确新语法，您会让旧版浏览器的用户看到未设置样式的文档。

有一些解决方法。第一个需要 JavaScript——如果您首先使用 DOM 创建元素，则可以在 IE 中对其进行样式设置

  
  
  


  
Hello!

Remy Sharp 将此技术很好地封装在一个名为 HTML5 shiv 的脚本中。当然，这意味着您使标记依赖于 JavaScript 才能工作，这与纯粹的 Web 标记理念相悖。您可以通过多种方式解决此依赖关系。您可以 将 HTML5 编写为 XHTML，您可以 使用条件注释或命名空间，或者您可以同时使用新的语义元素和带有类的 DIV 来满足所有浏览器的需求

  
    
    
    
    
  
  
  

    
Heading! Everybody duck!
  
  

    
I am content, hear me roar!
  
  

这似乎是最实用的解决方案，但需要付出很多额外的努力。

主要问题在于，不仅遗留浏览器无法正确支持 HTML5，这也是人们倾向于使用像 Modernizr 这样的库来检查 HTML5 支持情况后再应用它的原因。Modernizr 在检查当前浏览器支持哪些功能后，会向 HTML 元素添加类，从而为您提供在渐进增强中使用的句柄。所有这些技巧和修复程序也包含在 HTML5 Boilerplate 中，包括服务器设置以及使遗留浏览器正常工作的方法。从本质上讲，如果您在真实世界中对其进行测试，则体积更小的 Vanilla HTML5 标记又会变成大量代码。

如果您还想使用所有很酷的新 JavaScript API，则可以使用 Polyfill 来使遗留浏览器对您编写的代码做出一些处理。

这导致了更多我们需要回答的问题

• 我们应该将新技术硬塞进遗留浏览器吗？
• 补丁是否会增加复杂性，因为我们需要测试它们的性能？（为旧版浏览器提供看起来很糟糕或导致其速度下降的功能毫无意义）
• 如何将 IE 修复程序移动到服务器端？在检查浏览器后，使用 PHP/Ruby/Python 中带有类的 DIV 进行填充，并且 IE 不使用 JS？

我想要讨论的 HTML5 的最后一个功能是视频和音频。同样，它比表面上看起来要复杂得多

从技术上讲，嵌入 HTML5 视频应该像这样简单

但是，一旦您考虑了不同浏览器所需的各种不同格式，工作量就会大大增加

原因是知识产权、法律编解码器之争以及不同浏览器和平台中视频的实现。从本质上讲，您需要以三种格式提供视频。当然，当有需求时，总会有公司想出解决方案。Vid.ly 是 encoding.com 的一项服务，它为您提供一个唯一的 URL，该 URL 会以正确的格式将视频发送到您使用的设备。总而言之，他们为您创建了 28 种不同的格式，以满足各种移动设备和浏览器的需求。

HTML5 视频的另一个大问题是无法防止下载视频。这是预期的结果，但对于网络上的高级内容来说是一个大问题。正如 Adobe 这篇文章的评论中所讨论的，发布者希望有一种方法来阻止人们下载和重新使用他们的视频，而是希望他们的受众在封闭的环境中观看它们。

总而言之，在涉及 HTML5 视频时，需要回答一些问题

• 我们能否期望内容创建者创建多种格式的视频来支持一项开放技术？
• 是否可以信任像 vid.ly 这样的服务来进行内容创建和存储？
• HTML5 不适用于高级内容吗？

最后，我希望每位开发者和设计师都能够站出来，并要求对这些问题给出答案。仅仅说“就是这样”毫无意义。当我们保持技术封闭，并依靠脚本使网站正常工作时，从长远来看，我们确实会破坏网络。关于链接的 hashbang 的当前争论 就说明了这一点。

每个人都可以参与到 HTML5 工作组 中，并 向 MDN 添加文档——是时候开始工作了。