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

I've now also applied Jacob's feedback to the pull request
<https://github.com/w3c/pointerevents/pull/13/>.  In particular, I
clarified the part about increasing scrollX values, and added the custom
overscroll example.

Let me know if there's any more feedback.  If I don't here anything in the
next day or so I'll squash what I've got into a single commit and merge it
(but we can of course continue to iterate on it).

Rick

On Tue, Apr 21, 2015 at 4:02 PM, Rick Byers <rbyers@google.com> wrote:

> On Fri, Apr 17, 2015 at 8:04 AM, Arthur Barstow <art.barstow@gmail.com>
> wrote:
>
>> On 4/16/15 9:48 PM, Rick Byers wrote:
>>
>>> 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.
>>>
>>
>> I don't have a strong position on this either other than to note that
>> after we get consensus on this PR, we should ask the CSSWG/Community for
>> feedback.
>
>
> As discussed on the call today, we had this discussion for PEv1 already
> and decided to be restrictive - i.e. 'touch-action: pan-y manipulation' is
> illegal because 'pan-y' is redundant here.  We should be consistent with
> this pattern and disallow any redundancy (as my proposed grammar does).
>
>  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?).
>>>
>>
>> I don't feel too strongly on how the 4 new values are documented but I
>> tend to favor one per line.
>
>
> Done
>
>  4. I added an example showing how different pan values are intersected.
>>>
>>
>> (It appears the grammar implies the value of the outer most div should be
>> "pan-left pan-y" but I presume the CSS syntax spec says the value order
>> doesn't actually matter.)
>
>
> Right, from the CSS spec conventions:
> <http://www.w3.org/TR/CSS21/about.html#value-defs> "A double bar (||)
> separates two or more options: one or more of them must occur, in any
> order."
>
>  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.).
>>>
>>
>> L687: I don't grok what the "vice-versa" means in this context.
>>
>
> Moved this discussion inline to the pull request
> <https://github.com/RByers/w3c-pointerevents/commit/aae1e90fb9337cbad5ea11e0454d1c62122ace8a#diff-eacf331f0ffc35d4b482f1d15a887d3bR680>
>
> L687: s/beyond it's extent/beyond its extent/
>>
>
> Thanks, done.
>
> L687: Re "It's not possible to change the behavior of a pan in the middle
>> of an operation.", wondering if that statement should be normative (instead
>> of included in a non-normative note).
>
>
> I think this is covered by the touch action processing model below, in
> particular "When a user touches an element, ...".  The algorithm doesn't
> allow for touch-action to be consulted in any other scenario.  WDYT?
>
>  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).
>>>
>>
>> L673: I think I would s/even if scrolls that start in that direction are
>> disallowed/even if scrolls that start in the reversed direction are
>> disallowed/.
>>
>
> Done
>
> Trying to read this PR in its larger context, it seems like the spec
>> should include a definition of "default touch behavior".
>>
>> -Thanks, AB
>>
>>
>>
>