> On 25/01/2012, at 3:10 PM, Chris Jones wrote:
> >> Subject: Re: Screen orientation API proposal
> >> I agree with both of you. This should definitely be easily
> >> parsable,
> >> and I
> >> agree with Chris that app manifests are a much much better idea
> >> (for
> >> all
> >> kinds of reasons) than the meta tag madness. But this is probably
> >> content
> >> for a much broader discussion.
> > I think to move the screen orientation proposal forward, we should
> > have at least part of that broader discussion.
> > Dean, has Apple been following the "web apps" efforts underway at
> > Google and Mozilla?
> I'm not sure exactly what you're referring to, sorry. Do you mean the
> W3C Web Apps WG?
I'm not sure if the Web Apps WG charter covers this work, TBH. One of the folks CC'd would know better than I.
> > The manifest formats we're working on are designed to solve some
> > of the problems you've almost certainly run into with iOS web
> > apps. We very much want to ensure that iOS's use cases are
> > covered too. Would you and/or your colleagues be interested in
> > catching up through a higher-bandwidth medium?
> Yes, I believe so - pointers appreciated. Any formal involvement by
> Apple (i.e. if it meant joining a standards group) is not my
> decision, but I'm definitely interested.
There are three efforts underway, mostly heading towards the same goals, and definitely moving towards some common standards
1. Google's "Installable Web Apps" for Chrome: http://code.google.com/chrome/apps/
2. Mozilla Labs' Open Web Apps project: https://developer.mozilla.org/en/Apps
3. A native implementation of installable web apps in Gecko, mostly for Boot2Gecko at the moment, eventually for Firefox: (There's no pretty overview page, but the latest work on installing apps themselves is ongoing in https://bugzilla.mozilla.org/show_bug.cgi?id=720415
. Some more discussion at https://etherpad.mozilla.org/apps-api-rev
The strategy and implementation of all three is somewhat different, but one important feature they share (relevant to the screen orientation API proposal here) is an "app manifest". In a nutshell, an app manifest is a separate JSON file that aggregates what boils down to a superset of the "apple-mobile-web-app-*" <meta> properties. Within a page, it will likely be referred to by something like <link rel="app-manifest" href="foo.manifest">. A page that has a manifest is an "installable web app". UAs can show special UI for installable apps browsed to in normal browser chrome.
There are several motivations for a separate manifest file. (If I miss some, folks on CC please correct me.)
- As I mentioned before, manifests are much smaller than the apps they refer to. This is important for "web app markets". A large collection of web apps can be enumerated through a small amount of manifest data. And when installing an app, the same link to the manifest can be passed to the engine's install() API. I.e. the manifest serves as a common interchange format.
- Similarly, UAs that don't understand manifest files can save on bandwidth by just ignoring the <link>. Harder with <meta>. The <link> can also be fetched on demand.
- More easily extensible format (JSON). <meta> is equivalently extensible, but at considerable syntactic overhead. Better author ergonomics, likely easier spec work.
- Manifest is read-only. It's not clear what should happen if an installed web app changes its <meta> tags after being installed, while it's running.
It's similarly easy for authors to use manifests and <meta> in a backwards and forwards compatible way. <link rel="app-manifest"> will be ignored in older UAs, and manifest-compatible UAs can ignore the <meta> tags.
Of course, like the three groups above, I'm sure Apple will have a distinct, fourth set of strategic goals. But it seems to me that so many use cases are common that it behooves all of us to find a common standard for application metadata.
Let us know how we can follow up on this.