Articles Tagged ‘HTML5’

The Limitations of WebSQL and Offline apps

Web applications are the next big thing in the web. Being able to take web sites and make them run alongside native apps, having them work offline and perform just as well as their native counterparts is the next step along the road. As usual, with all new technology, there are some limitations.

There are three pieces of technology that are combined to make a web app: app caching, local storage and a web database technology.
App caching tells browsers what files to store offline and retrieve from disk. These are permanently stored until new instructions are received, unlike traditional caching which works until the cache is full, then starts removing files.

Limitation 1
In iOS 4.3, app caching for offline web apps is broken and does not work.

Local storage is for key/value pairs of information. It’s for simple things like settings and values that need to be retrieved quickly. It’s been called “cookies on crack” before, but it’s really just a very fast dictionary for simple data.

Limitation 2
Depending on your browser, localStorage will keep 5-10MB of data, the equivalent of 200,000-500,000 characters. If all you want to do is store small serialised JSON objects that aren’t related, use this.

Web databases are client-side data storage for larger amounts of more complex data. Whilst you can make web apps with just app caching and local storage, it’s not going to be very interactive, or the data may be unstructured, or there will be lots of Ajax calls to fetch data. Web databases are where this technology gets a bit dodgy.

Originally, there was Google Gears, a plug-in which brought a SQLite database to help web apps run offline. This was then standardised into the WebSQL module and developed as a SQL database available through JavaScript. Google, Apple and Opera all implemented it and it can be found in iOS and Android devices today.

Limitation 3
Chrome has a hard 5MB database size limit – you will need to use a chrome web app to remove this limit.
Limitation 4
Chrome doesn’t support OUTER JOIN or RIGHT JOIN statements.
Limitation 5
Debugging is very difficult with large amounts of data as the web inspector isn’t efficient at displaying a thousand rows (and will crash with around 20,000 rows, around 2MB of data).
Limitation 6
Version numbers are not taken into account. Don’t bother with them.
Limitation 7
All calls are asynchronous – if you rely on results at a certain time, be prepared to write a lot of callback functions. Your code can get messy very quickly.
Limitation 8
Performance is sluggish if you don’t batch up statements into transactions.

Even better still, WebSQL is no longer in development, so these problems will remain. Microsoft and Mozilla said they didn’t like it and wanted to used a different technology: IndexedDB.

IndexedDB is on it’s way, but not mature enough yet to be used, nor is it implemented in any of the mobile browsers.

For offline apps, you’re better sticking with WebSQL until IndexedDB matures.

Hopefully, some kind developer will come along and write a technology-agnostic wrapper, maybe that person will be you, the reader of this article. If you’re thinking about it, let me know 🙂

Javascript Fun at London Web Standards #lwsfun

Last night was London Web Standards‘ April 2011 event, Fun with JavaScript. Speakers Rob Hawkes of Mozilla and Seb Lee-Delisle of Plug-in Media came to talk about all the fun stuff you can do with JavaScript, canvas, and HTML5. Sketchnotes for both talks are below.

We were also joined by a man showing us a quick look at Dreamweaver CS5.5 with it’s new HTML5 features. Unfortunately, the software had a few bugs which showed up in the talk, and after being burned by the very expensive adobe software for years, the crowd didn’t take to the UI very well, which wasn’t helped by a low-res projector. Still, it looks like a big improvement over the old version, but I’ll still use Coda when on my Mac.

Rob Hawkes: multiplayer gaming in HTML5

Sketchnotes of Rob Hawkes' talk Multiplayer Gaming with HTML5

Sketchnotes of Rob Hawkes' talk Multiplayer Gaming with HTML5

Rob is a canvas and animation guru. He’s not far out of uni and has a book out this month! He gave a new talk on multiplayer gaming, and how it was possible in HTML5.

Basically: Canvas + Websockets + a server (rob recommended Node.js) = multiplayer gaming on the web.

Rob didn’t go into much detail as to how to do all this, just talked us through the principles of what you should be doing, what you should avoid, how to prevent cheating and simple tricks to improve performance.

At the end, Rob proposed a HTML5 gaming knowledge repository, a community wiki and tutorial site, so that it’s easier for people to learn. Someone at the event will take him up on the offer, so look forward to more things soon!

Rob has a book on Foundation HTML5 Canvas: Gaming and Entertainment for pre-order on

Seb Lee-Delisle: Fun with JavaScript

Sketchnotes for Creative JS visual effects – Seb Lee-Delisle

Sketchnotes for Creative JS visual effects – Seb Lee-Delisle

Seb is a flash guy, but also a JavaScript guy and a graphics guy. He’s so multi-talented that he doesn’t know what exactly he does any more.

Seb has won two BAFTAs (thanks for correcting me Seb!) for some of his BBC kids web sites. He personally runs a javascript graphics workshop and took us through a few things that we’d do if we went on it.

He started with particles, showing us how to do basic (pseudo) physics in canvas and JavaScript. He then broke out his large array of particle demos, showing how complex effects can be produced with very simple code.

Seb then talked about performance, and how bad canvas is at the moment. DOM elements with hardware acceleration is easily twice as fast as canvas, especially on the iPad. The iPad’s saving grace is its touch screen, which can take 11 touch points (just in case we grow an extra finger). Seb created a simple asteroids game using touch events for input.

Seb finally talked about 3D and how using libraries was a great way to go from 2d to 3D very simply. He recommended Unity as a game engine and framework of choice, and they’re building HTML5 renderers on top of their regular OpenGL and DirectX methods. Exciting stuff indeed.

HTML5 Video and Audio at #lwsdeep

This month at London Web Standards, two in-depth HTML5 talks, covering bits which aren’t in common usage at the moment, and what you can do with the bits that are. This is part two, Opera’s Patrick Lauke (@patrick_h_lauke) on <video> and <audio>. Part one has Google’s Michael Mahemoff (@mahemoff) on 8 HTML5 features you haven’t seen before. Below are my notes and write-up. Enjoy!

Sketchnotes from HTML5 Video and Audio

Sketchnotes from HTML5 Video and Audio

First off, Patrick had a cold, hence the poorly drawn tissue in the top-left corner.

<video> and <audio> are some of the most important  elements in HTML5. Steve Jobs thought so much of these new elements and HTML5’s potential, that Flash was dropped from iOS devices and everyone was encouraged to make the transition. Even Microsoft has recognised their importance, adding native support for the elements in IE9.

The basic idea behind <video> and <audio> was to do for these media types what had been done for images. Instead of using messy <object> and <embed> tags to make Flash work properly, create something simple that doesn’t rely on proprietary technology. Therefore, <video> is now a native object in the browser, which allows you to treat it just like any other object, including styling it with CSS and even using CSS transforms on the video.

There’s an important aside around video formats which I’ll cover briefly here. There are three codecs:

  1. MP4/H.264 – implemented by Chrome, Safari and IE9, encumbered with potential royalty payments, whatever the MPEG association try to say.
  2. Ogg Theora – implemented by Chrome, Firefox and Opera, open source but not very good as a codec
  3. WebM – implemented by Chrome, Firefox, Opera and IE9 (with downloaded codec) it’s made for the web and will be the de-facto standard going forward. Apple have yet to commit to using the format

Thankfully, you can use multiple sources in your videos which will fall back to one another. You can even fall back all the way to Flash to give older browsers a fighting chance.

Each browser gets to implement their own controls for the video player, but these can be overridden and the whole video controlled by JavaScript. There are events which fire at different times and  theoretically it’s possible to time-match subtitle tracks, which WhatWG are looking into for future versions of the HTML spec.

<audio> is very similar in implementation to <video>, with the same format fight, this time between MP3 and Ogg Vorbis. Interestingly you can remove the controls from the page and run the whole thing from JavaScript, allowing for such horrible interactions as a whoosh sound when hovering over a button.

Best yet, is that Patrick officially certified these techniques ready for use. Their is sufficient support and fallback options to support all browsers, take YouTube for example, running HTML5 video for nearly a year now. However, he asks that you use feature detection rather than browser sniffing when making these fallbacks. There are a few tools out at the moment which do all this for you, such as SublimeVideo and videoJS.

And that’s it. Hope you enjoyed it. You can read Part one of #lwsdeep here.