Bug 133112 - Touch-action css property support
Summary: Touch-action css property support
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Event Handling (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 133114 (view as bug list)
Depends on: 149854
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-20 01:54 PDT by Jorik Tangelder
Modified: 2016-03-27 15:44 PDT (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jorik Tangelder 2014-05-20 01:54:04 PDT
What about supporting the touch-action property of the pointer events specification? IE, Blink already support this, and Mozilla is busy implementing it.
https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-touch-action-css-property

Even when pointer events are not implemented, this css property would really improve the support for touch gestures in webpages. Now we're stuck with only calling preventDefault, and often makes elements blocking the scrolling of a page when not needed...

(copied from https://bugs.webkit.org/show_bug.cgi?id=105463#c35)
Comment 1 Patrick H. Lauke 2014-05-20 02:53:32 PDT
hah, seems Jorik beat me to it. feel free to de-dup between this and https://bugs.webkit.org/show_bug.cgi?id=133114
Comment 2 Rick Byers 2014-05-20 07:21:05 PDT
FYI there are several reasons we decided to add touch-action to blink.  Eg. from https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/sc5lHnlcLvM/ntJWuKKHUqYJ: 

 1. Provides precise control over the dreaded 300ms click delay on mobile
 2. Reliably enables side-swipe UIs (frees libraries from having to predict when exactly scrolling may start on different browsers)
 3. Enables high-fidelity polyfills of pointer events (eg. as in Polymer)
 4. Provides a declarative signal to blink (and potentially the compositor) about the developers intent wrt. touch input - eg. providing a potential solution the touchstart ACK timeout problem
 5. Reducing confusion around the highly-overloaded response to preventDefault on touch events
 6. A prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread

It's #5 that seems to resonate most with typical web developers.  In particular I continue to see developers struggle with implementing side-swipe UIs (#2), and I believe mobile safari requires them to reverse-engineer a magic distance threshold number (which then imposes a compat burden on the web no to change that magic value).
Comment 3 Benjamin Poulain 2014-05-20 09:59:24 PDT
*** Bug 133114 has been marked as a duplicate of this bug. ***
Comment 4 Patrick H. Lauke 2014-05-20 10:28:42 PDT
Adding this from https://bugs.webkit.org/show_bug.cgi?id=133114 here:

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
Comment 5 Benjamin Poulain 2014-05-20 13:20:21 PDT
Some context: I do not have time to experiment with touch-action at the moment. If someone is interested in contributing patches to WebKit, I would be happy to provide guidance and reviews.

Rick: some questions about the spec:
-At the moment, pan-x and pan-y are pretty much useless for every use case we have. We would need the touch action to have the direction, eg. pan-positive-y/pan-negative-y or pan-y-downard/pan-y-upward. Is there anything like that in the work?
-Is it specified in what coordinates system are the x/y for pan-x/pan-y? Is it in the block coordinates? Its containing block? The whole frame? The main frame?

Patrick: touch-action:manipulation is basically just as bad as preventDefault() for the click delay. Touch events have raw position, mouse/click events are adjusted based on the device DPI, scale factor, finger surface, etc. For tap/click, the right thing to expose is the adjusted value, not the raw touch. The problem is touch-action:manipulation defines touch behavior, not synthetic events.
The synthetic mouse events are superior to touch events for tap/click. I still welcome a real proposal to that issue (IIRC, you had opened a bug for that?).
Comment 6 Patrick H. Lauke 2014-05-20 13:43:13 PDT
"Patrick: touch-action:manipulation is basically just as bad as preventDefault() for the click delay. Touch events have raw position, mouse/click events are adjusted based on the device DPI, scale factor, finger surface, etc. For tap/click, the right thing to expose is the adjusted value, not the raw touch. The problem is touch-action:manipulation defines touch behavior, not synthetic events."

Unless I'm missing something, all that touch-action:manipulation in the context of touch events would do (and I believe that's what Chrome and Mozilla are implementing/have implemented so far) is a rather fancy way of saying "don't wait 300ms for the second tap of a double-tap action". Nothing about affecting raw vs adjusted position values as far as I know.
Comment 7 Patrick H. Lauke 2014-05-20 13:51:02 PDT
"The synthetic mouse events are superior to touch events for tap/click. I still welcome a real proposal to that issue (IIRC, you had opened a bug for that?)"

Yes, it's https://bugs.webkit.org/show_bug.cgi?id=122212 (where we got a bit sidetracked by the fantastic hidden feature is iOS that not even power users know about that is double-tap-to-scroll ;) )
Comment 8 Jacob Rossi [MSFT] 2014-05-20 16:50:50 PDT
Just a couple additional thoughts/responses:

Definitely agree that "synthetic" events (esp. click) are far superior for activation behaviors. Other goodness here too like better accessibility.
     * Note that IE11 now uses the PointerEvent interface for click and will even fire it for multi-touch provided you aren't zooming. So we don't really consider it a "synthetic" event in this regard.

Like Patrick says, touch-action doesn't affect whether you a browser alters coordinate accuracy (in fact, such adjustment is out of scope for our working group)

touch-action: manipulation is about restricting touch behaviors to "scrolling and continuous zooming" aka, disabling features like double-tap-to-zoom
     * This in turn enables browsers to optimize out the 300ms delay for synthetic events like click, but isn't technically a required feature of the API

pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc.
     * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon.
Comment 9 Benjamin Poulain 2014-05-20 17:17:09 PDT
(In reply to comment #8)
> Just a couple additional thoughts/responses:

Thanks for participating.

> touch-action: manipulation is about restricting touch behaviors to "scrolling and continuous zooming" aka, disabling features like double-tap-to-zoom
>      * This in turn enables browsers to optimize out the 300ms delay for synthetic events like click, but isn't technically a required feature of the API

I disagree, but that's a completely different problem. Please have a look at https://bugs.webkit.org/show_bug.cgi?id=133112.

> pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc.
>      * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon.

On OS X or iOS, we fully support scrollview-inside-scrollview.
Comment 10 Jacob Rossi [MSFT] 2014-05-20 18:29:24 PDT
>> pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc.
>>      * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon.

>On OS X or iOS, we fully support scrollview-inside-scrollview.

Not sure I follow how that relates to touch-action. IE (and Chrome/Firefox I think) supports this too. Can you explain further?
Comment 11 Benjamin Poulain 2014-05-20 18:50:11 PDT
(In reply to comment #10)
> >> pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc.
> >>      * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon.
> 
> >On OS X or iOS, we fully support scrollview-inside-scrollview.
> 
> Not sure I follow how that relates to touch-action. IE (and Chrome/Firefox I think) supports this too. Can you explain further?

Let's say we would want to change all the carousels to touchAction instead of gesture recognition from touch events.

Let's say the carousel start in the middle.
-In that first state, only pan-y is enabled, pan-x is handled through the touch events.
-You pan to the right edge.
-You rubberband or stop at the edge, but either way, the last position is maxX.
-Now we have two cases:
    -If you continue panning to the right, the superview should take the gesture and track it from there.
    -If you start panning in the other direction, then view takes the touch events and tracks the input.

If you can specify the direction, you change change the touch-action based on the internal state of the carousel.
Comment 12 Jacob Rossi [MSFT] 2014-05-21 12:36:53 PDT
Ah, makes sense. When I use "carousel" I usually mean the ones that wrap around like the kids' ride. They're usually moving things from the beginning to the end of the scroller or vice-versa to create the illusion of a full carousel loop. So you never hit this issue and pan-x/pan-y work just fine.

But, not all work this way and I agree the positive/negative values would improve the experience. Though I like a solution like CSS Scroll Snap Points to enable this to be built with native scrolling instead.

"Pull to refresh" was another scenario we had in mind for positive/negative pan values (so you could enable touch events when pulling down at the top of a scroller, to animate the refresh icon or something; but then still have native scrolling for the rest of the scroller).

Though I understand there may be some complicated issues for Apple to work through to join, it'd really be great if we could continue the positive/negative discussion over in the working group (I don't think we really want to design the API here in the webkit bug).
Comment 13 Benjamin Poulain 2014-05-21 14:32:54 PDT
(In reply to comment #12)
> Ah, makes sense. When I use "carousel" I usually mean the ones that wrap around like the kids' ride. They're usually moving things from the beginning to the end of the scroller or vice-versa to create the illusion of a full carousel loop. So you never hit this issue and pan-x/pan-y work just fine.
> 
> But, not all work this way and I agree the positive/negative values would improve the experience. Though I like a solution like CSS Scroll Snap Points to enable this to be built with native scrolling instead.

Snap points is a good idea to investigate regardless.

There will still be cases when people want full control with JavaScript. With iOS, we try to give as much power as possible to the web page. Generic solutions to provide a near native experience for a large variety of use cases are very useful to have. I can see touch-action being useful there.

> "Pull to refresh" was another scenario we had in mind for positive/negative pan values (so you could enable touch events when pulling down at the top of a scroller, to animate the refresh icon or something; but then still have native scrolling for the rest of the scroller).
> 
> Though I understand there may be some complicated issues for Apple to work through to join, it'd really be great if we could continue the positive/negative discussion over in the working group (I don't think we really want to design the API here in the webkit bug).

I really doubt that is gonna happen. I don't think I will have useful comments before prototyping anyway.
Comment 14 Chris Rebert 2015-10-06 16:20:38 PDT
This bug depends on https://bugs.webkit.org/show_bug.cgi?id=149854
Comment 15 yisibl 2015-12-16 04:17:06 PST
Implement touch-action: manipulation; for iOS
https://bugs.webkit.org/show_bug.cgi?id=149854
Comment 16 Jacob Rossi [MSFT] 2015-12-17 15:53:07 PST
This tracks support for the auto and manipulation values: https://bugs.webkit.org/show_bug.cgi?id=149854

Are there plans to implement none as well? 

Besides the performance optimizations this could enable, support for parsing none will help libraries like: https://github.com/jquery/PEP/issues/250