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

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]
Sent: Tuesday, March 17, 2015 11:33 PM
To: Rick Byers
Cc: Dave Methvin; 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.