Re: Is touch-action implicitly applied to any elements?

Reviving this old thread.  I've some questions about why the
processing model is defined this way instead of using a simpler model
where only the touch-action of the element touched is relevant, but
touch-action is inherited.  I realized I've never asked what the
motivation for this design was.

I've assumed that the reason for this is to minimize the number of
rules that need to be added (especially when adapting code designed
for mouse where you may have a complex DOM structure and it may be
hard to find all the places that need a touch-action rule).  Eg. if I
have a map that needs to handle events for panning then I'm of course
going to have touch-action: none on the map container (which will
apply when I touch descendants like tile images).  But perhaps it's
possible for descendants of the container to have their own scrollable
elements (eg. when a location is clicked, perhaps a card comes up with
details/reviews etc. with content that can be scrolled).  It's
probably simpler (and less error-prone) to let such content scroll
with touch automatically instead of inheriting the touch-action: none
of it's container.

Jacob, Is this the primary reason for the original design, or is there
more that I'm missing?  Do you think we should add a note to the spec
to explain this?  It's apparently non-obvious to most people that read
the spec.

Thanks,
   Rick

On Wed, Dec 19, 2012 at 1:01 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:
> I believe there’s some language missing from the spec to clear things up.
> Here’s perhaps a more concise description of the behavior (emphasis on the
> last sentence):
>
>
>
> When a user touches an element, that element's -ms-touch-action property
> determines the default touch behaviors permitted for that contact, like
> panning or zooming. The touch behavior is then performed on the nearest
> ancestor element that is capable of that behavior, unless an intermediate
> ancestor element specifies that the behavior is not permitted.
>
>
>
> Does that clear things up?
>
>
>
> From: Daniel Freedman [mailto:dfreedm@google.com]
> Sent: Monday, December 17, 2012 3:13 PM
> To: Rick Byers
> Cc: public-pointer-events@w3.org
> Subject: Re: Is touch-action implicitly applied to any elements?
>
>
>
> In the second version of your example, switching to -ms-touch-action: auto
> on the outer div leaves no -ms-touch-action: none area in the page.
>
> IE10 has a default action on document ( or window?) to use x-axis panning
> for back/forward history gesture.
>
> The finger can move around a little bit in the x-axis when dragging, and it
> appears the history gesture has no hysteresis.
>
> If you quickly tap the area instead, you will see a MSPointerMove event.
>
>
>
> On Mon, Dec 17, 2012 at 3:01 PM, Rick Byers <rbyers@google.com> wrote:
>
> Oh, I totally missed that the spec says touch-action isn't inherited - duh.
> Sorry.
>
>
>
> Ok then I'm seeing different behavior that is surprising.  If touch-action
> isn't inherited, then why does changing outer between 'none' and 'auto'
> affect the behavior of inner when it's not overflow scroll?  Is IE using the
> touch-action of the parent somehow in deciding how to implement "auto"?
>
>
>
> Sample code updated: http://jsfiddle.net/rbyers/YTSuu/.
>
>
>
> On Mon, Dec 17, 2012 at 5:45 PM, Rick Byers <rbyers@google.com> wrote:
>
> In the absence of additional CSS rules that also specify touch-action, the
> following two should be equivalent, right?
>
>
>
> <div id="outer" style="touch-action: none">
>
>   <div id="inner"> </div>
>
> </div>
>
>
>
> and
>
>
>
> <div id="outer" style="touch-action: none">
>
>   <div id="inner" style="tocuh-action: inherit"> </div>
>
> </div>
>
>
>
> In the current IE implementation this seems not to be the case.  In
> particular, if the inner div is overflow: scroll, then it seems to take on
> the behavior of '-ms-touch-action: auto'.  Explicitly specifying inherit
> gets the behavior I expect.  Sample code here:
> http://jsfiddle.net/rbyers/YTSuu/.
>
>
>
> I can see why this might be a good thing (probably makes it really easy to
> convert certain mouse based games to support touch without breaking inner
> scrollable elements), but I also find it surprising.  If this is really the
> intended behavior, then the spec should probably say something about it,
> right?
>
>
>
> Thanks,
>
>    Rick
>
>
>
>
>
>
>
>

Received on Thursday, 23 May 2013 14:29:32 UTC