If you attach pointer event handler to document.documentElement or document.body within another pointer handler, the original handler (within which you attach the document / body handler) is called twice).

Code:

var logContainer = document.querySelector('#log'),
    log = function (msg) {
      logContainer.innerHTML = logContainer.innerHTML + '\n' + msg;
    },

    pointerdownHandler,
    pointerupHandler,

    docElement = document.documentElement,
    el1 = document.querySelector('.el1');


pointerupHandler = function () {
  log('pointerup handler');
  docElement.removeEventListener('pointerup', pointerupHandler, false);
};

pointerdownHandler = function (e) {
  log('pointerdown handler');
  docElement.addEventListener('pointerup', pointerupHandler, false);

};

// why is pointerdownHandler invoked twice?
el1.addEventListener('pointerdown', pointerdownHandler, false);

Example: http://jsbin.com/iwuhar/1/edit
Example with comparison to mouse events: http://jsbin.com/iwuhar/4/edit

http://stackoverflow.com/questions/1695376/msie-and-addeventlistener-problem-in-javascript

Currently on Win8, we fallback to mouse. This is no good. Pointer.js should just be rewriting MSPointer* events to pointer* events with small tweaks.

Maybe add scroll as pointer event for fully unification?

pinch-zoom, swipe, etc come to mind.

Usual, we scale with two figera and touch the screen almost at same moment, but two finger-tilt is touch the screen one by one.

Shall we add a timer for scale to distinguish them?

Was toying around with creating a rotate gesture event, which would be two fingers that rotate clockwise or counter clockwise from their reference points, respectively.

The problem I see is that this sort of gesture would easily also fire the scale gesture.

So, my question is, how can we provide a mechanism where conflicting gestures can co-exist?

One thought is that when you register a gesture that knows it conflicts with a previous one, that it can somehow disable or de-register the previously conflicting one, so you get a last-come-last-served sort of behavior. But this sort of thing is brittle and complex to manage.

Another is to perhaps have a way to consolidate an event into a combo event, where you say "both scale and rotate happened", and fire that combo event for BOTH handlers, respectively. That way inside the handlers the application developer can decide if they want to respond to only one, or the other, or in some cases, perhaps both simultaneously.

The mechanism could consolidate events that happen roughly simultaneously into this combo event, or even an event array, so a single handler can know all the eligible events that it participated in.

What do you think?

NOTE: similar frustrations have existed for years between click and double-click, so I'm seeking to find a way to have the event system be a little smarter, to prevent end-developers from having to manually handle those cases.

This example
http://borismus.github.com/pointer.js/demos/basic-gestures.html
works fine in Google Chrome with my Mac trackpad gesture

But, events do not fire in Firefox.

It is not critical that it works with the Mac, but I'm just wondering why it doesn't. Will it would work on a Windows 8 touch screen?

Any ideas?

Thanks,
Don

Have you thought much about how you want this all to work in terms of subscribing to events? One option is to do everything via jQuery so it might end up looking like this:

 $("#myDiv").bind("swipe:left", function() {...});

This is trivial to implement, but what about using it outside of jQuery? It would be nice to have our library work without it then just wrap it in a jQuery library for convenience. Hammer's solution for this is just to have the user create a Hammer in lui of subscribing. So it ends up being like this:

var hammer = new Hammer(document.getElementById("myDiv"));
hammer.onPinch(function() { "Do stuff" });

I don't know if I like this api style because I think you should still be able to subscribe to events in the normal way using addEventListener on the dom elements. I don't know if there is a proper way to do this but maybe we could opt for something like this:

var mydiv = document.getElementById("myDIv");
new SwipeEmitter(mydiv)
//later...
mydiv.addEventListener("swipe:left", function() {...})

Or we could hack into things a bit, get crazy and have something that looks like this:

document.getElementById("myDiv").emmitSwipeEvents();

But that might be taking things too far.

I'm using jquery:

element.bind("pointerdown", function() {
alert("works");
});

on chrome it works fine, but not on the latest firefox... any ideas?

If you only add a touchstart and later user starts using a mouse to interact things will break. (imagine an iPad with a mouse). More info about it here: http://webreflection.blogspot.com.br/2012/06/dealing-with-future-pointers.html

Feeling that the way would be to add listeners to all event types and normalize them internally (after you start a touch wait for touchend, if you start a mouse event wait for another mouse event..) I also feel the library shouldn't change the native addEventListener() because the dispatched event will differ from native events and names could clash (can lead to incompatibilities with other libs in the future).

Each touch event listener is forcing event.preventDefault(). This breaks the default functionality on touch devices, like page scrolling in Android for example.

I'd suggest removing those, if there is no specific reason to prevent the default actions.

Here's an exmaple code that doesn't use any libs except for Modernizr and Pointer.js:
http://jsbin.com/uqudov/3

Here's an example of the code with jQuery:
http://jsbin.com/usuxif/3

For the sake of being short I'll only paste jQuery's example code:

// here the link is not followed and `#` doesn't appear in the address bar
$('.container-click').on('click', 'a', function (e) {
  e.preventDefault();
  console.log('link clicked');
});

// the links in this container are followed by browser
$('.container-pointer').on('pointerup', 'a', function (e) {
  e.preventDefault();
  console.log('link clicked');
});

Returning false doesn't work either (you can try to test it http://jsbin.com/uqudov/3/edit)

The three examples don't work at all in Firefox 13 on Ubuntu 12.04.

No exceptions in console.

If for example in the pointer event logger you add an overlay above the div#test that spans 50% of the height (and it is a child of div#test) then you will see that when you click outside of div, everything works as expected, but when you click on the overlay you will always get pointer count = 0;

My guess is that the information does not bubble up on the DOM tree

On devices that support both the touch events, and the mouse events (like say the chromebook pixel), pointer.js only responds to the touch events.

I might have an older version of the library, but I would expect any applicable input method to be allowed, and not restricted to a single input method...

I do not think that this is the intended behaviour.

In looking at the double-tap recognizer it would seem that no logic is included to recognize whether the taps relate to the same pointer (finger).

Sigh...

Hey,
just a simple question: I can't find any license, it would be nice to add an license.

Greetings