- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 4 Dec 2013 08:18:52 +1000
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Webapps WG <public-webapps@w3.org>, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>, Kostiainen, Anssi <anssi.kostiainen@intel.com>, Web and Mobile IG <public-web-mobile@w3.org>
On Wednesday, December 4, 2013 at 4:27 AM, Jonas Sicking wrote:
> > > I also think that we need a way to put the manifest in-line in the
> > > main document. In part, technologies tend to be a lot easier to
> > > understand if you can create a single-file demo. In part, for small
> > > simple apps, having to separate the manifest into a separate file
> > > could be annoying and might drive people to stick to the existing
> > > meta-tags.
> >
> >
> >
> > Would it suffice to use the API? It’s much simpler than trying to write out JSON by hand and wouldn’t require us to create any new special script type, etc.
> >
> > <script>
> > if(“requestBookmark” in navigator){
> >
> > var appDetails = {name: “Awesome app!”, mode: “standalone”};
> > navigator.requestBookmark(appDetails).then(happy,sad);
> > }
> > </script>
>
>
> I don't think so. That wouldn't let search engines find it. It also
> wouldn't let us hook it up to the bookmark menu unless the page always
> calls requestBookmark very early in the page load sequence at all
> times.
Right, but the search engine use case is what <link rel=“manifest” href=“foo.json"> is for.
Loading of manifest data is then prioritized by the UA till it’s needed (i.e., till the user actually takes some action to “bookmark to homescreen”) - then the right icons, etc. would be d/l presumedly.
So, the way I’ve been viewing this is that API provides a way to customize the externalized JSON metadata by overriding values - so it tries to cleanly abstract the idea of application metadata from the JSON itself by using as much information from the document and the JSON as is available.
> I'd rather stick the manifest as metadata in the markup and make
> requestBookmark take no arguments.
This would already be supported, in that once the content of the link element is loaded:
<script>
var installButton = $(“#installbutton”);
//wait for it to load
$(“link[rel=manifest]”).on(“load”, (e) => installButton.enable());
//use the metadata available to the document
installButton.on(“click”, (e) => navigator.requestBookmark());
</script>
If the load fails for whatever reason, then the developer could provide fallback either in the form of meta tags and/or by passing the custom manifest object.
If you and others still don’t think the above meets the use cases, then I’d be ok to introduce something like:
<script type=“manifest”>
{
… metadata …
}
</script>
But need to talk to HTML folks about what the right thing to do here is (with regards to legacy UAs, not breaking parsing, etc.).
--
Marcos Caceres
Received on Tuesday, 3 December 2013 22:19:24 UTC