I don't know if this will help, but I've always liked to use drag
more than swipe
. Using Hammer on my projects, swipes were a bit finicky. And from a UX standpoint, drag feels instantaneous vs a swipe. Much like, mousedown vs mouseup/click. So in instances where it's appropriate, and I believe in the case of showing swipey menu it is, I'd opt for drag
.
Replacing your example with drag
rather than swipe
, and also using CSS transition, -webkit-transition
, rather than jQuery's animate (drag will trigger like a mousemove, vs a click or a mouseup) seemed to make it work.
Hammer('.nav').on('dragdown', function(e){
e.gesture.preventDefault()
$(".blue").html("down")
$('.nav').css({"top":"0px"});
})
.on('dragup', function(e){
e.gesture.preventDefault()
$(".blue").html("dragup")
$('.nav').css({"top":"-150px"});
});
//Added in CSS, for .nav
.nav {-webkit-transition:0.5s top;}
This does still have the page overscroll. A preventDefault()
on document.ontouchstart
would could fix that but that breaks scrolling. You might be able to do a selective preventDefault()
by checking the scrollOffset perhaps. But I guess in the long run, I'd recommend something like iScroll.
Also maybe tweak the hitbox for the drag to be a bit larger. Which I did in the last example. I attached the dragdown
event on the document instead of the "menu" so the menu doesn't have to be visibly bigger.
Hammer(document).on("dragdown",function(e){
//calculate ratio of first touch from top
var pos=e.gesture.startEvent.center.pageY/window.innerHeight
if(pos<0.2){ //drag occurs in the first 20% of the screen
menu.style.marginTop="0px" //or animate here
e.gesture.preventDefault()
e.gesture.stopPropagation();
}
})