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

RE: Making click/contextmenu use PointerEvent interface

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Fri, 25 Jan 2013 23:53:41 +0000
To: Rick Byers <rbyers@google.com>
CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-ID: <187d6fe139234966bbc600bf4d7551c3@BN1PR03MB021.namprd03.prod.outlook.com>
> First, how confident are you that this won't break some websites?  In particular, if a site is doing 'Object.prototype.toString.call(event)' to check the type of an event (perhaps comparing it to others) it could be confused by click becoming a PointerEvent instead of a MouseEvent.  Hopefully this should be exceedingly rare (obviously the common case is just to look at event.type), but is it so rare that we can ignore it?  If not, then the obvious alternative is to add a new 'pointerclick' event type.

I think the instances of this will be very low (also typeof and .constructor will be affected). As a sanity check, I checked some data from the top 110k pages and only found 209 instances of "MouseEvent", which is pretty small (and would be the upper bound of actually impacted pages from this set). Hand picking a couple dozen or so, most were false-positives (e.g. document.createEvent("MouseEvent")). I did find a couple pages that look like they have a code path that would be affected. But the number is so small that I think this change will be OK to make.

I'd really like to avoid creating a new event (I feel that would go the way of DOMActivate and not be successful in uptake), if possible. Just more hassle for web developers to have to switch (esp. in the interim where not all browsers supported the new event).

From: Rick Byers [mailto:rbyers@google.com]
Sent: Wednesday, January 23, 2013 7:48 AM
To: Jacob Rossi
Cc: public-pointer-events@w3.org
Subject: Re: Making click/contextmenu use PointerEvent interface

On Fri, Jan 18, 2013 at 7:07 PM, Jacob Rossi <Jacob.Rossi@microsoft.com<mailto:Jacob.Rossi@microsoft.com>> wrote:
Hey folks,

As we've discussed before, click is generally considered an activation event and not considered a "compatibility mouse event" [1]. That is to say, a UA that didn't implement DOM L3 Mouse Events should still implement the click event and devices other than mouse can produce this event. In that line of thinking, we've been considering making this event (and also, the contextmenu event) use the PointerEvent object. The primary use case is being able to determine what type of device caused the click/contextmenu.

Yes, I've talked with a few web developers where they really need to know if a click came from touch or from mouse.  So I agree solving this scenario is important.

I'd first like the PE group's input on such a change. Also, how would we make this change?

First, how confident are you that this won't break some websites?  In particular, if a site is doing 'Object.prototype.toString.call(event)' to check the type of an event (perhaps comparing it to others) it could be confused by click becoming a PointerEvent instead of a MouseEvent.  Hopefully this should be exceedingly rare (obviously the common case is just to look at event.type), but is it so rare that we can ignore it?  If not, then the obvious alternative is to add a new 'pointerclick' event type.

The DOM L3  Events and HTML5 definitions of when to fire click/contextmenu are still accurate, but need to indicate the PointerEvent interface should be used for the event object:

"The click event type must be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the pointer button, or otherwise activates the pointer in a manner that simulates such an action. The actuation method of the mouse button depends upon the pointer device and the environment configuration, e.g., it may depend on the screen location or the delay between the press and release of the pointing device button." [2]

"If the user requested a context menu using a pointing device:
The user agent must fire a trusted event with the name contextmenu, that bubbles and is cancelable, and that uses the MouseEvent interface, at the element for which the menu was requested. The context information of the event must be initialized to the same values as the last MouseEvent user interaction event that was fired as part of the gesture that that was interpreted as a request for the context menu." [3]

My recommendation would be to update the UI Events (was "DOM4 Events") and HTML 5.1 Nightly specs--something along the lines of "if a User Agent supports Pointer Events, then it SHOULD use the PointerEvent interface."

Sounds best to me (assuming we decide it's safe to make this change to the web).

If the PE group agrees we should make this change, then I can draft exact spec text and we can propose it to the WebApps and HTML WGs.

-Jacob


[1] http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0075.html
[2] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-click
[3] http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#context-menus
Received on Saturday, 26 January 2013 00:36:18 GMT

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