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

Agreed.  I prefer #1,  but I'm biased , having never implemented level 1 ;-)

I'll wait for your house keeping before submitting any PRs.
On Apr 13, 2015 7:45 PM, "Jacob Rossi" <Jacob.Rossi@microsoft.com> wrote:

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