Re: [pointerevents] Specify that "click", "dblclick" and "contextmenu" events are PointerEvents

I agree with @patrickkettner that `click` has evolved into a user activation (or interactivity) event, so it is no longer a strict mouse event.  But from the same perspective, it is not a pointer event either, right?

Since almost the entire discussion revolved around the need for PointerEvents properties, let's summarize key points into a few buckets:

- **Fractional coordinates:**  The compat risk here is significant, and the majority (all?) of the suggestions suggest truncating to integers.  So making `click`, `dblclick` and `contextmenu` PointerEvents adds no value to the current situation.

- **PointerEvent properties other than `pointerType` and `pointerId`:**  We concluded above that `pressure` should be zero for `click` since `click` follows `pointerup`.  So we can only expect default/unknown values for `tiltX`, `tiltY` and `twist` too.  The same decision goes to `dblclick`.  We now have only the `contextmenu` event left but the event may be fired on `pointerup` (Windows) or `pointerdown` (non-Windows) or even through keyboard, so it is hard to infer anything from any particular value of these properties.

- **`pointerType` and `pointerId`:**  These seem to be the only properties we may need for for `click`, `dblclick` and `contextmenu`.  I am yet to see a concrete use-case that *requires* these properties.  Note that any app looking for these properties can already get them today by tracking `pointerdown`/`pointerup` events.  Do we know about any such app today?

Since the compat risk of changing these old events is not negligible, I would suggest waiting until we have a deciding factor for the last point above.  If needed, we may even mark this issue as non-v2 blocking.

GitHub Notification of comment by mustaqahmed
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 30 May 2017 16:57:32 UTC