- From: Mustaq Ahmed via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 May 2017 16:57:25 +0000
- To: public-pointer-events@w3.org
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 https://github.com/w3c/pointerevents/issues/100#issuecomment-304941643 using your GitHub account
Received on Tuesday, 30 May 2017 16:57:32 UTC