W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Wed, 6 Jun 2012 18:23:03 +0100
Cc: Marcos Caceres <w3c@marcosc.com>, Arthur Barstow <art.barstow@nokia.com>, ext Anant Narayanan <anant@mozilla.com>, public-webapps <public-webapps@w3.org>, "public-native-web-apps@w3.org" <public-native-web-apps@w3.org>
Message-Id: <38E8C2A4-5C87-4A34-BF37-2E51C58777EC@gmail.com>
To: Tobie Langel <tobie@fb.com>

On 6 Jun 2012, at 16:10, Tobie Langel wrote:

> On 6/6/12 5:02 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:
> 
>> On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote:
>> 
>>> Absolutely, or:
>>> 
>>> <html manifest=/path/to/config.webapp>
>>> 
>>> and combine appcache and config into a single format. The AppCache
>>> manifest format works beautifully in JSON (and I'm sure it would do
>>> equally well in XML). See how the sample manifest files provided in the
>>> HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982
>> 
>> yep, that could also workŠ though I wonder if it's too late to be
>> swapping manifest formats.
> 
> The two manifest formats could very well co-existing. Furthermore, since
> only the structure of the data differs, the AppCache algorithm wouldn't
> need to change.

This seems like a pretty convincing use-case for obtaining web app metadata, and extends the existing practices of iOS meta tags and .ico files (both of which are kludges in their own way).

The core metadata seems also pretty simple and uncontroversial: 

id
version
shortName
name
description
author (aka developer)
authorEmail	
authorHref (aka developer.url)
content (aka launch_path)
feature (aka required_feature)
license

We then have some sections that may or may not need some more work:

=== Locales and localization ===

This is pretty close to the approach used in Widgets and maps quite nicely, including defaultlocale attribute.

=== Icons ===

Responsive images in general are still quite painful to handle, and I know we sort of ducked this one in Widgets. There is also divergence even on aspect ratios (OpenSocial uses 2:1 rather than square, for example.) There have been some discussions on this topic and related areas such as screenshots (cf Native Web Apps and PhoneGap) so this one may need more work.

=== Rendering hints (orientation, viewmodes, height, width...) ===

This continues to be a pain, particularly when apps share the screen as in Apache Rave, and you need to make them sit nicely with each other. 

The orientation property seem similar to how PhoneGap has used Widgets [1]. However in that case it is used to hint to the device which orientations should be enabled by the device, rather than set a launch orientation that may conflict with the orientation of the user's device.

Likewise fullscreen is something else that has been used as an extension to Widgets by PhoneGap.

However I'm not sure how either of these fits with ViewModes, so this needs thrashing out.

=== Security (installs_allowed_from...) ===

This is probably the most controversial area, and relates to a more general process of app store behaviour; this is also something we considered under the general area of "embedding", and so there are other things that may fit such as download links for the packaged version of the webapp. It may have to end up in its own spec, or be pushed to the web-app-stores CG.

[1] https://build.phonegap.com/docs/config-xml

> 
> --tobie
> 
Received on Wednesday, 6 June 2012 17:23:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT