4 For HTML5: Browser Support, OnInput Tricks, and LocalStorage

by John Jainschigg (January 30, 2012)

Score your browser. If you develop for the web, chances are you have the latest versions of many different browsers on your desktop. And chances are you carry around a vast and ever-expanding table of incompatibilities, quirks, and variant interpretations of w3c screed in your head. Or at least you do, up through HTML 4.01. Meanwhile, for a lot of coders, HTML5 is still in the weird territory between "I can't believe browsers can finally do this!" and "I can't believe THAT browser can't (yet) do this!" To wrap your head around the differences in HTML5 support at the very bleeding edge, http://html5test.com is a great first stop. It runs a GitHub project by Niels Leenheer, drawing on work by Henri Sivonen and others, to develop an effective feature-detection suite for HTML5, and will produce a simple numeric score for any browser you drive up to its homepage – one you can compare with scores from many other browsers and versions, including those for tablets, mobiles, and embedded devices.

Detect Features, not Browsers. Every (cough) "real" web coder has written (or stolen) a browser-detect function to get them over that incompatibility speed-bump in a minimally tweaky, albeit brute-force way. These range from what are essentially one-liners that parse the (spoofable) user-agent string to more-robust detections that look at the DOM, javascript, and other details to nail down type and version with more assurance. The latter is a better approach – potentially more standards-based – and is particularly apt for dealing with questions about whether a visiting browser offers support for a particular HTML5 feature. For those unfamiliar with the approach, this article on MSDN (http://msdn.microsoft.com/en-us/magazine/hh475813.aspx) offers a solid model: testing for standards first (because many current browsers support them, as well as quirky legacy equivalents), then falling back (to quirky legacy equivalents) if necessary.

Use oninput without fear. Modern browsers offer uniform support for the new HTML5 oninput event, which fires when the user engages with an input field. It's great for writing inline validation and other tricky stuff like multi-line text-entry with functional word-wrap or ‘exit form element on return keypress,' which we used to do with onkeyup/onkeydown events (and a certain amount of pain). Sadly, to support older browsers, you still have to include this code. But Belgian blogger Mathias Bynens (http://mathiasbynens.be) offers a clever, terse way to have your oninput and onkeydown/up too. He suggests doing this:

someElement.oninput = function() {

  this.onkeydown = null;

  // Your code goes here

};

someElement.onkeydown = function() {

  // Your code goes here

};

… in other words, define handlers for both events, then remove the onkeydown handler when the more modern event fires. He notes that the onkeydown handler will run once in any case, because onkeydown fires before oninput, so your keydown code needs to take that into account, and also, ideally, be set up to cascade so that this.onkeydown isn't pointlessly set and reset to null with each event processed. But the formula can work for many HTML5 events that represent semantic or functional improvements over older methods, and helps you avoid needing more complex feature detection strategies.

Store it locally. This is one of those HTML5 features that just knocks me out every time I use it. It stores stuff – your page's stuff – in the user's local storage, under your domain. And the stuff you store survives tab-closes, browser closes, and shutdowns until the user removes it, or you do. LocalStorage can be the basis of powerful little apps that work offline, or help you design sleek UIs that behave more like applications, protecting user data and remembering context in important and constructive ways. It's a little like server-side session-associated variables with automatic serialization, but running on the client side. Test for the capability with:

If (typeof(localStorage) != ‘undefined') // API is available

Then write to it with:

localStorage.setItem("mykey","My value");

… using a try/catch to field errors. Retrieve items like this:

val thevalue = localStorage.getItem("mykey");

And delete them like this:

localStorage.removeItem("mykey");

John Jainschigg is a contributing editor for SourceForge and Geeknet.