RE: click and contextmenu events

In IE10, click follows the DOM Events definition, which is that it is dispatched to the nearest common ancestor of the down and up events. This has the positive aspect that you can extend the physical object analogy of touch to UI like buttons:  touching down on the left side then dragging to the right and lifting will still activate it (like a physical button). Generally speaking, we don't see accidental activation when dragging (you used the term "pan", but since we're talking touch-action: none, I'm using "drag" so as not to be confused with scrolling). This is because you often drag over multiple elements, which means the click will go to some arbitrary non-activatable parent element. That said, you're right that there are scenarios where this isn't ideal (consider a canvas-based map where dragging would be over a single element and cause a click). While we don't have immediate plans to change our behavior, I wouldn't put that beyond the realm of possibility. Though I don't see any definition, beyond what's already called for by DOM Events, being in the scope of this group.

Yes, contextmenu is like click (not a compatibility mouse event). Hence why I include it in my proposal to use the PointerEvent object. Probably worth adding contextmenu to the sentence in PE that says click is not a compatibility mouse event.

-Jacob

From: Rick Byers [mailto:rbyers@google.com]
Sent: Wednesday, February 20, 2013 2:25 PM
To: public-pointer-events@w3.org
Subject: click and contextmenu events

Although it's mostly out of scope, the spec talks a little about click events.  I played with the IE10 implementation a little wrt. click (using www.rbyers.net/eventTest.html<http://www.rbyers.net/eventTest.html>) and was surprised that on a region with touch-action:none, ANY pointerup seems to be followed by a click event.  This means, for example, that if a map is handling pan gestures, but also supports being tapped (eg. to place or select a push-pin), then the application needs to have it's own tap gesture recognizer (to avoid taking the tap action at the end of every pan).  'click' is an indication that a user intends to activate something, I wouldn't have expected the UA to want to send that for anything other than a singer-finger tap.

The spec has a note that includes "Because it is not a compatibility mouse event, user agents typically fire click for all pointing devices, including pointers that are not primary pointers".  This covers part of what I'm seeing, but not all of it.  Perhaps we should expand this note to describe the typical behavior of click in more detail?  This seems like an easy place for implementations to differ, resulting in compatibility problems.

If we're going to mention click, should we mention contextmenu too?  It seems the behavior in IE is similar (eg. contextmenu still fires even when preventDefault is called).

Thanks,
   Rick