My requirements for the "Manifest for Web Applications"

Hi,

I am a mobile web developer and have some contributions to make regarding your current draft specification for “Manifest for web application”.


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

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.  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, or b) launch within the app, with a navigation element allowing users to return to the web app.

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.

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

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.  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.

Specification assumes combined use of cache manifest file?

I can’t see any reference to a splash screen / loading sequence control.  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.

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.

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.


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.

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.

Will the web page run in the background?

Can we request the app reloads every time it is reopened.  Can we define whether it should run in the background, or be killed on minimise.  Would the Web Audio API continue to play in the background when the app is minimised?

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.

Regards

Mark