[whatwg] Proposal: "Offline-Capable" Meta Tag and API Indicates Application's Ability to Function Without Network Connection

[Brian Blakely]

That is a *great* addition, thank you Justin.  Perhaps "offline-capable"
should be changed to "offline-status" with two possible parameters:
"capable" and "ready", the former indicating that the app has the potential
to function offline, and the latter indicating that the app can presently
function offline.  A blank or falsy status indicates that the application
cannot function without a network connection.

In this way, a UA will know when it is appropriate to communicate with the
user, and what to communicate.

Easy controls for manually refreshing the app cache would be largely
transparent to authors, and would allow them to be fuzzier with their
expiration dates.  Other kinds of syncing would require an event, so the
author can run some localStorage routines or what-have-you.

-Brian


On Thu, Oct 13, 2011 at 11:31 AM, Justin Novosad <junov at chromium.org> wrote:

> Hi Brian,
>
> I think this is a very interesting proposition.  I would like to add
> that there should also be UA-native indication to the user that an app
> can become offline-capable upon request, along with a mechanism for
> requesting offline capability, and for triggering app data
> synchronization.  The motivation being that there should be a
> universal way to manage the
> state of all offline capable apps at the browser/OS level.
>
> On Wed, Oct 12, 2011 at 6:06 PM, Brian Blakely <anewpage.media at gmail.com>
> wrote:
> > *The element:*
> > <meta name="offline-capable" content="true" />
> >
> > *Its purpose:*
> > Trigger a UA-native indication to the user that the current application's
> > primary and entire collection of features can be used without a network
> > connection.
> >
> > *API:*
> > A simple API in the form of a document.offlineCapable boolean
> setter/getter
> > would allow an application to dynamically inform the user when the
> > application is in an offline-capable state.  For example, a nature
> > photography app may not be truly offline-capable until all of its graphic
> > assets have finished downloading.  As such, when the application has
> > detected its final image has loaded, it will execute
> document.offlineCapable
> > = true; and the user will be notified that they will no longer need WiFi
> to
> > continue usage.
> >
> > *Exposition:*
> > This seems simple, almost superfluous, but it is of staggering
> importance.
> >  An "online only" stigma is of greatly growing impedance to the web
> > platform's reputation as a software platform, and it persists among the
> vast
> > majority of users.  The latest versions of all major browsers will
> support
> > features like DOM Storage and Application Cache very soon, but these
> > features are largely ambiguous, even amongst the technically savvy.
> >
> > In addition to implementation of offline technologies, app authors are
> > currently individually responsible for informing their users that an app
> can
> > be used offline. This is not an adequate solution, and a universal
> > notification that is UA-native would be far more effective at enhancing
> > awareness.
> >
> > Because mere utilization of appcache and localStorage do not always make
> an
> > application "offline capable", offering a manual flag to authors allows a
> UA
> > to complement, or override, its heuristic detections of this state.
> >
> > The Web must become known as a full software platform, instead of just a
> > lite version of the "native" App Store experiences out there.  In order
> to
> > do so, its features must be more discoverable by users, and in a
> > standardized fashion.
> >
> > Thanks,
> > -Bri
> >
>