{"id":3174,"date":"2011-05-12T14:43:43","date_gmt":"2011-05-12T18:43:43","guid":{"rendered":"http:\/\/www.useragentman.com\/blog\/?p=3174"},"modified":"2012-05-20T08:45:41","modified_gmt":"2012-05-20T12:45:41","slug":"fixing-oninput-in-ie9-using-html5widgets","status":"publish","type":"post","link":"http:\/\/www.useragentman.com\/blog\/2011\/05\/12\/fixing-oninput-in-ie9-using-html5widgets\/","title":{"rendered":"Fixing oninput<\/code> in IE Using html5Widgets"},"content":{"rendered":"

\"\" In my previous blog post<\/a>, I wished that the onforminput<\/code> event was not deprecated in the HTML5 specification. I have used this attribute in the past to show values in range elements and show calculations of values inside a form, and thought it was perfect for those who know little JavaScript to implement features like this very easily. Rob Crowther<\/a> made pointed out<\/a> that the oninput<\/code> event, which has a similar function as onforminput<\/code> the main argument behind dropping onforminput<\/code> event. Makes sense, and I was happy — it works in all modern web browsers, including IE. But as you would guess, there has to be at least one problem with a cool bit of new web technology when it comes to cross-browser implementation.<\/p>\n

What are the issues?<\/h2>\n

IE has three issues related to oninput<\/code>:<\/p>\n

    \n
  1. oninput<\/code> is not supported at all in IE8 and lower.<\/li>\n
  2. IE9 does not allow referring to form fields directly in the oninput<\/code> expression. For example, this code works in all browsers except IE9:
    \n
    \n
    \r\n<form name=\"f1\" oninput=\"output.value = parseFloat(darkness.value);\"<\/span>>\r\n    Darkness Level:\r\n    <input type=\"range\" name=\"darkness\" value=\"0\" min=\"0\" max=\"255\">\r\n    <output name=\"output\">   \r\n<\/form>\r\n<\/pre>\n<\/blockquote>\n
    This is not so bad, since one could refactor the event code like this:<\/p>\n
    \n
    \r\n<form name=\"f1\" \r\n  oninput=\"document.getElementById('output').innerHTML = parseFloat(darkness.value);\"<\/span>>\r\n    Darkness Level:\r\n    <input type=\"range\" name=\"darkness\" value=\"0\" min=\"0\" max=\"255\">\r\n    <output id=\"output\">   \r\n<\/form>\r\n<\/pre>\n<\/blockquote>\n<\/li>\n
  3. If you use the backspace key while entering in a value, IE9 doesn’t fire the oninput<\/code> event.  This, in my opinion, is really bad, because it does affect how the form behaves.  For example, take the following form in IE9:
    \n
    \n\n\n\n\n\n\n
    \nAmount:\n<\/th>\n\n\n<\/td>\n<\/tr>\n
    \nItem:\n<\/th>\n\n
    \n<\/td>\n<\/tr>\n
    Tax:<\/th>\n45.00<\/output><\/td>\n<\/tr>\n
    Total:<\/th>\n344.99<\/output>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/form>\n
    As the user types in values for the amount and price into the form, the oninput<\/code> event calculates the tax and total.  However, if the user is entering a value into, say, the price and make a mistake and press the backspace, IE9 will not update the tax and total.<\/strong>  Your application will give erroneous information, the user will be surprised at the total being larger than he expected, says “screw this” and leaves the application.  Your company loses the big sale, your boss fires you, and next thing you know you are on a street, or worse, coding COBOL<\/a> on a 30 year old IBM PC running MS-DOS 1.0 in some fishing tackle store.<\/strong>  Not pretty.<\/li>\n<\/ol>\n
    Oh The Humanity! How Can I Prevent Such a Fate?<\/h2>\n
    Since I hate COBOL, I decided to update my html5Widgets library to:<\/p>\n
      \n
    1. Add support for oninput<\/code> for browsers that don’t support it (e.g. IE7 and 8)<\/li>\n
    2. Force IE9 to fire a form’s oninput<\/code> when the backspace and delete keys are pressed inside any of the input<\/code> nodes.<\/li>\n
    3. Force IE9 to fire a form’s oninput<\/code> when the cut<\/code> event is fired on any of the input<\/code> nodes.<\/li>\n<\/ol>\n
      Using the link below, you can see an example similar to the one above using html5Widgets to fix these issues.<\/p>\n
      Let’s see html5Widgets give IE some oninput<\/code> goodness<\/a><\/p>\n
      In order to do this, I used ideas from Daniel Friesen’s<\/a> blog post, A HTML5 Browser Maze, Oninput Support<\/a><\/em> (thanks to Paul Irish<\/a> for pointing me into that direction).  The result works rather well.  Note that I did not fix the IE9 “cannot use .value<\/code>, must use .innerHTML<\/code>” bug described earlier. It’s a little bit more verbose, but for now it’s what a developer needs to do for true cross-browser oninput<\/code> support. I have also kept onforminput<\/code> support in the code, just in case anyone has used it in the past (e.g. me).  To ensure the best experience, I wouldn’t use both events on the same page.  <\/p>\n
      Note also I did not add support for oninput<\/code> in any element other than form<\/code>.  I may do this after further research in the way it supported across browsers (for example, Firefox has an issue with oninput<\/code> being used on textarea<\/code> elements<\/a>).<\/p>\n
      Download<\/h2>\n
      Download the latest version of html5Forms.js, which includes html5Widgets with oninput<\/code> support, from github.<\/a><\/p>\n
      Further Reading<\/h2>\n