Related: should the suppressed click be stopPropagation’d as well? Currently we just preventDefault.

just realized that we'd probably would want touchmove to be preventDefault’d (also used to be that way), since a preventDefault on touchstart also cancels the click event (on touch platforms).

Well, just looking now, and it definitely appears that we must suppress touchstart’s default behavior on iOS, or dragging is basically useless because it will trigger scrolling (panning or pinch-zooming). And since we have to disable touchstart at the start of the gesture, there’s no way to not re-enable the click if that touch gesture doesn’t result in any movement.

/cc @jasondavies @jfirebaugh

did you consider suppressing touchmove instead? Seems to work quite well on iOS: http://be-asp.budget.opendata.ch/ (maybe worth testing in a isolated example but I don't have time to create one atm.)

I tried suppressing touchmove and it didn’t seem to have any effect (using iOS Simulator).

touchmove suppressing works for me in iOS simulator 6.0 and iPad with iOS 6:
http://bl.ocks.org/tpreusse/5971476

also added an alert on click which works for me with touchmove preventDefault'd but not touchstart preventDefault'd.

Thanks for that! I figured out what was going on and have fixed it in ba1a411, which now prevents default on touchmove rather than touchstart. It does seem, though, that any preventDefault on touchmove also prevents the subsequent click from firing (not just the browser’s default behavior), but I think that’s probably okay.