ウェブアプリケーションマニフェスト

W3C作業草案

このドキュメントの詳細情報
このバージョン：
https://www.w3.org/TR/2026/WD-appmanifest-20260813/
最新公開バージョン：
https://www.w3.org/TR/appmanifest/
最新エディタドラフト：
https://w3c.github.io/manifest/
履歴：
https://www.w3.org/standards/history/appmanifest/
コミット履歴
編集者：
Marcos Cáceres (Apple)
Daniel Murphy (Google Inc.)
Christian Liebel (Thinktecture AG)
以前の編集者：
Matt Giuca (Google Inc.) -
Anssi Kostiainen (Intel Corporation) -
Aaron Gustafson (Microsoft Corporation) -
Mounir Lamouri (Google Inc.)
Rob Dolin (Microsoft Corporation)
Kenneth Rohde Christiansen (Intel Corporation) -
Diego González (Microsoft Corporation) -
フィードバック：
GitHub w3c/manifest (プルリクエスト, 新規イシュー, オープンイシュー)
ブラウザサポート：
caniuse.com

Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

この仕様は、開発者がウェブアプリケーションに関連するメタデータを一元的に管理できる、JSONベースのファイル形式を定義します。このメタデータには、ウェブアプリケーションの名前、アイコンへのリンク、ユーザーがウェブアプリケーションを起動した際に開く推奨URLなどが含まれます（これらに限定されません）。マニフェストでは、開発者がウェブアプリケーションのデフォルトの画面の向きを宣言したり、アプリケーションの表示モード（例：フルスクリーン）を設定することも可能です。さらに、マニフェストを使ってウェブアプリケーションを特定のURLに「スコープ」することもできます。これにより、マニフェストが適用されるURLを制限し、他のアプリケーションからウェブアプリケーションへの「ディープリンク」を提供する手段となります。

このメタデータを利用することで、ユーザーエージェントは開発者に、ネイティブアプリケーションに近いユーザー体験を作成する手段を提供できます。

この文書のステータス

このセクションは、本書の公開時点におけるステータスを説明します。現在のW3Cの出版物およびこの技術レポートの最新改訂版は、 W3C標準および草案一覧でご覧いただけます。

警告

この文書はWeb Applications Working Groupによって、 勧告トラックを用いて作業草案として公開されました。

作業草案としての公開は、W3Cおよびそのメンバーによる承認を意味するものではありません。

この文書は草案であり、随時更新、置換、または他の文書によって廃止される可能性があります。進行中の作業以外のものとして引用するのは不適切です。

この文書は W3C特許ポリシーの下で運営されているグループによって作成されました。 W3Cは、 グループの成果物に関連して提出された特許開示の一覧を公開しています。該当ページには特許を開示するための手順も記載されています。特許に関する実際の知識があり、当該特許が 必須クレームを含むと考える場合は、 W3C特許ポリシー第6項に従って情報を開示しなければなりません。

この文書は 2025年8月18日 W3Cプロセス文書に準拠しています。

1. ウェブアプリケーションマニフェスト

アプリケーションマニフェストは、ウェブアプリケーションが起動される際の、起動パラメータやアプリケーションのデフォルト設定を含む [JSON] ドキュメントです。

マニフェストには マニフェストURL が関連付けられており、これは マニフェスト が取得された [URL] です。

マニフェストのルートには、以下のいずれかのメンバーを持つことができ、すべて任意です。メンバーの順序は自由です。

注

1.1 例

このセクションは規範的ではありません。

このセクションでは、開発者が本仕様の様々な機能をどのように活用できるかを示します。

1.1.1 典型的な構造

このセクションは規範的ではありません。

以下は、典型的な マニフェストの例です。

例 1: 典型的なマニフェスト 
{
  "lang": "en",
  "dir": "ltr",
  "name": "Super Racer 3000",
  "short_name": "Racer3K",
  "icons": [{
    "src": "icon/lowres.webp",
    "sizes": "64x64",
    "type": "image/webp"
  }, {
    "src": "icon/lowres.png",
    "sizes": "64x64"
  }, {
    "src": "icon/hd_hi",
    "sizes": "128x128"
  }],
  "scope": "/",
  "id": "superracer",
  "start_url": "/start.html",
  "display": "fullscreen",
  "orientation": "landscape",
  "theme_color": "aliceblue",
  "background_color": "red"
}

1.1.3 複数アイコンの宣言

このセクションは規範的ではありません。

このセクションでは、icons メンバーを使って、ウェブアプリケーションに複数のアイコンを宣言する方法を示します。以下の例では、開発者はウェブアプリケーションに関連付けるアイコンについて以下の選択をしています。

  • 開発者は同じサイズで2種類のアイコンを含めており、一方は type メンバーで明示的にWebPとして指定しています。ユーザーエージェントがWebPをサポートしない場合は、同じサイズの2つ目のアイコンがフォールバックされます。このアイコンのMIMEタイプはHTTPヘッダーで判別するか、アイコンの先頭バイトを受信した時点でユーザーエージェントがスニッフィングできます。
  • 開発者はピクセルベースのアイコン形式（例: PNGファイル）について様々なサイズを指定しています。これらのサイズはユーザーエージェントが特定の文脈（例: デバイスのホーム画面）で適切なアイコンを選択するためのヒントとなります。また、開発者はICOファイル（例: hd_hi.ico）も含めており、これは特定の表示サイズごとに個別に最適化されたラスターアイコンを多数含んでいます。例えば、256x256の画像を16x16の文脈で単純に縮小して使うのは適切ではなく、16x16専用にデザインされた画像を使うことが多いです。さらにSVGアイコンも追加しており、これは任意のアイコンサイズに動的にリサイズできますが、文脈によっては（例: 小さすぎてぼやけるなど）不適切になる場合があります。

アイコンのリストはユーザーエージェントに渡され、ユーザーエージェントが文脈や表示場所ごとに最適なアイコンを選択します。

例 3: 複数アイコン 
{
  "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"
    }]
}

1.1.4 ショートカットの作成

このセクションは規範的ではありません。

以下の例では、開発者は2つのショートカットを追加しています。マニフェストのURLが https://example.com/manifest.webmanifest であると仮定します：

  • 最初のショートカットは「後で再生」というテキストで表示されます。 オペレーティングシステムがコンテキストメニュー項目のアイコンを サポートし、さらにその目的で SVG 画像もサポートしている場合、ユーザー エージェントはテキストの横に https://example.com/icons/play-later.svg を表示します。 起動されると、ユーザーエージェントは新しい トップレベルのトラバーサブルをインスタンス化し、 https://example.com/play-later にナビゲートします。
  • 2 番目のショートカットは 「サブスクリプション」というテキストで表示されます。起動されると、ユーザーエージェントは 新しいトップレベルのトラバーサブルをインスタンス化し、 https://example.com/subscriptions?sort=desc にナビゲートします。
例 4: ショートカット追加 
{
  "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"
        }
      ]
    },
    {
      "name": "Subscriptions",
      "description": "View the list of podcasts you listen to",
      "url": "/subscriptions?sort=desc"
    }
  ]
}

1.1.5 「scope」の理解

このセクションは規範的ではありません。

scope メンバーは、どのドキュメントがウェブアプリケーションの一部か、そうでないかをブラウザに伝えます。つまり、ユーザーがウェブサイトを移動する際に、どのウェブページセットにマニフェストが "適用" されるかを指定します。

例えば、{"scope": "/"} は、マニフェストが同一オリジンの全ドキュメントに適用されることを意味します。一方、{"scope": "/racer/"} は、"/racer/" 以下のパスにあるドキュメントのみにマニフェストが スコープ内 とみなされます。したがって、"/racer/race1.html" や "/racer/race2.html" などはすべて スコープ内 ですが、"/elsewhere/" やルートの "/" は "スコープ外" で、マニフェストはこれらのパスのドキュメントには適用されません。スコープパスは1つのみサポートされます。技術的な詳細は 5. ナビゲーションスコープ を参照してください。

マニフェストの適用 とは、マニフェスト内で指定された表示関連のメンバー（例: display "fullscreen" や特定の画面向きの指定）が有効になることを意味します。アプリケーションが スコープ内 のURLに遷移している限り、ブラウザはマニフェストを適用し続けます。しかし、ウェブアプリケーションが "スコープ外" に遷移すると、マニフェストは適用されなくなり、ブラウザ独自のデフォルト設定が適用されます。例えば、アプリケーションがフルスクリーン表示されなくなり、通常のブラウザタブ上のウェブページとして表示されるようになります。スコープ内外への遷移時の扱いは実装者に委ねられています。技術的な詳細は 1.17.5 マニフェストの適用 を参照してください。

最後に、ユーザーがオリジン内のどのドキュメントからでもウェブアプリケーションをインストールできる可能性があるため、マニフェストには常に scope メンバーを宣言するのが良い慣習です。マニフェストに scope メンバーがない場合、start_url メンバーのパスがフォールバックとして使われます。さらに start_url メンバーもない場合は、ウェブアプリケーションがインストールされたドキュメントURLがスコープとして使われます。予期しないナビゲーション動作を避けるため、著者は常に scope メンバーを（できれば "/" で）含めるべきです。

1.2 dir メンバー

マニフェストの dir メンバーは、ローカライズ可能なメンバーに対するデフォルト 方向を、マニフェストについて指定する。 dir メンバーの値には、 テキスト方向を設定できる。

テキスト方向は次の通りで、ローカライズ可能メンバーの値がデフォルトで以下のようになります：

"ltr"
左から右へのテキスト。
"rtl"
右から左へのテキスト。
"auto"（デフォルト）
テキスト方向が不明。ユーザーエージェントはヒューリスティックを使ってテキスト表示方法を推定します。例えば [UAX9] で説明されている first-strong アルゴリズムなどです。

テキスト方向リストは リスト « "ltr", "rtl", "auto" » です。

dir メンバーの処理は、順序付きマップ json と 順序付きマップ manifest が与えられたとき：

  1. manifest["dir"] に "auto" を設定する。
  2. json["dir"] が 存在しない場合、または json["dir"] が 文字列でない場合は、return する。
  3. 先頭と末尾のASCIIホワイトスペースを除去する。 json["dir"] から。
  4. ASCII小文字化する json["dir"] を。
  5. テキスト方向リストが 含まない json["dir"] の場合、return する。
  6. manifest["dir"] に json["dir"] を設定する。

1.3 lang メンバー

マニフェスト の lang メンバーは、文字列であり、 言語タグの形式で、マニフェストのローカライズ可能メンバーの値の言語を指定します。lang メンバーが指定されていない場合、言語は不明として扱われます。

注

言語を指定することで、ユーザーエージェントは適切な処理やリソース（フォント、スタイリング、ハイフネーション、アクセシビリティのための音声合成など）を選択でき、ユーザー体験が向上します。

言語タグ は 文字列であり、[BCP47] で定義される Language-Tag の生成規則に一致します。

注

言語タグは大文字・小文字を区別しません。例として 'fr'（フランス語）、'en-AU'（オーストラリア英語）、'zh-Hans-CN'（中国で使われる簡体字中国語）などがあります。

lang メンバーの処理は、順序付きマップ json と 順序付きマップ manifest が与えられたとき：

  1. json["lang"] が 存在しない場合、または json["lang"] が 文字列でない場合は、return する。
  2. 先頭と末尾のASCIIホワイトスペースを除去する json["lang"] から。
  3. IsStructurallyValidLanguageTag を json["lang"] に対して呼び出し、false を返した場合は return する。
  4. manifest["lang"] をセットする。値は CanonicalizeUnicodeLocaleId 抽象操作を json["lang"] に対して呼び出した結果。

1.4 name メンバー

マニフェスト の name メンバーは、文字列で、 ウェブアプリケーションの名前を表します。これは通常、ユーザーに表示される（例えば他のアプリ一覧やアイコンのラベルなど）名前です。

name メンバーは ローカライズ可能メンバーです。

name メンバーは、アクセシブルネームとして インストール済みウェブアプリケーションに使われます。

注: `name` メンバーの処理

マニフェスト処理時は、 テキストメンバーの処理アルゴリズムを使って name メンバーを処理します。

1.5 short_name メンバー

マニフェスト の short_name メンバーは、文字列で、 ウェブアプリケーションの短縮名を表します。これは、ウェブアプリケーションの完全な名前を表示するためのスペースが不足している場合に使用されます。

short_name メンバーは ローカライズ可能メンバーです。

注: `short_name` メンバーの処理

マニフェスト処理時は、 テキストメンバーの処理アルゴリズムを使って short_name メンバーを処理します。

1.6 scope メンバー

マニフェスト の scope メンバーは、文字列であり、 このウェブアプリケーションのナビゲーションスコープを表します。 アプリケーションコンテキストの範囲を決定します。

注: デフォルトのスコープ

scope メンバーの処理は、順序付きマップ json と 順序付きマップ manifest が与えられた場合：

  1. manifest["scope"] に . を manifest["start_url"] を基準にパースした結果を設定する。
  2. json["scope"] が空文字列なら return。
  3. scope に json["scope"] を manifest URL を基準にパースした結果を設定する。
  4. scope が失敗なら return。
  5. scope の query と fragment を null に設定する。
  6. manifest["start_url"] が scope内 でなければ return。
  7. それ以外の場合は manifest["scope"] に scope を設定する。

1.7 icons メンバー

マニフェストの icons メンバーは、さまざまなコンテキストにおいてウェブアプリケーションの アイコン表現として機能する画像を指定します。 たとえば、他のアプリケーションの一覧内でウェブアプリケーションを 表すため、またはウェブアプリケーションを OS のタスク スイッチャーやシステム環境設定に統合するために使用できます。

icons メンバーは ローカライズ可能メンバーです。

注

1.8 display メンバー

マニフェスト の display メンバーは、ウェブアプリケーションの表示モードに関する開発者の希望を表します。値は display mode です。 display mode のいずれかを指定できます。

display メンバーの処理は、順序付きマップ json と 順序付きマップ manifest が与えられた場合：

  1. manifest["display"] に "browser" を設定する。
  2. json["display"] が 存在しない場合、または json["display"] が 文字列でない場合、return。
  3. 先頭と末尾のASCIIホワイトスペースを除去する json["display"] から。
  4. ASCII小文字化する json["display"] を。
  5. display modes list が 含まない json["display"] の場合、return。
  6. manifest["display"] に json["display"] を設定する。

1.9 orientation メンバー

マニフェストの orientation メンバーは、ウェブアプリケーションのすべてのトップレベルの トラバーサブルに対するデフォルトの画面の向きとして機能する文字列です。使用可能な値は OrientationLockType 列挙型の値であり、 この仕様では向きの値と呼ばれます （すなわち、"any"、"natural"、"landscape"、"portrait"、"portrait-primary"、 "portrait-secondary"、"landscape-primary"、または "landscape-secondary"）。

ユーザーエージェントが、orientation メンバーの値をデフォルトの画面の向きとしてサポートする場合、その値が ウェブ アプリケーションの存続期間中のデフォルトの画面の向きとして機能します （実行時に他の何らかの手段によって上書きされる場合を除きます）。これは、 画面の向きのロックが解除されたとき [SCREEN-ORIENTATION]、またはトップレベルのトラバーサブルが ナビゲートされたときは常に、ユーザーエージェントが画面の向きを デフォルトの画面の向きに戻さなければならないことを 意味します。

注

この仕様は [SCREEN-ORIENTATION] の OrientationLockType に依存しますが、 ユーザーエージェントが [SCREEN-ORIENTATION] API を実装するのは 任意です。APIのサポートはもちろん推奨されます。

特定の UI/UX 上の考慮事項やプラットフォームの慣例により、 一部の画面の向きは併用できない場合があります。どの向きと 表示モードを併用できないかは、実装者の裁量に委ねられます。 たとえば、一部のユーザーエージェントでは、 browser 表示モードの間に、アプリケーションのデフォルトの画面の向きを変更することは 適切でない場合があります。

注記

ウェブアプリケーションの実行開始後は、他の手段によって トップレベルのトラバーサブルの向きを変更できます（たとえば、 [SCREEN-ORIENTATION] API を介して）。

orientation メンバーの処理は、順序付きマップ json と 順序付きマップ manifest が与えられた場合：

  1. json["orientation"] が存在しない場合、または json["orientation"] が文字列でない場合、 return。
  2. json["orientation"] から先頭と末尾の ASCII 空白を除去する。
  3. json["orientation"] をASCII 小文字化する。
  4. json["orientation"] が含まない場合、いずれの orientation 値も、return。
  5. manifest["orientation"] を json["orientation"] に設定する。

1.10 start_url メンバー

マニフェスト の start_url メンバーは 文字列であり、 開始URL を表します。これは開発者がユーザーエージェントに、ウェブアプリケーションを起動する際（例：端末のアプリメニューやホーム画面からアイコンをクリックした時）に読み込んでほしいと推奨する URL です。

start_url メンバーはあくまで助言であり、ユーザーエージェントは任意で 無視したり、ユーザーが利用しないよう選択できるようにしても構いません。また、ユーザーエージェントは、例えばウェブアプリのブックマーク作成時やそれ以降、エンドユーザーがURLを変更できるようにしても構いません。

start_url メンバーの処理は、順序付きマップ json、順序付きマップ manifest、URL manifest URL、および URL document URL が与えられたとき：

  1. manifest["start_url"] に document URL を設定する。
  2. json["start_url"] が 存在しない場合、 または json["start_url"] が 文字列でない場合は return。
  3. json["start_url"] の型が 文字列でない、 または空文字列の場合は return。
  4. start URL に json["start_url"] を manifest URL を基準にパースした結果を設定する。
  5. start URL が失敗の場合は return。
  6. start URL が document URL と同一オリジンでない場合は return。
  7. それ以外の場合は manifest["start_url"] に start URL を設定する。

1.10.1 プライバシー考慮事項：start_url のトラッキング

start_url を工夫して、アプリケーションがブラウザ外から起動されたことを示すようにすることも考えられます（例："start_url": "index.html?launcher=homescreen"）。これは解析やカスタマイズに役立つ場合があります。しかし、開発者が start_url にユーザーを一意に特定する文字列を含めることも考えられます（例：サーバー割り当てID "?user=123"、"/user/123/"、"https://user123.foo.bar" など）。これはフィンガープリント/プライバシーに関わる情報であり、ユーザーが気づかない場合もあります。

注: 開始URLに識別子を追加しないこと

start URL にユーザーを一意に識別する情報を含めることは悪い慣行です。なぜなら、ユーザーがサイトデータを消去してもフィンガープリントは消去されないためです。ただし、この仕様では開発者がそれを行うことを実際に防ぐことはできません。

上記を踏まえ、インストール時やそれ以降、ユーザーエージェントはユーザーがアプリケーションの start URL を確認・必要に応じて修正できるようにすることが推奨されます。

ユーザーエージェントはこのようなフィンガープリントに対し、他の保護策を提供しても構いません。例えば、ユーザーがオリジンのデータを消去した際、そのオリジンの スコープ内 のアプリケーションのアンインストールを提案し、アプリの開始URLに残るフィンガープリントを除去しても良いでしょう。

1.11 id メンバー

マニフェストの id メンバーは、アプリケーションの アイデンティティを表す文字列である。この アイデンティティは URL の形式を取り、 開始 URLと同一オリジンである。

アイデンティティは、ユーザーエージェントが アプリケーションを普遍的かつ一意に識別するために使用する。ユーザーエージェントが すでにインストールされているアプリケーションに対応しないアイデンティティを持つ マニフェストを検出した場合、別のアプリケーションと同じ URL から 提供されている場合であっても、そのマニフェストを別個のアプリケーションの説明として扱うべきである。 ユーザーエージェントが、manifest["id"] が 等しい（フラグメントを除外を任意で true に設定して）マニフェストを検出した場合、すでにインストールされているアプリケーションのアイデンティティと 一致することを、このマニフェストがすでにインストールされている アプリケーションのマニフェストを置き換えるものであり、別個のアプリケーションではないことを示すシグナルとして使用するべきである。以前に確認したものとは 異なる URL から提供されている場合であっても同様である。

注記: フラグメントを 除外することがベストプラクティスである
注記

アイデンティティは、Web アプリケーションの リストを収集するサービスが、アプリケーションを一意に識別するために 使用できる。

注記

アイデンティティは URL と同様に処理されるが、 ナビゲート可能なリソースを指すものではないため、 スコープ内である必要はない。

順序付き マップ json、順序付き マップ manifest が与えられたとき、id メンバーを処理するには、次の手順を実行する。

  1. manifest["id"] を manifest["start_url"] に設定する。
  2. json["id"] の型が文字列でない場合、 return。
  3. json["id"] が空文字列の場合、return。
  4. base origin を manifest["start_url"] のオリジンとする。
  5. id を、base origin をベース URL として json["id"] を解析した結果とする。
  6. id が失敗の場合、return。
  7. id が manifest["start_url"] と同一オリジンでない場合、 return。
  8. id のフラグメントを null に設定する。
  9. manifest["id"] を id に設定する。

1.12 theme_color メンバー

マニフェスト の theme_color メンバーは、テーマ適用可能なメンバー であり、アプリケーションコンテキストの既定のテーマカラーとして機能します。 テーマカラーが何を指すかは、[HTML]で定義されています。

ユーザーエージェントが、theme_color メンバーの値をデフォルトのテーマカラーとして尊重する場合、その色は、 マニフェストが適用されるすべてのトップレベルのトラバーサブルのテーマカラーとして機能します。ただし、ユーザーエージェントは、 文書の URL が アプリケーションコンテキストのマニフェストの スコープ内にあり、その文書に meta 要素が含まれ、その name 属性が 「theme-color」である場合、 デフォルトのテーマカラーを上書きしてもよいものとします。 ただし、ユーザーエージェントは、 meta 要素の name 属性が「theme-color」であることによって、文書の URL がスコープ内にない場合に、 デフォルトのテーマカラーを上書きすべきではありません。これは、 アプリケーションがこれらの文書を制御できないためです。

ユーザーエージェントは、テーマカラーのアルファ成分を文脈に応じて無視しても構いません。例えば、多くの環境では テーマカラーは透明にできません。

実装者は、theme_color メンバーで定義された値を prefers-color-scheme 対応のために上書きしても構いません。

注

マニフェストの処理時には、 カラー・メンバーの処理アルゴリズムを使用して theme_color メンバーを処理します。

1.13 background_color メンバー

マニフェスト の background_color メンバーは テーマ適用可能なメンバーであり、 ウェブアプリケーションの想定される背景色を記述します。 これはアプリケーションのスタイルシートですでに利用可能な情報を繰り返すものですが、 ユーザーエージェントがマニフェストが既知の場合に、 実際のファイルがネットワークから取得されるかディスクから読み出されるより前に、 ウェブアプリケーションの背景色を描画するために利用できます。

background_color メンバーは、ウェブアプリケーションのローディング中にユーザー体験を向上させるためのものであり、 ユーザーエージェントは、ウェブアプリケーションのスタイルシートが利用可能な場合には背景色として使用してはなりません（MUST NOT）。

実装者は、background_color メンバーで定義された値を prefers-color-scheme 対応のために上書きしても構いません。

注

マニフェストの処理時には、 カラー・メンバーの処理アルゴリズムを使用して background_color メンバーを処理します。

1.14 shortcuts メンバー

マニフェスト の shortcuts メンバーは、ウェブアプリケーション内の主要タスクへのアクセスを提供するリストです。各要素は shortcut item です。

注

ショートカットの表示方法や表示数は、ユーザーエージェントやOSの裁量によって決定されます。

shortcuts メンバーの処理は、順序付きマップ json、順序付きマップ manifest、 URL manifest URL が与えられたとき：

  1. processedShortcuts を新しいリストとして作成する。
  2. manifest["shortcuts"] に processedShortcuts を設定する。
  3. json["shortcuts"] が 存在しないか、 リストでない場合は return。
  4. json["shortcuts"] の各 entry に対して：
    1. shortcut に process a shortcut を entry, manifest URL, manifest["scope"], manifest["dir"] を使って呼び出した結果を設定。
    2. shortcut が failure なら continue。
    3. shortcut を processedShortcuts に追加する。

ユーザーエージェントは、OSのアプリコンテキストメニュー（例：右クリックや長押し）と同じ方式でショートカットを公開するべきです（SHOULD）。また、manifest内の順番どおりに表示すべきです。表示の仕方もOSのコンテキストメニューと一貫性を持たべきです。OSの仕様や制限に合わせて表示数を省略しても構いません（MAY）。

1.15 *_localized メンバー

ローカライズ可能なメンバーとは、ローカライズできるマニフェストのメンバーである。マニフェストの各ローカライズ可能なメンバーには、 対応する *_localized メンバーがあり、ここで * は メンバー名を表す。

言語マップ とは、キーが言語タグで、値がローカライズ済み値である順序付きマップである。 ローカライズ済み値とは、キーで指定された言語に ローカライズされたコンテンツである。

ローカライズ可能なメンバーに割り当てられた値は、 デフォルト表現である。 *_localized メンバーには、アプリケーション内の 指定されたローカライズ可能なメンバーについてローカライズ済み値を定義する言語マップが 含まれる。ユーザーエージェントは、ユーザーのローカライズ 設定を使用して、言語タグキーが ユーザーの設定に最もよく一致するローカライズ済み値を選択するべきである。 そのようなローカライズ済み 値が 利用できない場合は、デフォルト表現が 使用される。

1.15.1 テキスト値のローカライズ

ローカライズ済みテキストオブジェクトは、次の プロパティを持つ順序付き マップである。

value
ローカライズされた文字列。
dir （任意）
テキスト方向。
lang （任意）
言語タグ。

文字列を受け入れるローカライズ可能なメンバーの場合、 *_localized メンバーの言語マップは、 文字列またはローカライズ済みテキストオブジェクトのいずれかをローカライズ済み値として受け入れる。

文字列が使用される場合、またはdir メンバーがローカライズ済みテキストオブジェクトに 存在しない場合、デフォルト方向（dir メンバー、マニフェストの）が 適用される。

注記

文字列が使用される場合、または ローカライズ済みテキストオブジェクトのlang メンバーが存在しない場合、言語マップのキーの言語タグが適用される。

注記

順序付きマップ json、 順序付きマップ map、 文字列 member、およびテキスト方向 defaultDirectionが与えられたとき、*_localized テキストメンバーを処理するには、次の手順を実行する。

  1. member が json に存在しない場合、return。
  2. languageMap を json[member] とする。
  3. languageMap が順序付きマップでない場合、return。
  4. languageTags を languageMap のキーとする。
  5. map[member] を新しい順序付きマップに設定する。
  6. languageTags の各 languageTag について反復し、 languageMap[languageTag]、languageTag、map、member、および defaultDirection を渡して、ローカライズ済み テキストオブジェクトを処理する。

文字列または 順序付きマップ localizedValue、文字列 defaultLanguageTag、順序付き マップ map、 文字列 member、およびテキスト方向 defaultDirectionが与えられたとき、ローカライズ済みテキストオブジェクトを処理するには、次の手順を実行する。

  1. normalizedValue を順序付きマップとする。
  2. localizedValue が文字列の場合、 localizedValue から先頭と 末尾の ASCII 空白を除去し、normalizedValue["value"] を localizedValue に設定する。
  3. localizedValue が順序付きマップの場合:
    1. "value" が localizedValue に存在し、かつ localizedValue["value"] が文字列の場合、localizedValue["value"] から先頭と 末尾の ASCII 空白を除去し、 normalizedValue["value"] を localizedValue["value"] に設定する。
    2. "lang" が localizedValue に存在し、かつ localizedValue["lang"] が文字列の場合、localizedValue["lang"] から先頭と 末尾の ASCII 空白を除去し、 normalizedValue["lang"] を localizedValue["lang"] に設定する。
    3. "dir" が localizedValue に存在し、かつ localizedValue["dir"] が文字列の場合:
      1. localizedValue["dir"] から先頭と 末尾の ASCII 空白を除去する。
      2. テキスト方向 リストが localizedValue["dir"] を含む場合、 normalizedValue["dir"] を localizedValue["dir"] に設定する。
  4. "value" が normalizedValue に存在しない場合、return。
  5. "lang" が normalizedValue に存在しない場合、 normalizedValue["lang"] を defaultLanguageTag に設定する。
  6. "dir" が normalizedValue に存在しない場合、 normalizedValue["dir"] を defaultDirection に設定する。
  7. normalizedValue["lang"] を指定してIsStructurallyValidLanguageTag を呼び出すか、defaultLanguageTag を指定してIsStructurallyValidLanguageTag を呼び出した結果が false の場合、return。
  8. map[member][defaultLanguageTag] を normalizedValue に設定する。
注記

ローカライズ済み テキストオブジェクトを処理するアルゴリズムは、ローカライズ済み値パラメーターとして文字列またはローカライズ済みテキストオブジェクトのいずれかを受け取るが、処理された結果は value、lang、および dir メンバーが設定されたローカライズ済みテキストオブジェクトに正規化される。

1.15.2 画像リソースのローカライズ

リストの画像リソースを受け入れるローカライズ可能なメンバーの場合、*_localized メンバーの言語マップは、 リストの画像リソースをローカライズ済み値として受け入れる。

順序付きマップ json、 順序付きマップ map、文字列 member、およびURL manifest URLが与えられたとき、 *_localized 画像リソースメンバーを処理するには、次の手順を実行する。

  1. member が json に存在しない場合、return。
  2. languageMap を json[member] とする。
  3. languageMap が順序付きマップでない場合、return。
  4. languageTags を languageMap のキーとする。
  5. map[member] を新しい順序付きマップに設定する。
  6. languageTags の各 languageTag について反復する。
    1. languageTag を指定してIsStructurallyValidLanguageTag を呼び出した結果が false の場合、continue。
    2. languageMap[languageTag] をリスト の画像リソースとして、map[member]、manifest URL、および languageTag をメンバーとして渡し、画像 リソースを処理する。

1.16 color_scheme_dark メンバー

マニフェスト の color_scheme_dark メンバーは、キーがテーマ適用可能なメンバーであり、 値が OS がダークカラーテーマを使用している場合にそれらのメンバーの値を上書きする色値である 順序付きマップです。

テーマ適用可能なメンバーは、以下のマニフェストメンバーのいずれかです：

マニフェストを適用するとき、OS がダークカラーテーマを使用している場合、 テーマ適用可能なメンバーのうち 存在する color_scheme_dark の各 member について、 ユーザーの環境設定（例：アクセシビリティ設定等）が優先される場合を除き、 ユーザーエージェントは color_scheme_dark[member] の値を member の値として使用すべき (SHOULD)です。

1.16.1 テーマ適用可能なメンバーのテーマ設定

color_scheme_dark メンバーを処理するには、順序付きマップ json、 順序付きマップ manifest、および URL manifest URL：

  1. json["color_scheme_dark"] が 存在しない場合、終了します。
  2. colorScheme に json["color_scheme_dark"] を代入します。
  3. colorScheme が 順序付きマップでない場合、終了します。
  4. processedColorScheme に新しい 順序付きマップ を代入します。
  5. 設定： manifest["color_scheme_dark"] を processedColorScheme にします。
  6. 次の各 member： « "theme_color", "background_color" » について：
    1. 色メンバーの処理 を colorScheme、 processedColorScheme、 member を渡して呼び出します。

1.17 マニフェストのライフサイクル

本節では、マニフェストを処理するアルゴリズムと、 適用されるマニフェストについて定義します。

ユーザーエージェントは、リンクタイプ "manifest" およびリンクされたリソースの取得と処理方法に関する手順を サポートしなければなりません (MUST)。

1.17.1 マニフェストの処理

無視するよう指示された場合、ユーザーエージェントは、条件の原因となった マニフェスト、メンバー、または値が存在しないかのように動作しなければならない。

次のアルゴリズムは、処理 拡張ポイントを提供する。マニフェストに新しいメンバーを追加する 他の仕様は、アルゴリズムのこの時点でこの 仕様にフックすることが推奨される。それらは、manifest オブジェクトにすでに存在する値を変更するべきではない。

注記

処理 拡張ポイントは、 モンキーパッチに関連する 問題を回避するのに役立つことを意図している。

マニフェストを処理する手順は、次の アルゴリズムで与えられる。このアルゴリズムは、URL document URL、 URL manifest URL、バイト列 bodyBytes、および client（環境設定オブジェクトまたは null）を受け取る。

  1. json を、bodyBytes を渡してJSON バイトを Infra 値に解析する結果とする。
  2. json が解析例外である場合、または json が 順序付きマップでない場合:
    1. json を空の順序付きマップに設定する。
  3. manifest を空の順序付きマップとする。
  4. json および manifest を渡して、 dir メンバーを処理する。
  5. json および manifest を渡して、 lang メンバーを処理する。
  6. json、manifest、および "name" を渡して、テキストメンバーを処理する。
  7. json、 manifest、"name_localized"、および manifest["dir"] を渡して、 *_localized テキストメンバーを処理する。
  8. json、manifest、および "short_name" を渡して、テキストメンバーを処理する。
  9. json、 manifest、"short_name_localized"、および manifest["dir"] を渡して、 *_localized テキストメンバーを処理する。
  10. json、manifest、 manifest URL、および document URL を渡して、start_url メンバーを処理する。
  11. json および manifest を渡して、id メンバーを処理する。
  12. 文書の処理済みマニフェストが null でなく、かつ文書の処理済みマニフェストの id が manifest["id"] と等しくない場合、return。
  13. json、manifest、 および manifest URL を渡して、scope メンバーを処理する。
  14. json、manifest、および "theme_color" を渡して、カラーメンバーを処理する。
  15. json、manifest、および "background_color" を渡して、カラーメンバーを処理する。
  16. json および manifest を渡して、display メンバーを処理する。
  17. json["icons"]、 manifest、manifest URL、および "icons" を渡して、画像リソースを処理する。
  18. json、manifest、 "icons_localized"、および manifest URL を渡して、 *_localized 画像リソースメンバーを処理する。
  19. json、 manifest、および manifest URL を渡して、 color_scheme_dark メンバーを処理する。
  20. json、 manifest を渡して、 orientation メンバーを処理する。
  21. json、manifest、 および manifest URL を渡して、shortcuts メンバーを処理する。
  22. 処理拡張ポイント: アルゴリズムの この時点で、独自および／またはその他のサポートされているメンバーを処理する。
  23. manifest の client を client に設定する。
  24. 文書の 処理済みマニフェストを manifest とする。

1.17.2 色メンバーの処理

Note: サポートされる色

sRGB の色と、 ユーザーエージェントが外部知識なしに sRGB に変換できる色（例："AliceBlue"）のみが サポートされます。 たとえば、lab(…) や color(display-p3, …) は外部知識なしに sRGB に変換できますが、 color(--custom-profile, …) は、マニフェスト内では指定できない "@color-profile" ルールとの対応付けが必要になるため、利用できません。

順序付きマップ json、 順序付きマップ map、 および 文字列 member を用いて、 色メンバーを処理するには次のようにします：

  1. json[member] が 存在しないか、 json[member] が 文字列でない場合、終了します。
  2. 先頭および末尾の ASCII 空白を除去し、 json[member] から取り除きます。
  3. color を、 json[member] の値を CSS 色として パースした結果とします。
  4. color が失敗であれば、終了します。
  5. color が、ユーザーエージェントが本来備える情報のみを用いて sRGB に変換できる場合、 color を sRGB に変換します。
  6. color が sRGB の色でない場合、終了します。
  7. map[member] を color に設定します。

1.17.3 テキストメンバーの処理

順序付きマップ json、 順序付きマップ map、 および 文字列 member が与えられたとき、 テキストメンバーを処理するには次のようにします：

  1. json[member] が 存在しないか、 json[member] が 文字列でない場合、終了します。
  2. 先頭および末尾の ASCII 空白を除去し、 json[member] から取り除きます。
  3. map[member] を、 json[member] の値に設定します。

1.17.4 ドキュメントなしでマニフェストを処理

マニフェストの処理の手順は、 [HTML] の link要素の処理手順によって呼び出されます。この場合、clientは ドキュメントの 関連設定オブジェクトです。 これらの手順は、ユーザーエージェントが関連するドキュメントなしでマニフェストを処理するために呼び出すこともMAYあります。この場合、clientは null です。

この場合、[HTML] における対応する手順によって与えられる保証に 合致させるために、ユーザーエージェントは少なくとも過去のある時点で次を満たすことを 推奨されます (SHOULD)：

Note: これらのチェックの根拠

1.17.5 マニフェストの適用

処理済みマニフェストがトップレベルのトラバーサブルに適用されるとは、マニフェストのメンバーが トップレベルのトラバーサブルの表示や動作に影響を 与えていることを意味します。 トップレベルのトラバーサブルが作成されるたびに、ユーザー エージェントは、ナビゲーションが開始される前に、マニフェストをそれに 適用してもよいものとします。

ユーザーエージェントは、既存の トップレベルのトラバーサブルにマニフェストを適用してもよいものとします。アクティブ文書の URL がマニフェストのスコープ 内にある場合、既存の トップレベルのトラバーサブルはアプリケーションコンテキストになります。URL がスコープ 内にない場合、その結果となる動作は実装定義です。

注記
注記

マニフェストが適用されたトップレベルのトラバーサブルは、 アプリケーション コンテキストと呼ばれます。

処理済みマニフェストは、トップレベルのトラバーサブルから適用解除することもできます。これが行われると、 トップレベルのトラバーサブルは アプリケーションコンテキストではなくなります。

注記

ユーザーエージェントがディープリンクへナビゲートするよう求められた結果として、 アプリケーションコンテキストが作成された場合、ユーザー エージェントは、historyHandling を「replace」に設定して、 直ちにディープリンクへナビゲートしなければなりません。それ以外の場合、 アプリケーションコンテキストが作成されると、ユーザーエージェントは、 historyHandling を「replace」に設定して、 直ちに開始 URLへ ナビゲートしなければなりません。

注記

1.17.6 マニフェストの更新

manifest リンク関係について規定されているとおり、マニフェストは ページが読み込まれるたびに取得および処理されます。マニフェストの処理が成功した場合、ユーザーエージェントは、 更新されたマニフェストを、アプリケーションに関連付けられた現在および将来の任意のアプリケーションコンテキストに 適用してもよいものとします。

ユーザーエージェントは、src メンバーが変更された場合、 マニフェスト画像リソースが 更新されたと見なすべきです。src が変更されていない場合、ユーザー エージェントは、場合によっては画像をダウンロードし、 視覚的な差異を確認してもよいものとします。

注記：アイコンの メタデータの変更

更新の目的では、次のメンバーは、インストール時および 起動サーフェス上で提示されるため、 セキュリティ上重要なメンバーです。

  1. short_name および short_name_localized 内のローカライズされた表現、
  2. icons および icons_localized 内のローカライズされた表現、
  3. name および name_localized 内のローカライズされた表現。

マニフェストのその他すべてのメンバーは、セキュリティ上重要でないメンバーと見なされます。

セキュリティ上重要な更新とは、 セキュリティ上重要なメンバーに対する更新です。同様に、 セキュリティ上重要でない更新とは、 セキュリティ上重要でないメンバーに対する更新です。

マニフェスト画像リソース型の、更新されたセキュリティ上重要なメンバー（たとえば、icons）を検討する際、ユーザー エージェントは、画像に視覚的に大きな差異がないと判断した場合、それをセキュリティ上重要でない更新と見なし てもよいものとします。

ユーザーエージェントは、すべてのセキュリティ上重要でない更新を 直ちに適用するべきです。

ユーザーエージェントは、すべてのセキュリティ上重要な更新を ユーザーに提示し、変更を適用する前に明示的な許可を要求する べきです。

注記：更新が提示された際に 表示されるユーザーオプションの例

セキュリティ上重要なメンバーは、その方向にかかわらず、 [UTS55] で説明されているように、 双方向的に分離された方法で表示するべきです。

ユーザーがローカライズ設定を変更した場合、ユーザーエージェントは、 起動サーフェスに表示されるセキュリティ上重要なメンバーを、 *_localized メンバーで指定された ローカライズされた表現に自動的に調整してもよいものとします。これらの変更は、 ユーザーが次にウェブアプリケーションを開いたときに提示する べきです。

2. マニフェスト画像リソース

各マニフェスト画像リソースは、画像リソースです。 マニフェスト画像リソースが提示される文脈は、関連するマニフェストメンバーの意味によって決まります（例：iconsメンバーは通常、アプリケーションアイコンを表すために使用されます）。

マニフェスト画像リソースは、画像リソースと異なり、追加のpurposeメンバーを持つことができます。

ユーザーエージェントは、MAY、マニフェスト画像リソースに関連付けられた画像を、プラットフォームの視覚スタイルにより適合させるために変更することがあります。例えば、角を丸めたり特定の色で塗りつぶしたりしてユーザーに表示する場合です。開発者は、重要な情報が色の変更や角の切り取りによって失われないよう、このようなシナリオに備えて画像リソースを準備することが推奨されます。

マニフェスト画像リソースを取得するためには、マニフェスト画像リソース imageと、アプリケーションマニフェスト manifestを与え、 画像リソースの取得の結果か null を返します。

  1. manifest のクライアントが null の場合、null を返します。
    注記
  2. requestを新しいリクエストとします。
  3. requestのURLを、imageのsrcに設定します。
  4. requestの宛先を「image」に設定します。
  5. requestのクライアントを、manifestのクライアントに設定します。
  6. image およびrequestを用いて画像リソースを取得する結果を返します。
注記

2.1 purposeメンバー

purpose メンバーは、 一意な空白区切りトークンの 順序なし集合です。許可される 値は、アイコンの用途です。

マニフェスト画像リソースがアイコンとして使用される場合、 開発者は、ホストのOSのコンテキストにおいて、その画像が何らかの特別な 用途（すなわち、より良い統合のため）に使用されることを意図していると示唆できます。 ユーザーエージェントは、明示されたアイコンの 用途以外にアイコンを使用すべきではありません。

注記

たとえば、用途が「monochrome」のアイコンは、 単色塗りつぶしのバッジまたはピン留めアイコンとして使用でき、 アプリケーションのフルカラー起動アイコンとは視覚的に区別されます。ユーザーエージェントは、 purpose メンバーの値を、 purposeをどこにどのように表示するかを決定するための ヒントとして使用します。開発者が別途宣言しない限り、 ユーザーエージェントはアイコンを任意の用途に使用できます。

アイコンの用途は次のとおりです。

monochrome
ユーザーエージェントは、単色塗りつぶしのモノクロ アイコンが必要な場所で、このアイコンを提示できます。アイコン内の色情報は破棄され、 アルファデータのみが使用されます。その後、ユーザーエージェントは、 任意の単色塗りつぶしの上に重ねるマスクとしてアイコンを使用できます。
maskable
この画像は、アイコンマスクと セーフゾーンを考慮して設計されており、画像のうち セーフゾーンの外側にある部分は、ユーザーエージェントによって 安全に無視され、マスクで除去できます。
any（デフォルト）
ユーザーエージェントは、purposeが 要求されない場所で自由にアイコンを表示できます。たとえば、「any」の用途を持つマニフェスト画像リソースは、 「monochrome」が要求されるコンテキストでは使用されません。

アイコンの 用途リストは、リスト « "monochrome", "maskable", "any" » です。

注記

アイコンに複数の用途が含まれている場合、それらの用途のいずれにも使用できます。 明示された用途が一つも認識されない場合、そのアイコンは完全に無視されます。 たとえば、アイコンの用途が "monochrome fizzbuzz" である場合、"monochrome" は有効な用途であるため、 モノクロアイコンとして使用できます。ただし、アイコンの用途が "fizzbuzz" のみである場合、そのアイコンは無視されます。

順序付き マップ json が与えられたとき、画像の用途を決定するには、次を行います。

  1. json["purpose"] が存在しない場合、または json["purpose"] が文字列でない場合：
    1. 集合 « "any" » を返します。
  2. keywordsを、json["purpose"]をASCII 空白で分割した結果とします。
  3. purposesを新しい集合とします。
  4. keywordsの各keywordについて、 繰り返します：
    1. アイコンの用途リストがkeywordを含まない場合、 続行します。
    2. そうでなければ、keywordを purposesに付加します。
  5. purposesが空の場合、失敗を返します。
  6. purposesを返します。

2.2 コンテンツセキュリティポリシー

ユーザーエージェントが アイコン画像を取得できるかどうかを規定するセキュリティポリシーは、マニフェストの所有者であるDocumentに関連付けられた img-src ディレクティブ [CSP3] によって規定される。

2.3 アイコンマスクとセーフゾーン

一部のプラットフォームでは独自の好ましいアイコン形状がありますが、ウェブアプリケーションは複数のプラットフォームで動作する必要があるため、maskable目的を追加することで、ユーザーエージェント指定のマスクをアイコンに適用できることを示すことができます。これにより、プラットフォーム上でアイコンが一体的に見えるようにし、場所によって異なるマスクや背景色を適用できます。

セーフゾーンは、maskableアイコン内で常に可視であることが保証される領域です。アイコンの中心に中心点を持つ半径2/5（40%）の円として定義されます。アイコンが正方形でない場合は、幅と高さの小さい方が基準です。

注

maskableアイコンのデザイナーは、すべての重要部分がセーフゾーン内にあることを確認してください。

safe zone illustrated
図 1 セーフゾーンはアイコンの幅と高さの小さい方の2/5（40%）の半径を持つ中心円です。

このゾーン内のすべてのピクセルはすべてのマスクで必ず見えることが保証されます。セーフゾーン外のピクセルは、マスクの種類によっては見える場合もありますが保証されません。

ユーザーエージェントは、任意のサイズのマスクを適用してもよいですが、画像サイズの2/5（幅と高さの小さい方が基準）より中心から遠いピクセル（セーフゾーン外）は透明にします。

ユーザーエージェントは、セーフゾーン内のピクセルを透明にしてはなりません。

ユーザーエージェントは、アイコンに追加のパディングを付与して拡大してもよいです。

アイコンが透明ピクセルを含む場合、ユーザーエージェントはアイコンをユーザーエージェントが選択したソリッド塗り（例：白）に合成しなければなりません。

注

maskableアイコンでは透明ピクセルの使用を避けることが推奨されます。

2.3.1 マスク例

注

セーフゾーン内に収めることで、ほとんどのアイコンは上下左右に約10%の余白（コンテンツまたは非必須コンテンツ、例えばアイコンの背景）ができます。セーフゾーン以外がマスクされた場合もアイコンを確認することが推奨されます。

2.3.1.1 "maskable"目的のアイコン
An icon over a checkerboard background
図 2 画像 透明な背景付きのベース画像
An icon in a purple circle (40% of the size) over a yellow background
図 3 セーフゾーン アイコンサイズの半径2/5（40%）の円
2.3.1.2 マスク例
An icon inside a rounded yellow square on a purple background
図 4 角丸四角 Android
An icon inside an extremely rounded yellow square on a purple background
図 5 スクワイアクル Android
An icon inside a rounded yellow circle on a purple background
図 6 円 Android
An icon inside a somewhat rounded yellow square on a purple background
図 7 角丸四角 iOS
An icon on a yellow background
図 8 フルブリード Windows

2.4 単色アイコンとソリッド塗り

一部のプラットフォームでは、アイコンがソリッド塗り（単色など）で表示されることが強制され、アイコンの透明度のみマニフェストで指定できます。ウェブアプリケーションは複数のプラットフォームで動作する必要があるため、monochrome目的を追加することで、ユーザーエージェント指定の色をアイコンに適用できることを示すことができます。これにより、プラットフォーム上でアイコンが一体的に見えるようにし、場所によって異なる色やパディングを適用できます。

monochromeアイコンを表示する際、ユーザーエージェントはピクセルの赤、緑、青成分を独立して表示してはなりません。ユーザーエージェントは各ピクセルを元のアルファ値で表示すべきですが、赤・緑・青値はユーザーエージェントが選択した値にします。すべてのピクセルで同じ色値を使用することが推奨されます。

注

monochromeアイコンのデザイナーは、全ピクセルを黒にして透明度のみでシルエットを作成することができます。

ユーザーエージェントは、追加のパディングを付与してアイコンを拡大してもよいです。

ユーザーエージェントは、透明ピクセルの背後に任意の背景色を追加してもよいですが、背景とアイコンのコントラストが十分であることを推奨します。

2.4.1 単色アイコンの使用例

2.4.1.1 使用例
A black icon over a checkerboard background
図 9 画像 色なしベース画像。
A dark gradient icon over a checkerboard background
図 10 グラデーション塗り 画像がグラデーションで塗られている。
A dark yellow icon over a light gray background
図 11 パディングつきソリッド塗り マニフェストのテーマカラーで塗られている。

2.5 画像リソースの処理

画像リソースの処理を行うには、リスト images、 順序付きマップ map、manifest URL、および文字列 memberを与えます：

  1. imageResourcesを新しいリストとする。
  2. map[member]にimageResourcesを設定する。
  3. imagesがリストでなければ、終了する。
  4. 各potential imageについてimagesを反復する：
    1. imageを、JSONから画像リソースを処理した結果（potential imageとmanifest URLを与える）とする。
    2. imageがfailureなら、continue。
    3. purposesを、画像の目的を決定する （potential imageを渡す）結果とする。
    4. purposesがfailureなら、continue。
    5. image["purpose"]にpurposesを設定する。
    6. appendでimageをimageResourcesに追加する。

3. ショートカット項目

各ショートカット項目は 順序付きマップであり、ウェブアプリ内の重要なタスクやページへのリンクを表します。以下のメンバーを持ちます：

ユーザーエージェントは、これらのメンバーを使って、ユーザーがウェブアプリのアイコンを操作した際にOSが表示するコンテキストメニューを組み立てることができます。ユーザーがOSメニューからショートカットを起動した場合、ユーザーエージェントはショートカットの起動を行うべきです。

3.1 name メンバー

ショートカット項目の name メンバーは、文字列であり、通常ユーザーにコンテキストメニューで表示されるショートカットの名称を表します。

nameメンバーはローカライズ可能なメンバーです。

3.2 short_name メンバー

ショートカット項目の short_name メンバーは文字列であり、ショートカットの名称の短縮版を表します。これは、フルネームを表示するのに十分なスペースがない場合に使用されます。

short_nameメンバーはローカライズ可能なメンバーです。

3.3 description メンバー

ショートカット項目の description メンバーは文字列であり、開発者がショートカットの目的を説明できます。 ユーザーエージェントはこの情報を支援技術に公開してもよいです。

descriptionメンバーはローカライズ可能なメンバーです。

3.4 url メンバー

ショートカット項目の url メンバーは、処理済みマニフェストのスコープ内のURLであり、関連するショートカットが起動されたときに開かれます。

3.5 icons メンバー

ショートカット項目の icons メンバーは、様々なコンテキストでショートカットのアイコン表現となる画像を列挙します。

iconsメンバーはローカライズ可能なメンバーです。

3.6 ショートカットの起動

ショートカット項目 shortcut（manifestを持つ）が起動された場合、ウェブアプリケーションの起動の手順をmanifestとshortcut.urlで実行します。

3.7 ショートカット項目の処理

ショートカットを処理するには、順序付きマップ item、URL manifest URL、URL scope、 テキスト方向 defaultDirection が与えられたとき：

  1. 次のいずれかの場合は failure を返す：
  2. url を、 パースした item["url"]（ベースURLは manifest URL）の結果とする。
  3. url が failure の場合、failure を返す。
  4. url が scope の スコープ内 でない場合、failure を返す。
  5. shortcut を ordered map «[ "url" → url, "name" → item["name"] ]» とする。
  6. *_localizedテキストメンバーを処理し、item、shortcut、"name_localized"、defaultDirection を渡す。
  7. "short_name" が 存在し、かつ item["short_name"] が 文字列である場合、 shortcut["short_name"] を item["short_name"] に設定する。
  8. *_localizedテキストメンバーを処理し、item、shortcut、"short_name_localized"、defaultDirection を渡す。
  9. "description" が 存在し、かつ item["description"] が 文字列である場合、 shortcut["description"] を item["description"] に設定する。
  10. *_localizedテキストメンバーを処理し、item、shortcut、"description_localized"、defaultDirection を渡す。
  11. 画像リソースを処理し、 item["icons"]、shortcut、manifest URL、"icons" を渡す。
  12. *_localized画像リソースメンバーを処理し、item、shortcut、"icons_localized"、manifest URL を渡す。
  13. shortcut を返す。

4. インストール可能なウェブアプリケーション

どのようなウェブサイトも、インストール可能なウェブアプリケーションです。

ユーザーエージェントは、エンドユーザーがエンドユーザーのデバイスにウェブ アプリケーションをインストールする手段を提供できます。これにより、ユーザーは、 マニフェストのメンバーが適用された新しいトップレベルのトラバーサブルをインスタンス化できます。

ウェブアプリケーションがインストールされると、インストール済みウェブアプリケーションと呼ばれます。すなわち、マニフェストの メンバーまたはそのデフォルトが、ウェブアプリケーションのトップレベルの トラバーサブルに適用されます。これにより、インストール済み ウェブアプリケーションは従来のブックマークと区別されます。従来のブックマークから ウェブページを開いても、マニフェストのプロパティはそのページに 適用されません。

注記

例えば、インストールをサポートするユーザーエージェントでは、Web アプリケーションを、エンドユーザーから見て ネイティブアプリケーションと区別できないような方法で提示および起動できる。例えば、 ホーム画面、ランチャー、またはスタート メニューにラベル付きアイコンとして表示される場合などである。Web アプリケーションを起動するとき、 マニフェストは、 開始 URLが読み込まれる前に、ユーザーエージェントによって適用され、 トップレベル辿可能体に対して適用される。 これにより、ユーザーエージェントは、マニフェストの関連する値を適用し、場合によっては Web アプリケーションの表示モードや画面の向きを 変更する機会を得る。あるいは、これも一例として、ユーザーエージェントは Web アプリケーションを、ユーザーエージェント自体のブックマークリストに インストールすることもできる。

4.1 アプリケーション名

アプリケーションの名前は、 name メンバーまたは short_name メンバーのいずれかから導出される。ユーザー エージェントは、まず対応する *_localized メンバーからローカライズされた値を解決するべきである。

name メンバーまたは short_name メンバーのいずれかが欠落している、空である、または誤った 型である場合、 ユーザーエージェントは、short_name メンバーのフォールバックとして name メンバーを使用するか、 name メンバーのフォールバックとして short_name メンバーを 使用してもよい。

name および short_name メンバーが 欠落している、空である、または誤った型である場合、ユーザーエージェントは、 欠落しているマニフェスト メンバーに適した代替を見つけるために、Document にフォールバックしてもよい （例えば、name または short_name の代わりに application-name を使用する）。あるいは、ユーザーエージェントは、 プラットフォームの 慣例に従うデフォルトの名前（例えば、「無題」）を割り当てるべきである。あるいは、ユーザーエージェントは、エンドユーザーが アプリケーションの名前として使用できるテキストを入力できるようにしてもよい。

name および short_name メンバーの両方が 存在する場合、利用可能なスペースにどちらのメンバーが 最も適しているかを決定することは実装に委ねられる（例えば、 short_name メンバーは、アイコンの下の 利用可能なスペースに より適している場合がある）。

4.2 ウェブアプリケーションの起動

OSまたはユーザーエージェントの裁量で、ウェブアプリケーションを起動する手順を 処理済みマニフェストで実行する。

Note

この処理は通常、ユーザーがアプリ起動用UI（ホーム画面、ランチャー、スタートメニューなど）から インストール済みウェブアプリを選択したときに 行われます。

ウェブアプリケーションを起動する 手順は次のアルゴリズムで与えられる。 このアルゴリズムは処理済みマニフェスト manifest、オプションのURL target URL、 オプションのPOSTリソース POST resourceを受け取り、 アプリケーションコンテキストを返す。

target URL が与えられている場合、その値は 必ず (MUST) manifest の スコープ内 でなければなりません。

他の仕様が、本アルゴリズムの各手順を自身の手順と置き換えることが できます (MAY)。 この置き換えは、ウェブアプリケーションを起動するすべての呼び出しに 適用されます。

Note

このアルゴリズムは、実験的なlaunch_handlerマニフェストフィールドで すべてのウェブアプリ起動動作を設定できるよう、置き換え可能となっています。 置き換えられたアルゴリズムは既定で 新しいアプリケーションコンテキストを作成する を呼び出しますが、条件により異なる動作をします。

  1. 新しいアプリケーションコンテキストを作成する 手順をmanifest、 target URL、 POST resourceを渡して実行した結果を返す。

新しいアプリケーションコンテキストを作成する手順は 次のアルゴリズムで与えられる。 アルゴリズムは処理済みマニフェスト manifest、オプションのURL target URL、 オプションのPOSTリソース POST resource を受け取り、 アプリケーションコンテキストを返す。

  1. target URLが指定されていない場合、target URLを 開始 URLに設定します。
  2. traversableを、target URLおよびPOST resourceを用いて新しいトップレベルの トラバーサブルを作成する手順を実行した結果とします。
  3. manifestをtraversableに適用します。
  4. traversableを返します。

4.3 プライバシーとセキュリティの考慮事項

エンドユーザーに Web アプリケーションを インストールする機能を提供する UI では、その Web アプリケーションに関するアイコン、 名前、開始 URL、オリジンなども確認できるようにすることが推奨される。 これは、エンドユーザーがインストール前に Web アプリケーションに関する 情報を意識的に承認し、場合によっては変更する機会を 与えるためである。また、これにより エンドユーザーは、例えば予期しないアイコンや 名前を使用することによって、その Web アプリケーションが別の Web アプリケーションになりすましているかどうかを判別する機会も得られる。

ユーザーエージェントは、他のアプリケーションが システムにインストールされているアプリケーションを特定できないようにすることが推奨される（例えば、 ユーザーエージェントのキャッシュに対するタイミング攻撃を介して）。これは、 例えば、Web アプリケーションがインストールされた後に、マニフェストからリンクされているリソース （例えば、アイコン）をユーザーエージェントのキャッシュから無効化することで 実現できる - または、通常の Web ブラウジングに使用されるものとは完全に異なる キャッシュを使用することで実現できる。

4.4 アンインストール

ユーザーエージェントは、ユーザーがインストール済みウェブアプリケーションを削除できる仕組みを提供すべきです。

削除時には、アプリケーションに関連した他の永続データや設定（権限や永続ストレージ等）も取り消す機会をユーザーに提示することが推奨されます。

6. 表示モード

表示モードは、Web アプリケーションが OS のコンテキスト内でどのように提示されるか（例えば、 フルスクリーンなど）を表す。表示モードは、特定のプラットフォームで使用されるユーザーインターフェイス（UI）の メタファーおよび機能に対応する。表示モードの UI 規則は純粋に助言的なものであり、実装者は 最適と考える方法で自由に解釈できる。

この仕様では、次の表示モードを定義する。

fullscreen
ブラウザーの UI 要素を非表示にして Web アプリケーションを開き、 利用可能な表示領域全体を使用する。
standalone
Web アプリケーションを、スタンドアロンのネイティブ アプリケーションのような外観と操作感で開く。これには、アプリケーションが別の ウィンドウを持つこと、アプリケーションランチャー内に独自のアイコンを持つことなどが含まれ得る。このモードでは、 ユーザーエージェントは URL バーなどの標準的なブラウザー UI 要素を除外するが、ステータス バーやシステムの戻るボタンなど、その他のシステム UI 要素を含めることができる。
minimal-ui
このモードは standalone に似ているが、 エンドユーザーに、ナビゲーションを制御するための最小限の UI 要素 （すなわち、戻る、進む、再読み込み、および場合によっては 文書のアドレスを表示する何らかの手段）へアクセスする手段を提供する。ユーザーエージェントは、 「共有」や「印刷」 ボタンなど、そのプラットフォームおよびユーザーエージェントで慣例となっている その他のプラットフォーム固有の UI 要素を含めることができる。
browser （デフォルト）
ユーザーエージェントでハイパーリンクを開くためのプラットフォーム固有の規則 （例えば、ブラウザータブまたは新しい ウィンドウ内）を使用して Web アプリケーションを開く。
注記

fullscreen 表示モードは、 Fullscreen API 標準とは直交しており、独立して動作する。fullscreen 表示モードはブラウザーウィンドウのフルスクリーン状態に 影響する一方、[FULLSCREEN] API はビューポート内に含まれる要素に対して 動作する。したがって、Web アプリケーションでは、 表示モードを fullscreen に設定しながら、 document.fullScreenElement が null を返し、fullscreenEnabled が false を返すことができる。

マニフェストが適用されてトップレベル辿可能体に関連付けられると、その時点で有効な 表示モードが、その トップレベル辿可能体の適用済み表示モードとなる。ユーザーエージェントは、セキュリティ上の理由（例えば、トップレベル 辿可能体がスコープ外へナビゲートされる場合）に、 適用済み表示モードを変更してもよい。また、ユーザーエージェントは、 別の表示モードに切り替える手段をユーザーに提供してもよい。

display メンバーが欠落している場合、または有効な display メンバーが存在しない場合、ユーザーエージェントは browser 表示モードを適用済み表示モードとして使用する。したがって、 ユーザーエージェントは browser 表示モードをサポートしなければならない。

すべての表示モードには、表示モードのリストであるフォールバックチェーンがある。各表示モードのフォールバックチェーンは次のとおりである。

  1. browser は «»。
  2. minimal-ui は « "browser" »。
  3. standalone は « "minimal-ui", "browser" »。
  4. fullscreen は « "standalone", "minimal-ui", "browser" »。

Web アプリが 選択した表示モードを決定する手順 は、次のアルゴリズムで与えられる。このアルゴリズムは、 処理済みマニフェスト manifest を受け取り、 表示モードを返す。

  1. 処理拡張ポイント: この時点で、 独自および／またはその他のサポートされている表示モードを処理する。
  2. ユーザーエージェントが manifest["display"] をサポートしている場合、 manifest["display"] を返す。
  3. manifest["display"] の フォールバックチェーンの各 fallback_mode について反復する。
    1. ユーザーエージェントが fallback_mode をサポートしている場合、 fallback_mode を返す。
  4. 表明: このステップに到達することはない。
注記

上記のループは、表明に到達する前に必ず値を返すことが保証されている。 これは、browser がすべてのモードの フォールバックチェーンに含まれており、かつすべてのユーザーエージェントが browser 表示モードをサポートするという要件があるためである。

表示モード リストは、リスト « "fullscreen", "standalone", "minimal-ui", "browser" » である。

ユーザーエージェントは、Web アプリケーションの適用済み 表示モードを、display-mode メディア特性 [MEDIAQUERIES-5] に反映しなければならない。

注記

ユーザーエージェントは、マニフェストで宣言されたものとは必ずしも 一致しない適用済み表示モードを、 CSS または JavaScript からアクセス可能なdisplay-mode メディア 特性を通じて公開する。このメディア 特性は、マニフェストが適用されていない場合にも、Web ページのその他の表示モードを 反映することに注意すること。例えば、エンドユーザーが ページをフルスクリーンにした場合、ユーザーエージェントはこの変更を display-mode メディア特性を介して CSS およびスクリプトに反映する。

7. プライバシーおよびセキュリティに関する考慮事項

7.1 プライバシーに関する考慮事項

この仕様は、価値の高いデータを直接扱うものではありません。 ただし、インストール済みウェブアプリケーションおよびそのデータは、 「価値が高い」と見なされる可能性があります（特にプライバシーの観点から）。

ウェブアプリケーションには、ローカルデバイスとリモートホストの両方と 同時にやり取りできるコンテンツが含まれる可能性があるため、 実装者は、個人情報をリモートホストに公開することによって生じる プライバシーへの影響を考慮する必要があります。緩和策および 多層的な防御策は実装者の責任であり、 この仕様では規定しません。ただし、これらの対策を設計する際には、 情報共有についてユーザーが認識できるようにし、権限を 取り消すことのできるインターフェイスへ容易にアクセスできるようにすることが 実装者に推奨されます。

ユーザーエージェントが、システムにどのアプリケーションが インストールされているかを他のアプリケーションが特定できないようにすることが推奨されます（たとえば、 ユーザーエージェントのキャッシュに対するタイミング攻撃による特定）。 これは、たとえば、ウェブアプリケーションがインストールされた後に、 マニフェストからリンクされているリソース（たとえばアイコン）を ユーザーエージェントのキャッシュから無効化するか、通常のウェブ閲覧に使用されるものとは 完全に異なるキャッシュを使用することによって実現できます。

ショートカットのurlを、アプリケーションが ブラウザーの外部から起動されたことを示すように作成できることが考えられます （たとえば、"url": "/task/?from=homescreen"）。また、 開発者がユーザーを一意に識別する文字列（たとえば、サーバーによって割り当てられた UUID）をurlにエンコードすることも 考えられます。これは、ユーザーが認識していない可能性のある フィンガープリンティングおよびプライバシーに関わる情報であり、 開始 URLにエンコードされた識別子と同様に、 ユーザーがサイトデータを消去しても消去されません。

開始 URLと同様に、ユーザーエージェントが、 インストール時またはその後いつでも、ショートカットのurlをユーザーが確認し、 必要に応じて変更できるようにすることが推奨されます。

7.2 セキュリティに関する考慮事項

マニフェスト形式は JSON であり、[UNICODE]を使用して エンコードされるため、[JSON]および [UNICODE-SECURITY]に記載された セキュリティ上の考慮事項が適用されます。さらに、 開発者がカスタムデータまたは制約のないデータを マニフェストに含めることを防ぐ方法はないため、実装者は、 サービス拒否攻撃の防止、メモリ不足の回避、 またはプラットフォーム固有の制限への対処などのために、 本来制約のないメンバー型の値に対して、実装固有の制限を 設ける必要があります。

ウェブアプリケーションには一般に ECMAScript、HTML、CSS ファイル、 およびその他のメディアが含まれ、これらはサンドボックス化された環境で実行されます。 したがって、実装者は、自らがサポートする型に関するセキュリティ上の影響を 認識する必要があります。特に、実装者は、少なくとも次の 仕様で概説されているセキュリティ上の考慮事項を検討する必要があります： [CSS-MIME]、[ECMAScript-MIME]、[HTML]。

この仕様では、マニフェストの特定のメンバー内で URL を宣言できるため、 実装者は、[URL]仕様で説明されている セキュリティ上の考慮事項を検討する必要があります。 マニフェスト内で検出されたIRIおよび IDNAアドレスを表示しようとする実装には、 [UNICODE-SECURITY]に示された セキュリティ上の助言に従うことが強く推奨されます。

開発者は、[CSP3]仕様全体で説明されている セキュリティ上の考慮事項、特にマニフェストをインライン化する目的で data:を有効なソースとすることに関する事項を認識する必要があります。 そうすると、マニフェストを文書自体に直接含めることが可能になるため、 XSS 攻撃を有効にする可能性があります。これは完全に避けることが最善です。

エンドユーザーがウェブアプリケーションをインストールすることを可能にする UI では、 ウェブアプリケーションに関するアイコン、名前、開始 URL、オリジンなども確認できるようにすることが 推奨されます。 これは、エンドユーザーがウェブアプリケーションをインストールする前に、 それに関する情報を承認し、必要に応じて変更するかどうかを 意識的に判断する機会を与えるためです。また、たとえば、 予期しないアイコンや名前が使用されているかどうかを確認することで、 ウェブアプリケーションが別のウェブアプリケーションになりすましているかを エンドユーザーが見分ける機会も得られます。

ウェブアプリケーションの実行中は、オリジン、開始 URL や現在の URL、 付与された権限、関連付けられたアイコンなど、ウェブアプリケーションに関する 一般的な情報へアクセスする手段を、ユーザーエージェントが エンドユーザーに提供することが推奨されます。 このような情報をエンドユーザーにどのように提示するかは、実装者に委ねられます。

さらに、表示 モードを「browser」以外に設定するマニフェストを 適用する場合、ユーザーエージェントが、ウェブブラウザーの通常の閲覧コンテキストから 離れることをエンドユーザーに明確に示すことが推奨されます。 理想的には、ウェブアプリケーションの起動または切り替えは、 ホストプラットフォーム上の他のアプリケーションを起動または切り替える方法と 一貫した方法で行われます。たとえば、長く明確な アニメーション遷移を使用するか、「アプリケーション X を起動しています」というテキストを読み上げます。

displayメンバーにより、オリジンはユーザーエージェントの ネイティブ UI をある程度制御できます。全画面を占有した後、 別のアプリケーションのユーザーインターフェイスを模倣しようとする可能性があります。 これは、'display-mode'メディア特性 [MEDIAQUERIES-5]によっても容易になります。この機能を通じて、 スクリプトはウェブアプリケーションの表示モードを知ることができます。

A. IANAに関する考慮事項

MIMEタイプ application/manifest+json は、アプリケーションマニフェストメディアタイプです。 MIMEタイプと.webmanifest ファイル拡張子は Internet Assigned Numbers Authority (IANA)に登録されています。

A.1 メディアタイプ登録

マニフェストが転送されるプロトコルが [MIME-TYPES] 仕様（例：HTTP）をサポートする場合、マニフェストには アプリケーションマニフェストメディアタイプ でラベル付けすることが推奨されます。

タイプ名:
application
サブタイプ名:
manifest+json
必須パラメータ:
該当なし
オプションパラメータ:
該当なし
エンコーディングに関する考慮事項:
application/json と同じ ([RFC7159] セクション 8.1)
プライバシーとセキュリティの考慮事項:
7. プライバシーとセキュリティの考慮事項を参照。
この MIME タイプを使用するアプリケーション:
ウェブブラウザ
追加情報:
マジックナンバー:
該当なし
ファイル拡張子:
.webmanifest
Macintoshファイルタイプコード:
TEXT
詳細情報の問い合わせ先（氏名・メールアドレス）:
Web Applications Working Group へ public-webapps@w3.org で問い合わせ可能です。
用途:
COMMON
利用制限:
なし
著者:
W3C の Web Applications Working Group.
変更管理者:
W3C.

B. 適合性

非規範的と記載されたセクションに加え、この仕様のすべての著作ガイドライン、図、例、および注も非規範的です。それ以外の全ては規範的です。

この文書内のキーワード MAY、MUST、MUST NOT、OPTIONAL、RECOMMENDED、SHOULD、および SHOULD NOT は、 BCP 14 [RFC2119] [RFC8174] に記載された通り、ここで示すように全て大文字で現れる場合にのみ、その意味で解釈されます。

この仕様に適合していると主張できる製品のクラスは一つだけです：ユーザーエージェントです。

注

この仕様は主にウェブブラウザを対象としていますが、他のソフトウェアでも適合的に実装することは可能です。例えば、検索エンジンやクローラーはマニフェストを見つけて処理し、インストール可能なウェブアプリとして機能するサイトのカタログを作成できます。

B.1 拡張性

このセクションは非規範的です。

この仕様は拡張可能となるよう設計されています。他の仕様がマニフェストに新しいメンバーを定義することを推奨します。ただし、その際は本仕様の慣習に従ってください。特に、処理拡張ポイントを使ってマニフェストの処理手順にフックしてください。また、各メンバーの処理手順も本仕様の方式に従って必ず明記してください。これはプラットフォームの一貫性維持に役立ちます。

コミュニティが拡張を簡単に見つけられるよう、Extensions Registryに拡張を追加してください。

新しいメンバーを仕様化する際は、この仕様で定義された内容を上書きしたりモンキーパッチしないでください。 また、他のメンバーより先に/後に自分のメンバーが処理されると仮定しないでください。新しいメンバーとその処理は原子的・自己完結的に保ってください。さらに、実装は未認識または未サポートのメンバーを自由に無視できます。

編集者が仕様を暫定的にパッチして実装を進めたい場合は、バグを登録し、編集者の意図をコミュニティに周知してください。

B.1.1 独自マニフェストメンバー

このセクションは非規範的です。

独自拡張は望ましくありませんが、現実的には回避できません。ユーザーエージェントが本仕様で規定されていないマニフェストJSONのメンバーを解釈する場合、注意して実装してください。

独自拡張を追加する実装者は、その拡張が標準化の可能性があるか（例：他プラットフォームのユーザーエージェントでも利用価値があるか）を検討してください。もしそうならAPIはベンダー中立で設計し、標準提案してください。もし本当に独自（特定エコシステム専用）なら、その短縮名でプレフィックスし名前衝突を防いでください。

将来標準化されたら削除されることを前提としたベンダープレフィックスは使わないでください（それらは永遠に残りがちです）。今後も意味のあるプレフィックスのみ使ってください。

実装者は独自拡張をExtensions Registryに追加してください。これによりコミュニティが各ベンダーやウェブコミュニティの定義拡張を追跡できます。定期的に標準化候補として検討します。

以下は仮想の独自拡張3例です。

例 13: 独自拡張 
{
  ...
  "kpl_fancy_feature": "some/url/img",
  "gmpc_awesome_thing": { ... },
  "blitzly_site_verification": "KEY_9864D0966935"
  ...
}
注

この例では、（架空の）外部サイトやサービス名を意図的に使っています。これはブラウザやベンダーのプレフィックスではなく、独自サービスのプレフィックスです。

C. アプリケーション情報

このセクションは非規範的です。

Web Application Manifestの複数のメンバーは、ウェブアプリケーションがデジタルストアフロント、インストールダイアログ、その他配布・マーケティングされる可能性がある場面での表示に関する追加メタデータを提供します。これらのユースケース対応強化のため、以下のメンバーはWeb App Manifest - Application Informationに移されました：

E. JSONスキーマ

このセクションは非規範的です。

マニフェスト文書の検証に関心のある開発者は、 schemastore.org で非公式のマニフェスト形式用の JSON スキーマを参照できます。これは Apache 2.0 の下でライセンスされています。これは Mads Kristensen によって厚意で保守されています。開発者が JSON スキーマに問題を見つけた場合は、GitHub の SchemaStore リポジトリでバグを報告してください。

F. 国際化に関する考慮事項

この節は非規範的です。

著者は、次のいずれかの方法を使用してマニフェストの内容を ローカライズすることが想定されています。

マニフェスト内のローカライズされた値：

著者は、対応する *_localized メンバー （たとえば、name_localized）を使用して、マニフェストのローカライズ可能なメンバーにローカライズされた値を指定できます。 個々のローカライズされたエントリーは、文字列またはローカライズされたテキストオブジェクトにできます。ローカライズされたテキストオブジェクトは、その lang および dir プロパティを使用して、独自の自然言語およびテキスト方向の メタデータを指定でき、マニフェスト全体のlang および dir メンバーによって指定されるデフォルトを上書きします。

ユーザーエージェントは、ローカライズされた値を次のいずれかの 方法で処理してもよいものとします。

パススルーローカライゼーション：
ユーザーエージェントは、インストール時にすべてのローカライズされた値 （言語マップ全体）をホストオペレーティングシステムへ渡します。ユーザーが OS レベルで優先言語を変更すると、ホスト OS は、ユーザーエージェントを実行することなく、 更新されたローカライズ済みの値（たとえば、 アプリケーション名）を直ちに提示できます。
オンデマンド／更新時の評価：
ユーザーエージェントは、解析時にユーザーの現在のロケールに基づいて ローカライズされた値を評価します。ユーザーがシステム 言語を変更しても、アプリのプロパティは直ちには更新されません。代わりに、 ユーザーが次にアプリケーションへアクセスしたとき、または バックグラウンドでの更新確認時に更新されます。これにより、ユーザーエージェントは、 ホストOSを更新する前に、 セキュリティ上重要な変更（名前の変更など）を検査し、 必要に応じてユーザーの確認を求めることができます。
言語を動的に設定する：
これには、たとえば、エンドユーザーに優先言語を尋ね、 その言語設定に基づいて文書へのマニフェストリンク関係を 動的に追加または置換することが含まれます （たとえば、"manifest.php?lang=fr" のような URL を使用します）。
サーバー側の言語ネゴシエーションまたはジオターゲティングを使用する：
ウェブアプリケーションをホストするサーバーは、ジオターゲティングを使用するか、 言語ネゴシエーションを実行することによって、エンドユーザーの言語を 事前に判定しようとする場合があります（たとえば、HTTP 「Accept-Language」ヘッダー [RFC9110]、またはカスタム HTTP ヘッダーを使用します）。 詳細およびベストプラクティスについては、W3C の 国際化に関する記事、ロケール設定に 使用される Accept-LanguageおよびHTTP ヘッダー、meta 要素、および言語情報を参照してください。

上記の選択肢を踏まえ、開発者は、エンドユーザーの 優先言語に関するプライバシーに注意する必要があります。エンドユーザーが ウェブアプリケーションに対して言語設定を明示的に示した場合 （すなわち、単にユーザーエージェントのデフォルト言語 設定を使用しているだけではない場合）、エンドユーザーの優先言語を 通信経路上で平文のまま送信することは、一般に適切ではありません。そうすると、 エンドユーザーに関する個人情報が明らかになります。そのため、開発者には、 ウェブアプリケーションに対する広範な監視の可能性を低減するために [TLS]を使用することが推奨されます [RFC7258]。

G. ユースケースと要求

本書は Installable Web Appsのユースケースと要求を取り扱っています。

H. 課題のまとめ

この仕様には記載されている課題はありません。

I. 変更履歴

このセクションは非規範的です。

初回の公開作業草案以降に行われた主な変更点は以下の通りです：

J. 謝辞

このセクションは非規範的です。

この文書は [HTML] 仕様のライセンスが許す範囲で、そのテキストを再利用しています。

Dave Raggett および Dominique Hazael-Massieux は HTML5Apps プロジェクトを通じて本仕様に貢献しました。

Claudio Gomboli はアイコン例画像の提供に貢献しました。

インディアナ大学ブルーミントンのセキュリティ研究者は、スコープ外ナビゲーションに関連する潜在的リスクを報告し、本仕様に貢献しました。

K. 索引

K.1 この仕様で定義されている用語

K.2 参照によって定義されている用語

L. 参考文献

L.1 規範的参考文献

[accname-1.2]
アクセシブルな名前および説明の計算 1.2. Bryan Garaventa; Melanie Sumner. W3C. 2026年5月29日. W3C 作業草案. URL: https://www.w3.org/TR/accname-1.2/
[BCP47]
言語を識別するためのタグ. A. Phillips, 編者; M. Davis, 編者. IETF. 2009年9月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/info/rfc5646/
[CSP3]
コンテンツセキュリティポリシーレベル 3. Mike West; Antonio Sartori. W3C. 2026年7月29日. W3C 作業草案. URL: https://www.w3.org/TR/CSP3/
[css-color-4]
CSS 色モジュールレベル 4. Tab Atkins Jr.; Chris Lilley; Lea Verou. W3C. 2026年7月28日. 候補勧告草案. URL: https://www.w3.org/TR/css-color-4/
[CSS-MIME]
text/css メディア型. H. Lie; B. Bos; C. Lilley. IETF. 1998年3月. 情報提供. URL: https://www.rfc-editor.org/info/rfc2318/
[css-syntax-3]
CSS 構文モジュールレベル 3. Tab Atkins Jr.; Simon Sapin. W3C. 2021年12月24日. 候補勧告草案. URL: https://www.w3.org/TR/css-syntax-3/
[dom]
DOM 標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://dom.spec.whatwg.org/
[ECMA-402]
ECMAScript 国際化 API 仕様. Ecma International. URL: https://tc39.es/ecma402/
[ECMAScript-MIME]
スクリプティングメディア型. B. Hoehrmann. IETF. 2006年4月. 情報提供. URL: https://www.rfc-editor.org/info/rfc4329/
[fetch]
Fetch 標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://fetch.spec.whatwg.org/
[HTML]
HTML 標準. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 現行 標準. URL: https://html.spec.whatwg.org/multipage/
[image-resource]
画像リソース. Aaron Gustafson; Rayan Kanso; Marcos Caceres. W3C. 2021年6月4日. W3C 作業草案. URL: https://www.w3.org/TR/image-resource/
[INFRA]
Infra 標準. Anne van Kesteren; Domenic Denicola. WHATWG. 現行標準. URL: https://infra.spec.whatwg.org/
[JSON]
JavaScript Object Notation（JSON）データ 交換形式. T. Bray, 編者. IETF. 2017年12月. インターネット標準. URL: https://www.rfc-editor.org/info/rfc8259/
[MEDIAQUERIES-5]
メディアクエリレベル 5. Tab Atkins Jr.; Florian Rivoal; Daniel Libby; Luke Warlow. W3C. 2026年2月19日. W3C 作業草案. URL: https://www.w3.org/TR/mediaqueries-5/
[MIME-TYPES]
多目的インターネットメール拡張 （MIME）第2部：メディア型. N. Freed; N. Borenstein. IETF. 1996年11月. 標準 草案. URL: https://www.rfc-editor.org/info/rfc2046/
[permissions]
権限. Marcos Caceres; Mike Taylor. W3C. 2025年10月6日. W3C 作業草案. URL: https://www.w3.org/TR/permissions/
[RFC2119]
要求レベルを示すために RFC で使用する キーワード. S. Bradner. IETF. 1997年3月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC7159]
JavaScript Object Notation（JSON）データ 交換形式. T. Bray, 編者. IETF. 2014年3月. 標準化提案. URL: https://www.rfc-editor.org/info/rfc7159/
[RFC8174]
RFC 2119 キーワードにおける大文字と小文字の曖昧さ. B. Leiba. IETF. 2017年5月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/info/rfc8174/
[SCREEN-ORIENTATION]
画面の向き. Marcos Caceres; Léonie Watson. W3C. 2026年7月24日. W3C 作業草案. URL: https://www.w3.org/TR/screen-orientation/
[UAX9]
Unicode 双方向 アルゴリズム. Manish Goregaokar मनीष गोरेगांवकर; Robin Leroy. Unicode Consortium. 2025年 8月13日. Unicode 標準付属書 #9. URL: https://www.unicode.org/reports/tr9/tr9-51.html
[UNICODE]
Unicode 標準. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[UNICODE-SECURITY]
Unicode のセキュリティに関する 考慮事項. Mark Davis; Michel Suignard. Unicode Consortium. 2014年9月 19日. Unicode 技術報告書 #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html
[URL]
URL 標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://url.spec.whatwg.org/
[UTS55]
Unicode ソースコードの 処理. Robin Leroy; Mark Davis. Unicode Consortium. 2024年1月29日. Unicode 技術標準 #55. URL: https://www.unicode.org/reports/tr55/tr55-5.html

L.2 参考情報文献

[FULLSCREEN]
Fullscreen API 標準. Philip Jägenstedt. WHATWG. 現行標準. URL: https://fullscreen.spec.whatwg.org/
[i18n-glossary]
国際化用語集. Richard Ishida; Addison Phillips. W3C. 2024年10月17日. W3C ワーキンググループノート. URL: https://www.w3.org/TR/i18n-glossary/
[manifest-app-info]
ウェブアプリマニフェスト－アプリケーション 情報. Aaron Gustafson. W3C. 2023年8月21日. W3C ワーキンググループノート. URL: https://www.w3.org/TR/manifest-app-info/
[mimesniff]
MIME スニッフィング標準. Gordon P. Hemsley. WHATWG. 現行標準. URL: https://mimesniff.spec.whatwg.org/
[RFC7258]
広範な監視は 攻撃である. S. Farrell; H. Tschofenig. IETF. 2014年5月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/info/rfc7258/
[RFC8246]
HTTP の不変レスポンス. P. McManus. IETF. 2017年9月. 標準化提案. URL: https://httpwg.org/specs/rfc8246.html
[RFC9110]
HTTP セマンティクス. R. Fielding, 編者; M. Nottingham, 編者; J. Reschke, 編者. IETF. 2022年6月. インターネット標準. URL: https://httpwg.org/specs/rfc9110.html
[SERVICE-WORKERS]
Service Workers ナイトリー. Monica CHINTALA; Yoshisato Yanagisawa. W3C. 2026年7月23日. 候補勧告草案. URL: https://www.w3.org/TR/service-workers/
[TLS]
Transport Layer Security（TLS）プロトコル バージョン 1.2. T. Dierks; E. Rescorla. IETF. 2008年8月. 標準化提案. URL: https://www.rfc-editor.org/info/rfc5246/