- From: Scott González <scott.gonzalez@gmail.com>
- Date: Tue, 29 Jan 2013 12:49:46 -0500
- To: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <CAO8i3icaDTJFmcEc9nLySbLSo5McOyTTWLVSBdgER4UJ=jhR=Q@mail.gmail.com>
Following up from our call today, I looked into what methods jQuery might use for inspecting click events. As mentioned on the call, we currently look at the event type to determine which properties to copy/fix in our normalized event objects. There was a recent attempt at using instanceof [1], but it was decided to continue using the event type check [2]. The benefit of using instanceof is that we wouldn't need to keep a list of event types that have mouse properties. However, it would also require getting the window for the target event in order for it to work properly across frames. Not having to maintain a list would be more compelling if the list were actively changing, but the list is fairly static. However, we would like to eventually move to using instanceof. As long as PointerEvent inherits from MouseEvent, this would be fine. In fact, once PointerEvent has implementations, jQuery would probably add a case specifically for PointerEvent to handle the new properties. [1] https://github.com/jquery/jquery/pull/1115/files#L3R463 [2] https://github.com/jquery/jquery/commit/6f7b6915bf457c413476faefb2159df717c2c210#L2R490 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. > > I'd first like the PE group's input on such a change. Also, how would we > make this change? > > 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." > > 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 Tuesday, 29 January 2013 17:50:14 UTC