Re: [manifest] V1 ready for wider review

2014-02-14 Thread Alex Russell
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.


Re: [manifest] V1 ready for wider review

2014-02-12 Thread Jonas Sicking
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

2014-02-12 Thread Marcos Caceres



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.