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

W3C作業草案

このドキュメントの詳細情報
このバージョン：
https://www.w3.org/TR/2026/WD-appmanifest-20260507/
最新公開バージョン：
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 であると仮定します：

  • 1つ目のショートカットは "Play Later" というテキストで表示されます。OS がコンテキストメニュー項目用アイコンをサポートしており、SVG画像も利用できる場合、ユーザーエージェントは https://example.com/icons/play-later.svg をテキストの横に表示します。起動時、ユーザーエージェントは新しい トップレベル閲覧コンテキスト を生成し、 https://example.com/play-later に遷移します。
  • 2つ目のショートカットは "Subscriptions" というテキストで表示されます。起動時、ユーザーエージェントは新しい トップレベル閲覧コンテキスト を生成し、 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 列挙型のいずれかで、 本仕様では orientation値 （"any"、"natural"、"landscape"、"portrait"、"portrait-primary"、"portrait-secondary"、"landscape-primary"、"landscape-secondary"）です。

ユーザーエージェントが orientation メンバーの値を デフォルト画面向きとしてサポートしている場合、 その値はウェブアプリケーションの存続期間中（実行時に他の手段で上書きされない限り）デフォルト画面向きとなります。 つまり、ユーザーエージェントは orientation がアンロックされるたび [SCREEN-ORIENTATION] や トップレベル閲覧コンテキスト の ナビゲート時に、 デフォルト画面向き に戻さなければなりません（MUST）。

注

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

UI/UXの制約やプラットフォーム慣習によって、ある画面向きと 同時に使えないものがあります。 どの画面向きと表示モードが同時に使えないかは実装者の裁量です。例えば、あるユーザーエージェントでは browser display mode 中は アプリケーションのデフォルト画面向きを変更する意味がない場合があります。

注

ウェブアプリケーションが実行されている間は、他の手段（[SCREEN-ORIENTATION] APIなど）でも トップレベル閲覧コンテキスト の向きを変更できます。

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

  1. json["orientation"] が 存在しない場合、または json["orientation"] が 文字列でない場合は、return。
  2. 先頭と末尾のASCIIホワイトスペースを除去する json["orientation"] から。
  3. ASCII小文字化する json["orientation"] を。
  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形式で、start URL と同一オリジンです。

識別子は、ユーザーエージェントがアプリケーションをユニバーサルに一意に識別するために利用されます。ユーザーエージェントが、既にインストールされているアプリケーションと一致しない 識別子 を持つマニフェストを見つけた場合、それを別個のアプリケーションとして扱うべきです（SHOULD）、たとえ他のアプリと同じURLから提供されていても。ユーザーエージェントが、manifest["id"] が既存アプリの 識別子 と 等しい（フラグメント除外オプションを任意で設定）場合は、 そのマニフェストを既存アプリのマニフェストの置き換えとみなし、別のアプリとして扱わない（SHOULD）、たとえ以前と異なるURLから提供されていても。

注: フラグメント除外はベストプラクティス
注

識別子 は、ウェブアプリケーション一覧を収集するサービスなどでアプリを一意に識別するために使えます。

注

識別子 はURLとして処理されますが、リソースへのナビゲート先ではないため、scope内である必要はありません。

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

  1. manifest["id"] に manifest["start_url"] を設定する。
  2. json["id"] の型が 文字列 でない場合は return。
  3. json["id"] が空文字列なら return。
  4. base origin を manifest["start_url"] の origin に設定する。
  5. id に json["id"] を base origin を基準にパースした結果を設定する。
  6. id が失敗の場合は return。
  7. id が manifest["start_url"] と同一オリジンでなければ return。
  8. id の fragment を 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メンバーには 言語マップが入り、 アプリケーション内で指定したローカライズ可能メンバーの ローカライズ値を定義します。ユーザーエージェントは、ユーザーのローカライズ設定に従って ローカライズ値のうち、 言語タグキーが最も一致するものを選択すべきです（SHOULD）。 該当するローカライズ値がない場合は、 デフォルト表現を使用します。

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

ローカライズテキストオブジェクトは、以下のプロパティを持つ 順序付きマップです：

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

文字列を受け付けるローカライズ可能メンバーに対しては、 *_localized メンバーの 言語マップに、文字列または ローカライズテキストオブジェクトを ローカライズ値として指定できます。

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

注

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

注

*_localized テキストメンバーの処理は、順序付きマップ json、順序付きマップ map、 文字列 member、 defaultDirection を受け取る：

  1. member が json に存在しない場合は return。
  2. languageMap を json[member] とする。
  3. languageMap が 順序付きマップでない場合は return。
  4. languageTags を languageMap のキーとする。
  5. map[member] に新しい 順序付きマップをセットする。
  6. languageTags の各 languageTag に対して、 process a localized text object を languageMap[languageTag], languageTag, map, member, defaultDirection で呼び出す。

ローカライズテキストオブジェクトの処理は、文字列 または 順序付きマップ localizedValue、 defaultLanguageTag、 map、 member、 defaultDirection を受け取る：

  1. normalizedValue を 順序付きマップとして作成。
  2. localizedValue が 文字列の場合、 先頭と末尾のASCIIホワイトスペースを除去し、 normalizedValue["value"] にセット。
  3. localizedValue が 順序付きマップの場合：
    1. "value" が存在し、かつ 文字列なら、先頭と末尾のASCIIホワイトスペースを除去し、 normalizedValue["value"] にセット。
    2. "lang" が存在し、かつ 文字列なら、先頭と末尾のASCIIホワイトスペースを除去し、 normalizedValue["lang"] にセット。
    3. "dir" が存在し、かつ 文字列なら：
      1. 先頭と末尾のASCIIホワイトスペースを除去。
      2. text-direction list が 含む場合は normalizedValue["dir"] にセット。
  4. "value" が normalizedValue に存在しない場合は return。
  5. "lang" が normalizedValue に存在しない場合は normalizedValue["lang"] に defaultLanguageTag をセット。
  6. "dir" が normalizedValue に存在しない場合は normalizedValue["dir"] に defaultDirection をセット。
  7. IsStructurallyValidLanguageTag を normalizedValue["lang"] または defaultLanguageTag で呼び出し false なら return。
  8. map[member][defaultLanguageTag] に normalizedValue をセット。
注

ローカライズテキストオブジェクトの処理アルゴリズムは、 文字列と ローカライズテキストオブジェクトの両方を ローカライズ値として受け取れますが、処理後は ローカライズテキストオブジェクトの value、lang、 dir がセットされた状態で正規化されます。

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

リスト形式で画像リソースを受け付けるローカライズ可能メンバーの場合は、 *_localized メンバーの 言語マップに 画像リソースのリストを ローカライズ値として指定できます。

*_localized 画像リソースメンバーの処理は、 順序付きマップ json、 順序付きマップ map、 文字列 member、 manifest URL manifest URL を受け取る：

  1. member が json に存在しない場合は return。
  2. languageMap を json[member] とする。
  3. languageMap が 順序付きマップでない場合は return。
  4. languageTags を languageMap のキーとする。
  5. map[member] に新しい順序付きマップをセット。
  6. languageTags の各 languageTag に対して：
    1. IsStructurallyValidLanguageTag を languageTag に対して呼び出し 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 マニフェストの処理

無視するよう指示された場合、ユーザーエージェントは、 その条件を引き起こしたマニフェスト、メンバー、または値が存在しないかのように 振る舞わなければなりません (MUST)。

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

Note

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

マニフェストの処理の手順は、次のアルゴリズムによって示されます。 このアルゴリズムは、URL ドキュメントのURL、 URL マニフェストのURL、 バイト列 bodyBytes、および client（環境設定オブジェクト または null）を受け取ります。

  1. json を、bodyBytes を渡して JSON バイト列を Infra 値にパースする 結果とします。
  2. json がパース例外であるか、json が 順序付きマップでない場合：
    1. json を空の 順序付きマップ に設定します。
  3. manifest を空の 順序付きマップとします。
  4. dir メンバーを処理し、 json と manifest を渡します。
  5. lang メンバーを処理し、 json と manifest を渡します。
  6. テキストメンバーを処理し、 json、manifest、"name" を渡します。
  7. *_localized テキストメンバーを処理し、 json、 manifest、 "name_localized"、 および manifest["dir"] を渡します。
  8. テキストメンバーを処理し、 json、manifest、"short_name" を渡します。
  9. *_localized テキストメンバーを処理し、 json、 manifest、 "short_name_localized"、 および manifest["dir"] を渡します。
  10. start_url メンバーを処理し、 json、 manifest、 manifest URL、 document URL を渡します。
  11. id メンバーを処理し、 json と manifest を渡します。
  12. document の 処理済みマニフェスト (processed manifest) が null でなく、かつその 処理済みマニフェスト の id が 等しくない場合、 manifest["id"] に対して、処理を終了します。
  13. scope メンバーを処理し、 json、 manifest、 manifest URL を渡します。
  14. 色メンバーを処理し、 json、 manifest、 "theme_color" を渡します。
  15. 色メンバーを処理し、 json、 manifest、 "background_color" を渡します。
  16. display メンバーを処理し、 json と manifest を渡します。
  17. 画像リソースを処理し、 json["icons"]、 manifest、 manifest URL、 "icons" を渡します。
  18. *_localized 画像リソースメンバーを処理し、 json、 manifest、 "icons_localized"、 manifest URL を渡します。
  19. color_scheme_dark メンバーを処理し、 json、 manifest、 manifest URL を渡します。
  20. orientation メンバーを処理し、 json、 manifest を渡します。
  21. shortcuts メンバーを処理し、 json、 manifest、 manifest URL を渡します。
  22. 処理拡張ポイント： この時点で、任意の独自メンバーやその他サポートされるメンバーを処理します。
  23. manifestのクライアントを clientに設定します。
  24. document の 処理済みマニフェスト (processed manifest) を 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 マニフェストの適用

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

ユーザーエージェントは、既存の トップレベルの閲覧コンテキストに対して マニフェストを適用することも できます (MAY)。 その場合、アクティブドキュメントの URL が、 マニフェストの スコープ内 (within scope) であれば、その既存の トップレベルの閲覧コンテキストは アプリケーションコンテキスト (application context) になります。 もし URL が スコープ内でない場合、 結果の挙動は実装依存です。

Note
Note

マニフェストが適用された トップレベルの閲覧コンテキストは、 アプリケーションコンテキスト (application context)と呼ばれます。

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

Note

1.17.6 マニフェストの更新

manifest リンク関係で規定されているように、マニフェストは ページロードごとに取得され、処理されます。 マニフェストの処理が成功した場合、 ユーザーエージェントは、 そのアプリケーションに関連付けられた現在および将来の アプリケーションコンテキストに対して、 更新されたマニフェストを適用することが できます (MAY)。

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

Note: アイコンメタデータの変更

更新の目的において、次のメンバーはインストール時および起動時の表示に用いられるため、 セキュリティ上センシティブなメンバー (security-sensitive members) と見なされます：

  1. short_name と short_name_localized におけるローカライズされた表現。
  2. icons と icons_localized におけるローカライズされた表現。
  3. name と name_localized におけるローカライズされた表現。

マニフェストのその他すべてのメンバーは、 セキュリティ上センシティブでないメンバー (non-security-sensitive members) と見なされます。

セキュリティ上センシティブな更新 (security-sensitive update)とは、 セキュリティ上センシティブなメンバーへの更新です。 それに対応して、 セキュリティ上センシティブでない更新 (non-security-sensitive update)とは、 セキュリティ上センシティブでないメンバーへの更新です。

型が マニフェスト画像リソース（例： icons）である 更新された セキュリティ上センシティブなメンバーを考慮する際、 その画像が見た目に大きく変わっていないとユーザーエージェントが判断した場合には、 それを セキュリティ上センシティブでない更新であると 見なすことが できます (MAY)。

ユーザーエージェントは、 すべての セキュリティ上センシティブでない更新を 直ちに適用することが 推奨されます (SHOULD)。

ユーザーエージェントは、 すべての セキュリティ上センシティブな更新を ユーザーに提示し、 変更を適用する前に 明示的な許可 (express permission) を 要求することが 推奨されます (SHOULD)。

Note: 更新時にユーザーへ提示されるオプション例

セキュリティ上センシティブなメンバーは、 その方向性に関わらず、 [UTS55] で説明されているように、 双方向にアイソレートされた形で表示されるべきであると 推奨されます (SHOULD)。

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

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

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

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

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

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

  1. もし manifestのclientが null であれば、null を返します。
    注
  2. requestを新しいリクエストとして作成します。
  3. requestのURLを、imageのsrcに設定します。
  4. requestのdestinationを "image" に設定します。
  5. requestのclientを、manifestのclientに設定します。
  6. imageおよびrequestを使った画像リソースの取得の結果を返します。
注

2.1 purposeメンバー

purpose メンバーは 空白区切りの一意なトークンの順不同セット です。許可される値は icon purposes です。

manifest image resource がicon として使われる場合、 開発者は、その画像がホストOSのコンテキストで （より良い統合のために）特別な用途を持つことを示唆できます。 ユーザーエージェントは 記載された icon purpose 以外でそのアイコンを 使うべきではありません。

Note

例えば、purposeが"monochrome"のアイコンは バッジやピン留めアイコンとしてソリッドで表示でき、 アプリケーションのフルカラーのランチアイコンとは視覚的に区別されます。 ユーザーエージェントは purpose メンバーの値を表示場所・方法の ヒントに用います。 開発者により明示的に指定がない限り、 ユーザーエージェントは アイコンをany purpose に利用できます。

icon purposesは以下のとおりです：

monochrome
ユーザーエージェントが ソリッドな単色アイコン が必要な場面でこのアイコンを表示できます。 アイコン内の色情報は破棄され、 アルファデータのみ利用されます。 その後ユーザーエージェントは このアイコンを任意のソリッド塗りつぶし上のマスクとして使えます。
maskable
この画像は アイコンマスクとセーフゾーン を考慮して設計されており、 画像内のセーフゾーン外の部分はユーザーエージェントにより安全に無視・マスクできます。
any (デフォルト)
ユーザーエージェントは、purpose が不要な場所で自由にこのアイコンを表示できます。 例えば、manifest image resource に"any"が指定されている場合、 "monochrome"が必要なコンテキストでは利用されません。

icon purposes listは、 リスト « "monochrome", "maskable", "any" »。

Note

複数のpurposeを持つアイコンは、それらのいずれについても利用可能です。指定purposeがひとつも認識されない場合、そのアイコンは完全に無視されます。 例えば、アイコンのpurposeが "monochrome fizzbuzz" ならば、"monochrome"は有効なpurposeなので単色アイコンとして利用され得ますが、 purposeが"fizzbuzz"だけの場合は無視されます。

画像の目的を決定するには、順序付きマップ json が与えられたとき：

  1. json["purpose"] が 存在しない、または json["purpose"] が 文字列でない場合：
    1. set « "any" » を返す。
  2. keywords を、 ASCII空白で分割した json["purpose"] の結果とする。
  3. purposes を新しい set とする。
  4. keywords の各 keyword について：
    1. icon purposes list が keyword を 含まない場合は 次へ。
    2. そうでなければ、 keyword を purposes に追加する。
  5. purposes が 空である場合、failure を返す。
  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. インストール可能なウェブアプリケーション

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

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

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

Note

たとえば、インストールをサポートするユーザーエージェントにおいては、 ウェブアプリケーションはエンドユーザーからネイティブアプリのように見える形で表示や起動が可能です。 たとえばホーム画面、ランチャー、スタートメニューにラベル付きアイコンとして表示できるなどです。 ウェブアプリケーションを起動 すると、ユーザーエージェントはマニフェストを 適用し、 トップレベル閲覧コンテキスト で開始URLが読み込まれる前に反映します。 これによりユーザーエージェントは、 表示モードdisplay modeや 画面の向きなど、マニフェストの値を適用・変更する機会が得られます。 あるいは別の例として、ユーザーエージェント自身のブックマークリストに インストールする形でも対応できます。

4.1 アプリケーション名

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

nameメンバーまたはshort_nameメンバーが不足・空・型違いの場合、ユーザーエージェントはnameメンバーをshort_nameの代用に、またはshort_nameメンバーをnameの代用に使用してもよいです。

nameもshort_nameも不足・空・型違いの場合、ユーザーエージェントはDocumentから適切な代用を探してもよいです（例：application-nameをnameやshort_nameの代用に利用）。または、プラットフォームの慣習に従うデフォルト名（例："Untitled"）をユーザーエージェントが割り当てすべきです。または、ユーザーエージェントがエンドユーザーに入力させることもできます。

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 を 新しいトップレベルtraversableを作成手順で target URL および POST resource を渡して得る。
  3. browsing context を traversable の アクティブなブラウジングコンテキストとする。
  4. manifest を適用し、 browsing context に反映する。
  5. browsing context を返す。

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

エンドユーザーがウェブアプリケーションをインストールできるUIでは、アイコン、名前、start URL、オリジン等を確認・編集できるようにすることが推奨されます。これは、ユーザーがインストール前にその情報を承認・修正できるようにし、またアプリが意図しないアイコンや名前で他のウェブアプリを偽装していないか判別する機会を与えます。

ユーザーエージェントは、他のアプリケーションがシステムにインストールされているアプリを判別できないようにすることが推奨されます（例：ユーザーエージェントのキャッシュへのタイミング攻撃）。例えば、インストール後にユーザーエージェントのキャッシュからマニフェストにリンクされたリソース（アイコン等）を無効化する、あるいは通常のウェブ閲覧用とは別のキャッシュを使うなどの方法が考えられます。

4.4 アンインストール

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

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

6. 表示モード

表示モードは、 ウェブアプリケーションがOS上でどのように表示されるかを示します（例：フルスクリーンなど）。 表示モードは、各プラットフォームで使われるユーザーインターフェース（UI）や機能に対応しています。表示モードのUI慣習はあくまで参考であり、実装者は自由に解釈できます。

この仕様では、以下の表示モードを定義します：

fullscreen
ブラウザのUI要素を非表示にし、利用可能な表示領域全体をウェブアプリケーションで埋め尽くします。
standalone
ウェブアプリケーションをスタンドアロンのネイティブアプリのように表示します。これには、アプリが別ウィンドウや独自アイコンを持つことなどが含まれます。 このモードでは、ユーザーエージェントは標準のブラウザUI（URLバーなど）を除外しますが、ステータスバーやシステムの戻るボタンなど、他のシステムUI要素は含めることができます。
minimal-ui
このモードはstandaloneに似ていますが、 最小限のUI要素（戻る、進む、リロード、アドレス表示など）をユーザーが操作できるようにします。 ユーザーエージェントは、プラットフォーム固有のUI要素（例：共有、印刷ボタンなど）も含めることができます。
browser （デフォルト）
ウェブアプリケーションを、ユーザーエージェントがハイパーリンクを開く際のプラットフォーム固有の方式（例：ブラウザタブや新規ウィンドウ）で表示します。
注

fullscreen 表示モードは、 Fullscreen API Standardとは独立して動作します。 fullscreen 表示モードはブラウザウィンドウのフルスクリーン状態に影響し、 [FULLSCREEN] APIはビューポート内の要素に対して動作します。 そのため、ウェブアプリの表示モードが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" »。

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

  1. 処理拡張ポイント：このタイミングで独自や他のサポートされる表示モードを処理します。
  2. ユーザーエージェントが manifest["display"] をサポートする場合、それを返す。
  3. 次の各 fallback_mode について フォールバックチェーンの manifest["display"]:
    1. ユーザーエージェントが fallback_mode をサポートする場合、それを返す。
Note

上記のループは browser がすべてのモードの フォールバックチェーンに含まれており、 かつすべてのユーザーエージェントが browser 表示モードをサポートすることが求められるため、 必ず値が返されます。

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

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

注記

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

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

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

マニフェストの形式は JSON であり、[UNICODE] を用いてエンコードされます。 したがって、[JSON] および [UNICODE-SECURITY] に記載されている セキュリティ考慮事項が適用されます。さらに、 マニフェスト に開発者がカスタム/制限のないデータを含めることを防ぐ手段がないため、 実装者は無制限な型の値について、サービス拒否攻撃の防止や メモリ不足対策、プラットフォーム特有の制限回避などのため、 実装依存の制約を独自に課す必要があります。

ウェブアプリケーションは通常、ECMAScript、HTML、CSSファイル、その他のメディアを含み、サンドボックス環境で実行されます。 したがって、実装者はサポートする型のセキュリティ影響を認識する必要があります。 特に、最低限以下の仕様で示されるセキュリティ影響を考慮する必要があります: [CSS-MIME]、 [ECMAScript-MIME]、 [HTML]。

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

この仕様ではマニフェストの特定メンバー内でURLの宣言が可能なため、 実装者は [URL] 仕様で論じられるセキュリティ上の注意を考慮する必要があります。 マニフェスト内で見つかった IRIs や IDNA アドレスを表示する実装は、 [UNICODE-SECURITY]に記載のセキュリティ助言に従うことが強く推奨されます。

開発者は [CSP3] 仕様全体で論じられるセキュリティ上の注意、とりわけ data: をマニフェストのインライン化のための有効なソースにすることについて注意する必要があります。 これによりマニフェストを文書内に直接含めることが可能となり、XSS攻撃を招く可能性があるため、完全に避けるのが最善です。

エンドユーザーがウェブアプリケーションをインストールできるUIでは、 アイコン、名前、start URL、オリジン等のアプリ情報を確認できることが 推奨されます。これは、ユーザーがインストール前にアプリ情報を承認・修正できる機会を与えるためです。 また、予期しないアイコンや名前などを使用して他のウェブアプリを偽装していないか見抜く機会も与えます。

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

ショートカットのurlが、アプリケーションがブラウザの外部から起動されたことを示すように細工される可能性があります （例："url": "/task/?from=homescreen"）。 また、開発者がurlにサーバー割り当ての UUID など ユーザーを一意に識別できる文字列を埋め込む可能性もあります。 これはフィンガープリンティングやプライバシーに関わる情報であり、ユーザーが気付かないことがあります。

ウェブアプリケーションが実行中は、ユーザーエージェントがオリジン、開始または現在のURL、許可された権限、関連アイコンなど よく使われるアプリ情報へのアクセス手段をエンドユーザーに提供することが推奨されます。 これら情報のエンドユーザーへの公開方法は実装者の裁量に任されます。

さらに、マニフェストでdisplay modeを "browser"以外に設定した場合、 ユーザーエージェントはエンドユーザーに通常のブラウザ閲覧コンテキストを離れることを明示することが 推奨されます。 理想的には、ウェブアプリの起動や切り替えは、ホストプラットフォーム上の他のアプリと同様の方法で行われるべきです。 例えば、長く明快なアニメーションによる遷移や「アプリXを起動します」と話すなど。

displayメンバーは、オリジンにユーザーエージェントのネイティブUIのある程度の制御を許します。 フルスクリーンを取得した後、他のアプリの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スキーマ

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

manifest文書のバリデーションに関心がある開発者は、マニフェスト形式の非公式JSONスキーマがschemastore.orgで公開されていることを参照できます。Apache 2.0ライセンスの下で配布され、Mads Kristensenによって管理されています。JSONスキーマに問題があれば、バグ報告をSchemaStoreリポジトリ（GitHub）にお願いします。

注: Web Manifest JSONスキーマ

F. 国際化

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

著者はマニフェストの内容を次のいずれかの方法でローカライズすることが期待されています：

マニフェスト内のローカライズ値:
著者は マニフェスト の ローカライズ可能なメンバー に、 ローカライズ値 を提供できます。 ユーザーエージェントはすべてのローカライズ値をホストOSに渡します。 ユーザーが OS レベルで ロケール を変更したとき、OS は インストール済みウェブアプリケーション のローカライズ済み値を更新して表示できます。
言語の動的設定:
例えば、エンドユーザーに希望言語を尋ね、それに基づきmanifestリンク関係を動的に追加・置換する（例："manifest.php?lang=fr"のようなURLを使う）などが含まれます。
コンテンツネゴシエーションやジオターゲティングなどサーバ側で設定:
ウェブアプリをホストするサーバはジオターゲティングやコンテンツネゴシエーション（例：HTTP "Accept-Language" ヘッダー [RFC9110] や独自ヘッダー）でエンドユーザーの言語を推測できます。

上記の選択肢を踏まえ、開発者はエンドユーザーの言語選好に関するプライバシーに注意すべきです：エンドユーザーがウェブアプリに明示的に希望言語を指定した場合（すなわちユーザーエージェントのデフォルト言語設定以外）、その情報を平文で送信するのは原則NGです。これは個人情報の漏洩につながり得ます。したがって、[TLS]を使い、Webアプリの監視リスクを低減することが推奨されます [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年4月30日. W3C作業草案. URL: https://www.w3.org/TR/accname-1.2/
[BCP47]
言語を識別するためのタグ. A. Phillips, Ed.; M. Davis, Ed. IETF. 2009年9月. 現行最良慣行. URL: https://www.rfc-editor.org/rfc/rfc5646
[CSP3]
コンテンツセキュリティポリシー レベル3. Mike West; Antonio Sartori. W3C. 2026年5月5日. W3C作業草案. URL: https://www.w3.org/TR/CSP3/
[css-color-4]
CSS カラー モジュール レベル 4. Tab Atkins Jr.; Chris Lilley; Lea Verou. W3C. 2026年5月2日. CRD. 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/rfc/rfc2318
[css-syntax-3]
CSS構文モジュール レベル3. Tab Atkins Jr.; Simon Sapin. W3C. 2021年12月24日. CRD. 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/rfc/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オブジェクト表現（JSON）データ交換形式. T. Bray, Ed. IETF. 2017年12月. インターネット標準. URL: https://www.rfc-editor.org/rfc/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/rfc/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/rfc/rfc2119
[RFC7159]
JavaScriptオブジェクト表現（JSON）データ交換形式. T. Bray, Ed. IETF. 2014年3月. 提案された標準. URL: https://www.rfc-editor.org/rfc/rfc7159
[RFC8174]
RFC2119における大文字と小文字の曖昧さ. B. Leiba. IETF. 2017年5月. 最良慣行. URL: https://www.rfc-editor.org/rfc/rfc8174
[SCREEN-ORIENTATION]
画面方向. Marcos Caceres. W3C. 2025年10月21日. 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]
Web App Manifest - アプリケーション情報。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/rfc/rfc7258
[RFC8246]
HTTP Immutable Responses. P. McManus. IETF. 2017年9月. Proposed Standard. 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 Nightly。Monica CHINTALA、Yoshisato Yanagisawa。W3C。2026年4月9日。CRD。URL: https://www.w3.org/TR/service-workers/
[TLS]
トランスポート層セキュリティ（TLS）プロトコル バージョン1.2。T. Dierks、E. Rescorla。IETF。2008年8月。提案標準。URL: https://www.rfc-editor.org/rfc/rfc5246
[webidl]
Web IDL 標準。Edgar Chen、Timothy Gu。WHATWG。リビングスタンダード。URL: https://webidl.spec.whatwg.org/