The mobile web can be a weird place at times. One of the most important details to keep in mind when building a great user experience is how tap and click work, and how they interact (hint: poorly).
Mobile browsers that support touch event bindings (eg, Webkit) also have to support click bindings on the same element, otherwise webpages built for the desktop would be completely useless on mobile browsers. So for every tap on a mobile web page a click is fired right along with it.
Initially this seems like a trivial detail and that we might just bind to click and be done with the whole discussion. Unfortunately there exists a 300ms (+/-) delay between the touchstart and click events to allow for scrolling, cancelling, and other interactions. This means that if you just bind to click, your user interactions are going to feel really sluggish.
Assuming you care about that sort of thing the next best solution would be to normalize by grabbing the first event and cancelling the second, but before you run off to do that you should know that the click event doesn't always fire on the same object as the touch event. Mobile browsers use complex heuristics to determine touch and click targets. In some browsers if you click near the border of an element the click will fire on a different target.
jQuery Mobile has addressed these problems (in so far as they can be addressed) with the vmouse plugin. It gives you virtual mouse events that will handle both mobile and desktop browsers to get your callbacks executing as quickly as possible. You can get your hands on it by cloning the repo and removing the amd define wrapper.
update We've updated the deps to allow the downloading of vmouse by itself from the builder: http://jquerymobile.com/download-builder/ simply select "Latest" or the upcoming alpha and you'll be able to choose vmouse by itself.
Finally, a note about standards. Specifically, the w3c's touch event standard is stalled thanks to patent issues which means things will get worse with Microsoft introducing its own standard (MSPointer). We should all get used to dealing with the disparity between the two event structures because it's going to be this way for a while.
Lots more reading from my friend Kin Blas: