HTML5 Browser Support

Continuing from my intro to HTML5 game devel­op­ment, one of the biggest pro­hib­it­ive factors in mobile game devel­op­ment today is lack of browser sup­port. While the inde­pend­ent browsers are the ones driv­ing the innov­a­tion, the slow upgrade cycle of cer­tain demo­graph­ics is mak­ing reach­ing a wide audi­ence tricky.

Potential Issues Developing HTML5 Games

Internet Explorer is the main cul­prit on the desktop, with a massive mar­ket share of out­dated browsers that can’t or won’t upgrade. IE adop­tion has tra­di­tion­ally been slow, but this is exacer­bated by IE9 not being avail­able for Windows XP, leav­ing a num­ber of users stuck on IE8 until they replace their com­puter, browser, or OS.

Firefox users also tend to have a slow upgrade cycle, but I’m con­fid­ent that newer fea­tures can prompt them to upgrade. There are no real restric­tions on whether Firefox users can upgrade their browser (other than per­haps in some enter­prise cir­cum­stances), so when faced with the fact that their browser is out of date I would like to think most people would reas­on­ably click “upgrade”,

Another more tricky issue you’ll face is that Android hand­sets tend to stick around a lot longer than their Apple coun­ter­parts. Many of them don’t get updates bey­ond a minor ver­sion or so bey­ond what they’re sold with, which leaves them per­petu­ally stuck on whichever browser ver­sion the man­u­fac­turer left them on. Thankfully this has recently improved with the strong pres­ence of an ever­green Chrome as the default browser and Firefox as a solid altern­at­ive, how­ever old hand­sets are still likely to have a bad browser by default.

There’s also the issue of com­put­ing power. Mobile devices have flaky hard­ware accel­er­a­tion sup­port and slower pro­cessors than most desktop com­puters, which can lead to prob­lems with frame rates and slug­gish inter­faces for seem­ingly simple oper­a­tions. There are a num­ber of things you can do to help improve per­form­ance, but that’s best covered elsewhere.

Browser Support for Key HTML5 Technologies

It’s import­ant to know what you’re in for when you get into web game devel­op­ment, so I took the oppor­tun­ity to do up a table of key web tech­no­lo­gies and where they stand as of today.

Cells with a ver­sion num­ber mean that the fea­ture is avail­able in a devel­op­ment release or a ver­sion that hasn’t yet reached main­stream adop­tion. These indic­ate a browser you’ll need to keep an eye on while devel­op­ing. A cell with no sup­port means you will have to find an altern­at­ive tech­no­logy for that class of browser.

Note: these days you can find a much more com­pre­hens­ive and up-to-date list of browser fea­tures at

Browser Support for Key HTML5 Technologies (2011–08)
Technology IE Firefox Safari Chrome Opera iOS Android
Canvas (2D) 9+
WebSockets 6+ 14+ iOS 4.2
WebGL 11+
Web Storage 8+
Audio 9+
Video 9+
Web Workers iOS 5 2.0+
Offline Web Applications 2.0+
Hardware Acceleration 4+ ? 3.0+

This table has been com­piled in part from the Wikipedia art­icle on lay­out engines and in part from copi­ous Googling.

Graceful Degradation

It’s pretty clear that while there’s strong sup­port for most new tech­no­lo­gies in the latest gen­er­a­tion of browsers, there’s a num­ber of holes in sup­port for those browsers cur­rently in the wild.

Thankfully, there’s also a num­ber of lib­rar­ies avail­able to help ease the trans­ition off older browsers.

  • The ExplorerCanvas lib­rary allow older Internet Explorer ver­sions to trans­par­ently use the Canvas API via a Flash container.
  • It’s import­ant to note that WebSockets is a very volat­ile spec, and while most cur­rent browsers come with an imple­ment­a­tion of the pro­tocol, it will need to be enabled by the user. Libraries such as can make this easier by fall­ing back to other more widely avail­able tech­no­lo­gies such as Flash or HTTP polling if nat­ive sock­ets aren’t available.
  • The most con­ten­tious issue is that of audio and video. Due to the format war between the browser vendors, you’re prob­ably going to have to have two ver­sions of video or audio file depend­ing on your audi­ence. This is not likely to change in the imme­di­ate future, but lib­rar­ies such as Buzz can make this pro­cess easier to manage.


Developing for the web has always been a game of fea­ture detec­tion and pro­gress­ive enhance­ment, so it’s unsur­pris­ing that HTML5 game devel­op­ment is a very sim­ilar sport.

Flaky imple­ment­a­tions in mobile browsers, mul­tiple con­flict­ing imple­ment­a­tions of audio and video formats, the slow pace of pro­gress and upgrade wall for Internet Explorer users; there’s no deny­ing your foray into HTML5 game devel­op­ment is going to be a chal­lenge. I like to think take these issues as a chal­lenge to over­come, after which devel­op­ment starts to look like a game in itself.

The aim of this game is to develop an awe­some product for the major­ity of web users. Before embark­ing on a pro­ject you should always check just how well your game plan is going to per­form for your tar­get mar­ket and con­sider using lib­rar­ies to ease the pro­cess. Program defens­ively, check that fea­tures exist before using them, and provide fall-backs in the cases where they don’t. If you play it right, the rewards are going to be great.

Leave a Reply