Web App Manifest

2.1 AppBannerPromptOutcome enum

enum AppBannerPromptOutcome {
    "accepted",
    "dismissed"
};

The AppBannerPromptOutcome enum's values represent the outcomes from presenting the end-user with an install prompt.

accepted:

The end-user indicated that they would like the user agent to install the web application.

dismissed:

The end-user dismissed the install prompt.

2.2 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.3 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"). 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.4 Installation process

An installation process is an attempt by the user agent to install a web application. The details of such a process (i.e., the display of an install UI, and any resulting IO operations of the host OS) are left up to implementers. Implementers need to be aware that there are privacy and security considerations that directly relate to the installation process.

For the purpose of this specification, the installation succeeded once the installation process succeeds in installing the web application (e.g., an icon was successfully placed onto the device's homescreen). If the end-user cancels the installation process (even if they manually triggered it, and then changed their minds), then the installation was canceled. Otherwise, the installation failed. Reasons for installation failure can include, for example, the OS denying permission to the user agent to add an icon to the homescreen of the device and the end-user rejecting the installation.

The steps to install the web application are given by the following algorithm:

1. Let window be the Window object of the top-level browsing context for which the user agent will attempt installation.
2. Then, in parallel:
   1. Instantiate an installation process.
   2. Let manifest and manifest URL be the result of obtaining the manifest.
   3. If obtaining the manifest results in an error, a user agent can, at this point, fall back to using the top-level browsing context Document's metadata to populate an installation process's UI.
   4. If obtaining the manifest succeeds, and the result of running processing the serviceworker member with manifest returns a valid registration, a user agent can at this point
      1. Let client be the top-level browsing context Document's relevant settings object, or null if unavailable.
      2. Invoke Start Register with scope and src members of the registration, a new promise, client, manifest URL, plus the type and update_via_cache members of the registration,
      in which case the state of the settled promise determines whether the installation succeeded or not.
   5. If the installation succeeded, queue a task on the application life-cycle task source to fire an event named appinstalled at the window object.

2.5 Install prompts

There are multiple ways that the installation process can be triggered:

• An end-user can manually trigger the installation process through the user agent's UI.
• The installation process can occur through an automated install prompt: that is, a UI that the user agent presents to the user when, for instance, there are sufficient installability signals to warrant installation of the web application.
• The installation process can occur through a site-triggered install prompt: the site can programmatically request that the user agent present an install prompt to the user. The user agent MAY restrict the availability of this feature to cases where, for instance, there are sufficient installability signals to warrant installation of the web application.

Prior to presenting an automated install prompt, a user agent MUST run the steps to notify that an install prompt is available, to give the site the opportunity to prevent the default action (which is to install the application). Alternatively, the user agent MAY run the steps to notify that an install prompt is available at any time, giving the site the opportunity to show a site-triggered install prompt without automatically showing the prompt.

In either case, when a user agent presents an install prompt, the end-user's choice is represented either "accepted" or "dismissed". These values are represented in the API of this specification via the AppBannerPromptOutcome enum.

The steps to notify that an install prompt is available are given by the following algorithm:

1. Wait until the Document of the top-level browsing context is completely loaded.
2. If there is already an installation process being presented, terminate this algorithm.
3. Queue a task on the application life-cycle task source to do the following:
   1. Let event be a newly constructed BeforeInstallPromptEvent named beforeinstallprompt, with its cancelable attribute initialized to true.
   2. Let mayShowPrompt be the result of firing event at the Window object of the top-level browsing context.
   3. If mayShowPrompt is true, then the user agent MAY, in parallel, request to present an install prompt with event.

2.6 Privacy and security considerations

During the installation process, it is RECOMMENDED that the user agent allow the end-user to inspect 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.8 Uninstallation

User agents SHOULD provide a mechanism for the user to remove the installed 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.1 BeforeInstallPromptEvent Interface

[Constructor,
 Exposed=Window]
interface BeforeInstallPromptEvent : Event {
    Promise<PromptResponseObject> prompt();
};

dictionary PromptResponseObject {
    AppBannerPromptOutcome userChoice;
};

The BeforeInstallPromptEvent is dispatched when the site is allowed to present a site-triggered install prompt, or prior to the user agent presenting an automated install prompt. It allows the site to cancel the automated install prompt, as well as manually present the site-triggered install prompt.

The PromptResponseObject contains the result of calling prompt(). It contains one member, userChoice, which states the user's chosen outcome.

An instance of a BeforeInstallPromptEvent has the following internal slots:

[[didPrompt]]

A boolean, initially false. Represents whether this event was used to present an install prompt to the end-user.

[[userResponsePromise]]

A promise that represents the outcome of presenting an install prompt.

window.addEventListener("beforeinstallprompt", event => {
  // Suppress automatic prompting.
  event.preventDefault();

  // Show the (disabled-by-default) install button. This button
  // resolves the installButtonClicked promise when clicked.
  installButton.disabled = false;

  // Wait for the user to click the button.
  installButton.addEventListener("click", async e => {
    // The prompt() method can only be used once.
    installButton.disabled = true;

    // Show the prompt.
    const { userChoice } = await event.prompt();
    console.info(`user choice was: ${userChoice}`);
  });
});

3.2 Extensions to the Window object

The following extensions to the Window object specify the event handler attributes on which events relating to the installation of a web application are fired.

partial interface Window {
    attribute EventHandler onappinstalled;
    attribute EventHandler onbeforeinstallprompt;
};

function handleInstalled(ev) {
  const date = new Date(ev.timeStamp / 1000);
  console.log(`Yay! Our app got installed at ${date.toTimeString()}.`);
}

// Using the event handler IDL attribute
window.onappinstalled = handleInstalled;

// Using .addEventListener()
window.addEventListener("appinstalled", handleInstalled);

4.1 Security considerations

It should not be 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.

4.2 Deep links

A deep link is a URL that is within scope of the navigation scope of an installed web application's 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.

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

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

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

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.

7.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 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 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 [HTML] opaque origin, terminate this algorithm.
3. If manifest link is null, terminate this algorithm.
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 element's base URL. If parsing fails, then abort these steps.
6. Let request be a new [FETCH] request, whose URL is manifest URL, and whose context is "manifest".
7. If the manifest link's crossOrigin attribute's value is 'use-credentials', then set request's credentials to 'include'.
8. Await the result of performing a fetch with request, letting response be the result.
9. If response is a network error, terminate this algorithm.
10. Let text be the result of UTF-8 decoding response's body.
11. 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.
12. Return manifest and manifest URL.

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

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

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

7.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 parsing text. If parsing throws an error:
   1. Issue a developer warning with any details pertaining to the JSON parsing error.
   2. Set json to be the result of 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 be the result of 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, document URL, and manifest["start_url"].
7. Set manifest["theme_color"] to the result of running processing the theme_color member given manifest["theme_color"].
8. Set manifest["background_color"] to the result of running processing the background_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 ImageResource members given manifest["icons"], manifest URL, and "icons".
11. Set manifest["screenshots"] to the result of running processing ImageResource members given manifest["screenshots"], manifest URL, and "screenshots".
12. Set manifest["related_applications"] to the result of running processing the related_applications member given manifest["related_applications"].
13. Set manifest["serviceworker"] to the result of running processing the serviceworker member given manifest["serviceworker"], manifest URL, and serviceworker.
14. Extension point: process any proprietary and/or other supported members at this point in the algorithm.
15. Return manifest.

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

7.4 Updating the manifest

8.1 dir member

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

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:

• description member.
• name member.
• short_name member.

The text-direction values defined by TextDirectionType, 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".

8.2 lang member

The lang member is a language tag (string) that specifies the primary language for the values of the manifest's directionality-capable 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 CanonicalizeLanguageTag 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, a URL document 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 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 default.
6. 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.
7. Otherwise, return scope URL.

8.7 icons member

The icons member is an array of ImageResources 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.

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 ImageResource'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

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

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 Document of the top-level browsing context.
   2. Return document URL.
5. Otherwise, return start URL.

8.11 serviceworker member

The serviceworker member describes a service worker as defined in [SERVICE-WORKERS-1].

The serviceworker member represents an intented service worker registration in form of a registration object

The steps for processing the serviceworker member are given by the following algorithm. The algorithm takes a ServiceWorkerRegistrationObject registration. This algorithm returns a ServiceWorkerRegistrationObject registration, which can be undefined.

1. If registration is undefined, return undefined.
2. Set registration["src"] to the result of running processing the src member of a service worker given registration["src"] and manifest URL.
3. If the result of running is origin potentially trustworthy with the origin of registration["src"] is Not Trusted, issue a developer warning, abort these steps and return undefined.
4. Set registration["scope"] to the result of running processing the scope member of a service worker given registration["scope"].
5. Return registration.

"serviceworker": {
  "src": "sw.js",
  "scope": "/foo",
  "update_via_cache": "none"
}

8.12 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 USVString theme color as an argument. This algorithm returns a USVString?.

1. Let potential color be the result of running [CSS-SYNTAX-3]'s parse a component value algorithm with theme color as input. If parsing returns a syntax error, return undefined.
2. 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.
3. Return color.

8.13 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.14 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.15 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 USVString background color as an argument. This algorithm returns a USVString?.

1. Let potential color be the result of running [CSS-SYNTAX-3]'s parse a component value algorithm with background color as input. If parsing returns a syntax error, return undefined.
2. 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.
3. Return color.

8.16 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, 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.17 screenshots member

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

8.18 iarc_rating_id member

The iarc_rating_id member is a string that represents an ID value of the IARC rating 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 International Age Rating Coalition (IARC) can be found at: How IARC Works and How developers can get their games and apps rated with IARC.

9.1 Fetching image resources

To fetch the image associated with an ImageResource, the user agent MUST run the steps to fetch an image resource. The algorithm takes an image URL (ImageResource.src), the manifest URL, and the document (Document) from which the manifest was linked. It returns a Response:

1. Let request be a new Request.
2. Set the following properties of request:
   1. url is set to image URL.
   2. initiator is "manifest".
   3. type is "image".
   4. cors is "no-cors".
   5. referrer is manifest URL.
   6. client is document.
3. Perform a fetch using request and return the response.

9.2 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.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 an ImageResource 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).

For example, as a badge or "pinned" icon that is visually distinct, in color or form, from an application's launch icon. The user agent uses the value of the purpose member as a hint to determine where and how an ImageResource is displayed. Unless declared otherwise by the developer, a user agent can use an icon for any purpose.

The icon purposes are as follows:

badge:

A user agent can present this icon where space constraints and/or color requirements differ from those of the application icon.

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 an ImageResource image. This algorithm will return a set.

1. Let set be an empty set.
2. Let value be image["purpose"].
3. If Type(value) is String:
   1. Let list keywords be the result of splitting value on spaces.
   2. For each keyword of keywords:
      1. Set keyword to keyword, lowercased.
      2. If keyword is not one of the icon purposes, or set contains keyword, then issue a developer warning and continue.
      3. Otherwise, append keyword to set.
4. If set is empty, then append "any" to set.
5. Return set.

{
  "name": "News",
  "icons": [{
    "platform": "android",
    "purpose": "badge",
    "sizes": "16x16",
    "src": "icons/badges/android.png",
    "type": "image/png"
  }, {
    "purpose": "badge",
    "src": "icons/badges/safari.svg",
    "type": "image/svg"
  }]
}

9.4 sizes member

The sizes member of an ImageResource 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 ImageResources 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 the sizes member of an image are given by the following algorithm. The algorithm takes an ImageResource image. This algorithm will return a set.

1. Let set be an empty set.
2. Let value be image.sizes.
3. If Type(value) it not String, return undefined.
4. Otherwise, parse value as if it was a [HTML] sizes attribute and let list keywords be the result.
5. For each keyword of keywords:
   1. Append keyword, lowercased, to set.
6. Return set.

9.5 src member

The src member of an ImageResource 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 ImageResource 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 image["src"].
2. If Type(value) it not String, return undefined.
3. Otherwise, parse value using manifest URL as the base URL and return the result.

9.6 type member

The type member of an ImageResource 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 resources. 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 image["type"].
2. If Type(value) it not String, return undefined.
3. 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.
4. Return value.

9.7 platform member

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

9.8 processing an array of image resources

The steps for processing ImageResource members 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 ImageResources. This algorithm returns an Array<ImageResource>

1. Let imageResources be a new Array object created as if by the expression [].
2. For each entry of manifest[member name]:
3. 1. If entry["src"] is not undefined:
      1. Let image be a new object created as if by the expression ({}).
      2. Set image["src"] to the result of running processing the src member of an image given entry and manifest URL.
      3. Set image["type"] to the result of running processing the type member of an image given entry and manifest URL.
      4. Set image["sizes"] to the result of running processing the sizes member of an image given entry and manifest URL.
      5. Set image["purpose"] to the result of running processing the purpose member of an image given entry and manifest URL.
      6. Append image to imageResources
4. Return imageResources.

10.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
• ImageResource

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

11.1 src member

The src member of a ServiceWorkerRegistrationObject dictionary is a URL representing a service worker.

The steps for processing the src member of a service worker are given by the following algorithm. The algorithm takes a USVString source URL, and a URL manifest URL, which is the URL from which the manifest was fetched. This algorithm will return a URL or undefined.

1. If Type(source URL) is not String or source URL is the empty string, then return undefined.
2. Otherwise, parse source URL using manifest URL as the base URL and return the result.

11.2 scope member

The scope member of a ServiceWorkerRegistrationObject dictionary is the service worker's associated scope URL.

The steps for processing the scope member of a service worker are given by the following algorithm. The algorithm takes a USVString scope URL, and a URL manifest URL, which is the URL from which the manifest was fetched. This algorithm will return a URL or undefined.

1. If scope URL is undefined, return undefined
2. Otherwise, parse scope URL using manifest URL as the base URL and return the result.

11.3 type member

The type member of a ServiceWorkerRegistrationObject dictionary is the service worker's worker type. The possible values are those of the WorkerType enum defined in [HTML].

11.4 update_via_cache member

The update_via_cache member of a ServiceWorkerRegistrationObject dictionary determines the update via cache mode for the service worker. The possible values are those of the ServiceWorkerUpdateViaCache enum defined in [SERVICE-WORKERS-1].

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

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

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.