Re: Fall back strategy for manifest

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