One of the most interesting features of the HTML5 specification is the capability for web applications to perform while offline (i.e., without internet connectivity). Most browsers implement a caching mechanism that stores downloaded resources to a local drive, which is done as resources are encountered. While this does help with performance, as resources are only cached as they are encountered, not all resources may be cached. So, potentially, if connectivity is lost, then the site is not fully functional.
Introducing the Cache Manifest. A manifest file contains caching directives for what to cache, what to not cache, and instructions on what to do when a web resource is not available. This text file defined by the web application indicating to an HTML5 complaint browser resources to cache in "application cache." This manifest file is referenced by an HTML manifest attribute. An example is shown below:
<html lang="en-us" manifest="example.appcache">
…
</html
Explicitly specifying the browser to cache specific HTML, JavaScript, and CSS files is done by defining these elements under a CACHE directive in the manifest file. This file contains an identification directive along with a CACHE directive, followed by specific resources to cache. An example is shown below:
CACHE MANIFEST # 2012-9-1:24
# Explicitly cached 'master entries
CACHE
app.js
css/jquery.mobile-1.1.0-rc.2.min.css
css/jquery.mobile.structure-1.1.0-rc.2.min.css
css/jquery.mobile.theme-1.1.0-rc.2.min.css
css/styles.css
index.html
libs/AMDbackbone-0.5.3.js
libs/backbone-0.9.2.js
libs/css/normalize.css
libs/jqm-config.js
libs/jquery-1.7.2.js
libs/jquery.mobile-1.1.0-rc.2.min.js
……
Comments can be added to the file using # tag. Also, comments can be used to invoke a cache refresh from the browser; when contents change in this file, the browser will re-download entries. It is also worth noting that this downloading is asynchronous.
Resources that always require connectivity (and therefore will bypass the application cache) can be specified under the NETWORK: directive, as shown below:
NETWORK:
http://localhost:8080/khs-backbone-example/sherpa
Another nice feature is the ability to provide an alternative HTML file for resources that are inaccessible from the server. A FALLBACK: directive can be defined that will associate certain resource(s) with an HTML page for display when a browser can’t access a particular resource. The example below shows a FALLBACK: entry for any inaccessible HTML resource. Notice, wildcards are allowed in the FALLBACK: and NETWORK: directives.
FALLBACK:
/*.html /offline.html
The application cache can also be controlled via a JavaScript API. The status of an application cache can be checked by testing state on the:
var appCache = window.applicationCache;
switch (appCache.status) {
case appCache.UNCACHED:
return 'UNCACHED';
break;
case appCache.IDLE:
return 'IDLE';
break;
case appCache.CHECKING:
return 'CHECKING';
break;
case appCache.DOWNLOADING:
return 'DOWNLOADING';
break;
case appCache.UPDATEREADY:
return 'UPDATEREADY';
break;
case appCache.OBSOLETE:
return 'OBSOLETE';
break;
default:
return 'UKNOWN CACHE STATUS';
break;
};
With JavaScript programming, the application cache can be updated by first issuing an update, then checking the status for completion, and then swapping the cache. Example JavaScript is shown below:
var appCache = window.applicationCache;
appCache.update();
...
if (appCache.status == window.applicationCache.UPDATEREADY) {
appCache.swapCache();
}
The application cache is especially useful for HTML5/JavaScript-based mobile applications, with which bandwidth and connectivity is potentially an issue.
Hopefully, this quick introduction has provided enough information for you to apply it. For more details on the application cache and the details of the HTML5 spec, check out the "Living Specification."
– David Pitt
