Should "click", "dblclick" and "contextmenu" events be PointerEvents?

[RByers]

@dtapuska just noticed that Edge sends click as an instance of PointerEvent, not just MouseEvent. I think we've agreed before that this was a good idea, but I don't think we've talked about speccing it.

I think we can just add a short section to the PE spec "upgrading" click to PointerEvent. Also dblclick and contextmenu. @teddink, that's it right? I didn't check drag events or anything.

[RByers]

By the way, for context: The main reason we've said this is desirable it that sometimes it's useful to know the pointerType of a click / contextmenu. This is similar to, but subtly distinct from, wanting to know whether the source devices also fires touch events (sourceCapabilities.firesTouchEvents).

[dtapuska]

In Edge I tested dragstart and the event fired has a drag prototype and the drag prototype is a mouse event prototype.

[NekR]

I agree, it sounds good to have click as a PointerEvent. It'll provide only benefits to web devs.

[smaug----]

contextmenu can be triggered also using keyboard, and click can be the default action for certain key events and click() dispatches MouseEvent click.
So need to define what pointerType should be in each of those cases. Default is "", I guess we could use that for now.

And HTML spec needs a change for click(), somewhere https://html.spec.whatwg.org/multipage/webappapis.html#fire-a-click-event or https://html.spec.whatwg.org/multipage/webappapis.html#fire-a-synthetic-mouse-event

[smaug----]

Changing HTML spec might be a tiny bit controversial. Other option is to add a hook to the HTML spec where other specs could extends/re-define what kinds of events should be fired for click.

[patrickhlauke]

Does Edge only "upgrade" click to a PointerEvent if it was the result of a pointer interaction? And if so, can it perhaps be defined in PE as an extension to the regular click event (leaving the HTML spec untouched)?

[smaug----]

Would be rather odd to have platform dispatching 'click' as MouseEvent in some cases but as PointerEvent in some other cases. And error prone - event listeners couldn't trust the event to have the same properties each time.

[RByers]

Looks like IE has had some version of this back to IE11. After some discussion it sounds like the design we think makes the most sense is:

• All UA-generated click, dblclick, contextmenu events would be of type PointerEvent, with properties that match the corresponding pointer events (eg. pointerType, isPrimary).
• click() and keyboard-initiated click/contextmenu events will have all PointerEvent properties set to their defaults (eg. pointerType="").
• we'll treat DragEvent as a separate (low priority) issue (filed Should DragEvent be upgraded to a PointerEvent? #106).

Next step is to check to see to what extent Edge already matches this design. @teddink says he'll do this. As @smaug---- says, specing this properly will be hard. But perhaps we can just start with something partly hacky here in the PE spec and then try to get it integrated into the correct places.

[jacobrossi]

I think this is roughly what we implemented yes. I think we also want PointerEvent for your "auxclick" proposal which currently uses MouseEvent (e.g. WICG/auxclick#6).

[jacobrossi]

FYI - here's the old thread on this https://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0081.html

:-)