Closed MalabarFront closed 11 years ago
This works as intended to provide as fast response time as possible.
It's up to the designer/developer to not put the toggle in a place where this functionality would cause harm to the user.
I disagree with your argument on this one. There's nowhere on the page where you could guarantee a user won't place their thumb to scroll and swipe, so the plugin firing events on touchstart, to me, is the source of the harm, not the placement of the toggle button.
There are ways to eliminate the 300ms delay without introducing this behaviour. As Google themselves say: "If the user touches down on the button and then drags the screen a bit and then invokes a touchend on the button then we should not fire a click." (Source: https://developers.google.com/mobile/articles/fast_buttons)
And Fastclick (https://github.com/ftlabs/fastclick) also avoids this problem.
Obviously this is your project, I'm just putting two pennies in as to what I think the sensible behaviour should be.
@MalabarFront I reopened the issue, maybe we can come up with a good solution to this :)
add a touchmove even and cancel the tap if it is fired (with a 5-10px threshold)
@cubiq Sounds like a good and simple solution!
I have a new version now coming which uses 10px threshold and triggers the menu open on touchend if there's no touchmove. Need just a bit more device testing before pushing to GitHub.
Any updates on this one? I'm having the same issue, as my menu is placed further down my page and gets triggered by accident when the user is scrolling.
@challahan This issue is fixed in the latest release I just pushed.
You're awesome - thank you!
As always, stellar work on this. One issue so far:
On touchscreens (tested on safari/chrome on iOS6), the menu toggle event fires as soon as your finger touches the toggle, not when it's lifted after a tap. So it essentially intercepts scrolling and turns the toggle into a dead area on the screen.
Cheers.