HTML and CSS Reference
In-Depth Information
To w To r k To l i n e , a n a p p l i c a t i To n n e e d To n l y a manifest telling the
browser what it needs to store in its local cache. The manifest
can be as simple as a list of files and you'll be done. Once
the browser has stored the cache of assets, CSS, JavaScript,
images, and so on, when the page is reloaded the browser uses
these local assets to drive the website.
Along with telling the browser what to cache, you can also tell
it what not to cache, ensuring that requests to that particular
URL always go via the Web. Finally, HTML5 gives you a way to
manage fallback cases. In the situation where you're currently
without a connection and you try to access a resource that isn't
in your local (offline) cache, the fallback can be used to serve
a different resource (which is also cached by the browser). For
example, going to the chat part of your application could fall
back to a page saying this feature is available only whilst online.
The first part of an offline application is down to the manifest,
which tells the browser what to cache (or what not to). The sec-
ond part is in the
applicationCache
. This object contains meth-
ods to trigger updates and to swap the latest cache into the
browser. It also has events firing off it that the author can use to
notify the user that the application might be upgradable.
NoTE
In the context of
the offline spec, the mani-
fest is a list of files that defines
what files should be included for
your offline application.
What about offline and online events?
Indeed, what about offline events? The HTML5 spec has defined offline events and, in fact, offline events
have been in some browsers for quite a number of years now. The spec defines two events that should
fire on the document:
online
and
offline
. There's still varying support in browsers today, but that's not
the problem. Currently these events only work as you'd expect in mobile devices (and given that there are
so many mobile devices, it's fair to say I haven't tested every mobile device). However on the desktop, the
situation is very different.
These events only fire when the user—yes, that's right, the user—explicitly sets the browser to Work Offline.
They don't automatically fire when, for whatever reason, the web connection drops or is reestablished.
To f u r t h e r c To m p To u n d t h e p r To b l e m , s To m e b r To w s e r s ( f To r i n s t a n c e , C h r To m e a n d S a f a r i ) l a c k a Wo r k O l i n e
menu item, so these events will never be triggered. Frankly, this is stupid in my book, which is why I
wouldn't particularly rely on these events in a production application. One possible alternative is to con-
stantly poll your service to ensure it's up, and I'll show you how you can do this using the manifest in the
section below entitled “Using the manifest to detect connectivity.”
