Re: Fall back strategy for manifest

On Monday, January 27, 2014 at 7:58 PM, Domenic Denicola wrote:

> Hi Marcos!
> 
> 4 ("Don't redefine stuff that is in HTML") certainly sounds appealing at first glance. Could you tell us more about possible problems with that approach? I assume it doesn't work out perfectly...
Basically, it affects apps that are not installed from a web page at all - i.e., where one points a UA to a manifest instead, like FxOS does. Also, I'm told that using the HTML doesn't work as nicely with packaged apps, when compared to the JSON file. The JSON gives a inert resource where the UA can find metadata about an app without needing to scrape or run the HTML. 

There are a bunch of additional problems with using this JSON to replicate HTML features, most of the details are here: 
https://github.com/w3c/manifest/issues/97

> Also, could you clarify the model with regard to the manifest and the HTML file(s)? It sounds like there's an assumption that there's a single important HTML file ("index.html" perhaps) where the <meta> and <link> tags could live. What about multi-page apps? What if they defined conflicting <meta> data?
The assumption is that any page can be bookmarked - so the model is designed around multipage apps. The web page declares a relationship to a manifest as follows:
 
<link rel="manifest" href="bookmark_info">


But any page can link to any manifest it wants. Or to no manifest at all, in which case the UA looks for a resource named "/.well-known/manifest.json"... don't even start about the "./well-known/" bit, not my fault :) 

The bookmarking information is more like a "snapshot" that is derived from the manifest and the page being bookmarked at that moment in time. The user can customize some of that information (e.g., they could change the name of the web application as it appears on the home screen, or choose to have the application always launch in the browser instead of "standalone", and so on).  

Hope that helps! 

> ________________________________________
> From: Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)>
> Sent: Monday, January 27, 2014 14:33
> To: www-tag@w3.org (mailto:www-tag@w3.org)
> Subject: Fall back strategy for manifest
> 
> Hi TAG,
> I'm currently working on standardizing this manifest thingy [1] that allows devs to define metadata for their Web apps using JSON. Example metadata includes the application's name and icons, plus the supported orientations and other little things for now.
> 
> The problem I'm having is that HTML already provides this capability through <meta> and <link> elements. So, ignoring the fact that I'm (mostly unnecessarily) redefining stuff that is already in HTML, the question I have is: what would be a web friendly way to handle when both the manifest and the HTML define metadata about the web application?
> 
> The options, I guess, are:
> 
> 1. Manifest wins: if valid metadata is provided in the manifest, ignore what is in the HTML. Otherwise, fall back to the HTML.
> 2. HTML wins: ignore anything in the manifest that is already in the HTML document. Use the manifest to fill the gaps.
> 3. Manifest and HTML should be combined - take the union of both and, in case of conflict, use that with either the stuff in the manifest winning or the stuff in the HTML winning.
> 4. Don't redefine stuff that is in HTML.
> 5. ???
> 
> I'm currently specifying 1. So, for example, if there are valid icons found in the manifest, then those are used and the ones in the HTML document are ignored. However, if the application's name is not in the manifest (or it was an invalid type), the user agent falls back to HTML.
> 
> Any guidance would be appreciated.
> 
> [1] http://manifest.sysapps.org/
> 
> --
> Marcos Caceres

Received on Monday, 27 January 2014 21:16:02 UTC