Recently, a colleague was building out an input range slider that would respond to a user interactions. Using the input event, he was able to update a designated output during the slide of the control, rather than after the release of the mouse. This solution worked beautifully on all browsers that we tested (Safari, Chrome, Firefox, Edge), all except for IE 10/11. For brevity, I’ll refer to these problematic versions as ‘the IEs’ from here on out.

After some testing and some research, we found 2 things in particular that was preventing the proper interaction with the control in the IEs:

  1. They ignored the input event completely
  2. Their change event behaved just like the input event did on other browsers

To address this, our first attempt was to try and feature detect the input event (oninput property) and create some logic so that browsers that didn’t have the property would resort to using the change event instead.

This turned out to be a failure, because surprisingly the object in IE had an oninput property (albeit, unfunctional).

Our next attempt required a bit more research by comparing the document object in the IEs as well as Edge. We were looking only for onms* properties, but for ones that weren’t present in Edge. We found a few that were unique to IE 10/11 and arbitrarily chose onmspointerup out of the bunch.

This code above allows us to pinpoint the troublesome IEs and use the change event to behave like a modern browser using the input event.