HTML5 realities: practical, constrained, and promising
When “Hype or Hope?” is debated vigorously enough on any subject, it’s easy to guess the truth combines both poles. That’s certainly the case with HTML5. The details are interesting enough that it’s worth a few lines to sketch the essentials of what you should know.
Every month or so, someone–Gartner last summer, Luke Stevens, Mike James, and others in the fall, up to the present–announces that the HTML5 emperor is more skimpily dressed than is seemly. “Hype or Hope?” is a headline that’s been re-used multiple times.
HTML5 is ungainly enough to be almost useless as a project specification. HTML5 is “future” for some audiences; I work with some organizations that still require Internet Explorer (IE) 6 solutions. While, in a pinch, compatibility shims can bring HTML5 even to IE6, I generally don’t fight that battle. On the other hand, HTML5 is a “done deal” for other audiences, and as practical as can be: nearly all browsers for Web-ready telephones in the US give HTML5 capabilities, and I feel free to assume HTML5 for such mobile apps.
“HTML5” is only the beginning of a technical description, though. Any real-world project must detail exactly what parts of HTML5 it requires–geolocation, video playback, and form fields are three much different parts of the sprawling HTML5 standard that tend to be used in different ways by applications. Effective creation and maintenance of an “HTML5-based” application inevitably requires more precise examination of what users do with the application, and how those users’ specific browsers support different parts of HTML5.
As much as deep Web history and themes of openness interest any of us strategically, there’s no need to take a position at that level to benefit tactically from HTML5 today. The current generation of Web browsers build in capabilities that would have seemed extraordinary just five years ago, and, in broad terms, HTML5 is the right starting point to unlock them.