• Choose a category
• All
• Classic-Fiction

 Iframe沙箱

 支持"getElementsByClassName()"

 "classList" API

 音频和视频（通过 Audio和 Video元素）API

 离线 web应用 API

 编辑（通过 contentEditable属性）API

 跨文档消息 API

 服务器端事件 API

HTML 5试图解决一些重大的问题，而且解决的不错，比我们上面列出的还要多。

Andrew ：“web存储”（客户端数据库）会被广泛使用——很多网站已经开始好好地利用它了。 新的 form控件（Web Forms 2）从一开始就存在于标准之中，我都等不及赶快使用了。服务 器发送事件可以用来构造纯粹的“推”服务程序，而不需要依赖 Ajax的不断轮询或不稳定的长 连接。我还喜欢自定义数据属性，虽然相比之下，这只是一个不太重要的特性。

Thomas ：除了离线应用特性（主要指持久化存储），我认为 VIEDO和 AUDIO标签是最重要 的新特性，因为我们终于可以离开烦人的 OBJECT和 EMBED了。当然这还需要一段时间， 直到所有浏览器都支持，不过这确实是朝着正确的方向在发展，而对所有非正式标准的标准 化工作也会让浏 览器表现得比现在更好。一个容易被忽略的特性是 web应用程序能够注册 协议和媒体类型，以使它们自己成为默认处理程序，就像桌面应用程序一样（但是从 UI 的

虚拟座谈：HTML5来了，JavaScript框架会如何发展

角度看，仍有很多阻碍，因为对计算机不甚了解的用户不懂什么是“协议”或者“媒体类型”）。

David ：除非被广泛支持，否则没有哪个 HTML 5的特性是非常值得关注的。这些概念值得去 实现，但在只有少数几个浏览器支持的情况下使用是不明智的。这就是我们不使用 querySelectorAll 的原因：浏览器厂商的不同实现会导致更多针对浏览器的 hack，而不是简 单的避免使用 QSA。

Scott & Joel ：在 HTML5中我最关注的是那些现在就可以使用，而不需要开发人员额外创建 不同版本程序的特性。我对其 中的数据库和缓存 API特别感兴趣，程序可以真正支持在线 和离线两种模式了。另外对于移动 web开发人员来说，HTML5提供了大量特性来处理低速 和连接 不稳定的移动网络。

另外一些 HTML5的特性也很让人激动，例如、

InfoQ：您认为现有的 JavaScript框架该如何发展，以支持像内置媒体、离线浏览以及更高级 的服务器进程通信这样的新特性？能粗略说一下您所在项目的路线图么？

Dylan ：我们的目标一直是弥补浏览器的不足。我们希望我们的框架能够越来越不重要（例 如，实现统一的事件系统或者是 QuerySelectorAll）。我们发现在某些情况下，我们会随着时 间的推移一点一点的删除代码，但是 Dojo的用户并不会感到有任何的不同，他们 还是可以 继续使用相同的 API，只是这些 API会简单的调用本地实现。对于你提到的更高级的特性， Dojo已经可以支持媒体和离线程序，并且支持 JSON-PRC和 REST，甚至可以在 Perservere这 样的服务器端 JavaScript环境中运行！

Matt & Eric：JavaScript框架的作用是利用更丰富的 API和透明的跨浏览器支持来改善编程环 境。YUI将会遵循 HTML 5标准（特别是那些已经对浏览器产生影响的），并添加对老版本浏 览器的支持，以便让新的功能可以在标准实现和推广之前就得以应用。客户端存储 API是一 个 例子，YUI将要实现它以消除 HTML 5和现有浏览器之间的不同。

Andrew ：像 Prototype这样的“中间件”框架，主要是把难用的、不一致的 API包装为统一的、 完善的接口，HTML5并不会 （为 Prototype）带来太大的影响。HTML5的特性会让某些工作 变得简单，但是 Prototype会一直保留“困难的方式”，直到最后一个非 HTML5浏览器不再得 到支持。

另一方面，建立在 Prototype上的库 －script.aculo.us，显然需要做出选择。Script.aculo.us 提供了一个“slider”控件，HTML5也有。是否应该使用浏览器内置的 HTML5 slider？还是使用

虚拟座谈：HTML5来了，JavaScript框架会如何发展

现有的纯 JavasScript版本，以保正在所有浏览器中的外观一致？

HTML5 提供了一些特性的本地实现，而之前的多年我们一直用 HTML和 JavaScript来实现这 些特性，这是一个进步。如果我们能够全部转移到 HTML5而不管老版本浏览器，大多数的 （JavaScript）库都可以移除大量的代码。但是在很长的一段时间里，我们还需要保留这些旧 代码。

Prototype和 script.aculo.us并没有长期的路线图，但是我知道，当四种主流浏览器中至少有 两个支持某一特性时，我就会认真考虑是否实现它。记住，HTML5不会一次就全部实现的。

Thomas ：是的，它们会进化的，最终当浏览器支持这些新特性时，它们也会支持。这对于 框架来说并不是什么新鲜事，当新版本浏览器发布时，通常需要关注的是 bugs而不是新特 性。目前，对于 script.aculo.us来说，最新的“舞台”将是 Canvas元素，它可以平衡 Prototype 的功能。例如，insertAdjacentHTML() DOM API可能会比我们目前插入 HTML的方法更快。

David ：我认为我们会像以前那样：从浏览器实现中抽象出 API，对那些不一致的实现进行修 复。在某种程度上，我们为老版本浏览器开发解 决方案，以提供跨浏览器支持，但当我们 无法实现时，我们会提供检测功能以处理这种情况（或许使用欺骗手段）。我们还不能忘记 IE6拒绝灭亡的事实，还要过 很长的时间，我们才能完全依赖这些特性。

对于路线图，我们将会利用这些特性的优点，首先创建更小、更快的库。如果我们可以为支 持 HTML5的浏览器构建更快的选择器引擎，我们会将精力集中在那 里，而不是一些非广泛 支持的特性。将规范集成到我们的 API将会提升性能并减少代码量，这在短期内是对我们的 最大好处，直到更高级的特性被浏览器市场普遍 实现。

Scott & Joel ：对于 GWT来说，我们会集中在那些被主流浏览器实现的特性上，但是我们也 可 能会根据用户浏览器的不同而提供不同的实现方式。例如我们提供了抽象的存储 API，可以 根据用户的环境使用 Google Gears或 HTML 5。GWT的好处是，最终用户只需要下载他们浏 览器支持的特定实现，因为我们已经事先考虑了所有的可能。

InfoQ：HTML 5为客户端添加了非常多的重量级特性，有些人认为目前的 JavaScript和 DOM 编程模型已经走到了尽头。我们是否需要为不久的将来考虑一个完全不同的编程模型？

Dylan ：jQuery和 Dojo的一个主要不同是，jQuery本质上是以 DOM为中心的，而 Dojo还试 图改进 JavaScript的不足。像 Mozilla Lab的 Bespin这样的程序用于非 DOM为中心的开发， 我一直认为 DOM是 JavaScript开发人员的工具，而不是全部，如果有些事不能通过修改 DOM 来解决，那就不应该在浏览器中解决。坦白地说，我们已经通过不同的工具提供了不同的开 发方式。

虚拟座谈：HTML5来了，JavaScript框架会如何发展

Matt and Eric ：浏览器环境允许不同的模型，而且事实上也有很多模型被开发出来。 Flash/Flex/AIR就是一个很好的 例子，它与 HTML/DOM/CSS（同时）都是 web成功的关键部 分。当你使用 iPhone上的 Facebook程序而不是 Facebook的移动网站 时，你就在使用一种 新的模型。到目前为止，还没有哪个其他的模型可以在访问性和简便性上超过它。我们应该 在以后“考虑其它模型”么？作为开发人员，我们曾 经有过争执，每次我们构建新程序时， 都会考虑其他的模型。如果今天的大多数程序是 web程序，那么就已经说明浏览器仍然有 价值。我们认为浏览器中仍有许多 未被发现的价值，聪明的改进规范（就像 ECMA3.1那样） 将会对目前的平台产生长远的改善。

Andrew ：这很难说。有些人希望浏览器解析标记；有些人希望浏览器在窗口上绘制像素。 这取决于你构建的程序类型。这并非是要代替 DOM，而是寻找其他的模型来补充 DOM，这 样你就可以使用最合适的工具来工作。我觉得 Canvas和 SVG可能就是这一类模型。

Thomas：我不这样认为， HTML、CSS和 JavaScript的组合已经被证明是非常实用和通用的， 每一项技术都在积极的进步，没有必要替换掉它们。

David ：怎么会在“不久的将来”呢？任何 HTML5中能够改变这个模型的东西，都会在多年后 才能出现。而且目前的模型已经很完善、很易于理解，更被成千上万的网页所使用。我认为 目前还不会有任何改变。

Scott & Joel：我认为目前的方式还没有任何走到尽头的迹象，反而发展的更快、更有组织了。

一方面，有很多理由去制造更好的浏览器（带有 V8的 Chrome、带有 TraceMonky的 Firefox、 带有SquirrelFish Extreme