- From: Ben Francis <notifications@github.com>
- Date: Fri, 03 Apr 2015 11:59:35 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Message-ID: <w3c/manifest/issues/272/89391958@github.com>
Thanks for your detailed explanation @sicking. If a web app is no different than a web page then I don't think there's really much point in the manifest. lang can be provided by ```<html lang="en">```, name can be provided by ```<title>```, icon can be provided by ```<link rel=icon>```, fullscreen display mode can be achieved with ```requestFullscreen()```, orientation with ```screen.orientation.lock()```, theme_color with ```<meta name="theme-color">``` and start_url is irrelevant. As you suggest, I think a web app is much more analogous to a web site, in that it is a collection of web pages. In my opinion the manifest only really becomes valuable because of the scope property. By defining a URL scope to which the manifest applies it allows the manifest to provide metadata not just for a single page, but for a collection of pages, and allows that metadata to be set in one place. I think the only difference between a web site and a web app is that a web app has a manifest which allows it to be loaded inside an application context, rather than a browsing context. The spec defines an application context as a browsing context with a manifest applied. Once an application context is created the metadata applies to all pages loaded inside the context, and any navigation to a URL outside of that scope should exit the application context and enter a browsing context or another application context, without the properties of the manifest applied. This is different to an ordinary browsing context which can be navigated to any URL. The standalone display mode coupled with the scope property allow a web app, at install time, to register with the user agent as handling a defined URL scope separately from the browser, in a standalone application context. Once installed they can also facilitate deep linking by capturing navigations in the browser which fall within their scope. I believe that web apps which can break out of the of the browser and stand alone as their own application in an operating system are the next evolution of the web. This also seems to be how implementers are implementing the manifest spec, using the manifest to describe a web app which can be used separately from the browser. Installing a web app, then, is a different and complimentary action to bookmarking a web page. Bookmarking a page just saves a shortcut to a particular URL on the web, which is just one page of a web site or a web app. Installing a web app means registering that app with the user agent as handling a particular URL scope separately from the browser in a standalone application context. I agree that a web app needs a URL to identify it. For a web app to be defined by the manifest, I believe the manifest needs to be unique to one app and for the manifest URL to be an identifier of the app. I agree that a good way to make sure that the manifest is an authoritative description of an app is to host it on the same origin of the app and to serve it with a particular content type header. The current version of the spec already says that the manifest must be same-origin with the web app, I think that should continue to be the case. How do people feel about also making the manifest Content Type header compulsory, in order to provide an assurance that the owner of the web server intended the manifest to be an authoritative description of their web app? --- Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/272#issuecomment-89391958
Received on Friday, 3 April 2015 18:59:58 UTC