- From: Peter-Paul Koch <pp.koch@gmail.com>
- Date: Tue, 15 Feb 2011 22:35:20 +0100
- To: Andrew Grieve <agrieve@google.com>
- Cc: public-webevents@w3.org
>> >> > [[ >> >> > If preventDefault() is called on all touchmove events, should a click >> >> > be >> >> > fired even after dragging and taking your finger off the screen? >> >> > -This is the case with iOS >> >> > -I can't think of why this would be desirable. >> >> > ]] >> >> >> >> I'd say Yes, the click event should fire. One user action triggers >> >> several events here, and the fact that you prevent the default of one >> >> should not influence the firing of other events. It may not be very >> >> desirable, but it is logical. (As far as I'm concerned.) >> > >> > I think if the answer is yes, then just the opposite is happening - >> > preventDefault is affecting the firing of other events. The question >> > here is >> > about a swipe that would not normally have fired a click, but does only >> > because preventDefault() was called on all of the touchmove events. >> >> Oh wow, do you mean that's what actually happens? That's Evil, if it's >> true. >> >> Is there a test page for this effect somewhere? > > Hmm, it's not exactly what I had thought. You need to tap-and-hold until the > browser thinks you might be clicking. Without preventDefault(), the browser > will enter native scroll mode and cancel the click. With preventDefault(), > the browser will never enter native scroll mode, and so the click will > always fire no matter how much you move your finger. This is all on iOS. > Test page: > http://dl.dropbox.com/u/6648754/webtests/touchmoveghostclick.html Safari iOS does as you say, as does BlackBerry WebKit. Android WebKit, Dolfin for bada, and Opera Mobile do not show the alert. So sanity wins by 3-2, the effect should not be specified, and Safari and BB have a bug. At least, that's my opinion. -------------------------------------------- ppk, mobile platform strategist http://quirksmode.org/about/ +.31.6.29585782 --------------------------------------------
Received on Tuesday, 15 February 2011 21:35:53 UTC