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

Ah of course - that should have been obvious to me (since I've argued that
this is one of the main benefits of pointer events over touch events),
sorry (I blame jet lag).

Thanks,
   Rick

On Thu, Feb 7, 2013 at 1:49 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

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