- From: Arthur Barstow <art.barstow@gmail.com>
- Date: Fri, 17 Apr 2015 08:04:41 -0400
- To: Rick Byers <rbyers@google.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>
- CC: Sangwhan Moon <sangwhan@iki.fi>, Dave Methvin <dave.methvin@gmail.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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