W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Installable web apps

From: Aaron Boodman <aa@google.com>
Date: Sat, 21 Aug 2010 14:48:08 -0700
Message-ID: <AANLkTikG-eA7-gk7YJ5hVtB09DGL2YETa+2QgAmgBXXq@mail.gmail.com>
On Mon, Jun 14, 2010 at 7:27 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Thu, 27 May 2010 18:22:03 +0200, Aaron Boodman <aa at google.com> wrote:
>> On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au>
>> wrote:
>>> <meta name="application-name" content="...">
>> You're right -- that one does exist already within the page. And it is
>> a shame to waste these existing features.
>> The more I think about it, the more I start to agree that just using
>> the <meta> and <link> tags we already have (with perhaps one addition
>> for permissions), could work.
>> Let me think about it some more.
> I think if we do more things it would make more sense to build them on top
> of <html manifest> rather than creating some new kind of JSON-based format
> that needs to be separately fetched.

Reviving ancient thread...

We are still interested in adding a lightweight concept of
'installation' to Chromium and Google Chrome that is separate from the
crx format. The attributes of an application that we like at the
moment are:

- a name
- a description
- a launch url
- icons of various sizes
- a set of permissions, such as geolocation and notifications
- a set of associated URLs (we would use this in Chromium to make
better decisions about how to group processes, and potentially how to
handle navigation)

To get a feel for the different approaches and tradeoffs, I've
implemented a prototype of this using the two of the approaches that
were discussed in this thread:

1. Embed metadata in the page, building off the existing support for,
eg, <meta name="application-name">:

<meta name="application-name" content="Pacman">
<meta name="application-description" content="The arcade classic">
<meta name="application-url" content="http://games.com/pacman">
<meta name="application-permissions" content="geolocation,notifications,...">
<meta name="application-urls" content="pacman/">
<link rel="icon" href="24.png" sizes="24x24">
<link rel="icon" href="48.png" sizes="48x48">
<link rel="icon" href="128.png" sizes="128x128">

2. Link to a separate metadata document:

<link rel="application-definition" content="application-definition.json">

// application-definition.json
  "name": "Pacman",
  "description": "The arcade classic",
  "launch_url": "http://games.com/pacman",
  "icons": [
      "url": "48.png",
      "width": 48,
      "height": 48
      "url": "128.png",
      "width": 128,
      "height": 128
  "permissions": [
    { "name": "geolocation" },
    { "name": "notifications" },
    ... etc ...
  "urls": [

In both cases, there would also be an associated navigator API:

void navigator.installApplication();
bool navigator.isInstalled;

I did not pursue adding the application definition to the existing app
cache manifest format. I discussed that with Chromium's resident
appcache expert and he was against it because he felt that the two
things were really completely different features and preferred keeping
them decoupled.

As I see it, here are the advantages of the two approaches:

- a bit simpler
- builds off the existing features in the platform

- DRY-er (doesn't repeat the same information on multiple pages of the
- Easier for third-party agents (eg search engines) to consume
(doesn't require an HTML parser)
- The browser doesn't have to load a page to consume

Based on this, I'm liking #2 better as a path forward and am going to
push to get an implementation of this working in Chromium.

Are there any other vendors interested in doing something similar? If
so, I'd like to hash out the details so we end up with


- a
Received on Saturday, 21 August 2010 14:48:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC