- From: Marcos Caceres <notifications@github.com>
- Date: Wed, 29 Apr 2015 11:59:19 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Message-ID: <w3c/manifest/issues/272/97541685@github.com>
For the record....
# Different understandings of the role of the web manifest
This document discusses pros and cons that can arise with the "additive" approach, defined in detail below, being taken in the current standardization of the web manifest. This document proposes an alternative approach that treats the manifest as "authoritative metadata" about a web application. What we mean by authoritative is also described in detail below.
Our alternative "authoritative" approach is not without it's own set of pros and cons, but Mozilla would like to present it to other implementers for consideration - particularly as we believe it allows for a different life-cycle management than the current additive approach.
Additionally, as the folks standardizing the web manifest have not yet finalized the design of the specification (and no one fully implements it), the cost of switching models might not be too high if other implementers agree.
As such, we would appreciate your thoughts on which model would be best to pursue (i.e., continue down current "additive" path or take the "authoritative" approach... or maybe some kind of hybrid approach).
## Manifest as additive, and its implications
To date, the W3C specification has been written with an assumption that the manifest provides additive metadata about a web application (i.e., a collection of web pages). It is additive in the sense that it overrides, amends, or works in concert with metadata found in a web page.
For instance, it is valid per spec to have a manifest that contains only the following information:
```JSON
{
"orientation": "landscape",
"display": "standalone",
"scope": "/clockapp/",
"short_name": "Clock"
}
```
And have that associated with a page, "/clockapp/index.html" in the following manner:
```HTML
<!doctype html>
<title>The World Clock — Worldwide</title>
<link rel=manifest href="//:cdn.bar.com/manifest.json">
<meta name='application-name' value='World Clock'>
<link rel='icon' href='clock.ico' sizes='16x16 32x32 48x48 64x64'>
```
As per the current processing rules of the manifest spec, this allows the UA to merge what is declared in the manifest and whatever metadata can be gathered from the DOM of the page from which the web application is being "bookmarked" or "added to home screen".
Combining the raw JSON manifest and the metadata from the web page, would yield a "processed manifest" that would look like:
```JSON
{
"orientation": "landscape",
"display": "standalone",
"scope": "/clockapp/",
"short_name": "Clock",
"name": "World Clock",
"icons": [{
"src": "clock.ico",
"sizes": "16x16 32x32 48x48 64x64"
}]
}
```
At install time, the above processed manifest is used to compose a UI dialog that allows the user to install the application.
### Rationale of additive model
The rationale for the current additive design and processing model is to leverage legacy metadata declarations found in existing web content. For instance, research conducted by Mozilla in October 2013 showed that `application-name`: was used in 1,571 sites out of Alexa's top 78,000 site (2%). Also, `link@rel=icon` (and favicon.ico) has been quite successful on the Web over the last decade, so the idea was to leverage those resources where possible.
In addition, as is the nature of all Web standards, it was assumed that cross-vendor implementation would be gradual - hence this additive model would allow developers to incrementally transition web page metadata from web pages to manifests over approximately 2-6 years (average time for cross-browser parity is +5-7 years). We are currently on ~year 2.
### Pros
* this approach is that it fits a "traditional" web development model. A manifest works similarly to, for instance, CSS (in a very loose sense): where values from the manifest are "applied" to a page when the application is opened from a user's home screen.
* Works with CDNs.
* No need for a MIME type.
* Allows manifest to work in concert with existing metadata on a page (or group of pages).
### Cons
* Updating installation details is difficult: if some of the data is derived from the manifest, and the rest was derived from the web page, it can be complicated to update the icons/name/etc. of an installed web application.
* Metadata is not authoritative: one app can use another application's metadata (possibly even across domains, CORS allowing).
* There is no 1:1 mapping between manifest metadata and HTML5's metadata - so new link/meta types/relationships might need to be specified for fallback to work properly in HTML with new features (e.g., "scope"). This makes the manifest an alternative way of providing HTML meta tags about a page (this begs the question if it's worth the trouble to standardize a whole new format just for this metadata, when this data could just be included in a web page?).
## Manifest as authoritative
The manifest as authoritative means that the manifest serves as the absolute "source of truth" about a web application - making it distinct from metadata found in individual documents of a web application. As such, when processing the manifest, no fallback metadata is gleaned from the Document from which the manifest was derived.
### Rationale of authoritative approach
The rationale for the authoritative approach is to make the manifest a useful/standalone resource in its own right: with metadata describing a web app as a whole (all URLs within a defined "scope"), which is separate from metadata describing any single web page from which the manifest might be linked.
This allows a manifest to be used independently of any document that makes up the web application itself (e.g., from a marketplace). This is achieved by restricting the manifest to a particular origin:
* having the manifest be same origin provides a light-weight trust mechanism to assert information about an application it hosts.
### Pros
* Manifest URL serves as a "stable" identifier for a web application.
* Single "source of truth": making it easier to reason about updates/changes to the manifest.: The metadata about the web application itself won't depend on any web page of the web application. This makes it simpler to perform updates, as the complete set of metadata can be gleaned from the manifest instead of the manifest + a HTML document (as is the case in the additive model).
* Marketplace-friendly: a developer can simply submit the link to the manifest to an online store (or even a regular website), and metadata about an application can be derived just from the manifest.
### Cons
* May require a MIME type. Historically, this has been problematic for developers who don't control their own server setups. For example, HTML had to drop its requirement of a MIME type on appcache manifests because of the number of developers that encountered issues trying to enable a particular type on a server (independently of the other problems inherent with appcache).
* Breaks the ability to use manifests on a CDN. This could be a problem for many sites that rely on CDNs for static content that are held at other origins.
* Might restrict customization and localization of the manifest - for instance, serving the right manifest to a user after he or she logs into a site.
---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/272#issuecomment-97541685
Received on Wednesday, 29 April 2015 18:59:49 UTC