Google 最终决定让指针事件成为 Chrome 的主要事件类型

Google 决定让指针事件（Pointer Events）成为 Chrome 的主要事件类型，抛弃苹果，加入微软和 Firefox 的阵营。

去年，Chrome 和 Blink 输入团队负责人 Rick Byers 曾宣称Blink/Chrome 不会实现指针事件（PE），尽管 Google 很久之前就已加入相关工作组。Byers 提到了一系列原因，包括 Apple 对于 PE 的反对会影响它的普及程度、给标准 16ms 帧预算带来大约 2% 的性能损耗以及在滚动时无法处理事件。Google 甚至把他们的 PE polyfill 库托管给 jQuery 基金会。

但是“持续收到的反馈表示，web 开发者、框架作者和其他浏览器开发商认为指针事件对于平台来说具有很大价值”，Byers 最近宣布Chrome 将实现 PE，可以通过某个标记开启。Chromium 官网的一个新 issue显示，PE 相关的工作已经开始。此外，Byers 和微软的 PE 团队已经就上文提到的性能问题进行讨论，这将涉及到一些 API 的改动。

我们就此事进一步的发展采访了 Byers。

InfoQ：请问你准备如何处理同时支持两种事件类型的设备？是否会像这个文档中建议的那样把所有的 TE（触摸事件）都转换成 PE？

RB：如果我们提供了对 PE 的支持，那么指针事件就会成为主要的事件类型。如果一个指针事件没有被处理，那它就可能会触发一个触摸和 / 或鼠标事件。幸运的是，我们从IE 提高移动 web 兼容性中（通过支持触摸事件）学到了很多。我很赞同 IE 工程师们的设计，我们也准备在 Chrome 中采用类似的设计，一些特殊的地方除外（当然在具体实现的时候我们可能会修改一些细节）。

InfoQ：微软的 Jacob Rossi表示他愿意协助你修复 PE 中可能存在的问题，但是在 W3C 中 PE 的规范已经成为了最终标准，据我所知现在只能对其进行细微的调整。你准备怎么做？

RB：在收到一些重要的反馈之后，关于新版 PE 规范的工作已经启动，（Rossi 提到的）不过是向新版 PE 规范中再加入一件（显然更大的）事而已。确保改动能兼容现有代码确实是一项巨大的挑战，但是我相信我们可以在兼容性和解决问题之间做出某种合理的权衡。

InfoQ：请解释一下为什么“默认不捕获的触摸输入模型会影响引擎性能”？

RB：区别在于哪个 DOM 节点接收‘移动’事件。对于触摸，触摸 - 移动事件的目标节点总是收到触摸 - 开始事件的元素（这是“隐式捕获”）。对于鼠标和（默认的）指针事件，目标总是当前指针所指的元素。这意味着每次移动鼠标，浏览器都需要通过“命中测试”来确定当前指针指向的元素。由于 CSS 布局的复杂性，命中测试也很复杂，有时很难预测其性能。从浏览器引擎开发者的角度来说，如何减少每个“帧预算”的工作量是我们面临的最大的性能挑战。响应触摸移动事件时，浏览器和应用可以通过 16ms 一次的事件来保证流畅的 60fps 体验。但是，尽管命中测试（在简单的用例中）只占帧预算的大约 2%，这仍然是一个不可忽视的代价。我们认为这种代价不应当由平台承担，除非开发者们明确地表示他们需要“不捕获”行为。

现在许多网站的设计方式都是“触摸优先”，因为开发者们都意识到优秀的移动用户体验能够有效提高用户参与度。我认为所有新出现的输入 API 都应该考虑到这一点并优先考虑直接操作（捕获），从而满足现代的用户交互。

Google 计划在所有支持平台的 Chrome 中实现 PE，包括 Android 和 WebView。PE 也会在 Spartan/IE10、Firefox（需要通过 flag 开启）、jQuery 和 Dojo 中实现。Apple 是目前唯一一家反对 PE的主流浏览器开发商。

查看英文原文：Google Is Going to Make Pointer Events the Main Event Type in Chrome after All

感谢邵思华对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流。