Re: Fall back strategy for manifest

On Thursday, February 13, 2014 at 1:07 AM, Jonas Sicking wrote:

> Hi everyone,
> 
> I think we'd make a big mistake by excluding name and icons from the manifest.
> 
> The main use-case that we have for the manifest is to support the
> "bookmark to home screen" use case. I.e. the ability for a user that
> uses a website to place a bookmark to this website on their home
> screen. The idea is that the manifest will contain the needed metadata
> to create this bookmark.
> 
> This feature has seen a lot of momentum, especially on mobile.
> 
> The two *main* pieces of metadata that this feature needs is the
> ability to describe the name and icon of the bookmark as it should
> appear on the home screen. So it seems very surprising to me to create
> a manifest feature specifically for "bookmark to home screen" which
> does not include these two pieces. I would expect authors to be
> equally surprised.
> 
> Asking authors to spread the metadata about the bookmark over two
> locations has several problems as far as I can see it.
> 
> * Spreading the metadata about a bookmark over two locations, the
> manifest and the page linking to it, makes authoring more annoying and
> error prone.

 
True. But you have to do it anyway for legacy/non-supporting user agents.  

> * It means that if you have a website with multiple pages (i.e. most
> website), you have to duplicate the icon and name data in each page.
> This further adds to authoring annoyance and likelihood of errors.

 
Again. As above. Or you need a polyfill it - which comes with its own set of problems.  

> * Authors need to be able to update the metadata for a homescreen
> bookmark. It's not rare for developers to want to update the branding
> around a website at the same time as a new version of the website is
> pushed out. This is a very common thing for native apps. By having all
> the metadata in one place, it makes it much easier to update all the
> information atomically.

 
True.   

> * Also related to updates, if any of the metadata for the bookmark
> lives in a HTML, that significantly increases the cost of checking for
> an update. Not only does it mean that we have to ping an additional
> resource, since the HTML file is likely to change much more often, it
> means that we will often have to download the whole HTML file in order
> to check if any of the relevant meta tags have changed. If this
> resource contains inlined resources like JS/images/stylesheets this
> could be a non-trivial download.

 
This is also true, but supporting such an update mechanism seems to be outside the scope of version 1. At least, it's not something that has been discussed in any detail.   

> * This makes manifests much less self sufficient for
> non-bookmark-to-home-screen. For example for searching for manifests
> that support a particular feature set. One of the use cases that we've
> envisioned for it is to enable things like "find websites which can
> handle a particular WebIntent". A search engine which finds such
> manifest would have to jump through extra hoops in order to grab the
> name and icon of that website. As would the author who creates the
> manifest.

 
Again, it depends on the kind of uptake this gets. You would still need to target legacy user agents for a while.  

> * I think that we've gotten Ruby's postulate backwards. The homescreen
> bookmark is a separate thing from the HTML page. By keeping metadata
> about the bookmark in the HTML page, we're increasing the distance of
> the metadata. This is noticable in the bullet points above, especially
> the last one, where handling the bookmark becomes more awkward since
> some of the data about it lives in a separate HTML resource.

 
This only really holds if one says that whatever is in the manifest applies to the currently nebulous concept of a "web application" - i.e., some related collection of resources in some URL space. The metadata in a document then just relates to that document (but can serve as the web application's metadata when a manifest is missing... basically the model you describe below).  

> * Another instance where grabbing the name from the HTML is awkward is
> for UAs that choose to use the 'startURL' property in the manifest.
> Does that mean that we now suddenly grab the name from that HTML page
> rather than the current page? Or should we use the name of the current
> page. That seems like breaking Ruby's postulate even more since the
> name used to open on HTML page comes from a second HTML page. And
> there would be no links from the open paged to the page that contains
> the name.

 
Right, but this is what excluding them from the manifest fixes. You always get them from the HTML... or the other way around in the model you propose below. There is no weird mishmash. 

> The behavior that I propose is that if a page contains a <link>
> pointing to a manifest then the contents of the manifest takes
> precedence. I.e. any name in the manifest is the name that should be
> used for the bookmark. And if the manifest contains icons then those,
> and only those, should be used for the bookmark.


This is also what I had originally proposed - though I'm still not in favor of replicating HTML features but can live with it. 

> UAs could still be permitted to fall back to whatever logic if a
> particular piece of information is completely missing from the
> manifest. So if there's no name in the manifest, then falling back to
> using <meta type=application-name> or <title> would make sense. And if
> *no* icons exist in the manifest, fall back to using icons from the
> current page could be permitted.

 
This is the model I would prefer too.  

> But in no instance would we do complex merging algorithms.
 
I would be happy with that :)

Received on Thursday, 13 February 2014 02:01:45 UTC