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

RE: Justification for the touch-action processing model

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Sat, 1 Jun 2013 18:48:27 +0000
To: Rick Byers <rbyers@google.com>
CC: Daniel Freedman <dfreedm@google.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-ID: <be54afb750074ae0a2ab3a0b49f82581@BN1PR03MB267.namprd03.prod.outlook.com>
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.

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.

-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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>
>
Received on Saturday, 1 June 2013 18:49:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC