Re: Justification for the touch-action processing model

On Sat, Jun 1, 2013 at 2:48 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

>  Addressing your first question:****
>
> The processing model is designed so that you can incorporate
> scrollable/zoomable elements as “ceilings” for the inheritance. Your map
> example illustrates this. Put a different way, we want it such that when
> you touch in a scrollable/zoomable element then you only need to consider
> the elements inside the scrollable/zoomable element to determine the
> touch-action.  Happy to add a note if that helps.
>

Thanks.  And is having a ceiling beneficial for any reason other than
particular implementation details in IE?  I'm not quite done the Chrome
implementation yet, but I don't think it makes anything easier for us.

As a web developer I'm definitely glad I don't have to remember to
explicitly specify touch-action: auto on scrollable elements that might
occur inside of touch-action: none regions.

Your second question:****
>
> Computed styles usually just reduce to a common unit/format. In the case
> of length properties, this does have the effect of needing to take into
> account parent/child relationships. But otherwise, it doesn’t. I think a
> good example of this is overflow. “overflow: auto” does not compute to
> “scroll” simply because the element now overflows. I like this design also
> because it becomes a little more straightforward to detect if a browser
> supports a particular touch-action value because the computed value only
> takes into account the specified style for the given element.
>

This makes sense, thanks!


>  -Jacob****
>
>
> On Wed, May 29, 2013 at 6:29 PM, Rick Byers <rbyers@google.com> wrote:
> >
> > [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
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >
> >****
>