RE: Request for Comments: Pointer Events spec's touch-action CSS property

> It seems like a common case might be to allow a pan on the element, but not on the parent, without necessitating a wrapper element. Something like this, perhaps: 
> 
> <div style="overflow:scroll;">
 > <div style="overflow:scroll; touch-action: self;" ></div>  </div> A touch on the child may perform a pan on the child, but must not perform a pan on the parent.
>
We (Microsoft) refer to what you're talking about as "scroll chaining."  This is similar to the -ms-scroll-chaining property IE10 supports:
http://msdn.microsoft.com/en-US/library/ie/hh772034.aspx

The primary function of touch-action is to aid in the decision of native handling (e.g. "touch actions/behaviors" like scrolling or zooming) and script handling (e.g. sending pointer events).  It's not really targeted at telling the UA *how* to perform the particular action (e.g. "you can pan, but don't chain to the parent").

> Might there not be common cases where the author might want to block some touch actions and allow others on the same element? For instance, allow default behavior for pinch-resizing, but prevent the panning from affecting ancestors of an overflow:scroll element?
There's been some discussion about this in our group:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217


Defining gestures, like pinch, is outside the scope our charter (http://www.w3.org/2012/pointerevents/charter/). But there may be room for defining particular actions (e.g. what the browser does in response to input). This is on the agenda for our group's Tuesday telecon.

>Also, I agree with Peter that we might be limiting ourselves by only considering this declarative default action handling for touch events only. I have, in the past, wished I could prevent mouse scroll wheels from affecting parent elements (such as the BODY), perhaps with something like this:
>
><body>
>   <div style="overflow:scroll; pan-action: self;" ></div>  
>  [full, overflowing page of stuff here....] </body> A pan (scroll) action on the child performs a pan on the child, but must not perform a pan on the ancestors.
Would love feedback on the scroll chaining property above, which I believe satisfies this scenario. It applies for mouse wheel as well.

The general reason we only have a "touch-action" is because the performance issue is primarily with touch. Because your finger is 1:1 with the contact on the screen (versus having your hand on a mouse while looking at a screen), performance lag is much more noticeable than other devices.  

> As for the block-level restriction, this was simply an optimization we made to IE10, which the spec is based on. In general, only block-level elements are capable of these types of behaviors. As for the name, well it's the *actions* (think: default action from events) that the *touch* can perform. We'd like to shoot for interop with IE10, but we're open for suggestions on other names if there's a strong objection to the current.
>
> Supposing we broke 'touch-action' into multiple properties, and generalized them to not be just touch-related, we could have these:
>
> pan-action
> zoom-action (pinching to zoom, if it is touch) focus-action (such as double-tap to zoom in or out on a single element) scale-action (pinching to resize) move-action (dragging to translate position) rotate-action
>
> But it would be better if they all started with the same word instead of ending with it. And maybe we shouldn't substitute the word 'pan' for 'scroll'. 
>
>Something like 'rotate-action: none' probably wouldn't have much effect, unless the UA actually rotated something selectable based on user action. But I think it would be very cool if 'rotate-action:self' actually allowed a user on a touch interface to do the equivalent of a 'transform:rotate(<angle-determined-by-fingers>)', without needing any JavaScript or anything else.

IE10 supports specifying individual actions via other value for the property (e.g. "pan-x" for horizontal scrolling). We're discussing this as a part of the bug I mentioned above, but have to make sure we stay within the realm of our charter.

Received on Saturday, 19 January 2013 06:37:44 UTC