So I had to study how Microsoft did implement their touch support. Pretty fast I stumbled over their well documented library. But unfortunately I had to discover that (again) Microsoft did something on their own: Even if Android and iOS did manage to support nearly the same eventtypes („touchstart“, „touchmove“, „touchend“) so you can easily use the same code for both device types, Microsoft introduced two proprietary event types: MSPointer and MSGesture.
So this lead to the point where I had to extend the nice hammer.js framework with new code which handles the special Microsoft events. You can find a fork on github which I will try to add it to the original framework soon when I’ve finished testing.
The main thing about the gesture support is that you have to create a MSGestureObject for each element you want to handle gestures – otherwise you will only get PointerEvents and will need to handle all interpretation by yourself. After you registrated such an object you will get the events with a plentyfull of information about the current gesture and it’s changes – like rotation and scaling. But here comes the disappointment: The online documentation only names it as rotation but unfortunately it’s more like a translation of the CSSMatrix which is also a proprietary object of Microsoft to handle CSS-transformations. So as I wanted to extend a framework which delivers a wrapper-event with these information I had to pull back and calculate the scaling and rotation by myself instead of using the quite cool but in this scenario unuseful features.
During my work I stumbled over several issues with the MSPointer & MSGesture events which I would like to share:
One issue is that the event bubbeling in IE10 works bottom-up – on iOS or Android it’s top-down… so after realizing this (and it unfortunately took quite long) I finally got an answer why I retrieved events from the wrong HTML elements – something which can be real disturbant when you try to register the MSGestureObject only for these elements you want events for.
Another problem is that even when MSGesture-events are fired the browser still continues to throw the MSPointer-events – fortunately this is something positive as you can now record your own „touches“-array… As the MSGestureEventObject comes with already calculates scale and rotation, they simply miss an array of touches with the coordinates of the finger-tips… As the hammer.js and my own implementation take big usage of these arrays I had to implement my own array with the MSPointerEvents.
On our Ultrabook we had also the problem that the touch device also fires a Mouse-event each time you tap or drag something… as this is normally not to be expected the initial author of the hammer.js-framework simply ignored this and interpreted each mouse event as a touch-event… I expected Windows 8 to hold back the mouse events as I’m really only touched the screen.
Finally there is to say that there does not really exists a nice debug-tool for the IE10 in touch-mode (or Metro-Style or however it is called)… so I had to turn back to classic „debug.print“/“console“-debugging by writing my own debug-console to the DOM… Every iOS-developer without Safari 6 (see my last post) will know what I mean.
UPDATE: Currently I’m struggeling with identifying whether the IE10 comes as Metro or desktop version… unfortunately there is no clear way to identify. The best practice is that you can only hope the desktop version is not started as 64-bit application and so you can lookup the userAgent-string. See this stackoverflow question for more details.
Our next question is how a Microsoft Surface behaves with Windows 8? On Windows RT it seems to simply send „touch“ events as there is a contributor of the hammer.js-framework who added Surface-support without interpreting new event types. But unless I do not have a Surface-device in my hands I will not be able to say something about it. But when I get hold of such a device I will post an article of course.