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

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