- From: Rick Byers <rbyers@google.com>
- Date: Wed, 20 Feb 2013 14:25:00 -0800
- To: public-pointer-events@w3.org
- Message-ID: <CAFUtAY-8O8i6hOEqVUND3UeKUrOdfc1ejRpo5xdjzPX3Fq+r0g@mail.gmail.com>
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) 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
Received on Wednesday, 20 February 2013 22:25:47 UTC