RE: Add direction-specific pan values to touch-action?

I was going to do some house cleaning to the spec (e.g. make it say “Level 2” or something) to prepare for this stuff first. But, it made me realize we should have a conversation about the spec approach.  There’s basically 2 options:


1)      Continue with the current spec and call it Level 2. Adapt features and make changes/extensions to existing algorithms/APIs inline.

2)      Write an extension spec that just documents what’s new and changed.

I could see either one as being acceptable (e.g. I abstain from a vote :-p). But they would substantially change your PR. So maybe we should just put a stake in the ground and go with one or the other?

From: Rick Byers [mailto:rbyers@google.com]
Sent: Thursday, April 9, 2015 2:34 PM
To: Jacob Rossi
Cc: Sangwhan Moon; public-pointer-events@w3.org; Dave Methvin
Subject: Re: Add direction-specific pan values to touch-action?


Any objection to me putting up a pull request for discussion with some specific changes to add this? Should be easy I think.
On Mar 21, 2015 11:57 AM, "Rick Byers" <rbyers@google.com<mailto:rbyers@google.com>> wrote:
Right.  In Chrome, we've come to the conclusion that the only way to fully address those nested chaining scenarios properly is with some sort of scroll customization API<https://docs.google.com/a/chromium.org/document/d/1VnvAqeWFG9JFZfgG5evBqrLGDZYRE5w6G5jEDORekPY/edit#heading=h.kd0gtwwz5bf9> where the browser mediates the composition of scrolling between components (this is especially true across iframe boundaries).

So yes, I think we should punt here on trying to solve the transition mid-interaction scenarios.  Although we have some such capability in Chrome today (and see it used for pull-to-refresh on sites like twitter.com<http://twitter.com>), we do not see this as a viable long term path for fully enabling the breadth of scenarios we want to support.

I.e. Jacob, you were right when you told me privately that you thought we'd find extending Touch Events to be insufficient for implementing the scenarios like pull-to-refresh<https://docs.google.com/a/chromium.org/document/d/1YppwqQtBpibxHeMprYEQKIIc7_0_rjtXeEpe6zxBdss/edit#heading=h.apuy6flaodnp> that we wanted to support.

That said, this is such a simple extension to touch-action which could be useful (in admittedly limited ways) immediately, that I think we should do it anyway.

Rick

On Fri, Mar 20, 2015 at 12:48 AM, Jacob Rossi <Jacob.Rossi@microsoft.com<mailto:Jacob.Rossi@microsoft.com>> wrote:
I love this idea!  Ben’s non-revolving carousel scenario is good. I’d also like to think about how this could work for pull-to-refresh.

In both cases,  it seems that the point at which you want to enact one of these directional values is determined more by the scroll position rather than the element your touch hit-tests to. Consider implementing the carousel Ben describes:

One approach would be that the last frame (or, perhaps pony? ☺) of the carousel has “pan-right pan-y” and the first frame has “pan-left pan-y” while all the ponies in between have just “pan-y.” This lets JS drive the carousel but allows native panning to chain up to the parent scroller at the extents.

However, the touch-action value honored is determined at the start of a touch. So as you swipe to the last frame, the change to “pan-right pan-y” to allow chaining won’t take place until the next touch. You can’t keep pulling from frame N-1 past frame N and start to chain to the parent scroller. You must lift after reaching frame N and pan again.

Ideally what you really want in these scenarios is the ability to transition mid-interaction from JS to native scroll or vice-versa.  That’s really tough to do in the multi-threaded, GPU-composited world. Are we OK punting on this nuance and continuing with the “fixed touch-action value per interaction” behavior described above, or is there interest/ideas in how to tackle the JS/native transition capability?

From: Sangwhan Moon [mailto:sangwhan@iki.fi<mailto:sangwhan@iki.fi>]
Sent: Tuesday, March 17, 2015 11:33 PM
To: Rick Byers
Cc: Dave Methvin; public-pointer-events@w3.org<mailto:public-pointer-events@w3.org>
Subject: Re: Add direction-specific pan values to touch-action?

The absolute panning direction does not reverse in RTL, so this shouldn't be a problem.

Logical "history traversal" directions are not flipped in RTL due to a legacy reason (Apparently VCRs didn't flip the order around so that stuck), so while everything else is flipped around the logical direction for "previous" is left, "next" is right for that reason.

Sangwhan

On Mar 18, 2015, at 11:30 AM, Rick Byers <rbyers@google.com<mailto:rbyers@google.com>> wrote:

That's a good question.  I think what matters for touch-action is the co-ordinate space of the input events.  Since those don't invert in RTL then I think we'd really want true right/left here.  The logic for chaining correctly with a native scroller would probably be non-trivial, but I doubt we could reasonably simplify this (RTL is hard).
Would left and right be reversed if the page language is right-to-left? Or would the CSS potentially need to change based on the language? I'm not familiar with whether gestures like that are reversed in languages like Arabic, or perhaps the use cases don't require it.