- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 12 Feb 2014 17:07:30 -0800
- To: Marcos Caceres <w3c@marcosc.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
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. * 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. * 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. * 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 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. * 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. * 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. 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. 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. But in no instance would we do complex merging algorithms. / Jonas On Wed, Feb 5, 2014 at 4:59 PM, Marcos Caceres <w3c@marcosc.com> wrote: > Asking Jonas to comment, as he has a different way of looking at the problem. > > On Tuesday, February 4, 2014 at 5:35 PM, Marcos Caceres wrote: > >> >> >> On Tuesday, February 4, 2014 at 4:26 PM, Robin Berjon wrote: >> >> > On 04/02/2014 12:12 , Marcos Caceres wrote: >> > > Yeah, of course there it sounds silly. But there are already multiple >> > > ways to provide the application's name (e.g., >> > > "apple-mobile-web-app-title") - the manifest adds yet another. >> > > (...) >> > > Maybe, but I don't see how else to prollyfill this - particularly for >> > > icons (see [1], icons is crazy proprietary town!)? I was actually >> > > going to build the above to show how the manifest can be used to >> > > target any browser that supports "add to home screen" (by just >> > > converting the manifest members into their proprietary >> > > equivalents)... I thought it was a good idea and not very contrived >> > > :( >> > >> > >> > >> > >> > Maybe I'm being thick but taking a static resource and using it to add >> > static information to another static resource doesn't strike me as a >> > great use for a polyfill! >> >> >> >> Correct. But, without it all legacy user agents and non-supporting browsers would not get an application-name or the icons. This goes directly back to Kenneth's claims [1] that at least some developers want to put this metadata in a JSON document outside of HTML. >> >> Now you are seeing the problem I'm trying to highlight and why I started this thread in the first place: we are taking stuff we copied from HTML and putting it into JSON ... only to shove it back into HTML(!). That feels really wrong to me and it appears you agree. >> > You're sending a scripts that detects if >> > manifests are supported, if not downloads the manifest, parses it, uses >> > that information to add meta... hasn't the user left your site by then? >> >> >> >> That's a risk and could be a real problem with relying on a manifest + polyfill instead of inserting this stuff directly into the HTML. >> > >> > What happens if it immediately strikes me as wonderful and I immediately >> > bookmark it before your script has run? What happens if I'm an old >> > school crawler? >> >> >> >> Again, these are *exactly* the problems with replicating the HTML metadata in the manifest instead of just using the HTML: putting the metadata into the manifest is basically giving the middle-finger to legacy user agents and any other application that consumes HTML but knows nothing about manifests. >> >> My question to the TAG is (and not to Robin): is it ok for manifest to replicate functionality from HTML when it is demonstrable that it could lead to excluding support for legacy user agents and non-supporting applications? I'm here asking the TAG for guidance because I need your help convincing implementers of the manifest spec that replicating functionality already provided by HTML is a bad idea. >> >> I, of course, could be wrong - and Kenneth presented strong counter arguments in [1]. The TAG's guidance would be really appreciated to help settle this matter (and so I can finish the spec:)). >> > It really looks to me like you want a build step, or failing that >> > server-side generation. >> >> >> >> Yes. Which again highlights why including "name" and "icons" in the manifest doesn't seem like a good idea. Again, I'm asking for guidance here specifically about "name" and "icons" (and not the other stuff that is in the manifest but not in HTML). >> >> [1] http://lists.w3.org/Archives/Public/www-tag/2014Jan/0154.html > >
Received on Thursday, 13 February 2014 01:08:28 UTC