We were discussing alternate approaches to the "delay" issue yesterday.

As an additional data-point, I'd be interested if you have an opinion on going the "tap" route vs. solving the delay by simulating (using dispatchEvent) "click"s vs. using YUI's synthetic-event layer to make "click" a synthetic event (which is similar to the FastClick implementation - the user is listening for click, but under the hood we're listening for touchend).

Ticket #2532282 was marked as a duplicate of this ticket.

From #2532282

It would be nice to have a gesturetap event in YUI3 (for instance based on event-move's gesturemovestart and gesturemoveend) that is triggered if the difference of position between the gesturemovestart and gesturemoveend is small. (For instance, https://github.com/alexgibson/tap.js/blob/master/tap.js uses 10 pixels).

Moving from 3.6.0 backlog to 3.7.0 so you can triage.

Moving 3.7.0 bugs to 3.6.x for triage.

I implemented a tap event using Tap.js as the basis for my work. You can find my code here, https://gist.github.com/3715086. We haven't gone to production with this yet but might be a good start for yal or others.

I tried implementing tap event using gesturemovestart, gesturemove, and gesturemoveend as suggested by Luke but ran into problems as those gestures only fire events for single touches. If someone starts with a single touch, thus firing gesturemovestart, and follows with a second touch I would never receive gesturemove or gesturemoveend events. Without those events I can't determine when a touch is completed and whether it qualified as a tap event. I could have fixed this with a timer but didn't like the idea. I'd rather be more accurate and use the touchmove/mousemove and touchend/mouseup events to determine if movement or multi-touch occurred.

There's a gallery implementation which Tilo is pulling into the library for 3.7.0. Its in the PR. Forwarding this on to him for ongoing communication

Yep, it's included the 3.7.0PR2 as the 'event-tap' module. More info on the blog post here:

http://www.yuiblog.com/blog/2012/09/12/yui-3-7-0pr2-final-round-of-testing/

Great, did you by chance add an option to call preventDefault on the end event? Otherwise for touch devices a click event will still fire after the tap event.

Good catch, thanks! :) I'll get that fix in for the 3.7.0GA. Should that be an option? It seems to me like you would want preventDefault to be called all the time on touchend.

Tap.js specifically allows click events to fire for input controls(select, input, textarea), so I'm assuming there's native behavior still dependent on the click event. I haven't used my tap event with inputs on the iPad yet so I can't be certain. I can experiment with it tomorrow and let yah know.

Sounds good. I'll do some testing on my end with those input controls as well later today. We have a code freeze for GA end of day tomorrow, so if you can let me know before that, I'll get your feedback into it.

Looks like always calling preventDefault is not the way to go. Form controls don't behave normally after tap events, so they won't gain focus or trigger value changes. For example, checkboxes and radios don't change from unselected to selected, dropdown lists don't open, buttons don't visually respond.

I'd recommend calling preventDefault for everything but Input, Button, Textarea, and Select tags. If yal want more flexibility you could make calling preventDefault an option, but by default allow events to continue for the previously mentioned tags.

Hey Jesse, did you test this on iOS? I'm doing my own testing to confirm this. Do you have an HTML file, or a fiddle that I can look at?

Hey Jesse, I did some manual testing on my own in iOS5 and this is what I found:

- With the current event-tap implementation, using `'tap'` still allows inputs, radio buttons, etc. to visually change state. However, these changes are not reflected at the `'touchend'` event. The value-change can only be picked up on the 'click' event. (I think you came across this issue as well).

- Calling e.preventDefault() in `touchEnd()` does not help the situation above. Clicks will still be fired after touchEnd. I dont see this as a bad thing necessarily. You can use the click event to get the value-change, and use the 'tap' event to do any user-interaction (such as changing the pressed state)

- There is a way to prevent clicks from firing after `touchend` events. Google does this via a "preventGhostClick()" on their Fast Button implementation (see https://developers.google.com/mobile/articles/fast_buttons). I have encapsulated this functionality inside 'event-tap' on this gist: https://gist.github.com/3724835. Using that will ensure that on touch devices, click is not fired after touchEnd, but I don't think we always want that to happen because of what I said in the point #2 above.

So all in all, I feel that there is nothing wrong with the 'click' event firing after the touchend. Not sure if I'm missing something - let me know if I am on the wrong track here.

No I think you're on the right track. I need a way to prevent the 'click' event from firing in certain cases and I think your implementation of Google's Fast Button will work. I agree we don't always want to prevent 'click' events so if there's an option for those edge cases that'd be great.

I was using iOS4 which is probably where differences between our test cases came into play.

Ok great. I have created a ticket for myself (#2532755) to control the firing of click events after touchEnd. I'll try to get it in for the first PR in 3.8.0. I think it can be done with some small modifications to Google's Fast Button implementation.

I'll close this ticket and we can continue discussion on the new one. Thanks!

New Ticket: http://yuilibrary.com/projects/yui3/ticket/2532755

Update event-tap documentation with comments on #2531502
View Commit: 0d90c3f405b0c3fd97350ccec07af709bbe43519

Update event-tap documentation with comments on #2531502
View Commit: 0d90c3f405b0c3fd97350ccec07af709bbe43519

Moving from 3.6.x to 3.7.0.