- From: Rick Byers <rbyers@google.com>
- Date: Tue, 30 Jul 2013 10:45:04 -0230
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <CAFUtAY84dOX2HL4EiBd2Y-rC-vDD8htmuMVXr5rERyxVaUro5Q@mail.gmail.com>
Here's an update on the implementation status of pointer events in blink and chrome. *tl;dr*: touch-action requires some substantial re-architecting, and one of the first phases of this (reliable compositor-thread hit testing) has now landed. But there is still a lot of complex work left before touch-action can be implemented with the correct performance properties. *Details* As we've discussed before, implementing touch-action ( http://crbug.com/241964) is our top priority (since it's the most complicated part, the main problem for polyfills, and provides benefit to touch events as well as pointer events). Design doc here: https://docs.google.com/a/chromium.org/document/d/1CV2AXyrdPdGSRypAQcfGrgQVuWYi50EzTmVsMLWgRPM/edit One of the main pieces needed to implement touch-action with the performance properties we want is a mechanism for doing touch hit testing on the compositor thread. Only the main thread has access to the DOM so it's non-trivial to correlate anything with the co-ordinate of a touch from any other thread. Chrome recently got a compositor hit testing mechanism for avoiding sending touch events for regions that have no handlers ( http://www.chromium.org/developers/design-documents/compositor-hit-testing) but it was very limited (inaccurate). Last week I landed a major re-implementation of this system to be sufficiently accurate for touch-action (http://crbug.com/248522). At the same time, a cool new feature was added to chrome dev tools that lets you visualize these regions (https://plus.google.com/115788095648461403871/posts/LXKEENhnQSD) Immediate next steps (next several weeks): - hit testing performance improvements - enable a naive implementation of touch-action behind the --enable-experimental-web-platform-features flag (on top of the basic touch-action CSS support I've already landed) - add initial experimental support for my proposed touch-action-delay CSS property (necessary for compat with the existing touch event model supported by non-IE browsers) - expand polymer PointerEvents polyfill to use browser touch-action support when present and look for compat issues on real sites. Longer term I still need to finalize the design for implementing touch-action-delay (again some major changes are necessary here) and wire it up to the hit testing system so we can implement touch-action with the desired performance properties. This is still at least another few months of work :-(. Once we've got an experimental version working, I'll start more serious discussions around standardizing touch-action-delay. Rick
Received on Tuesday, 30 July 2013 13:15:55 UTC