Re: New manifest spec - ready for FPWD?

On Tue, 03 Dec 2013 06:40:43 +0100, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On Tuesday, December 3, 2013 at 3:01 PM, Jonas Sicking wrote:
>
>> On Tue, Nov 26, 2013 at 1:02 PM, Marcos Caceres <w3c@marcosc.com  
>> (mailto:w3c@marcosc.com)> wrote:
>> > The Editors would appreciate if people take a look and see if you  
>> agree with the feature set.
>>
>>
>> When we did outside-of-browser-UI web apps for FirefoxOS we quickly
>> found that a lot of developers want to be able to rely on UA-provided
>> UI such as the back button.

Yeah, this was my experience developing widgets as well. Saying they run  
in the browser means people assume the browser can do "normal browser  
things" (which, admittedly, are poorly defined beyond "follow links and go  
back").

>> Yes, the app can detect that it's running "standalone" and display a
>> back button itself. However that was significantly more work than any
>> other part of creating a "standalone" app, which mostly consisted in
>> writing a manifest. It's especially a lot of work if you want to try
>> to replicate the platform-rendered back button on all platforms.
>>
>> 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

I'd suggest keeping the functions pretty granular. My navbar include  
various extension buttons, and my Opera navbar included the rewind  
function (which I loved). I think we'll set very mixed expectations if we  
try to make general statements about what browser functionalities are,  
that will cause more confusion than benefit.

(Unless we want to do that to try and discover exactly what people expect  
by seeing how much of all the thingz get b0rken).

>> If the UA doesn't support any of the properties in the "chrome"
>> section, then the UA should be required to not launch the app in
>> standalone mode.
>
>  Yeah that makes sense.
>> 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>
>
> It’s more or less equivalent to making it declarative and easily passes  
> the “OMG! that’s so easy!” test :)

Why wouldn't we use the API *and* allow people to write JSON if they want  
to? Or is that what you meant?

> Obviously, devs will still need to continue using a lot of the meta tags  
> for a while to support legacy browsers (or any browser that doesn’t  
> implement this).
>
>> 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).

Likewise it helps implementors who are not following the group really  
closely (and I can think of several of those off the top of my head) get a  
sense of what we're thinking about. On balance I think it's a better  
approach to include stuff, and say inline where it's up to in stability -  
especially at the relatively early stages where we expect changes anyway.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 3 December 2013 06:35:02 UTC