Web App Manifest

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

2.2 Application's name

The application's name is derived from either the name member or short_name member (if either is present) - otherwise, it is generated by the user agent or provided by the end-user.

When either member is missing from the manifest, a user agent MAY use the name member as a fallback for the short_name member or vice versa.

If the name and short_name members are undefined, the user agent SHOULD assign a default name (e.g., "Untitled") that follows platform conventions. Alternatively, a user agent MAY allow the end-user to input some text that can serve as the application's name.

When both the name and short_name members are present, it is left up to implementations to decide which member is best suited for the space available (e.g., the short_name member might be better suited for the space available underneath an icon).

2.3 Privacy and security considerations

It is RECOMMENDED that UI that affords the end user the ability to install a web application also allows inspecting the icon, name, start URL, origin, etc. pertaining to a web application. This is to give an end-user an opportunity to make a conscious decision to approve, and possibly modify, the information pertaining to the web application before installing it. This also gives the end-user an opportunity to discern if the web application is spoofing another web application, by, for example, using an unexpected icon or name.

It is RECOMMENDED that user agents prevent other applications from determining which applications are installed on the system (e.g., via a timing attack on the user agent's cache). This could be done by, for example, invalidating from the user agent's cache the resources linked to from the manifest (for example, icons) after a web application is installed - or by using an entirely different cache from that used for regular web browsing.

2.5 Uninstallation

User agents SHOULD provide a mechanism for the user to remove an installed web application application.

It is RECOMMENDED that at the time of removal, the user agent also present the user with an opportunity to revoke other persistent data and settings associated with the application, such as permissions and persistent storage.

3.2 Deep links

A deep link is a URL that is within scope of an installed web application's processed manifest.

An application context can be instantiated through a deep link, in which case, the manifest is applied and the deep link is loaded within the context of a web application.

4.1 Privacy and security considerations

When the web application is running, it is RECOMMENDED that the user agent provides the end-user a means to access common information about the web application, such as the origin, start and/or current URL, granted permissions, and associated icon. How such information is exposed to end-users is left up to implementers.

Additionally, when applying a manifest that sets the display mode to anything except "browser", it is RECOMMENDED that the user agent clearly indicate to the end-user that their are leaving the normal browsing context of a web browser. Ideally, launching or switching to a web application is performed in a manner that is consistent with launching or switching to other applications in the host platform. For example, a long and obvious animated transition, or speaking the text "Launching application X".

4.2 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:fullscreen {
    ...
}

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 */
}

5.1 Linking to a manifest

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

The application manifest MIME type serves as the default MIME type for resources associated with the "manifest" link type.

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.

6.1 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 aborts 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 origin be the Document's origin, and manifest link be the first link element in tree order whose rel attribute contains the token manifest.
2. If origin is an opaque origin, then abort these steps.
3. If manifest link is null, then abort these steps.
4. If manifest link's href attribute's value is the empty string, then abort these steps.
5. Let manifest URL be the result of parsing the value of the href attribute, relative to the document base URL. If parsing fails, then abort these steps.
6. Let request be a new Request.
7. Set request's URL to manifest URL.
8. Set request's initiator to "manifest".
9. Set request's destination to "manifest".
10. If the manifest link's crossOrigin attribute's value is "use-credentials", then set request's credentials mode to "include". Otherwise, set request's credentials mode to "omit".
11. Set request's mode to "cors".
12. Await the result of performing a fetch with request, letting response be the result.
13. If response is a network error, then abort these steps.
14. Let text be UTF-8 decode response's body.
15. Let manifest be the result of running processing a manifest given text, manifest URL, and the URL that represents the address of the top-level browsing context.
16. Return manifest and manifest URL.

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

6.2 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. They SHOULD NOT modify the existing values already in the manifest object.

The steps for processing a manifest are given by the following algorithm. The algorithm takes a string text 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 json be the result of parse JSON from bytes text. If parsing throws an error:
   1. Issue a developer warning with any details pertaining to the JSON parsing error.
   2. Set json to an empty object (i.e., equivalent of JSON parsing the string "{}").
2. If Type(json) is not Object:
   1. Issue a developer warning that the manifest needs to be an object.
   2. Set json to an empty object (i.e., equivalent of JSON parsing the string "{}").
3. Let manifest be the result of converting json to a WebAppManifest dictionary.
4. Set manifest["start_url"] to the result of running processing the start_url member given manifest["start_url"], manifest URL, and document URL.
5. Set manifest["lang"] to the result of running processing the lang member given manifest["lang"].
6. Set manifest["scope"] to the result of running processing the scope member given manifest["scope"], manifest URL, and manifest["start_url"].
7. Set manifest["theme_color"] to the result of running processing a color member given manifest["theme_color"].
8. Set manifest["background_color"] to the result of running processing a color member given manifest["background_color"].
9. Set manifest["categories"] to the result of running processing the categories member given manifest["categories"].
10. Set manifest["icons"] to the result of running processing ManifestImageResource members given manifest["icons"] and manifest URL.
11. Set manifest["screenshots"] to the result of running processing ManifestImageResource members given manifest["screenshots"] and manifest URL.
12. Set manifest["related_applications"] to the result of running processing the related_applications member given manifest["related_applications"].
13. Set manifest["shortcuts"] to the result of running processing the shortcuts member given manifest["shortcuts"] and manifest URL.
14. Extension point: process any proprietary and/or other supported members at this point in the algorithm.
15. Return manifest.

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

6.4 Updating the manifest

8.1 dir member

WebIDLenum TextDirectionType { "ltr", "rtl", "auto" };

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

The localizable members are:

• description member.
• name member.
• short_name member.
• ShortcutItem's name member.
• ShortcutItem's short_name member.
• ShortcutItem's description member.

The text-direction values defined by TextDirectionType, are the following, implying that the value of the localizable members is by default:

ltr

Left-to-right text.

rtl

Right-to-left text.

auto

No explicit directionality.

When displaying the localizable members to an end-user, if the base direction is ltr or rtl:

1. If the member is being displayed in a paragraph by itself, the user agent MUST override Rule P3 of [BIDI], setting the paragraph embedding level to 0 if the base direction is ltr, or 1 if the base direction is rtl.
2. Otherwise, the user agent MUST behave as if the member is in a left-to-right embedding [BIDI] if the base direction is ltr, or a right-to-left embedding if the base direction is rtl.

8.2 lang member

The lang member is a language tag (string) that specifies the primary language for the values of the manifest's localizable members (as knowing the language can also help with directionality).

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). 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 WebAppManifest manifest as an argument. This algorithm returns a DOMString?.

1. Let value be manifest["lang"].
2. If Type(value) is String:
   1. If calling IsStructurallyValidLanguageTag with value as the argument returns false, then:
      1. Issue a developer warning that the value is invalid.
      2. Return undefined.
   2. Otherwise, return the result of calling the CanonicalizeUnicodeLocaleId abstract operation, passing V as the argument.
3. Return undefined

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

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

8.5 description member

The description member allows the developer to describe the purpose of the web application.

8.6 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 USVString value, a URL manifest URL, and a URL start URL. This algorithm returns a URL.

1. Let default be the result of parsing ".", using start URL as the base URL.
2. If value is the empty string, then return default.
3. Let scope URL be the result of parsing value, using manifest URL as the base URL.
4. If scope URL is failure:
   • Issue a developer warning.
   • Return default.
5. 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 scope URL.
   2. Return default.
6. Otherwise, return scope URL.

8.7 icons member

The icons member are images that 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.

If there are multiple equally appropriate images 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 ManifestImageResource'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": "257x257"
    }]
}

8.8 display member

WebIDLenum DisplayModeType {
  "fullscreen",
  "standalone",
  "minimal-ui",
  "browser"
};

The display member is a DisplayModeType, whose value is one of display modes values. The item represents the developer's preferred display mode for the web application.

8.9 orientation member

The orientation member is a string that serves as the default screen 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 screen orientation, then that serves as the default screen 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 screen 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 screen orientation of an application while in browser display mode.

8.10 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 USVString value, a URL manifest URL, and a URL document URL. This algorithm returns a URL.

1. If value is the empty string, return document URL.
2. Let start URL be the result of parsing value, using manifest URL as the base URL.
3. If start URL is failure:
   • Issue a developer warning.
   • Return document URL.
4. If start URL is not same origin as document URL:
   1. Issue a developer warning that the start_url needs to be same origin as the Document of the top-level browsing context.
   2. Return document URL.
5. Otherwise, return start URL.

8.11 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 user agent MAY ignore the theme color's alpha component based on the context. For example, in most environments, the theme color cannot be transparent.

8.12 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 sequence<ExternalApplicationResource> related applications as an argument. This algorithm returns an sequence<ExternalApplicationResource>.

1. Let relatedApplications be a new Array object created as if by the expression [].
2. For each app of related applications:
   1. if neither app["src"] nor app["url"] are undefined:
      1. Set app["url"] to the result of running processing the url member of an application given app["url"].
      2. append app to relatedApplications
3. Return relatedApplications.

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

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

8.15 categories member

The categories member describes the expected application categories to which the web application belongs.

The categories member is only meant as a hint to catalogs or stores listing web applications and it is expected that these will make a best effort to find appropriate categories (or category) under which to list the web application. Like search engines and meta keywords, catalogs and stores are not required to honor this hint.

The steps for processing the categories member are given by the following algorithm. The algorithm takes a sequence<USVString> categories as an argument. This algorithm returns an Array<USVString>.

1. For each category of categories:
   1. Replace category within categories with category, ascii lowercased.
2. Return categories.

The categories string array is case insensitive and converted to lower-case by following the processing algorithm. Thus, sports, Sports, SPORTS, and SpOrTs are all equivalent.

8.16 screenshots member

The screenshots member is an array of ManifestImageResources, representing the web application in common usage scenarios.

8.17 iarc_rating_id member

The iarc_rating_id member is a string that represents the International Age Rating Coalition (IARC) certification code of the web application. It is intended to be used to determine which ages the web application is appropriate for.

{
  "name": "Donate App",
  "description": "This app helps you donate to worthy causes.",
  "iarc_rating_id": "e84b072d-71b3-4d3e-86ae-31a8ce4e53b7",
  "icons": [{
    "src": "images/icon.png",
    "sizes": "192x192"
  }]
}

More information on the IARC can be found at: How IARC Works and How developers can get their games and apps rated with IARC.

8.18 shortcuts member

The shortcuts member is an array of ShortcutItems that provide access to key tasks within a web application.

How shortcuts are presented, and how many of them are shown to the user, is at the discretion of the user agent and/or operating system.

The steps for processing the shortcuts member are given by the following algorithm. The algorithm takes a sequence<ShortcutItem> shortcuts and a URL manifest URL. This algorithm returns a sequence<ShortcutItem>.

1. Let processedShortcuts be a new Array object created as if by the expression [].
2. For each shortcut (ShortcutItem) in the sequence:
   1. If shortcut["name"] or shortcut["url"] are undefined, or if shortcut["name"] is the empty string, issue a developer warning and continue.
   2. Set shortcut["icons"] to the result of running processing ManifestImageResource members given shortcut["icons"] and manifest URL.
   3. Set shortcut["url"] to the result of parsing shortcut["url"] using manifest URL as the base URL. If the result is failure, issue a developer warning and continue.
   4. If shortcut["url"] is not within scope of manifest URL, issue a developer warning and continue.
   5. Append shortcut to processedShortcuts.
3. Return processedShortcuts.

A user agent SHOULD expose shortcuts via interactions that are consistent with exposure of an application icon's context menu in the host operating system (e.g., right click, long press). A user agent SHOULD render the shortcuts in the same order as they are provided in the manifest. A user agent SHOULD represent the shortcuts in a manner consistent with exposure of an application icon's context menu in the host operating system. A user agent MAY truncate the list of shortcuts presented in order to remain consistent with the conventions or limitations of the host operating system.

{
  "shortcuts": [
    {
      "name": "Play Later",
      "description": "View the list of podcasts you saved for later",
      "url": "/play-later",
      "icons": [
        {
          "src": "/icons/play-later.svg",
          "type": "image/svg+xml",
          "purpose": "any"
        }
      ]
    },
    {
      "name": "Subscriptions",
      "description": "View the list of podcasts you listen to",
      "url": "/subscriptions?sort=desc"
    }
  ]
}

9.1 Content security policy of image resources

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": "https://boo",
  "icons": [
    {
      "src": "//icons.example.com/lowres"
    },
    {
      "src": "//other.com/hi-res"
    }
  ]
}

9.2 platform member

The platform member represents the platform to which a containing object applies.

9.3 purpose member

The purpose member is an unordered set of unique space-separated tokens that are ASCII case-insensitive. The allowed values are the icon purposes.

When a ManifestImageResource is used as an icon, a developer can hint that the image is intended to serve some special purpose in the context of the host OS (i.e., for better integration). User agents SHOULD NOT use an icon other than for its stated icon purpose.

The icon purposes are as follows:

monochrome:

A user agent can present this icon where a monochrome icon with a solid fill is needed. The color information in the icon is discarded and only the alpha data is used. The icon can then be used by the user agent like a mask over any solid fill.

maskable:

The image is designed with icon masks and safe zone in mind, such that any part of the image that is outside the safe zone can safely be ignored and masked away by the user agent.

any:

The user agent is free to display the icon in any context.

The steps for processing the purpose member of an image are given by the following algorithm. The algorithm takes a ManifestImageResource image. This algorithm returns a set or failure.

1. If Type(image["purpose"]) is not String, or image["purpose"] consists solely of ascii whitespace, then return the set « "any" ».
2. Let keywords be the result of split on ASCII whitespace image["purpose"].
3. If keywords is empty, then return the set « "any" ».
4. Let purposes be the empty set.
5. For each keyword of keywords:
   1. Set canonicalKeyword to ascii lowercased keyword.
   2. If canonicalKeyword is not one of the icon purposes, or purposes contains keyword, then issue a developer warning and continue.
   3. Otherwise, append canonicalKeyword to purposes.
6. If purposes is empty, then return failure.
7. Return purposes.

9.4 Icon masks and safe zone

Some platforms have their own preferred icon shape, but as web applications should work across multiple platforms, it is possible to indicate that an icon can have a user-agent-specified mask applied by adding the maskable purpose. This allows the platform to ensure that the icon looks well integrated with the platform, and even apply different masks and background colors in different places throughout the platform.

The safe zone is the area within a maskable icon which is guaranteed to always be visible, regardless of user agent preferences. It is defined as a circle with center point in the center of the icon and with a radius of 2/5 (40%) of the icon size, which means the smaller of the icon width and height, in case the icon is not square.

All pixels in this zone are guaranteed to be seen in all masks. Pixels outside the safe zone are not guaranteed to (but can) be visible depending on the applied mask.

The user agent MAY apply a mask of any size, making any pixels that are more than 2/5ths of the image size (minimum of width and height if non-square) away from the center (the safe zone) transparent.

The user agent MUST NOT make any pixel within the safe zone transparent.

The user agent MAY enlarge the icon by adding additional padding.

If the icon contains transparent pixels, the user agent MUST composite the icon onto a solid fill (e.g., white) of the user agent's choice.

9.4.1 Examples of masks

Note

By staying inside the safe zone, most icons will have around 10% padding on the top, bottom, right and left with no content or non-essential content, such as an icon background. It is suggested that developers check their icon when all but the safe zone is masked out.

Icons with "maskable" purpose

Mask examples

9.5 Monochrome icons and solid fills

Some platforms enforce that icons be displayed with a solid fill such as a single color, where only the transparency of the icon can be declared in a manifest. As web applications need to work across multiple platforms, it is possible to indicate that an icon can have an user-agent-specified color applied by adding the monochrome purpose. This allows the platform to ensure that the icon looks well integrated with the platform, and even apply different colors and padding in different places throughout the platform.

When processing a monochrome icon, the user agent MUST NOT independently display the red component, green component, or blue component of a pixel. The user agent SHOULD display each pixel with its original alpha value, but with a red, green, and blue value of the user agent's choosing. It is RECOMMENDED that the user agent use the same color value for all pixels.

The user agent MAY enlarge the icon by adding additional padding.

The user agent MAY add a background of any color behind transparent pixels, and SHOULD ensure that the background has sufficient contrast with the icon.

9.5.1 Example usage of monochrome icons

Usage examples

9.6 processing image resources

The steps for processing ManifestImageResource members are given by the following algorithm. The algorithm takes an a list of entries and a URL manifestURL. This algorithm returns an a list of ManifestImageResources.

1. Let imageResources be a new list.
2. For each entry of entries:
   1. Let image be the result of running process an image resource from JSON given entry and manifest URL.
   2. If image is failure, continue.
   3. Let purpose be the result of running processing the purpose member of an image given entry.
   4. If purpose is failure, continue.
   5. Set image's purpose to purpose.
   6. Set image's platform to the value of entry's platform member.
   7. Append image to imageResources.
3. Return imageResources.

10.1 name member

The name member of a ShortcutItem is a string that represents the name of the shortcut as it is usually displayed to the user in a context menu.

10.2 short_name member

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

10.3 description member

The description member of a ShortcutItem is a string that allows the developer to describe the purpose of the shortcut. User agents MAY expose this information to assistive technology.

10.4 url member

The url member of a ShortcutItem is a URL within scope of a processed manifest that opens when the associated shortcut is activated.

10.5 icons member

The icons member of an ShortcutItem member serve as iconic representations of the shortcut in various contexts.

10.6 Launching a shortcut

When ShortcutItem shortcut having WebAppManifest manifest is invoked, run the following steps:

1. Let url be shortcut.url.
2. Let browsing context be the result of creating a new top-level browsing context.
3. Navigate browsing context to url.

11.1 platform member

The platform member represents the platform to which a containing object applies.

The following object types can make use of this member:

• ExternalApplicationResource
• ManifestImageResource

A platform represents a software distribution ecosystem or possibly an operating system.

12.1 url member

The url member of an ExternalApplicationResource dictionary 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 a USVString application URL. This algorithm will return an URL or undefined.

1. If application URL is undefined, return undefined.
2. Otherwise, parse application URL and if the result is not failure, return the result, otherwise return undefined.

12.2 id member

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

12.3 min_version member

The min_version member of an ExternalApplicationResource dictionary represents the minimum version of the application that is considered related to this web app. This version is a string with platform-specific syntax and semantics.

12.4 fingerprints member

WebIDLdictionary Fingerprint {
  USVString type;
  USVString value;
};

The fingerprints member of an ExternalApplicationResource dictionary represents an array of Fingerprints.

Each Fingerprints represents a set of cryptographic fingerprints used for verifying the application. A fingerprint has the following two properties: type and value. Each of these are strings, but their syntax and semantics are platform-defined.

13.1 Media type registration

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

The application manifest MIME type 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 application manifest MIME type.

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 [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 MIME 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 Applications Working Group can be contacted at public-webapps@w3.org.

Intended usage:

COMMON

Restrictions on usage:

none

Author:

W3C's Web Applications Working Group.

Change controller:

W3C.

13.2 Link relation type registration

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:

https://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.