Manifest for web apps
Home Page: https://www.w3.org/TR/appmanifest/
License: Other
This repository is the home of the ⭐ Web Application Manifest ⭐ specification being worked on by the Web Applications Working Group.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "github-actions[bot]")
I feel acting as a devil advocate coming back to that topic, but as I think the newly introduced naming convention, which is finally not the one we ended too before, introduce a new issue.
It is related to these issues:
In the first issue we said we needed a naming convention. Discussion was about choosing between "_" which was used in google and firefox manifest files, and camelCase which is more standard in JS and JSON formats including "package.json" mentioned in the second issue (but also JSON Schema Validation, GData JSON representation, ...)
"" looked to have been chosen for remote compatibility, but it looks like the "-" separator is known the one applied. So the remote compatibility argument is not valid anymore. I agree also that there is probably as much REST / JSON APIs out there using "" than the ones using camelCase. It is often because the JSON format is a port of an XML version in which "_" is more standard or because the server language use this convention (ex: perl)
Current version of the specification use "-"...
"-" is used in CSS but is problematic in JSON once converted into JS object as it is not a valid character for JavaScript identifiers (while "_" was at least ok)
This is why CSS properties in JavaScript are turned into camelCase notation, and so do the vendor prefix notations:
Potential impacts are that:
Potentially concerned "properties" in the current edition of the specification are:
Current spec defines how to process the appcache_path member, but doesn't say when or how to retrieve the app cache file.
Migrate the various administrative links to webapps.
Included the ipr page, the mailing list, etc.
The "Screen size object and its members" section needs some work.
required_features is not really to enable features, just to filter out some applications from the stores
Many apps have a long name e.g., "The Weather Channel App" but when displayed in a context with little space (e.g., on an idle screen) the name won't fit. As such, many native apps provide an alternate short name.
For example, the "Github issues" application shows up as "Issues" on the iPhone. Same with "Robot Unicorn Attack 2", which shows up as "RUA2". When searching for an app (on the phone), both the long name and the short name can be used as indexes.
The current manifest supports "fullscreen": true | false.
If people are really serious about supporting other view modes, then we can change the manifest to allow the various view mode values. Something like:
{
…
"viewModes": ["fullscreen", "maximized"]
...
}
Where viewMode is: A list that denotes the author's preferred view mode, followed by the next most preferred view mode and so forth. When the value is missing, or is left empty, it implies that the author expects the user agent to select an appropriate viewmode for the application.
With regards to width and height, we will need those for the "floating" case. But they only serve as a hint for the preferred width and height when the app starts up. I don't think we should add other window positioning information (leave that to the window manager).
Regarding permissions for Device APIs being listed in the manifest, I thought a previous proposal
and the related discussion on the WHATWG mailing list to which I participated :
may worth a read
As the manifest is no longer bound to any particular application type, it should be generalized:
Maybe just:
Manifest for Web Applications
Or:
Configuration Manifest for Web Applications
Suggestions welcomed.
@kenchris wrote:
Many games want to be fullscreen, and basically just scale the content to fit the screen while keeping the aspect ratio. These things should be possible to accomplish using media queries and CSS Device Adaptation, and it renders the screen_size less useful.
be nice, in addition to having a declarative means, to also provide an API to install apps.
The Release notes object and its members section is currently not defined.
Filter the following for relevant manifest things:
http://www.w3.org/QA/2013/08/enabling_new_types_of_web_user.html
The "Permissions object and its members" section is poorly specified.
There should be some means to make allow hosted apps to be "auto discoverable" by search engines and user agents.
The "Developer object and its members" section needs some work.
Apps that were launched after being installed might need a way to know if they were launched or navigated to.
Apple currently uses:
window.navigator.standalone
Document should define a section with use cases and requirements.
As this manifest targets a JSON format and was first created to manage "packaged apps" I immediately thought about the CommonJS / Node.js package format. I mentioned it during the F2F meeting but missed until now to fill it as an issue.
You'll notice that the main manifest format properties were already defined in the Package format:
CommonJS first defined Packages as:
http://wiki.commonjs.org/wiki/Packages/1.0
It is supported by different package tools and the npm node.js package.json format was mostly inspired from it:
https://npmjs.org/doc/json.html
Wakanda is also implementing its support at different levels:
I love this idea to push the developer to provide a bugs tracking URL (or email) as well as a list of maintainers.
The repositories property is interesting to provide either the original source repository as well as potential marketplace URLs from vendors for specific builds. This way, when a user click on a link to a manifest file, the browser can redirect to the most appropriate marketplace depending on the running platform (Android, FirefoxOS, iOS, ...)
The dependencies object relies on the package manager registry as is, which is a concern to me as those might not have all required components registered. Letting the option to provide repository URL in addition to the list of supported versions would be more "HATEOAS" (REST) compliant. In the context of Wakanda page packages, we define different types of dependencies like "devDependencies" (as node.js packages) or "loadDependencies" (used by the Ajax loader for CSS, JS and HTML template files). As for a packaged Web app, it is good to be able to define dependencies related to:
Note:
This issue is also related to this other closed one for which it looks I'm not the only one to be unsatisfied: #7 (Inconsistant naming of members)
The spec currently relies on HTML's "obtain" algorithm. However, it's probably better to use the fetch algorithm instead:
The following security considerations no loger apply:
As this specification relies on the standardized heuristics for determining the content type of files defined in the [[!SNIFF]] specification, implementers need to consider the security considerations discussed in the [[!SNIFF]] specification.
And this one neither:
In addition, user agents need to be careful about trusting path components found in the manifest. Such path components might be interpreted by operating systems as pointing at security critical files outside the browsing environment proper, and naive unpacking of zip packages into the file system might lead to undesirable and security relevant effects, such as overwriting of system files.
The spec is appearing at two places at once... And they are different :(
There is currently no declarative means for an web application to associate itself with a manifest. This would be good for autodiscovery by the UA, for search engines, and for when javascript is disabled.
Something like:
<!doctype html>
<html config="/manifest/">
<!-- OR -->
<link rel="appconfig | config | appmanifest | manifest | details | appdetails " src="/manifest/">@hollobit wrote: It would be good to change the reference information
--------- current text -------
[ECMAScript-MIME]
Reference not found.
[HTML-MIME]
Reference not found.
[JSON]
Reference not found.
[MIME]
Reference not found.
[SNIFF]
Reference not found.
[URL]
Reference not found.
--------- Proposed change -------
[ECMAScript-MIME]
B. Hoehrmann, Scripting Media Types, April 2006, Internet RFC 4329. URL: http://tools.ietf.org/html/rfc4329
[HTML-MIME]
D. Connolly; L. Masinter, The 'text/html' Media Type, June 2000, Internet RFC 2854. URL: http://tools.ietf.org/html/rfc2854
[JSON]
D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON) (RFC 4627). July 2006. RFC. URL: http://www.ietf.org/rfc/rfc4627.txt
[MIME]
MIME is specified in six RFC: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049, which together define the specifications.
[SNIFF]
A. Barth; I. Hickson, Media Type Sniffing, IETF (Work in Progress). URI: http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03
[URL]
T. Berners-Lee; L. Masinter; M. McCahill, Uniform Resource Locators (URL), December 1994, Internet RFC 1738. URI : http://tools.ietf.org/html/rfc1738
Putting the link type on an anchor kinda sucks for backwards compat. As in:
<a rel="manifest">install my app, y'all</a>So it should be "not allowed".
This feature is at risk. Unless we hear otherwise, this feature will be removed from the specification in the next few months.
In the past, various vendors had expressed an interest in having a splash screen for when an app boots up. However, at least one implementer claims that it's possible to achieve this effect by using background_color + icon members. Additionally, browsers engines are able to boot up in sub 200ms, making it possible for authors to create their own splash screen experiences without needing to rely on this.
Because of the limited processing capabilities of some devices and the amount of time it takes to initialize a Web runtime, there can be a small - yet noticeably perceivable - delay between when the end-user starts an application and the application actually becoming available and interactive to the end-user.
Depending on the complexity of the application and the processing power of the device, this delay can range from a few milliseconds to a couple of seconds. When applications take more than a few seconds to load, it can be disorienting to end-users as nothing is displayed on the screen; leading to a poor user experience. Native applications overcome this issue by allowing developers to use a media file that is displayed the instant the application is launched. Such a file is commonly referred to as a "splash screen" or "launch image".
It's been recommended that we add:
By adding a locale key to the locales field you are declaring that your app is localized for that locale and will perform in a reasonable fashion for clients using that locale.
The short name, set in the Respec config, of the spec is wrong.
The app cache manifest is per HTML file.
Even if a web app starts from a single HTML file, the one declaring the web app manifest, it often use other HTML pages.
the term "Web application" refers to a Web page (XHTML or a variant thereof + CSS) or collection of Web pages
http://www.w3.org/TR/mwabp/#webapp-defined
Additional pages can be used as:
All of them may have different modular offline cache properties
If we want the web application manifest to list offline cache property files they should all be listed, and then potentially associated to their "owner", so appcache_path may become appcache_paths.
Then, another question comes to my mind, what about resources (css, script, images...) used by different pages and listed potentially differently in their cache manifest... Maybe is it a non-question and the behavior should be specific to the context of each page...
There are currently two version of the spec :(
http://www.w3.org/2008/webapps/manifest/
http://www.w3.org/2012/sysapps/manifest/
The Webapps version is the correct one, I think.
Following the onepf/AppDF example, do you think it would be of value to make it possible for app developers to disclose content ratings through the manifest?
Why are some properties with underscore and some not?
relNotes vs required_features?
Elsewhere @sicking said:
Something that we don't have a bug for, and which I think would be
critical, is the ability for developers to put information in the
manifest which explicitly states if an app is usable offline or not.That way a developer can explicitly say that an app is not usable
offline. For example a packaged app might simply be a thin <iframe>
wrapper around a website. Or a hosted app might use appcache, but not
enough to actually be able to usefully work offline (I suspect this is
pretty common on desktop websites today given how crappy appcache is).And in theory it could flag that a hosted app that isn't using
appcache still works offline. I don't think there are any situations
where that's true today, but in the future we might add cache-pinning
APIs and other features which could enable hosted apps to work offline
even without appcache.
Currently, "name" is the only required member in the manifest (it must be present at the root - otherwise, the UA halts installation - behavior matches FxOS).
However, name could simply be implied as "undefined" when missing (or the UA could assign the application a name), so not to halt installation. For example, a UA could just use the domain name as the name (foo.com).
Having such draconian error handling seems like an anti-pattern on the Web.
I think we need to support content rating and age restriction feature in the manifest format.
For example, developers must label their applications according to ratings guideline, as like as levels (or available ages)
It can make two use cases.
Reference :
Is all properties the mandatory property ? I think we need the classification of property what is mandatory or optional. It can be provide the extensibility of manifest specification.
In traditional software distribution, it is common for software developers to express minimum "system requirements" for an application, particularly in games. For example, DOOM 3 from apple's App Store has the following system requirements:
As more sophisticated capabilities become disproportionally available to different devices and user agents, some apps stores on the Web have eluded to using something similar to warn or prevent users from purchasing software that their devices might not be able to execute.
Google's manifest format currently only asks developers to list two requirements (plugins or 3d).
"requirements": {
"plugins": {
"npapi": true
},
"3D": {
"features": ["webgl"]
}
}The system application working group published a draft specification that contained required_features member in the manifest format ():
"required_features": ["touch", "geolocation", "webgl"]
*Mozilla may be using the "required_features" member above in their store, but it's currently not part of their documentation.
As can be seen from above, the list of requirements are both arbitrary encroaches on things that should be device independent (e.g., touch) and things that are a standard part of the Web platform (geolocation) - and, in the case of geolocation, that already include a permission model.
Some initial questions are:
The use of JSON may pose some issues for developers wanting to use both RTL/LTR text (e.g., Hebrew or Arabic and english).
Quoting @clouserw:
Minor fixes: "locales keys matches" to "locales keys match" in the first sentence, and
"keys will not creates" to "keys will not create" in the last sentence. Thanks.
The "icons object and its members" section is poorly specified.
Should we allow orientation hinting in the manifest. Many games prefer to be run in either portrait or landscape, while other apps support "auto".
Given that JSON does not support any mechanism for distributed extensibility (not even crappy namespaces), extensions to the manifest format be either discouraged or some extension points provided.
From #11:
We had an offline discussion with Marcos regarding this and we realised that there are other options than proposing to extend the manifest at a particular place:
- filtering anything that isn't known by the runtime. The advantage is that it can help the application to know if a particular feature was taken into account and then emulate it but it might create issues with implementations adding new properties that would be shown and thus will have to be implemented by every one.
- not showing the manifest at all. The advantage is that all problems are resolved but some applications would need information inside the manifest like the app title, icon and description. Typically a marketplace or a homescreen. But those applications would also prefer to have a manifest object that already has localized strings so we could also imagine some kind of processed manifest.
It should not be a requirement that packaged apps run off the app: URI scheme. The runtime spec should RECOMMEND it. That should address Giri's concerns and give more freedom of choice if implementers want to use something else (e.g., a local http server per application). Again, all that matters is that the results are predictable and interoperable, not that app:// is used.
How do you think about it.
http://www.w3.org/2013/04/25-webapps-minutes.html#action10
Link at top of document don't quite work. Need to be fixed until we publish.
I think we need a milestone of this specification. Is it going to finish with runtime spec as a part of that ?
I think we need to standardize the permissions type.as predefined style (e.g: http://developer.android.com/reference/android/Manifest.permission.html )
It can be support following use cases:
how do you think about it ?
The "Locale object and its members" needs some work.
@hollobit wrote:
I think it would be good to divide subsection and insert sub-section-title
It would be helpful to reader.
------ Proposed text (subsection number/title) ------
3.1 Validation
------ end ------
Certain error conditions can result in an application manifest being treated as an invalid manifest. An invalid manifest is an application manifest that is deemed to be non-conforming in such a way that it would not be possible for the user agent to continue processing (e.g., it can't be parsed by the JSON parser). In such a case, the user agent may report the error to the user in a user-agent-specific manner, may navigate to an error page to report the error, or may ignore the error and do nothing. In either case, when a step results in an invalid manifest the user agent must abort whatever steps caused the condition.
------ Proposed text (subsection number/title) ------
3.2 Fetching and Processing
------ end ------
The steps for fetching an application manifest are given by the following algorithm. This algorithm can be applied equally to manifests fetched from HTTP/S or those derived over the app URI scheme.
....
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.