谷歌浏览器_google chrome浏览器_google浏览器

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的主流浏览器开发商。