Re: [manifest] V1 ready for wider review
On Wed, Feb 12, 2014 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 12, 2014 at 12:06 PM, Marcos Caceres mar...@marcosc.com wrote: The editors of the [manifest] spec have now closed all substantive issues for v1. The spec defines the following: * A link relationship for manifests (so they can be used with link rel=manifest). * A standard file name for a manifest resource (/.well-known/manifest.json). Works the same as /favicon.ico for when link rel=manifest is missing. * The ability to point to a start-url. * Basic screen orientation hinting for when launching a web app. * Launch the app in different display modes: fullscreen, minimal-ui, open in browser, etc. * A way of for scripts to check if the application was launched from a bookmark (i.e., similar to Safari's navigator.standalone). * requestBookmark(), which is a way for a top-level document to request it be bookmarked by the user. To not piss-off users, requires explicit user action to actually work. Expect buttoninstall my app/button everywhere on the Web now :) If you are wondering where some missing feature is, it's probably slated for [v2]. The reason v1 is so small is that it's all we could get agreement on amongst implementers (it's a small set, but it's a good set to kick things off and get us moving... and it's a small spec, so easy to quickly read over). We would appreciate your feedback on this set of features - please file [bugs] on GitHub. We know it doesn't fully realize *the dream* of installable web apps - but it gets us a few steps closer. If we don't get any significant objections, we will request to transition to LC in a week or so. I still think that leaving out name and icons from a manifest about bookmarks is a big mistake. I just made my case here http://lists.w3.org/Archives/Public/www-tag/2014Feb/0039.html Basically I think we need to make the manifest more self sufficient. I think that we're getting Ruby's postulate the wrong way around by making the file that describes the bookmark not contain all the data about the bookmark. Instead the two most important pieces about the bookmark, name and icons, will live in a completely separate HTML file, often with no way to find yourself from the manifest to that separate HTML file. I agree. I further think that the marginal utility in bookmarking something to the homescreen (sorry, yes, I'm focusing on mobile first) is low if it doesn't have a Service Worker / Appcache associated. It's strictly second-class-citizen territory to have web bookmarks that routinely don't do anything meaningful when offline.
[manifest] V1 ready for wider review
The editors of the [manifest] spec have now closed all substantive issues for v1. The spec defines the following: * A link relationship for manifests (so they can be used with link rel=manifest). * A standard file name for a manifest resource (/.well-known/manifest.json). Works the same as /favicon.ico for when link rel=manifest is missing. * The ability to point to a start-url. * Basic screen orientation hinting for when launching a web app. * Launch the app in different display modes: fullscreen, minimal-ui, open in browser, etc. * A way of for scripts to check if the application was launched from a bookmark (i.e., similar to Safari's navigator.standalone). * requestBookmark(), which is a way for a top-level document to request it be bookmarked by the user. To not piss-off users, requires explicit user action to actually work. Expect buttoninstall my app/button everywhere on the Web now :) If you are wondering where some missing feature is, it's probably slated for [v2]. The reason v1 is so small is that it's all we could get agreement on amongst implementers (it's a small set, but it's a good set to kick things off and get us moving... and it's a small spec, so easy to quickly read over). We would appreciate your feedback on this set of features - please file [bugs] on GitHub. We know it doesn't fully realize *the dream* of installable web apps - but it gets us a few steps closer. If we don't get any significant objections, we will request to transition to LC in a week or so. [manifest] http://w3c.github.io/manifest/ [v2] see goals for v2, https://github.com/w3c/manifest#goals-for-v2-and-beyond [bugs] https://github.com/w3c/manifest/issues -- Marcos Caceres
Re: [manifest] V1 ready for wider review
On Wed, Feb 12, 2014 at 12:06 PM, Marcos Caceres mar...@marcosc.com wrote: The editors of the [manifest] spec have now closed all substantive issues for v1. The spec defines the following: * A link relationship for manifests (so they can be used with link rel=manifest). * A standard file name for a manifest resource (/.well-known/manifest.json). Works the same as /favicon.ico for when link rel=manifest is missing. * The ability to point to a start-url. * Basic screen orientation hinting for when launching a web app. * Launch the app in different display modes: fullscreen, minimal-ui, open in browser, etc. * A way of for scripts to check if the application was launched from a bookmark (i.e., similar to Safari's navigator.standalone). * requestBookmark(), which is a way for a top-level document to request it be bookmarked by the user. To not piss-off users, requires explicit user action to actually work. Expect buttoninstall my app/button everywhere on the Web now :) If you are wondering where some missing feature is, it's probably slated for [v2]. The reason v1 is so small is that it's all we could get agreement on amongst implementers (it's a small set, but it's a good set to kick things off and get us moving... and it's a small spec, so easy to quickly read over). We would appreciate your feedback on this set of features - please file [bugs] on GitHub. We know it doesn't fully realize *the dream* of installable web apps - but it gets us a few steps closer. If we don't get any significant objections, we will request to transition to LC in a week or so. I still think that leaving out name and icons from a manifest about bookmarks is a big mistake. I just made my case here http://lists.w3.org/Archives/Public/www-tag/2014Feb/0039.html Basically I think we need to make the manifest more self sufficient. I think that we're getting Ruby's postulate the wrong way around by making the file that describes the bookmark not contain all the data about the bookmark. Instead the two most important pieces about the bookmark, name and icons, will live in a completely separate HTML file, often with no way to find yourself from the manifest to that separate HTML file. / Jonas
[manifest] name and icons, was Re: [manifest] V1 ready for wider review
On Thursday, February 13, 2014 at 1:21 AM, Jonas Sicking wrote: I still think that leaving out name and icons from a manifest about bookmarks is a big mistake. I just made my case here http://lists.w3.org/Archives/Public/www-tag/2014Feb/0039.html I'll reply separately. Basically I think we need to make the manifest more self sufficient. I think that we're getting Ruby's postulate the wrong way around by making the file that describes the bookmark not contain all the data about the bookmark. Instead the two most important pieces about the bookmark, name and icons, will live in a completely separate HTML file, often with no way to find yourself from the manifest to that separate HTML file. I still think that icons and name are outside the scope of V1 - but I've added them to V2. The whole manifest and icon updating mechanism you describe in your email to the TAG adds a bunch of complexity (yes, we need to deal with it eventually as it's an extremely valid use case - but we can defer it to HTML at this moment and for a few months... even if UAs don't do updating of icons and name from HTML). I still hold that we should get the most critical and least controversial functionality (display mode, default-orientation, and start-url) standardized before we do the other stuff. It also gives a chance for UA's to catch up and implement HTML's application-name and link rel=icon properly. UAs are going to need to support those HTML features to work with apps that don't make use of manifests. And apps the use manifests will work just fine till we add proper support for name and icons into the manifest - all web apps will need to include application-name and link rel=icon (as well as a bunch of proprietary stuff!) to target todays and yesterdays UAs regardless. So, IMHO, there is not much to be won by putting name and icons into V1 for implementers or for developers at this moment. I would go as far as to say that it's initially harmful to have name and icon in V1 because it discourages UAs from fixing their support for application-name and link rel=icon. Having the fallback behavior explicitly tested in V1 of the manifest may help improve support for those features of HTML. So, I'm not saying let's never do name and icon - I'm saying let just do the easy stuff we have some agreement on first.
