CODEWITHSUNDEEP
htmliossafaritouchhammer.js
glo
glo

Reputation: 799

Reliable use of hammer.js to get pan events while still naturally scrolling in iOS ...?

Essentially, I want to be able to use hammer.js simply to detect start and end of any pan event (or at the very least all pan-x events), whilst still allowing natural overflow-scrolling on the x-axis. A touchAction declaration on the pan recogniser allows this to work alongside natural overflow scrolling just fine on Android > Chrome, but not on iOS > Safari (touch-action declarations not currently being supported by any Safari build).

Codepen(debug-mode) or Codepen(normal-mode)

EG.

var hit = document.getElementById('hit');
var text = document.getElementById('text');

var hammer = new Hammer.Manager(hit);
hammer.add(new Hammer.Pan({
  direction: Hammer.DIRECTION_ALL,
  touchAction: 'pan-x'
}));

hammer.on("panstart", function(ev){
  console.log('panstart');
  text.textContent = ev.type +" detected.";
});
hammer.on("panend pancancel", function(ev){
  console.log('panend');
  text.textContent = ev.type +" detected.";
});

Is there a reliable way to detect all directions (or just x) of pan movement, but also allow normal overflow scroll-x behaviour (in iOS)? I have tried switching the pan recogniser to vertical, but found that the panstarts aren't always / reliably detected straight away.

Upvotes: 0

Views: 973

Answers (1)

glo
glo

Reputation: 799

On second thought, perhaps Hammer.js is overkill for this particular use-case.

I've managed to get the desired result, by stripping away Hammer, and simply using native ontouchstart and ontouchend events. eg:

aDomObject.addEventListener('touchstart', handlePanStart, false);
aDomObject.addEventListener('touchend', handlePanEnd, false);
aDomObject.addEventListener('touchcancel', handlePanEnd, false);

This way, the default actions for any touch event just fall through to the default browser behaviour (and in my case - overflow!).

Upvotes: 1

Related Questions