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

I've got a draft version of the touch-action updates here
<https://github.com/RByers/w3c-pointerevents/compare/fix-crlf...RByers:touchaction-directions?diff=split&name=touchaction-directions>
(I
can't create a proper pull request until someone accepts/merges my line
endings pull request).  I took the opportunity to also clarify a few other
subtleties which we glossed over in the past. Here are the key changes
people may want to give feedback on (feel free to do it here, or I'll
eventually get a pull request up for comment).

1. Added pan-right, pan-left, pan-up and pan-down values specified in a way
such that there's only ever one way (ignoring token order) to describe a
particular behavior.  Eg. 'pan-left pan-up' is legal but 'pan-left
pan-right' is not (because it would be equivalent to 'pan-x'), nor is
'pan-x pan-left'.  I don't have a strong opinion about this, but figured I
needed to take a stand on one side or the other for the grammar.

2. Defined the co-ordinate space of the directions in terms of the 'screen'
co-ordinates in the events.  I've heard this brought up as a deficiency in
the spec before (eg. if the direction was in 'client' co-ordinates instead
of 'screen', then pan-y inside an iframe that had 'transform:
rotate(90deg)' would mean horizontal panning from the user's perspective).

3. Rather than give each of the 6 pan values it's own description, I
grouped them all with the informal label of 'pan-*'.  Repeating nearly the
same text for each seemed silly, but I'm sure better syntax is possible
(maybe list all 6 on the line?).

4. I added an example showing how different pan values are intersected.

5. I removed the "nearest ancestor with horizontally scrollable content"
part of the definition.  I _think_ this was actually wrong (or at least
misleading).  Although the behavior of scroll chaining make this statement
confusing.  Big picture, the processing model is described accurately below
(find the nearest ancestor that supports ANY touch-action and intersect the
touch-action values on the elements between it and the hit-tested element).

6. I added a note describing the key scenario where values like pan-right
are useful (image carousel scroll chaining).  Perhaps I should also mention
custom overscroll effects?  Eg. when the document is scrolled to the top,
use 'touch-action: pan-x pan-down' to permit custom pointer event handling
for top overscroll (pull to refresh, etc.).

7. I mentioned that the pan values determine what direction the scroll may
start in, but once started the direction can be reversed.  Eg. for pan-down
it would be weird if the user could pan down for awhile but then not
reverse motion to pan back up to where they started.  I also mentioned that
in contrast axis-restricted scrolling remains restricted (with pan-x you
can't start horizontal then switch to vertical).  You could argue the
latter is a browser UI restriction and not something to be standardized
(IIRC IE never permits a scroll axis switch, but Chrome does so we needed
to address this when implementing touch-action).

Feedback?

Rick


On Wed, Apr 15, 2015 at 6:40 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

> Hearing no objections, I went ahead and implemented #1:
>
> https://github.com/w3c/pointerevents/commit/7df96182a451cce1e556fa147f12c1d3857d47aa
>
> So Pointer Events V2 is now open for business and accepting pull requests.
> :-)
>
> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@gmail.com]
> Sent: Tuesday, April 14, 2015 4:37 AM
> To: Rick Byers; Jacob Rossi
> Cc: Sangwhan Moon; Dave Methvin; public-pointer-events@w3.org
> Subject: Re: Add direction-specific pan values to touch-action?
>
> On 4/13/15 9:19 PM, Rick Byers wrote:
> >
> > Agreed.  I prefer #1,  but I'm biased , having never implemented level
> > 1 ;-)
> >
>
> I also prefer #1.
>
> If someone wants a `delta view` of the spec (aka #2 below), that should
> be relatively easy to generate. I would also recommend we keep the
> `Changes since last publication` section up to date.
>
> -ArtB
> >
> > I'll wait for your house keeping before submitting any PRs.
> >
> > On Apr 13, 2015 7:45 PM, "Jacob Rossi" <Jacob.Rossi@microsoft.com
> > <mailto: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?
> >
>