The Future of HTML5 Offline Functionality
One of the great promises of HTML5 is to allow rich web applications to continue to operate (inasmuch as it’s possible) when a connection is not available to the Internet. There are two major components of providing such a service, and both are addressed in some way by the HTML5 standard. However, these are two of the most-disputed areas of the spec when it comes to actual implementation.
The Application Cache
The HTML5 spec has a lengthy description of the Application Cache mechanism. Basically, this allows web developers to specify what content should be displayed for a URL when a connection can’t be made to the server that normally handles the URL.
For example, a particular LucidChart document might be edited by visiting a specific URL. The App Cache allows us to specify that we’d like certain content to be cached and displayed instead if www.lucidchart.com can’t be reached. That content would include the current version of the document and all its related metadata, along with the HTML, Javascript, CSS, and images needed to display it to the user.
While this concept is well-accepted in the standard, one critical issue hasn’t been addressed: How much space do you allow applications to use in this cache, and how do you gracefully allow the user to adjust those allocations?
Consider that in order to have true offline functionality for LucidChart, we need to have a copy of at least the current version of all of a user’s documents in the app cache. For many users, especially those who are using custom uploaded images, this size stretches into tens or hundreds of megabytes.
The HTML5 spec does not specify the amount of space available to applications, but currently developers can’t count on getting more than 5MB per domain.
Local Storage
While the application cache would allow users to view their past work, there needs to be a mechanism for saving new work that they accomplish until a connection is restored to the server. There are actually three competing standards in play for this area.
First, and the only one universally available (even in Internet Explorer) is Web Storage, AKA “DOM Storage.” This is simply a key-value map that allows developers to store arbitrary data for later use anywhere on the domain. This is very unstructured data, so there is no meaningful way to query the data in a way that parallels a normal modern database system. However, it is universally implemented today, so it is the most promising of the prospects.
However, Web Storage falls down in the same way that the App Cache does–there’s no specification of how much space should be available to sites. Chrome currently has a 5MB limit per domain, IE has a 10MB limit per domain, and Firefox appears to have no limit (though they notify users when a site is using a lot of storage). Depending on the kind of data a user is generating, this storage can run out alarmingly fast.
To help address the problem of unstructured data, another standard called Web SQL is competing for inclusion in HTML5. It’s a simple Javascript interface to a simple SQL database. In every current implementation, this database is implemented with the public domain SQlite library.
Mozilla, however, thinks that a “standard” that’s actually based on a particular implementation (in this case, SQlite) is not a standard at all. So they built a simple data store (incidentally, also built on top of SQlite) that exposes a simple key/value document hierarchy. Since the interface is well-defined, they claim this this is a better standard to build against that Web SQL. The problem, of course, is that only they support it (and only in Firefox 4+).
What Developers Need
We at LucidChart need the following in order to develop a first-rate offline tool:
- Higher storage limits for the App Cache and Web Storage. Preferably, a way to prompt the user to allow us to use unlimited storage–as any native app would have access to.
- Universal, reliable implementation of the App Cache standard in all major browsers.
- (Optional) Universal, reliable implementation of Web SQL. Unfortunately, Mozilla has sworn never to implement this standard.
And we are not alone in this. I struggle to think of a meaningful web application that does not have these needs in order to build offline functionality. Whether it’s email, word processing, drawing, diagramming, analytics, or CRM, we need a reliable way to store large amounts of structured data in the browser if we’re going to be able to cut the cord to the Internet and continue working.
About the author
Dav Gra is interested in the latest trends of online collaborative solutions for distributed teams, including this free Visio alternative which can be used as organizational chart software.
Processing your request, Please wait....
