Re: Making click/contextmenu use PointerEvent interface

Thanks for the data on potential compat impact.  I agree we should go
forward with this.

Worst case and we hit issues with major sites, we could probably switch to
the plan of MouseEvent having a 'pointerType' field instead (since the code
we'd expect people to write should be the same either way), right?

Rick

On Tuesday, January 29, 2013, Jacob Rossi wrote:

>  Great, thanks Scott.  Yes, instanceof should be fine for you to use even
> with this change since it will return true for either MouseEvent or
> PointerEvent. Good to know this doesn’t impact jQuery and won’t block you
> from your future plans.****
>
> ** **
>
> -Jacob****
>
> ** **
>
> *From:* Scott González [mailto:scott.gonzalez@gmail.com<javascript:_e({}, 'cvml', 'scott.gonzalez@gmail.com');>]
>
> *Sent:* Tuesday, January 29, 2013 9:50 AM
> *To:* Jacob Rossi
> *Cc:* public-pointer-events@w3.org <javascript:_e({}, 'cvml',
> 'public-pointer-events@w3.org');>
> *Subject:* Re: Making click/contextmenu use PointerEvent interface****
>
> ** **
>
> 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<javascript:_e({}, 'cvml', '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
>
>
> ****
>
>  ** **
>