Bug 133114 – Implement "touch-action:manipulation" Pointer Events CSS property to suppress 300ms touch > mouse compatibility events delay

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: DOM

[Patrick H. Lauke]

Although there seems to be no immediate desire to implement the full Pointer Events specification (see https://bugs.webkit.org/show_bug.cgi?id=105463), it may be worth considering at least supporting the touch-action:manipulation CSS property/value. 
This recent addition (the "manipulation" value) to the Pointer Events specification is used - in essence - to allow developers to suppress the classic 300ms delay present on touchscreen devices that by default allows for "double-tap to zoom", while retaining other abilities such as scrolling and pinch-to-zoom. It offers a compromise to the often drastic preventDefault() commonly used in touch-optimised applications (which does remove the 300ms delay, but also kills any other default interactions).

touch-action:manipulation is on track to be rolled out in both Firefox and Chrome - see

"Bug 979345 - Implement "touch-action: manipulation" CSS value for Pointer Events" https://bugzilla.mozilla.org/show_bug.cgi?id=979345
"Issue 349016:	Add support for touch-action: manipulation" https://code.google.com/p/chromium/issues/detail?id=349016

[Patrick H. Lauke]

For further context, see also "Optimizations to remove 300ms touch > mouse events delay" https://bugs.webkit.org/show_bug.cgi?id=122212

[Jorik Tangelder]

I'm more interested in the fact that this makes it easier to detect gestures, without doing al kinds of crazy tricks in the event handlers. That it has the ability to remove the 300ms is cool, but not the main function of the property.

[Rick Byers]

See also bug 133114 which proposes adding all of touch-action to WebKit.

Note that there's an argument to be made that disabling double-tap zoom on portions of a UI (or even on some pages but not others) is inconsistent and leads only the user confusion.  The counter-argument is that web developers are largely doing this already using libraries like FastClick (I believe FastClick or something like it is in use on most major mobile-optimized websites).  But those libraries come with other downsides (bugs, perf impact, loss of touch adjustment, other browser UI features unnecessarily disabled, etc.).

So my opinion is that we might as well give developers a simple reliable switch to clearly toggle the behavior they otherwise struggle to change.

[Rick Byers]

Sorry, that's bug 133112 that suggests adding all of touch-action.

[Benjamin Poulain]

Let's merge :)

*** This bug has been marked as a duplicate of bug 133112 ***

[Lucas Forschler]

Mass move bugs into the DOM component.