[whatwg] Installable web apps

[Aaron Boodman]

On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> On 2010-05-26 19:10, Aaron Boodman wrote:
>>
>> On Wed, May 26, 2010 at 4:30 AM, Henri Sivonen<hsivonen at iki.fi>
>> wrote:
>>>
>>> There's a zip file with a .crx extension that contains an icon, a
>>> permission manifest and potentially the code of the app ("Building
>>> a serverless app"). When the .crx file contains the code of the
>>> app, a .crx file is essentially like a .wgt file (which is what
>>> Opera has been pushing and already has a catalog site
>>> http://widgets.opera.com/ ) except with the manifest XML exorcised
>>> and replaced with JSON.
>>
>> This isn't really the point of this mail, but I just want to point
>> out that there are more differences between wgt and crx than the
>> format of the manifest file. The most important is that the identify
>> of a crx file is a public key, and all crx files are self-signed by
>> their key. This makes a crx file's identity unforgeable.
>
> There are, however, a lot of similarities between your proposal and widgets.
>  I compared the manifests of both crx and widgets, and I believe the
> metadata included in crx maps to that in widgets as follows:
>
> *Chrome Manifest* | *Widgets Manifest*
> (implied)         | <widget viewmodes="windowed">
> name              | <name>
> version           | <widget version="...">
> icons             | <icon src=""
> - 24              | ... height="24" width="24">
> - 128             | ... height="128" width="128">
> permissions       | <feature>
> web_content       | <access
> - enabled         | (implied)
> - origin          | ... origin="...">
> - paths           | N/A - what's the purpose of this, why is it needed?
> launch:           | Default start file, e.g. index.html, or
> - web_url         | N/A
> - local_path      | <content src="...">
>
> Digital signatures are also supported in widgets.  Are there any limitations
> that you are aware of with widgets-digsig compared with crx signatures that
> might make them unsuitable?

Maybe, but I think that debate should be separate from this thread.

>>> I think the Webby step to take from here is to introduce the
>>> concept of application bookmarks (still without zip files). To
>>> "install" a Web application, the user would navigate to the app's
>>> URL and create an application bookmark.
>>
>> For Chrome this isn't the UX we want. We want users to click a link
>> in the content area and be presented with an install dialog. We
>> think that going to something in the browser to "applicationify" a
>> web app is too indirect and that many users will not get it.
>
> That was the user experience offered by Safari 4 beta's experimental Save as
> Web Application feature and Mozilla Prism.  I can understand why that is
> perceived as suboptimal for many users.  But they had the advantage of
> allowing the user to turn any website they wanted into an application,
> whereas your proposed model depends on the site explicitly providing an
> application to install.  There are benefits to both models.
>
>> That said, I think there is room to support multiple models of
>> installation (or bookmarking, or whatever you want to call it),
>> though.
>
> Indeed.
>
>>> If it's still deemed useful to be able to pre-grant permissions, I
>>> think the app should, again instead of installed zip files,
>>> use<link rel=something>  to point to a manifest that shows what the
>>> apps wishes to be pre-granted. When the features to be granted have
>>> obvious JavaScript entry points from the window object (e.g.
>>> navigator.geolocation), the JavaScript names of those entry points
>>> should be used to identify the features in the manifest in order to
>>> avoid having to standardize separate permission names.
>>
>> We have a growing set of metadata you're trying to<link>  to:
>>
>> - Icons
>
> <link rel="icon" sizes="24x24" href="icon.png">

My concern with reusing favicons is that some browsers support
changing them at runtime, so they can be overloaded to show status
information. We were actually planning on doing this in Chrome too,
even for the larger sizes. Also, it seems weird to repeat the
application information on every webpage in an app, so I prefer
linking off to a separate resource anyway.

I wonder if it would be too much of a hack to only use the icon listed
in the HTML for use in the launch/bookmark UI, and only display
runtime changes to it in the tab/window titlebar.

>> - Application name (you didn't mention this, but I think it
>> is nice to have distinct from the<title>, which is often overloaded
>> with status information)
>
> <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.

>>  - Any permissions
>
> Not yet available.
>
>> To me, this all leads to the following proposal:
>>
>> <html>
>> <head>
>> <!-- for UAs that want a button in the browser chrome to appify -->
>> <link rel="application-description" href="myapp.json">
>> </head>
>> <body>
>> <!-- for UAs that want a button in the [content area] to appify -->
>> <button onclick="navigator.installApplication()">install</button>
>
> This is reminiscent of the old <bb> element proposal that used to be in
> HTML5.
>
> <bb type="makeapp">Install application</bb>
>
> http://www.w3.org/TR/2009/WD-html5-20090423/interactive-elements.html#the-bb-element
>
> Another alternative would be to use a link relationship perhaps link to
> either a manifest or to the URL of the application itself.
>
> e.g. <a href="htts://mail.google.com/mail/" rel="application">.
>
> This could work analogously to rel="sidebar", where some browsers recognise
> that and prompt the user to load the link in their sidebar. Although, in
> this case, it could prompt the user to install the app instead.
>
>> // myapp.json
>> {
>>  "name": "My Application",
>>  "icons": ...,
>>  "urls": [
>>    "reader/"
>>  ],
>>  "permissions": [
>>    ...
>>  ]
>> }
>
> I wonder if there would be a way to integrate this extra information into
> the existing cache manifest file, or into the HTML with <meta> and <link>
> elements, rather than creating a whole new manifest file format.

I talked to the local app cache expert on Chrome and he felt that it
was a weird combination. For example: what would it mean to have a web
page reference an app cache that contains no resources, only
application definition? <html manifest="..."> makes a page a "master
page" in an app cache. But if we combine the two features, that might
not be what the author wanted (he might have only intended to get the
application features).

- a