Re: Fall back strategy for manifest

On Tuesday, January 28, 2014 at 1:14 PM, Robin Berjon wrote:

> On 28/01/2014 12:13 , Marcos Caceres wrote:
> > So, I agree that the HTML should come first - and this works nicely
> > for things like the application-name. What I'm still not 100% on is
> > what I should do with things like icons... if one set of icons is
> > declared in the HTML, should I bother looking for the icons in the
> > manifest at all (i.e., should I union them)?
> 
> 
> 
> I think it makes sense to union them. Say you have data in your manifest 
> describing a dozen different icons for different contexts. It would be 
> really strange if by just overriding one in HTML you suddenly lost all 
> the others.


I don't know... thinking out loud here... but now it seems even more pointless to replicate the stuff that is already in HTML, that is `icons` and `name`, in the manifest format. 

As shown in [1], the stuff in the manifest is already a poor analogue of the equivalent HTML elements (e.g., no `media` attribute equivalent for <link rel=icon>s, and no `lang` attribute equivalent for <meta name=application-name>). 

And now consider that you have to include the metadata in the HTML anyway to have it work in legacy and non-supporting browsers - which means that there is no point in putting name and icons in the manifest at all: because HTML always wins over the stuff in the manifest (or you'd end up with a somewhat confusing mish-mash of the two in case they get merged together). The only time the stuff in the manifest would be used would be:

1. The developer doesn't want to provide this metadata to UAs which don't support the manifest (that seems bad for the Web! particularly when HTML already provides fairly well supported and fully standardized equivalents). 

2. The developer is creating a packaged app (but a different spec could specify name and icons specifically for packaged apps, which would actually make a little sense, though again the metadata could just be scraped from whatever the "index.html" is). 

So, the only value there is in the manifest is the stuff that HTML doesn't provide: namely, the members that hint to the browser about how an application should be displayed when launched (orientation and *maybe* some browser chrome options).... I say maybe because the rumor is that iOS 7.1 is introducing a "minimal-ui" option into HTML. I was hoping to standardize something similar to "minimal-ui", which we need for things like FirefoxOS, as part of the manifest.

That only leaves "orientation", "fullscreen", and "minimal-ui" hinting at application startup as things currently not standardized by HTML (there are a few other potential things but they are not in scope for v1 of the manifest). Note that Screen Lock API and Fullscreen APIs can override the stuff in the manifest - the sole purpose of the stuff in the manifest is to put the application in the right orientation and view mode as to avoid some flip-flopping when the web application is launched - and to serve as the "default orientation" for when the application's orientation is "unlocked".  

Basically this leaves (pseudo JSON showing the options):

{
app:{
  display: ["fullscreen" || "minimal-ui"],
  orientations: ["portrait"  || "landscape" || "...other orientation value here...."]
}
}  

So... what do you all think? Should I remove "name" and "icons" and just focus the manifest on stuff not supported in HTML? The name and icon stuff can then be moved to a spec specifically for packaged apps if need be.  

Kind regards,
Lonely About Manifests

[1] https://github.com/w3c/manifest/issues/97

Received on Tuesday, 28 January 2014 18:22:49 UTC