- 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