Re: Last Call comments

Hi Charles,

In addition to various WG member responses to this thread, the Pointer 
Events WG also discussed the comments from you and Sergey during our 
March 26 call. The minutes from that call are 
<> (NB: we 
discussed the points in reverse order).

Below, I insert the group's 1-line consensus (Resolution) for 4 of the 5 
points (please see the minutes for details). For one point (#3), the 
group decided to do some additional work before we are able to judge 
consensus so we will followup separately on that point.

For the purposes of our Last Call comment tracking, please let us know 
your thoughts on the resolutions for points #1, #2, #4 and #5.

-Thanks, ArtB

#Trackbot: this e-mail addresses Action-29

On 3/18/13 5:22 AM, ext Charles McCathie Nevile wrote:
> Hi, these comments are from people at Yandex who implemented Pointer 
> Events for our services...
> 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).

#1. RESOLUTION: an API to return active pointers is out of scope for v1, 
but will be tackled in v2

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

#2. RESOLUTION: supporting multi-mouse is out of scope for v1, will 
tackle in v2. The primary mouse having id 1 won't prevent this.

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

#3. We will reply separately about this point.

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

#4. RESOLUTION: keep tiltX/tiltY units as defined

> Preventing browser reaction via a custom css property contradicts both 
> the css paradigm (css is not designed to handle user input) and the 
> DOM Event paradigm (preventDefault is the normal way to prevent 
> browser behavior); furthermore, the idea that browser may have 
> different reactions on mouse and touch actions ruins the whole proposal.

#5. RESOLUTION: declarative-only control over browser default action 
(touch-action property) will remain the only mechanism for now

FYI, UCs and requirements we are deferring for v.Next are listed in 

> cheers
> Chaals

Received on Wednesday, 27 March 2013 12:32:17 UTC