Re: My requirements for the "Manifest for Web Applications"

Hi Mark, 

On August 6, 2014 at 5:22:01 AM, Mark Taylor (mark.spam@base88.com) wrote:
> My main feedback/concerns is that it is currently as inherently inflexible as the cache  
> manifest file, rendering it useless in many use cases:
>  
> Specification assumes that the entire app is self contained and requires a consistent  
> display mode

True for v1 :( Trying to fix this in v2.  

> Most web apps will have both internal links (to other parts of the web app), and external  
> links to elements outside of the web app.

True. 

> External links often do not contain a route back  
> to the web app, so the preferred behaviour is either for it to 
>a) launch in the web browser,  

True.

> or b) launch within the app, with a navigation element allowing users to return to the 
> web app.

True. I guess by navigation element you mean: 

1. iframe
2. window.open()
3. <a href="" target=_blank> 

> Traditionally this has been hacked into web apps using an iFrame. But there are so many  
> inherent problems with iFrames on mobile. Viewport settings permeate through to iframe  
> document (e.g. pinch to zoom setting), width/height, scrolling, gestures, cross browser  
> issues etc etc etc, the list goes on. So I don’t see this as a desirable/suitable solution.  

Ok, these are either browser bugs or developer bugs tho - so, we have to assume those will be fixed. But you are correct nonetheless.  

> I would like to see this specification address this common use case.

So, part of this is addressed by the "scope" property.

See: 
https://github.com/w3c-webmob/installable-webapps/issues/48 

tl;dr: it defines what URLs are part of the app (and implies which are not). So:

```JSON
{
  "scope": "//foo.com/myapp/"
}
```

So, everything in the "https://foo/com/myapp/" directory is my app. Open everything else in the browser.

If you navigate from foo.com/myapp/, to bar.com, then bar.com will have its own display mode (and you'll be jumping to a new app, if bar.com is installed). If bar.com doesn't have a display mode, then bar.com is just shown with browser chrome.  

> Specification assumes a simple application in one orientation
>  
> Many web apps include mixed content, often from third-parties. In some cases, the content  
> is delivered in mixed orientations.

Interesting, would like to see some concrete examples of this. 

>  Imagine a list of widgets, each widget that can be  
> launched may be better suited in a different orientation. And so it makes sense to allow  
> the web app to define the orientation at any given moment in time, not just on initial load.  

This is already supported. As the spec says:

"Once the web application is running, other means can change the orientation of a top-level browsing context (such as via [SCREEN-ORIENTATION] API). "

Thus, you can change the orientation to whatever the device supports after. Unlocking returns you back to what is defined in the manifest.

The more serious problem the spec has is that it assumes one particular orientation for all screen sizes. See:
https://github.com/w3c/manifest/issues/168

Basically, we need to be able to do this to support tablets/phones properly:

{
  "orientation": "any",
  "some-condition-device-width-or-watevas": {
      "orientation": "portrait"
  }
}


> Specification assumes combined use of cache manifest file?
>  
> I can’t see any reference to a splash screen / loading sequence control.

True about splash screen. We are still debating if we want to support that. See: 
https://github.com/w3c/manifest/issues/9


> This is often  
> the most difficult part of a web application. Different media is required based on many  
> variables including device, screen size, browser, locale, language, other more specific  
> variables. The only way to meet these requirements is to use Javascript, and once all  
> of these required resources are identified and sourced can we display the app.

Correct. We are working on various other specs to deal with that. For example, Resource Hints:
https://igrigorik.github.io/resource-hints/

And Resource Priorities:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html

There are other specs in the works too... like Client Hints:
https://github.com/igrigorik/http-client-hints 

> The inherent inflexibilities in the cache manifest mechanism mean that it is not used  
> by anyone i know. If your app is large, the cache manifest is too inflexible. If your app  
> is small, it’s too small to need/benefit from a cache manifest. I would like to see this  
> area addressed. How can the web developer ensure a smooth/seamless loading sequence  
> for his/her dynamic web app when updated content is required.

My friend:D you are in luck! let me introduce you to the service worker. It's everything you asked for and so much more:
https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md

In the manifest, you will be able to declare a service worker using the "service_worker" property:
https://github.com/w3c/manifest/issues/161

> Can we determine if the manifest file has taken effect
>  
> It is unclear to me whether the developer can determine if the manifest has been read,  
> and which parts of the manifest definition have taken effect. This is useful in order  
> to customise content. For example determining if the html is running in a web browser  
> (and therefore no settings have taken effect), so orientation may need to be handled  
> differently. There are other examples for display mode etc.

I'm proposing a CSS solution for that: 
https://github.com/w3c/manifest/issues/155

```CSS 
@media all and (display-mode: standalone){
  /*Add/remove standalone things */ 
}
```

You will also be able to test for the display-mode using JS. 

```
if (window.matchMedia("(display-mode: fullscreen)").matches) { 
  ...
}
```

> Specification assumes that the content will always be served from the same location  
>  
> Most web apps are versioned.
>
> Often the url contains the version number, so many web apps  
> will constantly change base url. Often a url is bookmarked by a user, but this is a redirect  
> to the latest version of the application.

Ok, but this seems pretty bad. Would leave sites open to manual downgrade attacks. And yes, AppCache is broken because it was build around the assumption that people would build single page apps in the future (i.e., the future being now). It turned out people didn't do that.  

> In the case of the cache manifest file, this presents a problem, as each new release of  
> the app is cached until the domain runs out of local cache. In this example, I would be concerned  
> that the manifest file would not take effect properly due to the redirect.

The manifest is bound to an origin, not to a URL. The query parameters don't matter so it's not affected by people doing this. 

> Will the web page run in the background?
>  
> Can we request the app reloads every time it is reopened.

There is a "start_url" property you can set in the manifest. That URL is open every time the app is launched. 

> Can we define whether it should  
> run in the background, or be killed on minimise. 

This is outside the scope of the manifest. This would need some kind of background worker or a wake lock (see system wake locks):

See: http://w3c-webmob.github.io/wake-lock-use-cases/

Please also note that Service Workers will also listen to events in the background. They are not exactly running in the background, but can be woken to perform actions for the app (e.g., when a push notification arrives, a SW will wake and deal with it). 

> Would the Web Audio API continue to play  
> in the background when the app is minimised?

Again, I think this is outside the scope of the manifest. 

> Anyway, I hope these questions don’t seem too out-of-scope / noobie. They’re just some  
> of the issues i’ve come across over the last couple of years and I think this is a good opportunity  
> to perhaps address some of them.

No, this is great Mark! Thank you for the great feedback!

Received on Thursday, 7 August 2014 19:50:16 UTC