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

Re: Making click/contextmenu use PointerEvent interface

From: Rick Byers <rbyers@google.com>
Date: Wed, 23 Jan 2013 10:47:51 -0500
Message-ID: <CAFUtAY85_Ot-tVXuoLvD907=HR8_Z=XJSBi+JMALVu_78g356A@mail.gmail.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On Fri, Jan 18, 2013 at 7:07 PM, Jacob Rossi <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 Wednesday, 23 January 2013 15:48:42 GMT

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