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

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.

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

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

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

L687: s/beyond it's extent/beyond its extent/

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

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

Trying to read this PR in its larger context, it seems like the spec 
should include a definition of "default touch behavior".

-Thanks, AB

Received on Friday, 17 April 2015 12:05:16 UTC