This polyfill will not affect such version and will still work with IE11 for original WP 8.1 and IE10 for WP8.
There is a weird trend in the US, most websites, frameworks, libraries, etc etc do not consider IE Mobile, even if version 10 and 11 might offers way better experience than old Android 2.x phones, still a consistent slice of the Mobile market.
The Fail Behind PointerEventsRegardless the good documentation, Microsoft did a mistake about events: it didn't consider simplicity and compatibility over adoption and more over, it didn't implement what was working already for the rest of the mobile world, and still from standards: Touch Events
The PointerEvents Utopia and FailureThere is a very simple reason Touch Events are the preferred and most of the time only choice for mobile web development: patterns between Mouse and Fingers are completely different!
As easy as it sounds, as human being and developer you cannot consider a moving action a generic one ... the mouse moves all the time, except when it scrolls through different mechanisms, while the finger moves only when it's touching the screen with an intentional initial target!
In few words, putting all events inside a single "stream" might sound a good move at first sight, but it's totally messed up the moment you try to use such API to define behaviors for Desktop and Mobile.
Augmented ComplexityInstead of simplifying user intent, touching the screen, and developers / application behavior, we need to maniacally filter every single event and behave differently if it's a Mouse one, a Touch one, a Pen one, or whatever touched that screen or is able to simulate even Multi touches with multiple devices ... in few words instead of two different kind of listeners, the Mouse one and the Touch one, we now need a split logic inside a single listener that at any time could confuse both user and application about the intent.
I honestly don't want or expect users to use both mouse and touches at the same time, so why should I be the one responsible to understand what's going on in my page, instead of the native Hardware/Metal close API which aim should be to simplify the higher level development as HTML and JS is?
Where Touch Events WinIs very simple, if we set a
touchstartevent to a receiving DOM node, it does not matter if we then set the
touchendevent in the same DOM node since it will keep triggering as we expect even if the little, medium, or fat finger, went out the initial related node ... we are basically simplifying a well known and annoying Mouse pattern where to drag things, after
mousedown, we need to add events to the document because the user might be faster than the DOM moving the mouse and we don't want to deal with bloody never ended events over a drag operation ... right ? Well, try to set
pointerupto a generic node and then try to drag it around ... I tell you already you will fail unless you don't change the
currentTargetper each event using the document for move and up.
Don't Polyfill PointerEvents To Already Slow Browsers!There are at least two projects which aim is to standardize PointerEvents for Touch Events compatible browsers ... well, the quick advice here is: dont' do that and the reason is simple: PointerEvents are some sort of over engineered Touch Events that will slow down consistently every cheap Android 2 phone which adoption is way larger than any Windows Phone and which performance are way more compromised by these kind of pointless libraries/polyfills when it comes to what the user meant to do: a bloody swipe or scroll and nothing else.
We don't need to know how much the Pen pressed the screen in that specific point and with which angle, we need to know that granny and mum swiped an article, end of the story for 99% of the cases!
Touch Events for IE MobileTaking the opposite direction of already mentioned libraries that I won't link for sanity of the mobile web sake, I've created something that slows down a little bit already modern, fast, good, and snappy Windows Phones 8 and 8.1 devices as I have and use on daily basis, through a repository which aim is to bring the easiness of Touch Events to any Windows Phone without you, developer, changing anything in your code base ... if not just adding ie-touch.js before any Touch Based logic you put in place.
Test IncludedCheck the source code of the basic test and try to replicate the same behavior with your PointerEvents logic and in a cross Mobile browser way ... I dare you!
After you failed trying to do so, check also my old Tesla multi-touch demo and see how it feels having Touch Events in windows Phones too ... have fun!