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> 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), 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>
> 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? J) 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> 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.
>>
>>
>>
>
>