- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 3 Dec 2013 10:27:15 -0800
- To: Marcos Caceres <w3c@marcosc.com>
- 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 Mon, Dec 2, 2013 at 9:40 PM, Marcos Caceres <w3c@marcosc.com> wrote: >> What I think we should have is something like: >> >> "chrome": { >> "back": true >> } > > Yep, this is currently captured here: > https://github.com/w3c/manifest/issues/76 > > Those of us working on this still need to investigate FxOS a bit more to see what people are using in practice and why (e.g., how much granularity do we really need? to the button level “forward”/“back", or can we just say “navigation-bar”, etc.). Captured here: > https://github.com/w3c-webmob/installable-webapps/issues/17 Simply wanting *just* the back/forward buttons has been common. I could imagine apps relying on the "reload" button as well. I have not heard of, but I could imagine, apps wanting to rely in the title of the page being displayed. Many web pages have for a long time used the title to communicate information to the user. I'm using one of those right now as I'm using gmail. It only communicates the subject line of the email I'm currently typing in the UA page title UI. The "url bar" is a very common separate UI piece on most platforms. However it's unclear how a URL bar would work in a standalone UI. Would the user be able to type any URL while still remaining in within the standalone UI? Seems surprising if we imagine that the standalone UI uses the icon of the app. Though we could always open any typed URL in the default browser. Anyway, staying away from url-bar seems safer for now. Beyond that I think platforms diverge a lot. In FirefoxOS we're planning on adding a whole menu which contains things like "bookmark", "save", "share", "reading list" etc. >> 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. I'd rather stick the manifest as metadata in the markup and make requestBookmark take no arguments. >> I also think the "dont-share-cookies-and-stuff" thing needs more work >> before it's ready for inclusion. > > Yes, totally. It’s just there for discussion. >> So might be better to drop that for >> FPWD. But I'm fine with keeping it in for now too and dropping it if >> we can't solidify it. > > I’m happy either way. I’ve been told by lawyer types elsewhere at the W3C that it’s best to pack lots of half-baked ideas into an FPWD. Gives those folks a better understanding of the impact the standard might have on them (… they will have to check again in LC, obviously, but it gives them a head start). Makes sense, sounds good. / Jonas
Received on Tuesday, 3 December 2013 18:28:18 UTC