Justification for the touch-action processing model

[Updating subject]

Also, as I work to implement this in blink, it seems like it would be
simpler if this processing model was defined in terms of what the computed
value for an element was (rather than the processing model being a layer on
top that's not visible in the computed/used value).  Eg., for:
<div style="touch-action:none">
  <div id=inner></div>
  <div id=scroller style="overflow: scroll;"></div>
</div>

In IE10 we get:
getComputedStyle(inner).touchAction=='auto'
getComputedStyle(scroller).touchAction=='auto'

But naively since (I think) we can compute the effective touch action
completely statically, it would make sense to do it at style resolution
time and cache result as the computed touch action value.  That would give:
getComputedStyle(inner).touchAction=='none'
getComputedStyle(scroller).touchAction=='auto'

Is there some reason I'm missing why the permitted touch actions for an
element shouldn't be computed at style resolution time?  We certainly can't
really compute the value at pointerdown time as the spec suggests because
that requires access to the DOM which most browsers don't have access to
from the GPU thread.

For blink, to be consistent with the IE10 behavior, I'll try stashing my
pre-computed 'effective touch action' somewhere other than the computed
style (so it's not exposed to callers of getComputedStyle).  But I'd like
to understand if there's a good reason for this extra level of abstraction
in the processing model.

Thanks,
   Rick

On Thu, May 23, 2013 at 10:28 AM, Rick Byers <rbyers@google.com> wrote:

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