RE: Constructor question and mouseEvents compat

On Wed, Apr 3, 2013 at 10:06 AM, Wesley Johnston <wjohnston@mozilla.com> wrote:
>
> Two quick issues:
>
> 1.) The Constructor for PointerEvents is listed in the PointerEvents interface, but not in the Constructor section. Moving it to the Constructor section would make more sense to me and matches what the UI Events spec does.

This seems like a worthwhile editorial change for a cleaner spec. I went ahead and made this change in the latest Editor's Draft [1].

> 2.) The mouse compatibility section is a little vague to me about what to do with multi-mode input. i.e. If there's a mouse and a touch on the screen, I think we only want to send mouse events for the mouse pointer and not the touch or (I would guess) many pages will have issues with two mice on screen at once? If there's a touch and a pen, I think whichever was set active first should dispatch mouse events?

We (Microsoft) often refer to the concept you're describing as "device arbitration." Platform-specific behavior may dictate this and may involve technologies out of scope for this spec (e.g. "Algorithms to determine unintended input (e.g. palm rejection)" [2]). We've discussed device arbitration in the group before [3], but I can elaborate a bit as the mail threads don't fully seem to capture the discussion we had (perhaps some old minutes do though). 

It gets challenging to define rules for device arbitration. For example, in a touch+mouse device, a user likely still expects a single touch (while not using the mouse) to be compatible on sites that wrote to mouse events. So you can't simply say that the real mouse wins, or else you'll force the user to use the mouse on certain sites that aren't touch aware. Yet, a "first to set active" is not clear in this scenario given that a mouse is typically always active. So you end up needing things like a timeout to decide if the mouse is truly "active."  This quickly gets further beyond the scope of this spec. Moreover, it's not unreasonable to think that different form factors might benefit from different arbitration rules (e.g. some form factors may choose to favor one input type over another). 

The spec defines arbitration within an input modality (e.g. the primary touch, primary pen, etc.) as that is straightforward and doesn't need to vary by platform or form factor. In IE10, we're subject to a set of platform-specific device arbitration rules when multi-modal input is in play. But, in the general case, you can think of this as 2 devices "fighting" for the mouse cursor location (e.g. you'll see mousemove events firing back and forth between the two locations). This is generally compatible with sites, which is the only real goal for the compatibility mouse events section. 

-Jacob


[1] https://dvcs.w3.org/hg/pointerevents/rev/d24dd1d54803 
[2] http://www.w3.org/2012/pointerevents/charter/#scope

[3] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0072.html

Received on Sunday, 7 April 2013 17:29:44 UTC