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

W3C作業草案

この文書の詳細情報
このバージョン:
https://www.w3.org/TR/2025/WD-appmanifest-20250903/
最新公開バージョン:
https://www.w3.org/TR/appmanifest/
最新編集者草案:
https://w3c.github.io/manifest/
履歴:
https://www.w3.org/standards/history/appmanifest/
コミット履歴
編集者:
Marcos Cáceres (Apple)
Kenneth Rohde Christiansen (インテル株式会社)
Diego González (マイクロソフト株式会社)
Daniel Murphy (Google合同会社)
Christian Liebel (Thinktecture AG)
以前の編集者:
Matt Giuca (Google合同会社) -
Anssi Kostiainen (インテル株式会社) -
Aaron Gustafson (マイクロソフト株式会社) -
Mounir Lamouri (Google合同会社)
Rob Dolin (マイクロソフト株式会社)
フィードバック:
GitHub w3c/manifest (プルリクエスト, 新規Issue, オープンIssue)
ブラウザサポート:
caniuse.com

Copyright © 2025 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.16.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 マニフェストのライフサイクル

このセクションでは、マニフェストの処理および 適用するマニフェストのためのアルゴリズムを定義します。

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

1.16.1 マニフェストの処理

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

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

注

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

マニフェストの処理の手順は、以下のアルゴリズムで示されます。 このアルゴリズムは URL document URL、URL manifest URL、および バイト列 bodyBytes を受け取ります。

  1. json を JSON バイトを Infra 値にパースし、bodyBytes を渡した結果とします。
  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 でなく、 かつ document の processed manifest の id が equal でない場合は、終了します。
  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. orientation メンバーの処理を json、manifest を渡して実行します。
  20. shortcuts メンバーの処理を json、manifest、manifest URL を渡して実行します。
  21. 処理拡張ポイント：このアルゴリズムのこのポイントで、独自やその他サポートされるメンバーを処理します。
  22. document の processed manifest を manifest に設定します。

1.16.2 カラーメンバーの処理

注: サポートされる色

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 を CSS カラーとして値をパースした結果とします。
  4. color が失敗の場合、終了します。
  5. color が、ユーザーエージェントが本質的に知っている情報のみで sRGB に変換できる場合、color を sRGB に変換します。
  6. color が sRGB の色でない場合、終了します。
  7. map[member] を color に設定します。

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

テキストメンバーの処理を行うには、順序付きマップ json、順序付きマップ map、および 文字列 member を使用します：

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

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

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

この場合、対応する [HTML] の手順と同等の保証を満たすために、ユーザーエージェントは少なくとも過去のある時点で以下を確認すべきです：

注: これらのチェックの理由

1.16.5 マニフェストの適用

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

注

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

アプリケーションコンテキストが、ユーザーエージェントがナビゲートしてディープリンクに移動した結果として作成された場合、ユーザーエージェントは直ちにディープリンクにナビゲートし、historyHandling を "replace" に設定しなければなりません。そうでない場合、アプリケーションコンテキストが作成された時点で、ユーザーエージェントは直ちにナビゲートしてstart URLに移動し、historyHandling を "replace" に設定しなければなりません。

注

1.16.6 マニフェストの更新

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

更新の目的において、以下のメンバーは セキュリティ上重要なメンバーです。これらはインストール時や起動画面で表示されます：

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

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

ユーザーエージェントは、セキュリティ上重要なメンバーへの変更をユーザーの明示的な許可なしに自動的に適用すべきではありません。

代わりに、ユーザーエージェントはセキュリティ上重要なメンバーへの変更を適切な管理オプションとともに提示し、ユーザーがウェブアプリケーションの更新について判断できるようにするべきです。

更新内容にセキュリティ上重要なメンバーの変更が含まれていない場合、ユーザーエージェントは変更を自動的に適用してもよいです。

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

注: ユーザーエージェントは部分的なアップデートを適用しません

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

各マニフェスト画像リソースは、ウェブアプリケーションの一部として概念的に含まれる画像リソースであり、オブジェクトを使用するメンバーの意味に応じて様々なコンテキスト（例：アプリメニューのアイコンなど）で使用するのに適しています。

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

ユーザーエージェントは、マニフェスト画像リソースに関連付けられた画像を、表示前にプラットフォームのビジュアルスタイルにより適合させるために修正してもよいです。例えば、角を丸めたり特定の色で塗るなどです。開発者は、こうした状況に備え、色の変更や角の切り捨てなどで重要な情報が失われないよう画像リソースを準備することが推奨されます。

2.1 purposeメンバー

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

マニフェスト画像リソースがアイコンとして使用される場合、 開発者は画像がホストOSで特別な目的（つまり統合の向上）のために使われることを示唆できます。 ユーザーエージェントは、アイコンをその目的以外で使用すべきではありません。

注

例えば、purposeが"monochrome"のアイコンは、バッジやピン留めアイコンなど、アプリのフルカラー起動アイコンとは視覚的に区別されるソリッド塗りのアイコンとして使われます。ユーザーエージェントはpurposeの値を、どこでどのように表示するかのヒントとして利用します。開発者が特に宣言しない限り、ユーザーエージェントはアイコンを任意の目的で使用できます。

アイコン目的は以下の通りです：

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

アイコン目的リストは、リスト « "monochrome", "maskable", "any" »です。

注

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

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

  1. json["purpose"]が存在しない、または json["purpose"]が文字列でない場合：
    1. set « "any" »を返す。
  2. keywordsをASCII空白で分割したjson["purpose"]の結果とする。
  3. purposesを新しいsetとして作成する。
  4. 各keywordについてkeywordsを反復する：
    1. アイコン目的リストがkeywordを含まない場合、 continue。
    2. それ以外なら、appendで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、text-direction defaultDirectionを与えます：

  1. 次のいずれかの場合はfailureを返す：
  2. urlを、URLパーサーで item["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. itemに"short_name"が存在し、かつitem["short_name"]が文字列なら、shortcut["short_name"]にitem["short_name"]を設定する。
  8. *_localizedテキストメンバーの処理をitem、shortcut、"short_name_localized"、defaultDirectionで実行する。
  9. itemに"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. インストール可能なウェブアプリケーション

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

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

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

注

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

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やユーザーエージェントの判断で、処理済みマニフェストを用いてウェブアプリケーションの起動手順を実行します。

注

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

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

target URLがある場合は、manifestのスコープ内でなければなりません。

他の仕様はこのアルゴリズムを独自の手順に置き換えてもよいです。置き換えはすべてのウェブアプリケーションの起動呼び出しに適用されます。

注

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

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

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

  1. target URLが与えられていない場合、target URLにstart 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メンバーが無い場合や無効な場合、ユーザーエージェントは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をサポートしていれば、それを返す。
注

上記のループは、どのモードのフォールバックチェーンにもbrowserが含まれ、すべてのユーザーエージェントがbrowser 表示モードをサポートする必要があるため、必ず値が返されます。

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

ユーザーエージェントは、ウェブアプリケーションに適用された表示モードを display-modeメディア特性 [MEDIAQUERIES-5]で反映しなければなりません。

注

ユーザーエージェントは実際に適用されている表示モード（マニフェストで宣言されたものとは限らない）を、 display-modeメディア特性でCSSやJavaScriptから取得できるようにします。 このメディア特性は、マニフェストが適用されていないウェブページの他の表示モードも反映します。例えば、エンドユーザーがページをフルスクリーンにした場合、ユーザーエージェントはCSSやスクリプトにこの変更を display-modeメディア特性で知らせます。

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. 国際化

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

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

マニフェスト内のローカライズ値:
著者はlocalized valueをローカライズ可能メンバーに設定できます。ユーザーエージェントはすべてのローカライズ値を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]
Accessible Name and Description Computation 1.2（アクセシブルネームと説明の算出 1.2）。Bryan Garaventa; Melanie Sumner。W3C。2025年6月17日。W3C作業草案。URL: https://www.w3.org/TR/accname-1.2/
[BCP47]
Tags for Identifying Languages（言語識別タグ）。A. Phillips（編集）；M. Davis（編集）。IETF。2009年9月。Best Current Practice。URL: https://www.rfc-editor.org/rfc/rfc5646
[CSP3]
Content Security Policy Level 3（コンテンツセキュリティポリシー レベル3）。Mike West; Antonio Sartori。W3C。2025年7月11日。W3C作業草案。URL: https://www.w3.org/TR/CSP3/
[css-color-4]
CSS Color Module Level 4（CSSカラー モジュール レベル4）。Chris Lilley; Tab Atkins Jr.; Lea Verou。W3C。2025年4月24日。CRD。URL: https://www.w3.org/TR/css-color-4/
[CSS-MIME]
The text/css Media Type（text/css メディアタイプ）。H. Lie; B. Bos; C. Lilley。IETF。1998年3月。Informational。URL: https://www.rfc-editor.org/rfc/rfc2318
[css-syntax-3]
CSS Syntax Module Level 3（CSS構文 モジュール レベル3）。Tab Atkins Jr.; Simon Sapin。W3C。2021年12月24日。CRD。URL: https://www.w3.org/TR/css-syntax-3/
[dom]
DOM Standard（DOM標準）。Anne van Kesteren。WHATWG。Living Standard。URL: https://dom.spec.whatwg.org/
[ECMA-402]
ECMAScript Internationalization API Specification（ECMAScript国際化API仕様）。Ecma International。URL: https://tc39.es/ecma402/
[ECMAScript-MIME]
Scripting Media Types（スクリプト メディアタイプ）。B. Hoehrmann。IETF。2006年4月。Informational。URL: https://www.rfc-editor.org/rfc/rfc4329
[fetch]
Fetch Standard（Fetch標準）。Anne van Kesteren。WHATWG。Living Standard。URL: https://fetch.spec.whatwg.org/
[HTML]
HTML Standard（HTML標準）。Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters。WHATWG。Living Standard。URL: https://html.spec.whatwg.org/multipage/
[image-resource]
Image Resource（画像リソース）。Aaron Gustafson; Rayan Kanso; Marcos Caceres。W3C。2021年6月4日。W3C作業草案。URL: https://www.w3.org/TR/image-resource/
[infra]
Infra Standard（Infra標準）。Anne van Kesteren; Domenic Denicola。WHATWG。Living Standard。URL: https://infra.spec.whatwg.org/
[JSON]
The JavaScript Object Notation (JSON) Data Interchange Format（JavaScriptオブジェクト記法（JSON）データ交換フォーマット）。T. Bray（編集）。IETF。2017年12月。Internet Standard。URL: https://www.rfc-editor.org/rfc/rfc8259
[MEDIAQUERIES-5]
Media Queries Level 5（メディアクエリ レベル5）。Dean Jackson; Florian Rivoal; Tab Atkins Jr.; Daniel Libby。W3C。2021年12月18日。W3C作業草案。URL: https://www.w3.org/TR/mediaqueries-5/
[MIME-TYPES]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types（MIME第2部：メディアタイプ）。N. Freed; N. Borenstein。IETF。1996年11月。Draft Standard。URL: https://www.rfc-editor.org/rfc/rfc2046
[permissions]
Permissions（権限）。Marcos Caceres; Mike Taylor。W3C。2025年6月24日。W3C作業草案。URL: https://www.w3.org/TR/permissions/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels（RFCで要求レベルを示すキーワードの使用）。S. Bradner。IETF。1997年3月。Best Current Practice。URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC7159]
The JavaScript Object Notation (JSON) Data Interchange Format（JavaScriptオブジェクト記法（JSON）データ交換フォーマット）。T. Bray（編集）。IETF。2014年3月。Proposed Standard。URL: https://www.rfc-editor.org/rfc/rfc7159
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words（RFC2119キーワードの大文字・小文字の曖昧さ）。B. Leiba。IETF。2017年5月。Best Current Practice。URL: https://www.rfc-editor.org/rfc/rfc8174
[SCREEN-ORIENTATION]
Screen Orientation（画面の向き）。Marcos Caceres。W3C。2023年8月9日。W3C作業草案。URL: https://www.w3.org/TR/screen-orientation/
[UAX9]
Unicode Bidirectional Algorithm（Unicode双方向アルゴリズム）。Manish Goregaokar マニッシュ・ゴレガオンカー; Robin Leroy。Unicode Consortium。2024年9月2日。Unicode Standard Annex #9。URL: https://www.unicode.org/reports/tr9/tr9-50.html
[UNICODE]
The Unicode Standard（Unicode標準）。Unicode Consortium。URL: https://www.unicode.org/versions/latest/
[UNICODE-SECURITY]
Unicode Security Considerations（Unicodeセキュリティの考慮事項）。Mark Davis; Michel Suignard。Unicode Consortium。2014年9月19日。Unicode Technical Report #36。URL: https://www.unicode.org/reports/tr36/tr36-15.html
[URL]
URL Standard（URL標準）。Anne van Kesteren。WHATWG。Living Standard。URL: https://url.spec.whatwg.org/
[UTS55]
Unicode Source Code Handling（Unicodeソースコードの取り扱い）。Robin Leroy; Mark Davis。Unicode Consortium。2024年1月29日。Unicode Technical Standard #55。URL: https://www.unicode.org/reports/tr55/tr55-5.html

L.2 参考情報文献

[FULLSCREEN]
Fullscreen API Standard（フルスクリーンAPI標準）。Philip Jägenstedt。WHATWG。Living Standard。URL: https://fullscreen.spec.whatwg.org/
[i18n-glossary]
Internationalization Glossary（国際化用語集）。Richard Ishida; Addison Phillips。W3C。2024年10月17日。W3C作業部会ノート。URL: https://www.w3.org/TR/i18n-glossary/
[manifest-app-info]
Web App Manifest - Application Information（Web App Manifest - アプリケーション情報）。Aaron Gustafson。W3C。2023年8月21日。W3C作業部会ノート。URL: https://www.w3.org/TR/manifest-app-info/
[mimesniff]
MIME Sniffing Standard（MIMEスニッフィング標準）。Gordon P. Hemsley。WHATWG。Living Standard。URL: https://mimesniff.spec.whatwg.org/
[RFC7258]
Pervasive Monitoring Is an Attack（広範な監視は攻撃である）。S. Farrell; H. Tschofenig。IETF。2014年5月。Best Current Practice。URL: https://www.rfc-editor.org/rfc/rfc7258
[RFC9110]
HTTP Semantics（HTTPセマンティクス）。R. Fielding（編集）；M. Nottingham（編集）；J. Reschke（編集）。IETF。2022年6月。Internet Standard。URL: https://httpwg.org/specs/rfc9110.html
[SERVICE-WORKERS-1]
Service Workers（サービスワーカー）。Yoshisato Yanagisawa; Monica CHINTALA。W3C。2025年3月6日。CRD。URL: https://www.w3.org/TR/service-workers/
[TLS]
The Transport Layer Security (TLS) Protocol Version 1.2（TLSプロトコル バージョン1.2）。T. Dierks; E. Rescorla。IETF。2008年8月。Proposed Standard。URL: https://www.rfc-editor.org/rfc/rfc5246
[webidl]
Web IDL Standard（Web IDL標準）。Edgar Chen; Timothy Gu。WHATWG。Living Standard。URL: https://webidl.spec.whatwg.org/