RE: Pointer Events and click

From: Daniel Freedman [mailto:dfreedm@google.com] 
Sent: Thursday, November 29, 2012 4:22 PM
To: public-pointer-events@w3.org
Subject: Pointer Events and click

> Hi, I'm working on a PointerEvents polyfill and I've run into an odd note in the spec.
> In section 7, click is explicitly excluded from the compatibility mouse events, leaving no good way to control the generation of click events.
>
> This brings to mind a few issues:
>
> 1. If a developer uses pointerdown.preventDefault, they could receive click events without a mousedown/mouseup. This seems very strange.

I think of the click event as the activation of a UI element. This concept isn't specific to a mouse and should exist for touch, pen, or other pointer devices. In some future utopian world where developers no longer care about mouse events, I would expect that click would continue to exist. So if you touch a button, you should see the events pointerdown, pointerup, click. Conversely, in such a world, mousedown/mousemove/mouseup should no longer be required-you only need them if you require compatibility with legacy content. Hence this is why preventDefault() only controls the legacy events. One way to think of it is that the default action of a pointerdown (where isPrimary is true) is to start simulating a mouse for that pointer. If you look back to the way mouse events work, preventDefault() on mousedown does not prevent click. Likewise, I would expect it would not prevent click for pointerdown either.

> 2. There are cases in which a developer would want to conditionally react to a click based on pointer movement. If the click event cannot be prevented by pointermove, the only option is to try and prevent the next click, which has potential for buggy interaction..

I suppose you could say the same cases exist for mouse events, right? Mouse events (and generally most events that happen in a sequence) don't allow cancelling one event (e.g. mousedown) to prevent firing another (e.g. click). So for these types of scenarios, you would need a similar type of workaround whether using mouse or pointer events. I do see that touch events prevent the click, but (based on my answer to your first point) I think that is the wrong behavior. Preventing one event in a sequence shouldn't stop the rest from firing.

It's worth noting that cancelling pointerdown in IE10 (MSPointerDown) will prevent the same actions that cancelling mousedown would have done*. So we should be capturing all the existing use cases that were possible with mouse events.  For example, it prevents focus moving or selection starting. Preventing pointerdown should stop actions associated with pointerdown (like starting a selection with a mouse or moving focus to the element). But a click does not automatically happen just because a pointerdown occurred. 

* This does not seem to be reflected in the current spec text and deserves additional detail. I'll open up a bug.

> 3. If click events are not provided by the browser, developers will try to make their own with pointerdown/up pairs, which is wasted effort.

I agree we don't want developers to try to match pointerdown/pointerup. That's why browsers should fire the click event. It's also why I think the click event continues to live on, even in a user agent that doesn't support mouse events. Further, it's why I don't think preventDefault() on pointerdown should prevent the click event from firing. For example, if you called preventDefault() on pointerdown to prevent mouse selection from happening then you may still want to receive the click.

> 4. Touch Events provide the ability to control click event generation, and developers familiar with that system will understand how it behaves.

I think developers are far more familiar with mouse events, which do not have this behavior. As I stated above, I think the touch events behavior is wrong because (a) click should apply for devices that aren't a mouse (it's not just there for compatibility) and (b) click is not a default action of the pointer coming down (it's a signal that a UI element is being activated).

> With these points in mind, would it be possible to add the control of click events to Pointer Events?

So as you can tell, I don't think preventDefault() on pointerdown should control click. Can you help me better understand a real world scenario where you need this? 

" There are cases in which a developer would want to conditionally react to a click based on pointer movement" sounds to me like the uses cases delve into gesture recognition, which is out of scope for our charter. [1]

Thanks!

-Jacob

[1] http://www.w3.org/2012/pointerevents/charter/#scope

Received on Sunday, 2 December 2012 23:28:05 UTC