HTML5 not yet ready for prime time

Before working with HTML5, I had initially questioned HTML5’s support and adoption, considering IE6 and IE7 were still dominating browsers.  Recently, Microsoft has announced IE would automatically update, like their competing browsers Firefox and Chrome.  I’ve developed using HTML5 and CSS3 for the past few months, using all the latest browsers.  In short, most of my tests and development failed to be cross-browser compliant.  I’ve probably swore at my computer a few dozen times and rewrote the code to use standard JavaScript just as many times.

For those of you who know me, they will know that I am using Internet Explorer 9 64 bit as a primary browser.  My reasons are very simple, I want something fast, has robust developer tools, and good crash management.  If my options were limited to IE 32 bit, I could promise you that I would not use Internet Explorer as a primary browser, despite having arguably the best developer tools (which oddly enough come built into the browser, unlike Firefox which requires you to install Firebug).  After using it as a primary browser for a few months, I’ve noticed how much different the web looks from the perspective of an IE user.  Websites had bugs, some code had breaking errors (that other browsers tend to ignore) and some sites simply refused to let you in if you used IE (regardless of the version).  I’ve had a few sites tell me to switch browsers for no clear reason.  Oddly enough, as a user of IE9, I love it, but as a developer who wants to build using the latest tools, that is simply not possible… unless of course I used IE10.

When developing in HTML5, I did not build a game, as most people expect HTML5 to be used for.  Instead, I used it to build tools and manage data.  Based on my earlier posts, you will see that this has been no small test, with more than 200k lines of code from the start.  Today, it stands at 165k lines of code (yes, we are refactoring).  HTML5 is supposed to have more tools and capabilities with handling forms and have new events that would hopefully cut down on the need of observers in a page.  Beyond that, I was mainly looked forward to HTML5 for the ability to embed multimedia into pages; like music, videos, articles and figures.

Support for contenteditable

One of the first things that was used was ‘contenteditable’.  This was perhaps the single biggest failure. This attribute not only gave us a hard time trying to figure out why content would never come out as expected, but there was a severe lack of events available, when using typical html elements, like a ‘p’ tag, ‘div’ tag or ‘span’ tag.  Every browser interpreted the content within the field differently.  If you deleted all the content from the field for example, some browsers would wrap the content with ‘p’ tags when you would start typing content again and there was no way to remove the tags unless it was processed with JavaScript.  Browsers interpreted line breaks differently, tabs were also all different.  Then came saving… in order for us to save the content, usually the event ‘onchange’ is preferred.  In this case, it is not available, since we were editing a ‘span’  element, which required us to use onBlur.  We had to build in custom functionality for us to mimic the onchange functionality with onblur, because as many know, the onblur events gets fired regardless of whether or not the content changed.

New form elements in HTML5

New Form elements have been equally unreliable, to a point it got extremely frustrating.  The browser to support the majority of the fields has been Opera, the worst being IE9.  However, if we include IE10 into the mix, it seems to offer all of them (though some with bugs).  When the browser doesn’t support the particular field, it seems to simply think it is a text input and will force the user manually input the values.  Due to this, we’ve essentially dropped support for all inputs but text and have built a custom observer class in javascript to inject the functionality we need into forms, like picking dates and times, moving a slider within an indicated range and using the input as a search to select a value (rather than use a select box that can have a hundred or more elements).

Form validators

Next, was attempting to use validators.  HTML5 validators are nice, but once again, not consistent throughout the browsers.  In fact, not only was IE bad, but Firefox was bad in some instances too, especially when attempting to run custom validators that simply would not work as intended.  Thankfully, Mootools provides a very nice and rich set of validation features that we are now using.  It provides a bit more flexibility in what we need to use.  Which was extremely useful for our method of inputting data, since we tend to edit and save one field at a time and validate those fields each time before saving, something that may not be ideal in HTML5.

What’s HTML5 if you don’t use canvas

Of course, HTML5 is used for much more than forms!  I did attempt to build an HTML5 tool set that used canvas.  Canvas is the single most impressive feature of HTML5, in my opinion, that gives Java, Shockwave, and Flash a run for their money.  Oddly enough, I thought this would have the most lackluster support on certain browsers, but was shocked to find out the browsers did them well in general and required very little work to make some features cross-browser compatible.  That is until I began getting into more advanced concepts and attempting to make a map based game, where a user could build and scroll around a map.  As I started adding dragging elements, I noticed some browsers didn’t all support dragging the same way, which made it difficult and navigate the map the same way in all browsers.  Some spots were unclickable because the canvas did not refresh the events properly in the correct areas.  Of course, my code wasn’t perfect and had some bugs, as it wasn’t even an alpha.  But what worked well in some browsers did not work the same in other browsers.  Workarounds could most certainly be put in place, but may cause issues down the road.

HTML5 is nice and looks extremely promising, but it is far from being ready for use, as Flash has been for the past few years.  Mobile has been largely using HTML5 now, because there is some level of consistency that applies between handsets, which is usually OS based.  If a mobile developer notices their game doesn’t work well for iOS, but does for Android and Windows Phone, they could very well choose to launch to those two markets and adapt the game/app to iOS later.  HTML5 on mobile has the ability to work and has been largely working for the past few months, but when it comes to desktop, I don’t see HTML5 being a game changer for at least a year, when the majority of web users are not using old browsers.

I’d love to hear your thoughts on this topic.  Although many of whom I spoke to agreed with many, others had strong opinions against my thoughts and say that HTML5’s time is now.