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

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.
>
>
>