Re: New manifest spec - ready for FPWD?

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