When I was growing up, it was an unwritten family tradition that major holidays were celebrated with a "Honey-Baked Ham". My father would frequently refer to a ham as "the gift that keeps on giving", owing to the fact that a single Honey-Baked Ham could last for weeks as left-overs, long after the holiday was over. When the ham was finally consumed, the bones could be used to make stock. I would get quite tired of Honey-Baked Ham before we could finish it, but my father never tired of it. (First world problems, I know!)
Fast forward to now and I'm a web developer. For better or for worse, I seem to have fallen into the Microsoft development world. There are some wonderful things in this world. I think that the .net platform is great. Jeff Atwood called .net "what Java should have been on every level".
Then, there are some not so great things in the Microsoft world. Internet Explorer, oh Internet Explorer, oh let me count the ways I hate thee! I can't lie; I do know that Microsoft introduced some truly innovative features in Internet Explorer, but in my experience, it has always been the browser that is most difficult to program for. Why?
The W3C is the organization that is responsible for designing the specifications for the world-wide web. They specify how the browser is supposed to interpret web code. That's great. Firefox, Chrome, Opera, Safari, and other browsers implement this standard as closely as possible. Sometimes, they add innovative, non-standard features in the hopes that developers will use them and they can be adopted into a future W3C specification. However, Microsoft chose a different way. They added new features in a non-standard way and even implemented old features in non-standard ways. As a result, web developers had to simultaneously develop to two standards: the W3C specifications and the Internet Explorer de-facto standard. Microsoft Internet Explorer was the first browser to implement AJAX, which is a major feature that revolutionized web development. AJAX was an incredible addition to the browser that is now part of the W3C standard. Why did they have to smash everything else along the way?
Finally, when Microsoft released Internet Explorer 8, they announced that they were turning a new leaf: they, too, would follow the W3C standard as closely as possible. Web developers let out a big sigh as Microsoft promised to do something they should have done from the beginning. Ironically, Internet Explorer 8 actually has a "quirks mode" which trys to render pages that were written for the old Internet Explorer versions.
Unfortunately, there are numerous web applications out there that were written specifically for even older versions of Internet Explorer; some of them are still used today. No one would dare demand that users browse a public web site with such ancient junk, but they may use it internally. Since Windows will not ordinarily run multiple versions of Internet Explorer, users in these organizations are forced to use Internet Explorer 7 or even Internet Explorer 6 to browse the public internet! Web developers have to bear this in mind as they design their pages!
However, as the years passed, these ancient behemoths began to be replaced, and web developers breathed a collective sigh of relief that their long night with legacy Internet Explorer was finally drawing to a close. I recently learned how utterly and completely wrong we were.
Recently, I was working a contract where I found that I was on "stand-by" as a project wound down. I wanted to put this time to productive use. I noticed that most everything is going from mouse to touch, so I purchased a touch-screen for my development machine and started tinkering with it. My intent was to learn how to program it.
I was a bit surprised to find that in spite of all the progress that has been made with touch interfaces, they are seldom used directly on web pages. The W3C standard for "touch events", which describe how a standards-compliant browser should respond to touches on the screen, is almost a year old as of this writing. Chrome implements this standard very well. Firefox implements it as well, but has touch events disabled by default. My Android phone browser implements it, as well. Then, I found out that Internet Explorer 11 (the newest version) does not support W3C touch events *at all*. You can write code to respond to these events until you are blue in the face and Internet Explorer will not do *anything* with them.
I did a quick Google search and found that Microsoft proudly boasts about how well Internet Explorer works with touch. They even have a slogan for it: "Touch the Web". Then why doesn't it work with the simple touch programs I wrote? Microsoft decided that Internet Explorer would not support the W3C touch events. Instead, it supports Microsoft "pointer events", which are similar in function, but completely different in their programming interface. For example, the W3C touch events use a single event to describe multiple touches; there is an array of "Touch" objects associated with each touch event. With Microsoft pointer events, there is a separate event for each touch.
If Microsoft really thinks that Microsoft pointer events are superior to W3C touch events, they could have programmed Internet Explorer to work with both so that standards-compliant web pages would work in Internet Explorer. If their way were better, developers might program to that instead of the W3C way, and then their way could become part of a future standard. No, they had to write a browser that is completely non-functional with the standard. In days of yore, a non-standard web page might render incorrectly, but it would usually at least be somewhat functional.
Once again, Internet Explorer is the gift that keeps on giving. We should all have suspected that Microsoft was being disingenuous when they said that Internet Explorer would follow the W3C standards, but as Billy Mays would say, "But wait: there's more!".
I received a bug report from another developer who said that the new version I contributed didn't work for him. I was completely unable to reproduce his issue, but then he told me that the bug only appeared when he used a pen input on a Microsoft Surface Pro tablet. This puzzled me; the type of input and the underlying architecture should have nothing to do with how the browser handles these pointer events. I asked the user to turn on console logging and send the output to me. In my experience, the sequence of events related to a touch is pointerdown, then zero or more pointermove, then pointer up. These events are translated by touchpolyfill into touchstart, touchmove, and touchend, respectively. In the console report I received, pointerdown and pointerup are not fired; only pointermove fires!
Not only does Internet Explorer not follow the W3C standard, but it implements its own standard differently across different platforms. The only thing I know to do to make this work is to keep track of which pointermove events were preceeded by a pointerdown event. Whichever event pointermove events are not preceeded by a pointerdown event will set off a very short timer, and if that timer expires before another pointermove event is fired, then a touchend event gets fired.
Update: September 19, 2014
The above issue has been resolved without resorting to timers, but IE still has lots of other fun quirks to deal with.
Speaking of fired, I have an idea regarding whoever thought that this was a good idea for Internet Explorer.
However, in Microsoft's defense, I have been told that Apple threatened Microsoft with patent lawsuits over touch events, so who the real bad guys are is a little muddy.
For future reference, CanIUse.com has a great reference on what browsers support the W3C touch events.