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

RE: Last Call comments

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Tue, 19 Mar 2013 21:41:30 +0000
To: Brandon Wallace <brandon.wallace@yahoo.com>, François REMY <francois.remy.dev@outlook.com>
CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-ID: <4353b57663c64011a16397582365e612@BN1PR03MB021.namprd03.prod.outlook.com>
Per the deliberate design of the spec, preventDefault() never prevents touch actions (panning, zooming):

"NOTE: Touch manipulations are intentionally not a default action of pointer events. Removing this dependency on the cancellation of events facilitates performance optimizations by the user agent."

If we leave the option for developers to use preventDefault(), then we can’t actually realize the performance wins of touch-action.  That very possibility that an event might cancel it means we have to wait on script. So PE explicitly prevents this. 

The approaches Daniel described should address both scenarios. Google and Bing maps are both using touch-action:none; today for similar scenarios. 

> The pointer system works well when you have only one input device (one mouse, one pen or single-touch-capable screen) and saves some code comparing to the Safari Mobile event model. But if you have more than one input device, the pointer-oriented code becomes far more complex and less obvious compared to the touch-oriented code for Safari Mobile because you have to deal with event streams on your own. We should simplify the tough case (multi-touch), not just the already simple one (single input device).

I'm not sure I follow the issue here. Is it that you believe the pointer model is difficult for multi-touch? Do you have a specific example that's more difficult with PE than TE? Generally speaking, I've heard the opposite of this (i.e. that pointer events are easier than touch events for multi-touch).

> Why should the mouse have pointerId == 1? There is no need for this, since we have a pointerType for detecting input device type, and it makes it impossible to use two mouse devices simultaneously.

The reason mouse uses 1 is that, unlike the other input types, a mouse is persistent. So it effectively gets a reserved pointerId and 1 is convenient for that. Platforms rarely support multi-mouse natively (it usually only works through 3rd party proprietary software in certain niche scenarios). I think it's entirely possible that we could extend the model to support multi-mouse, but I think it's safe to say this isn't a scenario most implementers are prioritizing. So we could tackle this in V2.

> The capturing system is a meaningless artifact of IE6, why implement it again?

It's not an artifact of IE6. There are clear scenarios for it, like the slider control example included in the spec. Another example is dragging elements around on the page.  While the capture phase of DOM events can be used for some of these scenarios, it generally requires more code and gets complex quickly when dealing with multi-touch or component models. Pointer capture APIs make it much simpler and more explicit. Further, pointer capture APIs make it simpler to mimic the touch event hit testing model, in the cases where that's desirable.

> Tilt angles are very difficult to work with, why not use standard spherical coordinates?

Actually, the tilt angles defined in Pointer Events are the standard for pen devices. See the USB HID usage tables spec, section 16.3.2:

I've found scenarios for both tiltX/tiltY and also spherical coordinates. Since it's not difficult to convert between the two, we went with the standard that devices are already reporting.


From: Brandon Wallace [mailto:brandon.wallace@yahoo.com] 
Sent: Tuesday, March 19, 2013 11:05 AM
To: François REMY
Cc: public-pointer-events@w3.org
Subject: Re: Last Call comments


I like the 'touch-action' property but it is nice to know preventDefault() can still be used in more dynamic situations.


From: François REMY <francois.remy.dev@outlook.com>
To: Brandon Wallace <brandon.wallace@yahoo.com> 
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org> 
Sent: Tuesday, March 19, 2013 12:43 PM
Subject: RE: Last Call comments

It doesn’t but the fact that the ‘touch-action’ property exists doesn’t disable your right to call ‘preventDefault’ if you have a complex setup and that ‘touch-action’ doesn’t do the trick, it’s just a way to make your life easier in the 95% of the cases where you don’t need something complex.
Calling preventDefault() to cancel a touch event is a performance issue because the browser has to wait the end of the JavaScript code to know if it can scroll the page or not, causing a visible glitch in some cases. In most cases, using CSS will be sufficient to express your needs and won’t delay the browser decision to scroll the page.
For the rare cases where CSS won’t fit, feel free to use preventDefault, I’m sure it’s gonna suit your needs.
De : Brandon Wallace
Envoyé : ‎19‎ ‎mars‎ ‎2013 ‎18‎:‎34
À : Daniel Freedman, Константинов Сергей
Cc : public-pointer-events@w3.org
Objet : Re: Last Call comments
How does your solution solve Example 2?

Example 2 is: How do I prevent browser behavior if the pinch gesture occurs on one part of the canvas element, but allow browser behavior if the pinch gesture occurs on the another part of the same canvas element?

From: Daniel Freedman <dfreedm@google.com>
To: Константинов Сергей <twirl@yandex-team.ru> 
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org> 
Sent: Tuesday, March 19, 2013 12:21 PM
Subject: Re: Last Call comments

Example 1 is what `touch-action: pan-x` is for. System controlled scrolling in the X axis, with PointerEvents generated in the Y axis.
Example 2, you would place `touch-action: none` on the map and do nothing for the info window, which will pinch-zoom as platform dictated.

In both examples, the css is static, and therefore you don't have to call preventDefault on any event.

On Tue, Mar 19, 2013 at 2:24 AM, Константинов Сергей <twirl@yandex-team.ru> wrote:
> I've to disagree with you on this. CSS *is* a perfectly valid way to configure the browser behavior.
When you need to alter browser behavoir statically - maybe.

Example 1: Safari two-finger scroll. Our task is to prevent browser behavior (page scroll) on vertical scroll and not to prevent browser behavior (history back/forward) on horizontal scroll.
Example 2: we have a map and info window on it. Our task is to prevent browser behavior (page zoom) in favor of map zooming when the fingers are on map; and we want not to prevent the same behavior (page zoom) when fingers are on the info window. Both map and info window are rendered on canvas.

What we have to do? Dynamically change CSS properties? That's ridiculous. In Safari we can just call preventDefault on touchmove event.

Received on Tuesday, 19 March 2013 21:42:37 UTC

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