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

RE: When exactly does the determination of default action happen?

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Thu, 7 Feb 2013 01:49:32 +0000
To: Rick Byers <rbyers@google.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-ID: <9c6899461def4c688692932669c42cdb@BY2PR03MB028.namprd03.prod.outlook.com>
On Wed, Feb 6, 2013 at 4:00 PM, Rick Byers <rbyers@google.com> wrote:
>
> Hi,
> The PE spec says "When a user touches an element, the effect of that touch is determined by the value of the touch-action property and the default touch behaviors on the element and its ancestors.".  But _when_ exactly is meant by "when a user touches an element"?  Does it mean as soon as the user first touches before anything has processed that touch?  Or might it, for example, mean "just before the pointerdown event is dispatched"?
>
> Here's a concrete class of issues causing us trouble in Chrome, that I'm wondering if pointer events should fix: sites that set overflow: scroll only when the mouse cursor is over the element (for example, the chat roster in gmail).  If touch-action is truly applied as soon as the user starts touching, then we'll see overflow: none and no touch scrolling will be possible (as with touch events).  If instead touch-action is checked just before pointerdown is dispatched, then we will (according to the mouse event compat rules) have already dispatched the mousemove event which will trigger overflow: scroll, and you should be able to scroll it fine.  
>
> I'm travelling this week so don't have access to a Win8 touch device to test IE10's behavior - sorry.

The value is determined prior to any event dispatch (including pointerdown and any compatibility mouse events). So it does not solve the Gmail chat roster scenario. But that is intentional.

The idea is that you can process input for the purposes of touch behaviors without *any* dependency on JavaScript code. If an event (e.g. mousemove) is guaranteed to be fired prior to determining the touch-action value, then you have to wait on JavaScript to return from the event. That wait is unbounded and can impact the performance of initiating a behavior like panning.

We too have seen sites that do what you describe (though just a very small number). Generally the experience they're going for is to hide the scrollbar when not in use. Toggling overflow is really a hack to do that. You might consider something like the -ms-overflow-style rule in IE10 as a better way to enable this scenario:  http://msdn.microsoft.com/en-US/library/ie/hh771902.aspx

-Jacob
Received on Thursday, 7 February 2013 01:50:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:17:04 GMT