W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2015

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

From: Rick Byers <rbyers@google.com>
Date: Tue, 21 Apr 2015 16:02:41 -0400
Message-ID: <CAFUtAY-kF=uunJk+deego51_EsyPrkbBfVvaR9oCYs1vFdKfuw@mail.gmail.com>
To: Arthur Barstow <art.barstow@gmail.com>
Cc: Jacob Rossi <Jacob.Rossi@microsoft.com>, Sangwhan Moon <sangwhan@iki.fi>, Dave Methvin <dave.methvin@gmail.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On Fri, Apr 17, 2015 at 8:04 AM, Arthur Barstow <art.barstow@gmail.com>

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


 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

 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

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


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 Tuesday, 21 April 2015 20:03:28 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 16 May 2015 00:31:59 UTC