Authority of the manifest's metadata

When a manifest is linked from a Document, it indicates to the user agent that the metadata is authoritative: that is, the user agent SHOULD use the metadata of the manifest instead of the one in the Document. However, in cases where metadata is missing, or in error, a user agent MAY fallback to the Document to find suitable replacements for missing manifest members (e.g., using application-name in place of short_name).

Security considerations

When the navigation scope is unbounded and a display mode other than browser is being applied, it is RECOMMENDED that user agents signal to the end-user when security and/or privacy sensitive navigations occur. The manner of signaling is left up to implementers, but can include things like showing the URL of the application context, dropping out of fullscreen to the browser display mode. Examples of security and/or privacy sensitive navigations include, but are not limited to:

• the application context being navigated from a secure connection to an insecure connection (or vice versa).
• the application context being navigated to a different origin.

This specification distinguishes between behavior in first-party and third-party contexts. In particular, if a scope member is declared in the manifest, it is not possible to navigate the top-level browsing context to somewhere outside the scope while the manifest is applied to the top-level browsing context. That's not to say that the web application cannot be navigated: just that the set of URLs to which the manifest applies is restricted by the navigation scope.

Deep links

A deep link is a URL that is within scope of an installed web application.

The 'display-mode' media feature

The display-mode media feature represents, via a CSS media query [[!MEDIAQ]], the display mode of the web application. This media feature applies to the top-level browsing context and any child browsing contexts. Child browsing contexts reflect the display mode of the top-level browsing context.

A user agent MUST expose the 'display-mode' media feature irrespective of whether a manifest is being applied to a browsing context. For example, if the end-user puts the whole user agent into fullscreen, then the user agent would reflect this change to CSS and scripts via the 'display-mode' media feature.

/* applies when the window is fullscreen */
@media all and (display-mode: fullscreen) {
    ...
}

/* applies when an element goes fullscreen */
#game:fullsceen{
    ...
}

Value:

fullscreen | standalone | minimal-ui | browser

Applies to:

visual media types

Accepts min/max prefixes:

No

A user agent MUST reflect the applied display mode of the web application via a CSS media query [[!MEDIAQ]].

@media all and (display-mode: minimal-ui) {
  /* ... */
}
@media all and (display-mode: standalone) {
  /* ... */
}

const standalone = matchMedia( '(display-mode: standalone)' );

standalone.onchange = (e) => {
  /* handle changes to display mode */
}

if (standalone.matches) {
  /* do standalone things */
}

Linking to a manifest

The manifest keyword can be used with a [[!HTML]] link element. This keyword creates an external resource link.

The media type for a manifest serves as the default media type for resources associated with the manifest link type.

In cases where more than one link element with a manifest link type appears in a Document, the user agent uses the first link element in tree order and ignores all subsequent link element with a manifest link type (even if the first element was erroneous). See the steps for obtaining a manifest.

To obtain a manifest, the user agent MUST run the steps for obtaining a manifest. The appropriate time to obtain the manifest is left up to implementations. A user agent MAY opt to delay fetching a manifest until after the document and its other resources have been fully loaded (i.e., to not delay the availability of content and scripts required by the document).

A manifest is obtained and applied regardless of the media attribute of the link element matches the environment or not.

Obtaining a manifest

The steps for obtaining a manifest are given by the following algorithm. The algorithm, if successful, returns a processed manifest and the manifest URL; otherwise, it terminates prematurely and returns nothing. In the case of nothing being returned, the user agent MUST ignore the manifest declaration. In running these steps, a user agent MUST NOT delay the load event.

1. From the Document of the top-level browsing context, let manifest link be the first link element in tree order whose rel attribute contains the token manifest.
2. If manifest link is null, terminate this algorithm.
3. If manifest link's href attribute's value is the empty string, then abort these steps.
4. Let manifest URL be the result of parsing the value of the href attribute, relative to the element's base URL. If parsing fails, then abort these steps.
5. Let request be a new [[!FETCH]] request, whose URL is manifest URL, and whose context is "manifest".
6. If the manifest link's crossOrigin attribute's value is 'use-credentials', then set request's credentials to 'include'.
7. Await the result of performing a fetch with request, letting response be the result.
8. If response is a network error, terminate this algorithm.
9. Let manifest be the result of running the steps for processing a manifest with response's body as the text, manifest URL, and the URL that represents the address of the top-level browsing context.
10. Return manifest and manifest URL.

HTTP/1.1 200 OK
Cache-Control: max-age=2592000
Content-Type: application/manifest+json

{
  "lang": "en",
  "name": "Super Racer 2000",
  "start_url": "/start.html",
  "display": "fullscreen",
  "orientation": "landscape"
}

Content security policy

A user agent MUST support [[!CSP3]].

The manifest-src and default-src directives govern the origins from which a user agent can fetch a manifest. As with other directives, by default the manifest-src directive is *, meaning that a user agent can, [[!FETCH]]'s CORS permitting, fetch the manifest cross-domain. Remote origins (e.g., a CDN) wanting to host manifests for various web applications will need to include the appropriate CORS response header in their HTTP response (e.g., Access-Control-Allow-Origin: https://example.com).

Processing the manifest

When instructed to issue a developer warning, the user agent MAY report the conformance violation to the developer in a user-agent-specific manner (e.g., report the problem in an error console), or MAY ignore the error and do nothing.

When instructed to ignore, the user agent MUST act as if whatever manifest, member, or value caused the condition is absent.

The following algorithm provides an extension point: other specifications that add new members to the manifest are encouraged to hook themselves into this specification at this point in the algorithm.

The steps for processing a manifest are given by the following algorithm. The algorithm takes a text string as an argument, which represents a manifest, and a URL manifest URL, which represents the location of the manifest, and a URL document URL. The output from inputting an JSON document into this algorithm is a processed manifest .

1. Let parsed manifest be an empty object.
2. Let manifest be the result of parsing text. If parsing throws an error:
   1. Issue a developer warning with any details pertaining to the JSON parsing error.
   2. Set manifest to be the result of parsing the string "{}".
3. If Type(manifest) is not "object":
   1. Issue a developer warning that the manifest needs to be an object.
   2. Set manifest to be the result of parsing the string "{}".
4. Extension point: process any proprietary and/or other supported members at this point in the algorithm.
5. Let the default direction of parsed manifest be the result of running the steps for processing the dir member with manifest as the argument.
6. Let start URL of parsed manifest be the result of running the steps for processing the start_url member with manifest, manifest URL, and document URL as arguments.
7. Let display mode of parsed manifest be the result of running the steps for processing the display member with manifest as the argument.
8. Let orientation of parsed manifest be the result of running the steps for processing the orientation member with manifest and display mode as arguments.
9. Let name of parsed manifest be the result of running the steps for processing the name member with manifest as the argument.
10. Let language of parsed manifest be the result of running the steps for processing the lang member with manifest as the argument.
11. Let short name of parsed manifest be the result of running the steps for processing the short_name member with manifest as the argument.
12. Let icons of parsed manifest be the result of running the steps for processing an array of images with manifest, manifest URL, and "icons" as arguments.
13. Let splash screens of parsed manifest be the result of running the steps for processing an array of images with manifest, manifest URL, and "splash_screens" as arguments.
14. Let scope of parsed manifest be the result of running the steps for processing the scope member with manifest, manifest URL, document URL, start URL as arguments.
15. Let related applications of parsed manifest be the result of running the steps for processing the related_applications member with manifest as argument.
16. Let prefer related applications of parsed manifest be the result of running the steps for processing the prefer_related_applications member with manifest as argument.
17. Let theme color of parsed manifest be the result of running the steps for processing the theme_color member with manifest as argument.
18. Let background_color of parsed manifest be the result of running the steps for processing the background_color member with manifest as argument.
19. Return parsed manifest.

Applying the manifest

A manifest is applied to a top-level browsing context, meaning that the members of the manifest are affecting the presentation or behavior of a browsing context.

A top-level browsing context that has a manifest applied to it is referred to as an application context.

If an application context is created as a result of the user agent being asked to navigate to a deep link, the user agent MUST immediately navigate to the deep link with replacement enabled. Otherwise, when the application context is created, the user agent MUST immediately navigate to the start URL with replacement enabled.

The appropriate time to apply a manifest is when the application context is created and before navigation to the start URL begins.

Updating the manifest

By using the manifest URL, a user agent MAY periodically check if the contents of a manifest has been modified (e.g., by honoring HTTP cache directives associated with the manifest or by checking for updates after the web application has been launched). In the event that the members of the manifest have been updated, as determined by running the steps for processing a manifest and seeing if anything has changed, the user agent MAY update the metadata corresponding to the web application (e.g., by replacing the name, icons, navigation scope, or whatever other data has been changed).

In addition, even if the manifest has not been modified, the user agents MAY periodically check if resources referenced from a manifest (e.g., the icons) have been modified by honoring HTTP cache directives. If any resources have been modified, the user agent MAY replace any stale resources.

To avoid one application masquerading as another, it is RECOMMENDED that users be made aware of any such updates using implementation or platform specific conventions.

dir member

The dir member specifies the base direction for the directionality-capable members of the manifest. The dir member's value can be set to one of the text-direction values.

The directionality-capable members are:

• name member.
• short_name member.

The text-direction values are the following, implying that the value of the directionality-capable members is by default:

ltr

left-to-right text.

rtl

right-to-left text.

auto

programmatically determined from the value of the member.

When displaying the directionality-capable members to an end-user, the user agent MUST use the base direction to compute directional runs and layout or position text correctly in text containing mixed-direction sequences [[!BIDI]]. When the base direction is "auto" the user agent MUST run the steps to programmatically determine the directionality of a member - and use the resulting text-direction value to assist in displaying the value of the member.

The steps to programmatically determine the directionality of a member are as follows. The algorithm takes the value of a member.

1. Find the first character (in logical order) of the value that is of bidirectional character type L, AL, or R [[!BIDI]].
2. If such a character is found and it is of bidirectional character type AL or R, return "rtl".
3. Otherwise, return "ltr".

The steps for processing the dir member is given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns one of the text-direction values.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "dir".
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. If Type(value) is "undefined", return "auto".
3. Otherwise, Trim(value) and let direction be the result.
4. If direction not one one the text-direction values, then:
   1. issue a developer warning that the value is invalid.
   2. Return "auto".
5. Return direction.

lang member

The lang member is a language tag (string) that specifies the primary language for the values of the manifest's name and short_name members.

A language tag is a string that matches the production of a Language-Tag defined in the [[!BCP47]] specifications (see the IANA Language Subtag Registry for an authoritative list of possible values, see also the Maintenance Agency for ISO 3166 country codes). That is, a language range is composed of one or more subtags that are delimited by a U+002D HYPHEN-MINUS ("-"). For example, the 'en-AU' language range represents English as spoken in Australia, and 'fr-CA' represents French as spoken in Canada. Language tags that meet the validity criteria of [[!RFC5646]] section 2.2.9 that can be verified without reference to the IANA Language Subtag Registry are considered structurally valid.

The steps for processing the lang member is given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "lang".
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Otherwise, Trim(value) and let tag be the result.
4. If calling IsStructurallyValidLanguageTag with tag as the argument returns false, then:
   1. issue a developer warning that the value is invalid.
   2. Return undefined.
5. Otherwise, return the result of calling the CanonicalizeLanguageTag abstract operation, passing tag as the argument.

name member

The name member is a string that represents the name of the web application as it is usually displayed to the user (e.g., amongst a list of other applications, or as a label for an icon).

The steps for processing the name member is given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "name".
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Otherwise, Trim(value) and return the result.

short_name member

The short_name member is a string that represents a short version of the name of the web application. It is intended to be used where there is insufficient space to display the full name of the web application.

The steps for processing the short_name member is given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "short_name".
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Otherwise, Trim(value) and return the result.

scope member

The scope member is a string that represents the navigation scope of this web application's application context.

The steps for processing the scope member is given by the following algorithm. The algorithm takes a manifest manifest, a URL manifest URL , a URL document URL, and a URL start URL . This algorithm returns a URL or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of the manifest with argument "scope".
2. Let type be Type(value).
3. If type is not "string" or value is the empty string, then:
   1. If type is not "undefined", issue a developer warning that the type is unsupported.
   2. Return undefined.
4. Let scope URL be a new URL using value as input and manifest URL as the base URL.
5. If scope URL is failure:
   • Issue a developer warning.
   • Return undefined.
6. If scope URL is not same origin as document URL:
   1. Issue a developer warning that the scope needs to be same-origin as Document of the application context.
   2. Return undefined.
7. If start URL is not within scope of scope URL:
   1. Issue a developer warning that the start URL is not within scope of the navigation scope.
   2. Return undefined.
8. Otherwise, return scope URL.

splash_screens member

The splash_screens member is an array of image objects that can serve as a loading screen for the web application. A splash screen indicates to the end user that a loading process is occurring (in effect, that the web application is being prepared by the user agent in the background). As the splash_screens member is an array of image objects, developers can use unique image objects definitions to target minimum screen resolutions and pixel densities.

This feature is primarily intended for user agents that take a perceptible amount of time to self-initialize (e.g., take longer than 200ms to be able to render content) - as such, it is OPTIONAL for a user agent to display a splash screen while the web application is being loaded. On launching a web application, if displaying a splash screen, the user agent MUST queue a post-load task on the Document of the start URL to remove the splashscreen, or, alternatively can follow platform conventions for how long a splash screen is displayed (e.g., a minimum of 1 second).

The splash_screens member is processed using the steps for processing an array of images.

icons member

The icons member is an array of image objects that can serve as iconic representations of the web application in various contexts. For example, they can be used to represent the web application amongst a list of other applications, or to integrate the web application with an OS's task switcher and/or system preferences.

The icons member is processed using the steps for processing an array of images.

If there are multiple equally appropriate icons in icons, a user agent MUST use the last one declared in order at the time that the user agent collected the list of icons. If the user agent tries to use an icon but that icon is determined, upon closer examination, to in fact be inappropriate (e.g. because its content type is unsupported), then the user agent MUST try the next-most-appropriate icon as determined by examining the image object's members.

{
  "icons": [
      {
        "src": "icon/lowres.webp",
        "sizes": "48x48",
        "type": "image/webp"
      },{
        "src": "icon/lowres",
        "sizes": "48x48"
      },{
        "src": "icon/hd_hi.ico",
        "sizes": "72x72 96x96 128x128 256x256"
      },{
        "src": "icon/hd_hi.svg",
        "sizes": "72x72",
        "density": 2
      }]
 }

display member

The display member is a string, whose value is one of display modes values. The item represents the developer's preferred display mode for the web application. When the member is missing or erroneous, the user agent MUST use the fallback display mode.

The steps for processing the display member are given by the following algorithm. The algorithm takes a manifest manifest as an argument, and returns a string.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest passing "display" as the argument.
2. If Type(value) is not "string" or Trim(value) is not part of the display modes values:
   1. If Type(value) is not "undefined", issue a developer warning that the type is unsupported.
   2. If value is not part of the display modes values, issue a developer warning that the value is unsupported.
   3. Return the fallback display mode's value.
3. Otherwise, Trim(value) and set value to be the result.
4. If value is not a display mode that the user agent supports, set value to value's fallback display mode and re-run this step.
5. Return value.

orientation member

The orientation member is a string that serves as the default orientation for all top-level browsing contexts of the web application. The possible values are those of the OrientationLockType enum defined in [[!SCREEN-ORIENTATION]].

If the user agent honors the value of the orientation member as the default orientation, then that serves as the default orientation for the life of the web application (unless overridden by some other means at runtime). This means that the user agent MUST return the orientation to the default orientation any time the orientation is unlocked [[!SCREEN-ORIENTATION]] or the top-level browsing context is navigated.

Although the specification relies on the [[!SCREEN-ORIENTATION]]'s OrientationLockType, it is OPTIONAL for a user agent to implement the [[!SCREEN-ORIENTATION]] API. Supporting the [[!SCREEN-ORIENTATION]] API is, of course, RECOMMENDED.

Certain UI/UX concerns and/or platform conventions will mean that some screen orientations and display modes cannot be used together . Which orientations and display modes cannot be used together is left to the discretion of implementers. For example, for some user agents, it might not make sense to change the default orientation of an application while in browser display mode.

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

The steps for processing the orientation member are given by the following algorithm. The algorithm takes a manifest manifest and display mode display mode as an argument, and returns a string.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "orientation".
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", issue a developer warning that the type is not supported.
   2. Return the empty string.
3. Otherwise, Trim(value) and set value to be the result.
4. If value is not one of the OrientationLockType enum values, or value is unsupported by the user agent, or the value cannot be used together with display mode:
   1. Issue a developer warning.
   2. Return the empty string.
5. Return value.

start_url member

The start_url member is a string that represents the start URL , which is URL that the developer would prefer the user agent load when the user launches the web application (e.g., when the user clicks on the icon of the web application from a device's application menu or homescreen).

The start_url member is purely advisory, and a user agent MAY ignore it or provide the end-user the choice not to make use of it. A user agent MAY also allow the end-user to modify the URL when, for instance, a bookmark for the web application is being created or any time thereafter.

The steps for processing the start_url member are given by the following algorithm. The algorithm takes a manifest manifest, a URL manifest URL , and a URL document URL. This algorithm returns a URL.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of the manifest with argument "start_url".
2. Let type be Type(value).
3. If type is not "string" or value is the empty string:
   1. If type is not "undefined", issue a developer warning that the type is unsupported.
   2. Return a new URL whose input is document URL.
4. Let url be a new URL using value as input and manifest URL as the base URL.
5. If url is failure:
   • Issue a developer warning.
   • Return a new URL whose input is document URL.
6. If url is not same origin as document URL:
   1. Issue a developer warning that the start_url needs to be same-origin as Document of the top-level browsing context.
   2. Return a new URL whose input is document URL.
7. Otherwise, return url.

theme_color member

The theme_color member serves as the default theme color for an application context. What constitutes a theme color is defined in [[!HTML]].

If the user agent honors the value of the theme_color member as the default theme color, then that color serves as the theme color for all browsing contexts to which the manifest is applied. However, a document may override the default theme color through the inclusion of a valid [[!HTML]] meta element whose name attribute is "theme-color".

The steps for processing the theme_color member are given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "theme_color".
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Otherwise, let potential color be the result of running [[!CSS-SYNTAX-3]]'s parse a component value algorithm with value as input. If parsing returns a syntax error, return undefined.
4. Let color be the result of attempting to parse potential color as a CSS color, as per [[!CSS-SYNTAX-3]]. If parsing fails:
   1. Issue a developer warning.
   2. Return undefined.
5. Return color.

related_applications member

A related application is an application accessible to the underlying application platform that has a relationship with the web application associated with a manifest.

The related_applications member lists related applications and serves as an indication of such a relationship between web application and related applications. This relationship is unidirectional and unless a listed application claims the same relationship, the user agent MUST NOT assume a bi-directional endorsement.

Example of usages of the related_applications could be a crawler that would use that information to gather more information about the web application or a browser that could suggest a listed application as an alternative if the user wants to install the web application.

The steps for processing the related_applications member are given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a list of application objects applications, which can be empty.

1. Let applications be an empty list.
2. Let unprocessed applications be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "related_applications".
3. If unprocessed applications is an array, then:
   1. For each potential application in the array:
      1. Let platform be the result of running the steps for processing the platform member of an application with potential application.
      2. If platform is undefined, move onto the next item if any are left.
      3. Let id be the result of running the steps for processing the id member of an application with potential application.
      4. Let url be the result of running the steps for processing the url member of an application with potential application.
      5. If both id and url are undefined, move onto the next item if any are left.
      6. Otherwise, let application be an object with properties platform, id, url respectively set to platform, id and url.
      7. Append application to applications.
4. Otherwise, if unprocessed applications is not undefined:
   1. Issue a developer warning that the type is not supported.
5. Return applications.

prefer_related_applications member

The prefer_related_applications member is a boolean value that is used as a hint for the user agent to say that related applications should be preferred over the web application. The user agent MUST consider the missing value as equivalent to have it set to false. If the prefer_related_applications is set to true, and the user agent wants to suggest to install the web application, the user agent might want to suggest installing one of the related applications instead.

The steps for processing the prefer_related_applications member are given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a boolean.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "prefer_related_applications".
2. If Type(value) is not "boolean":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return false.
3. Return value.

background_color member

The background_color member describes the expected background color of the web application. It repeats what is already available in the application stylesheet but can be used by the user agent to draw the background color of a web application for which the manifest is known before the files are actually available, whether they are fetched from the network or retrieved from disk.

The background_color member is only meant to improve the user experience while a web application is loading and MUST NOT be used by the user agent as the background color when the web application's stylesheet is available.

The steps for processing the background_color member are given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "background_color".
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Otherwise, let potential color be the result of running [[!CSS-SYNTAX-3]]'s parse a component value algorithm with value as input. If parsing returns a syntax error, return undefined.
4. Let color be the result of attempting to parse potential color as a CSS color, as per [[!CSS-SYNTAX-3]]. If parsing fails:
   1. Issue a developer warning.
   2. Return undefined.
5. Return color.

Content security policy of image objects

The security policy that governs whether a user agent can fetch an icon image is governed by the img-src directive [[!CSP3]] associated with the manifest's owner Document.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Security-Policy: img-src icons.example.com

<!doctype>
<html>
<link rel="manifest" href="manifest.webmanifest">

{
    "name": "custom manifest",
    "start_url": "http://boo",
    "icons": [{
        "src": "//icons.example.com/lowres"
      },
      {
        "src": "//other.com/hi-res"
      }]
}

density member

The density member of an image object is the device pixel density for which this image was designed. The device pixel density is expressed as the number of dots per 'px' unit (equivalent to a dppx as defined in [[css3-values]]). The value is a positive number greater than 0. If the developer omits the value, the user agent assumes the value 1.0.

The steps for processing a density member of an image are given by the following algorithm. The algorithm takes an image image object as an argument and returns a positive number.

1. If [[\HasOwnProperty]] internal method of image passing density as the argument returns false:
   1. Return 1.0.
2. Let value be the result of calling the [[\GetOwnProperty]] internal method of image passing " density" as the argument.
3. Let result be the result of parseFloat( value);
4. If result is NaN, +∞, or less than or equal to +0, then:
   1. Issue a developer warning.
   2. Return 1.0.
5. Return result.

sizes member

The sizes member of an image object is a string consisting of an unordered set of unique space-separated tokens which are ASCII case-insensitive that represents the dimensions of an image. Each keyword is either an ASCII case-insensitive match for the string "any", or a value that consists of two valid non-negative integers that do not have a leading U+0030 DIGIT ZERO (0) character and that are separated by a single U+0078 LATIN SMALL LETTER X or U+0058 LATIN CAPITAL LETTER X character. The keywords represent icon sizes in raw pixels (as opposed to CSS pixels). When multiple image objects are available, a user agent MAY use the value to decide which icon is most suitable for a display context (and ignore any that are inappropriate).

The steps for processing a sizes member of an image are given by the following algorithm. The algorithm takes an image object image. This algorithm will return a set.

1. Let sizes be an empty set.
2. Let value be the result of calling the [[\GetOwnProperty]] internal method of image passing " sizes" as the argument.
3. Let type be Type(value).
4. If type is not "string", then:
   1. If type is not "undefined", issue a developer warning that the type is unsupported.
   2. Return undefined.
5. Otherwise, parse value as if it was a [[!HTML]] sizes attribute and let keywords be the result.
6. For each keyword in keywords:
   1. Convert keyword to ASCII lowercase and add the resulting string to sizes.
7. Return sizes.

src member

The src member of an image object is a URL from which a user agent can fetch the image's data.

The steps for processing the src member of an image are given by the following algorithm. The algorithm takes a image object icon, and a URL manifest URL , which is the URL from which the manifest was fetched. This algorithm will return a URL or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of image passing " src" as the argument.
2. Let type be Type(value).
3. If type is not "string", then:
   1. If type is not "undefined", issue a developer warning that the type is unsupported.
   2. Return undefined.
4. If Trim(value) is the empty string, then return undefined.
5. Otherwise, parse value using manifest URL as the base URL and return the result.

type member

The type member of an image object is a hint as to the media type of the image. The purpose of this member is to allow a user agent to ignore images of media types it does not support.

There is no default MIME type for image objects. However, for the purposes of determining the type of the resource, user agents must expect the resource to be an image.

The steps for processing the type member of an image are given by the following algorithm. The algorithm takes an image object as an argument, and returns either a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of potential image passing "type" as the argument.
2. Let type be Type(value).
3. If type is not "string", then:
   1. If type is not "undefined", issue a developer warning that the type is unsupported.
   2. Return undefined.
4. Trim(value) and set value to be resulting string.
5. If value is not a valid MIME type or the value of type is not a supported media format, issue a developer warning and return undefined.
6. Return value.

Processing an array of images

The steps for processing an array of images are given by the following algorithm. The algorithm takes a manifest, a URL manifest URL, which is the URL from which the manifest was fetched, and a string that represents the member name of the member which contains the array of image objects. This algorithm returns a list of image objects, which can be empty.

1. Let images be an empty list.
2. Let unprocessed images be the result of calling the [[\GetOwnProperty]] internal method of manifest with member name as the argument.
3. If unprocessed images is an array, then:
   1. From unprocessed images, filter out any item where HasOwnProperty(item,"src") returns false.
   2. For each potential image in the array:
      1. Let src be the result of running the steps for processing the src member of an image with potential image and manifest URL.
      2. If src is undefined, move onto the next item in images (if any are left).
      3. Otherwise, let image be an object with properties src, type, sizes, and density. All properties initially set to undefined.
      4. Set image's src property to be src.
      5. Let type be the result of running the steps for processing the type member of an image passing potential image.
      6. If type is not undefined, set image's type property to be type.
      7. Let sizes be the list that result from running the steps for processing a sizes member of an image passing potential image.
      8. If sizes is not undefined, set image's sizes property to be sizes.
      9. Let density be the result from running the steps for processing a density member of an image are given by the passing potential image .
      10. If density is not undefined, set image's density property to be value.
      11. Append image to images.
4. Otherwise, if unprocessed images is not undefined:
   1. Issue a developer warning that the type is not supported.
5. Return images.

platform member

The platform member of an application object represents the platform on which the application can be found.

The steps for processing the platform member of an application are given by the following algorithm. The algorithm takes an application object application. This algorithm will return a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of application passing "platform" as the argument.
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Otherwise, Trim(value) and return the result.

url member

The url member of an application object represents the URL at which the application can be found.

The steps for processing the url member of an application are given by the following algorithm. The algorithm takes an application object application. This algorithm will return an URL or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of application passing "url" as the argument.
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Trim(value) and set value to be resulting string.
4. Otherwise, parse value and if the result is not failure, return the result, otherwise return undefined.

id member

The id member of an application object represents the id which is used to represent the application on the platform.

The steps for processing the id member of an application are given by the following algorithm. The algorithm takes an application object application. This algorithm will return a string or undefined.

1. Let value be the result of calling the [[\GetOwnProperty]] internal method of application passing "id" as the argument.
2. If Type(value) is not "string":
   1. If Type(value) is not "undefined", optionally issue a developer warning that the type is not supported.
   2. Return undefined.
3. Otherwise, Trim(value) and return the result.

Media type registration

This section contains the required text for MIME media type registration with IANA.

The media type for a manifest is application/manifest+json.

If the protocol over which the manifest is transferred supports the [[!MIME-TYPES]] specification (e.g. HTTP), it is RECOMMENDED that the manifest be labeled with the media type for a manifest.

Type name:

application

Subtype name:

manifest+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

Same as for application/json

Security and privacy considerations:

This specification does not directly deal with high-value data. However, installed web applications and their data could be seen as "high value" (particularly from a privacy perspective).

As the manifest format is JSON and will commonly be encoded using [[!UNICODE]], the security considerations described in [[!ECMA-404]] and [[!UNICODE-SECURITY]] apply. In addition, because there is no way to prevent developers from including custom/unrestrained data in a manifest, implementors need to impose their own implementation-specific limits on the values of otherwise unconstrained member types, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

Web applications will generally contain ECMAScript, HTML, CSS files, and other media, which are executed in a sand-boxed environment. As such, implementors need to be aware of the security implications for the types they support. Specifically, implementors need to consider the security implications outlined in at least the following specifications: [[!CSS-MIME]], [[!ECMAScript-MIME]], [[!HTML]].

As web applications can contain content that is able to simultaneously interact with the local device and a remote host, implementors need to consider the privacy implications resulting from exposing private information to a remote host. Mitigation and in-depth defensive measures are an implementation responsibility and not prescribed by this specification. However, in designing these measures, implementors are advised to enable user awareness of information sharing, and to provide easy access to interfaces that enable revocation of permissions.

As this specification allows for the declaration of URLs within certain members of a manifest, implementors need to consider the security considerations discussed in the [[!WHATWG-URL]] specification. Implementations intending to display IRIs and IDNA addresses found in the manifest are strongly encouraged to follow the security advice given in [[!UNICODE-SECURITY]].

Developers need to be aware of the security considerations discussed throughout the [[!CSP3]] specification, particularly in relation to making data: a valid source for the purpose of inlining a manifest. Doing so can enable XSS attacks by allowing a manifest to be included directly in the document itself; this is best avoided completely.

Applications that use this media type:

Web browsers

Additional information:

Magic number(s):

N/A

File extension(s):

.webmanifest

Macintosh file type code(s):

TEXT

Person & email address to contact for further information:

The Web Platform Working Group can be contacted at public-webapps@w3.org.

Intended usage:

COMMON

Restrictions on usage:

none

Author:

W3C's Web Platform Working Group.

Change controller:

W3C.

Link relation type registration

A request to register the manifest link relation type been submitted to IANA.

Relation Name:

manifest

Description:

Links to a manifest. A manifest provides developers with a centralized place to put metadata associated with a web application.

Reference:

http://www.w3.org/TR/appmanifest/

Notes:

Please refer to the steps for obtaining a manifest for details about how to fetch and apply a manifest.