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

W3C作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2025/WD-appmanifest-20250505/
最新公開バージョン:
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 (Intel Corporation)
Diego González (Microsoft Corporation)
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)
フィードバック:
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標準・ドラフト一覧 （https://www.w3.org/TR/）にあります。

警告

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

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

本書はドラフト文書であり、今後随時更新・差し替え・廃止される可能性があります。他の文書の引用元として使用するのは適切ではありません（進行中の作業を除く）。

この文書は W3C 特許ポリシー に基づき作成されています。 W3Cは、 特許開示の公開リスト を管理しており、グループ成果物に関する開示もそのページに記載されています。特許開示方法についても記載されています。ある特許に関して「必須クレーム」が含まれていると認識した場合は、 W3C特許ポリシー第6節 に従って情報を開示してください。

この文書は 2023年11月03日 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と仮定します:

  • 最初のショートカットは「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/"やルート"/"は「スコープ外」となり、マニフェストはそれらのパスの文書には適用されません。スコープパスは一つのみサポートされます。技術的詳細は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 algorithm など）を使ってテキスト表示を推定するべきです。

テキスト方向リストは、リスト « "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"] に パースした "."（ベースURLは manifest["start_url"]）の結果を設定する。
  2. json["scope"] が空文字列なら return。
  3. scope に パースした json["scope"]（ベースURLは manifest URL）の結果を設定する。
  4. scope が失敗なら return。
  5. scope の query と fragment を null に設定する。
  6. manifest["start_url"] が スコープ内 でない場合 return。
  7. それ以外の場合、manifest["scope"] に scope を設定する。

1.7 icons メンバー

マニフェスト の icons メンバーは、ウェブアプリケーションを様々なコンテキストで象徴的に表現する画像です。例えば、他のアプリケーション一覧でウェブアプリケーションを表したり、OSのタスクスイッチャーやシステム設定などと統合したりするために使われます。

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

注

1.8 display メンバー

マニフェスト の display メンバーは、ウェブアプリケーションに対する開発者の好みの 表示モードを表します。値は 表示モードです。

display メンバーを処理するには、 順序付きマップ json と 順序付きマップ manifest を与えて：

  1. manifest["display"] に "browser" を設定する。
  2. json["display"] が 存在しない、または json["display"] が 文字列でない場合、return。
  3. 前後のASCII空白文字を除去する。 json["display"] から。
  4. ASCII小文字化 json["display"]。
  5. 表示モードリストが 含まない 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 メンバーの値を デフォルト画面向きとしてサポートしている場合、アプリケーションのライフサイクル中はそれが デフォルト画面向きとなります（ランタイムで他の手段で上書きされない限り）。 これは、ユーザーエージェントが MUST 画面の向きがアンロックされたときや トップレベル閲覧コンテキストが ナビゲートされたときに 画面向きをデフォルトに戻す必要があることを意味します。

注

この仕様は [SCREEN-ORIENTATION] の OrientationLockType に依存しますが、 ユーザーエージェントが [SCREEN-ORIENTATION] API を 実装することは OPTIONAL です。APIの実装は推奨されます。

UI/UX上の懸念やプラットフォームの慣例により、特定の画面向きと 同時に利用できない 組み合わせがあります。どの画面向きと表示モードの組み合わせが同時に利用できないかは実装者の裁量に委ねられます。例えば、ユーザーエージェントによっては デフォルト画面向きを browser 表示モード時に変更することが意味をなさない場合もあります。

注

ウェブアプリケーション実行中に、[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 メンバーはあくまで助言的なものであり、ユーザーエージェントはMAY 無視したり、エンドユーザーに利用しない選択肢を提供してもかまいません。ユーザーエージェントは、例えばウェブアプリケーションのブックマーク作成時やその後、ユーザーが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"]（ベースURLは manifest URL）の結果を設定する。
  5. start URL が失敗なら return。
  6. start URL が 同一オリジンでない場合、return。
  7. それ以外の場合、manifest["start_url"] に start URL を設定する。

1.10.1 プライバシーへの配慮：start_url のトラッキング

start_url が、アプリがブラウザ外から起動されたことを示すように作成されることが考えられます（例："start_url": "index.html?launcher=homescreen"）。 これは解析用途やカスタマイズに役立ちますが、開発者が start_url にユーザーを一意に識別できる文字列（例："?user=123"、"/user/123/"、"https://user123.foo.bar" など）を埋め込むことも考えられます。これはフィンガープリントやプライバシーに関する情報であり、ユーザーが気付かない場合があります。

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

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

上記を踏まえ、インストール時やその後いつでも、ユーザーエージェントはユーザーがアプリケーションの 開始URL を確認・必要に応じて修正できるようにすることをRECOMMENDEDします。

ユーザーエージェントはこの種のフィンガープリントに対し他の保護策を提供してもかまいません。例えば、ユーザーがオリジンからデータを消去した場合、ユーザーエージェントはそのオリジンの スコープ内 アプリケーションのアンインストールを提案し、アプリの開始URLからフィンガープリントを削除することができます。

1.11 id メンバー

マニフェスト の id メンバーは、文字列であり、 アプリケーションの識別子を表します。 識別子はURL形式であり、開始URLと同じオリジンです。

識別子はユーザーエージェントがアプリケーションを一意に識別するために使われます。ユーザーエージェントが未インストールの識別子を持つマニフェストを検出した場合、同じURLからでも別アプリとして扱うSHOULDです。既存アプリとmanifest["id"]が 等しい（フラグメント除外は任意）なら、マニフェストを既存アプリの置き換えとして扱うべきです。

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

識別子は、ウェブアプリケーション一覧を収集するサービスで一意なアプリIDとして利用できます。

注

識別子はURLとして処理されますが、ナビゲート可能なリソースを指すわけではないため、スコープ内である必要はありません。

id メンバーを処理するには、 順序付きマップ json、順序付きマップ manifest を与える：

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

1.12 theme_color メンバー

manifest の theme_color メンバーは、アプリケーションコンテキストの デフォルトテーマカラー として機能します。テーマカラー の定義は [HTML] に記載されています。

ユーザーエージェントが theme_color メンバーの値を デフォルトテーマカラー として尊重する場合、そのカラーが テーマカラー となり、manifest が ブラウジングコンテキスト に 適用 されたすべてで使用されます。ただし、ユーザーエージェントは MAY、デフォルトテーマカラー を上書きできます。これは、その document の URL が scope 内 であり、かつ application context の manifest に meta 要素が含まれており、その name 属性が "theme-color" である場合です。 ただし、ユーザーエージェントは SHOULD NOT デフォルトテーマカラー を meta 要素で上書きすべきではありません。その name 属性が "theme-color" であっても、 document の URL が scope 内 でない場合は、 アプリケーションがそれらの document を制御できないためです。

ユーザーエージェントは MAY、テーマカラー の アルファ成分 を状況に応じて無視することができます。例えば、多くの環境では テーマカラー は透明にできません。

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

注

manifest の処理 時には、 color メンバーを処理する アルゴリズムが theme_color メンバーの処理に使われます。

1.13 background_color メンバー

manifest の background_color メンバーはウェブアプリケーションの 期待される背景色を説明します。これは既にアプリケーションのスタイルシートで利用可能ですが、manifest が認識された際に ネットワークやディスクからファイルが取得される前にユーザーエージェントが ウェブアプリケーションの背景色を描画するために利用できます。

background_color メンバーは、 ウェブアプリケーションの読み込み中にユーザー体験を向上させるためだけに使われ、ユーザーエージェントは MUST NOT、ウェブアプリケーションのスタイルシートが利用可能になった際の 背景色として利用してはいけません。

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

注

manifest の処理 時には、 color メンバーを処理する アルゴリズムが background_color メンバーの処理に使われます。

1.14 shortcuts メンバー

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

注

ショートカットの表示方法や表示数は、ユーザーエージェントや OS の裁量に委ねられます。

shortcuts メンバーを処理するには、ordered map json、ordered map manifest、および URL manifest URL を用います:

  1. processedShortcuts を新しい リストとして作成します。
  2. Set manifest["shortcuts"] に processedShortcuts を設定します。
  3. もし json["shortcuts"] が 存在しない または json["shortcuts"] が リストでない場合、終了します。
  4. For each entry of json["shortcuts"]:
    1. shortcut を process a shortcut で処理します。 entry, manifest URL, manifest["scope"], および manifest["dir"] を渡します。
    2. もし shortcut が失敗なら、次へ。
    3. Append shortcut を processedShortcuts に追加します。

ユーザーエージェントは SHOULD、OS のアプリケーションアイコンのコンテキストメニューの表示と一貫性のある操作（例: 右クリック、長押し）で ショートカットを表示すべきです。また、manifest で指定された順序でショートカットを表示すべきです。 表示方法はOSの慣習や制限に合わせてショートカットのリストを省略・短縮しても MAY です。

1.15 *_localized メンバー

ローカライズ可能メンバーは、 manifest の中でローカライズできるメンバーです。 manifest の各 ローカライズ可能メンバーには、 *_localized メンバーが対応し、* は元のメンバー名になります。

言語マップは、 ordered map で、 キーが 言語タグ、値が ローカライズ値 です。 ローカライズ値は、キーで示された言語の内容です。

ローカライズ可能メンバーに設定された値が デフォルト表現です。 *_localized メンバーには 言語マップが格納され、 アプリケーション内の特定の ローカライズ可能メンバーに対する ローカライズ値 を定義します。ユーザーエージェントは SHOULD、ユーザーのロケール設定に最も合致する 言語タグ キーの ローカライズ値 を選択する必要があります。該当する ローカライズ値 がない場合は、 デフォルト表現 が利用されます。

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

ローカライズテキストオブジェクトは、 ordered map で、下記のプロパティを持ちます:

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

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

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

注

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

注

*_localized テキストメンバーを処理するには、 ordered map json、 ordered map map、 string member、および テキスト方向 defaultDirection を用います:

  1. もし member が json に存在しない場合、終了します。
  2. languageMap を json[member] とします。
  3. もし languageMap が ordered map でなければ、終了します。
  4. languageTags を languageMap のキーとします。
  5. map[member] に新しい ordered map を設定します。
  6. For each languageTag of languageTags について process a localized text object を呼び出し、 languageMap[languageTag]、languageTag、map、member、および defaultDirection を渡します。

ローカライズテキストオブジェクトを処理するには、stringまたは ordered map localizedValue、 string defaultLanguageTag、ordered map map、 string member、および テキスト方向 defaultDirection を用います:

  1. normalizedValue を ordered mapとして作成します。
  2. もし localizedValue が 文字列なら、 前後の ASCII 空白を除去し、 normalizedValue["value"] に設定します。
  3. もし localizedValue が ordered mapなら:
    1. "value" が 存在し、かつ localizedValue["value"] が 文字列なら 前後の ASCII 空白を除去し、 normalizedValue["value"] に設定します。
    2. "lang" が 存在し、かつ localizedValue["lang"] が 文字列なら 前後の ASCII 空白を除去し、 normalizedValue["lang"] に設定します。
    3. "dir" が 存在し、かつ localizedValue["dir"] が 文字列なら:
      1. 前後の ASCII 空白を除去します。
      2. text-direction list が localizedValue["dir"] を 含むなら normalizedValue["dir"] に設定します。
  4. "value" が normalizedValue に存在しない場合は終了します。
  5. "lang" が normalizedValue に存在しない場合は normalizedValue["lang"] に defaultLanguageTag を設定します。
  6. "dir" が normalizedValue に存在しない場合は normalizedValue["dir"] に defaultDirection を設定します。
  7. IsStructurallyValidLanguageTag を normalizedValue["lang"] で呼ぶか、 IsStructurallyValidLanguageTag を defaultLanguageTag で呼び出し false なら終了します。
  8. map[member][defaultLanguageTag] に normalizedValue を設定します。
注

ローカライズテキストオブジェクトを処理するアルゴリズムは 文字列または ローカライズテキストオブジェクトを ローカライズ値パラメータに受け取り、 処理結果は ローカライズテキストオブジェクトとして value、 lang、 dir が設定されます。

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

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

*_localized 画像リソースメンバーを処理するには、 ordered map json、 ordered map map、string member、および URL manifest URL を用います:

  1. もし member が json に存在しない場合、終了します。
  2. languageMap を json[member] とします。
  3. もし languageMap が ordered map でなければ、終了します。
  4. languageTags を languageMap のキーとします。
  5. map[member] に新しい ordered map を設定します。
  6. For each languageTag of languageTags:
    1. IsStructurallyValidLanguageTag を languageTag で呼び出して false なら、 continue。
    2. 画像リソースを処理する を呼び出し、 languageMap[languageTag] を 画像リソースのリストとして渡し、 map[member]、manifest URL、および languageTag をメンバーとして渡します。

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

このセクションでは、manifestの処理および manifestの適用の アルゴリズムを定義します。

ユーザーエージェントは MUST、リンクタイプ "manifest" をサポートし、リンクされたリソースの取得と処理手順を 実装しなければなりません。

1.16.1 manifestの処理

無視するよう指示された場合、ユーザーエージェントは、 条件を引き起こしたmanifestやメンバー、値が存在しないかのように MUST 振る舞います。

下記のアルゴリズムは、処理拡張ポイントです。他の仕様がmanifestに新しいメンバーを追加する場合は、 このアルゴリズム内のこのポイントにフックすることが推奨されます。その際、SHOULD NOT 既存の manifest オブジェクトの値を変更してはいけません。

注

処理拡張ポイントは、 monkey patchingに関連する問題を 回避するのに役立ちます。

manifestの処理手順は以下のアルゴリズムによって示されます。 このアルゴリズムは URL document URL、 URL manifest URL、 バイト列 bodyBytes を受け取ります。

  1. json を JSONバイト列をInfra値にパースし、 bodyBytesを渡して得た結果とします。
  2. もし json がパース例外であるか、json が ordered map でない場合:
    1. json を空の ordered mapに設定します。
  3. manifest を空の ordered mapとして作成します。
  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 が 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. orientationメンバーを処理し、 json と manifest を渡します。
  20. shortcutsメンバーを処理し、 json、manifest、 manifest URL を渡します。
  21. 処理拡張ポイント: この時点で、独自プロパティや他の対応メンバーを処理してください。
  22. document の 処理済みmanifest を manifest に設定します。

1.16.2 カラーメンバーの処理

注: サポートされる色

sRGB色、およびユーザーエージェントが外部知識なしで sRGBに変換できる色のみがサポートされています（例: "AliceBlue"）。例えば、lab(…)やcolor(display-p3, …)は sRGBに変換できますが、 color(--custom-profile, …)はマニフェストで指定できない "@color-profile"規則の一致を探す必要があるため、サポートされません。

カラーメンバーを処理するには、 ordered map json、ordered map map、string member を使います:

  1. もし json[member] が 存在しないか、 json[member] が 文字列でなければ、終了します。
  2. 前後のASCII空白を除去します。 json[member]に対して実行します。
  3. color を CSS色としてパースした結果とします。 値は json[member] です。
  4. もし color が失敗なら終了します。
  5. もし color がユーザーエージェント固有の情報のみで sRGBに 変換可能なら、color を sRGBへ変換します。
  6. もし color が sRGB色でなければ終了します。
  7. map[member] に color を設定します。

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

テキストメンバーを処理するには、ordered map json、ordered map map、および string member を用います:

  1. もし json[member] が 存在しないか、json[member] が 文字列でなければ、終了します。
  2. 前後のASCII空白を除去します。 json[member]に対して実行します。
  3. map[member] に json[member] の値を設定します。

1.16.4 ドキュメントなしでmanifestを処理する

manifestの処理手順は [現行標準]の link 要素の処理手順によって呼び出されますが、ユーザーエージェントは 関連するdocumentなしでmanifestを処理するために MAY 呼び出すこともできます。

この場合、[現行標準]対応の保証と合わせるため、ユーザーエージェントは 少なくとも過去のある時点で以下を SHOULD 保証してください:

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

1.16.5 manifestの適用

処理済みmanifestは、適用されると、 トップレベルのブラウジングコンテキストに対し、 manifestのメンバーがそのブラウジングコンテキストの表示や挙動に影響を与えます。 ユーザーエージェントは、トップレベルのブラウジングコンテキストが作成された際、 MAY manifestを適用することができ、ナビゲーションが始まる前に実行できます。

注

manifestが適用されたトップレベルのブラウジングコンテキストは、 アプリケーションコンテキストと呼ばれます。

アプリケーションコンテキストが ユーザーエージェントによりナビゲートされて ディープリンクに到達した場合、 ユーザーエージェントは MUST 直ちに ナビゲーションを ディープリンクへ historyHandling を "replace" に設定して実施します。 それ以外の場合は、アプリケーションコンテキストが作成された際、 ユーザーエージェントは MUST 直ちに ナビゲーションを start URLへ historyHandling を "replace" に設定して実施します。

注

1.16.6 マニフェストの更新

manifest リンク関係の仕様通り、manifestはページ読み込みごとに取得・処理されます。 manifestの処理が成功した場合、ユーザーエージェントは MAY 更新されたmanifestを 現在および今後のアプリケーションに関連する アプリケーションコンテキストに 適用しても構いません。

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

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

セキュリティ重要メンバーは その方向性に関係なく、[UTS55]の説明通り 双方向分離して表示する SHOULD があります。

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

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

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

ユーザーがローカライズ設定を変更した場合、ユーザーエージェントは MAY セキュリティ重要メンバーの 起動面での表示を、 *_localized メンバーで指定された ローカライズ表記に自動調整しても構いません。これらの変更は SHOULD 次回ウェブアプリ起動時にユーザーに提示されるべきです。

注: ユーザーエージェントは部分更新を適用しない

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

各マニフェスト画像リソースは、画像リソースであり、 ウェブアプリケーションの概念的な一部として、使用するメンバーのセマンティクスに応じて様々な文脈で利用できるものです（例：アプリケーションメニューのアイコンなど）。

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

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

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を含まないなら、 continue。
    2. それ以外は、purposesに keywordを追加する。
  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 全面表示（Fullbleed） 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. imagesの各potential imageについて：
    1. imageに、JSONから画像リソースを処理するを potential imageと manifest URLを渡して実行した結果を代入する。
    2. imageが失敗の場合、continue。
    3. purposesに画像の目的を判定するを potential imageに渡して実行した結果を代入する。
    4. purposesが失敗の場合、continue。
    5. image["purpose"]に purposesをセットする。
    6. imageResourcesに imageを追加する。

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. 以下いずれかの場合、失敗を返す：
  2. urlに、manifest URLを基準に item["url"]をパースした結果を代入する。
  3. urlが失敗の場合、失敗を返す。
  4. urlがscopeのスコープ内でない場合、失敗を返す。
  5. shortcutにordered map «[ "url" → url, "name" → item["name"] ]» をセットする。
  6. *_localizedテキストメンバーの処理を item, shortcut, "name_localized", defaultDirectionで実行する。
  7. "short_name"がitemに存在して、かつ item["short_name"]が文字列なら、shortcut["short_name"]にitem["short_name"]をセットする。
  8. *_localizedテキストメンバーの処理を item, shortcut, "short_name_localized", defaultDirectionで実行する。
  9. "description"がitemに存在して、かつ 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. インストール可能なウェブアプリケーション

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

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

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

注

例えば、インストールをサポートするユーザーエージェントでは、ウェブアプリケーションはユーザーにとってネイティブアプリと区別がつかない形で表示・起動される場合があります。例えばホーム画面やランチャー、スタートメニューにラベル付きアイコンとして現れるなどです。ウェブアプリケーションの起動の際、ユーザーエージェントはマニフェストを適用し、最上位閲覧コンテキストにスタートURLが読み込まれる前に適用します。これにより、ユーザーエージェントはマニフェストの該当値を適用する機会を持ち、ウェブアプリケーションの表示モードや画面の向きを変更することもできます。また、ユーザーエージェントがウェブアプリケーションを自身のブックマークリストにインストールすることも可能です。

4.1 アプリケーション名

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

nameメンバーまたは short_nameメンバーが不足、空、または型が不正な場合、 ユーザーエージェントはnameメンバーをshort_nameメンバーのフォールバックとして使ったり、 逆にshort_nameメンバーをnameメンバーのフォールバックとして使ったりできます。

nameおよびshort_nameメンバーが 不足、空、または型が不正な場合、ユーザーエージェントはDocumentから適当な代替値を探すことができます （例：nameや short_nameの代わりにapplication-nameを使用）。 あるいは、ユーザーエージェントはプラットフォームの慣例に従い「無題」などのデフォルト名を割り当てるべきです。 また、ユーザーエージェントがエンドユーザーにテキスト入力を許可し、それをアプリケーション名として使うこともできます。

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をスタートURLに設定する。
  2. traversableに新しい最上位トラバーサブルの作成手順を target URLとPOST resourceで実行した結果を代入する。
  3. browsing contextにtraversableのアクティブな閲覧コンテキストを代入する。
  4. manifestを適用をmanifestとbrowsing contextに対して実行する。
  5. browsing contextを返す。

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

エンドユーザーがウェブアプリケーションをインストールできるUIでは、アイコン、名前、スタートURL、オリジンなどを確認できるようにすることが推奨されます。 これはエンドユーザーがインストール前にウェブアプリについて意識的に承認・必要なら修正できるようにするためです。 また、予期しないアイコンや名前を使うことで他のウェブアプリケーションを偽装していないかを見分ける機会にもなります。

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

4.4 アンインストール

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

削除時には、アプリに関連する他の永続データや設定（パーミッションやストレージなど）も取り消す機会をユーザーに提供することが推奨されます。

6. 表示モード

表示モードは、ウェブアプリケーションがOSの文脈で（例：フルスクリーンで）どのように提示されるかを表します。表示モードはプラットフォームごとのユーザーインターフェース（UI）のメタファーや機能に対応します。表示モードのUIの慣習はあくまで助言的なものであり、実装者は最適と考える方法で自由に解釈できます。

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

fullscreen
ウェブアプリケーションをブラウザーUI要素を隠して、利用可能な表示領域全体に表示します。
standalone
ウェブアプリケーションをスタンドアロンのネイティブアプリのように見せて動作させます。これには異なるウィンドウやアプリランチャー内の独自アイコンなどが含まれます。このモードでは、ユーザーエージェントはURLバーなどの標準的なブラウザーUI要素を除外しますが、ステータスバーやシステムの戻るボタンなど他のシステム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. processing extension-point：この時点で独自またはその他対応表示モードを処理します。
  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]で記載されているセキュリティ考慮事項が適用されます。加えて、 manifestに開発者がカスタムや制約のないデータを含めることを防ぐ手段がないため、 実装者はサービス拒否攻撃の防止、メモリ不足の回避、プラットフォーム特有の制限への対応などのために、制約のないメンバー型の値に対して実装依存の制限を設ける必要があります。

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

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

本仕様ではマニフェストの特定メンバー内でURLの宣言が可能であるため、 [URL]仕様で述べられているセキュリティ考慮事項を検討する必要があります。 マニフェスト内で見つかったIRIsやIDNAアドレスを表示する実装では、 [UNICODE-SECURITY]のセキュリティ勧告に強く従うことが推奨されます。

開発者は、[CSP3]仕様全体で議論されているセキュリティ考慮事項、 特にdata:をマニフェストを「インライン化」するための有効なソースにすることについて注意する必要があります。 これにより、マニフェストをドキュメント内に直接含めることでXSS攻撃を許すことになる可能性があり、完全に避けるのが最善です。

エンドユーザーがウェブアプリケーションをインストールできるUIでは、 アイコンや名前、スタートURL、オリジンなどを確認できるようにすることが推奨されます。 これはインストール前にエンドユーザーがウェブアプリの情報を意識的に承認・必要なら修正できる機会を提供するためです。 また、予期しないアイコンや名前を使うことで他のウェブアプリケーションを偽装していないか判断する機会にもなります。

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

ショートカットurlが、アプリがブラウザー外から起動されたことを示すように作成される可能性も考えられます （例："url": "/task/?from=homescreen"）。 また、開発者がurlにユーザー固有の識別子（例：サーバーから割り当てられたUUID）を埋め込むことも考えられます。 これはフィンガープリント/プライバシーに関する情報であり、ユーザーが認識していない可能性があります。

ウェブアプリケーションが動作中は、ユーザーエージェントがオリジンやスタートURL・現在の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
必須パラメータ:
N/A
オプションパラメータ:
N/A
エンコーディングに関する考慮事項:
application/jsonと同様 ([RFC7159] section 8.1)
プライバシーとセキュリティの考慮事項:
7. プライバシーとセキュリティの考慮事項参照。
このMIMEタイプを使用するアプリケーション:
ウェブブラウザー
追加情報:
マジックナンバー:
N/A
ファイル拡張子:
.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] の説明通り、ここで示すようにすべて大文字で現れる場合のみその意味として解釈されます。

この仕様への適合を主張できる製品クラスは1つだけです：ユーザーエージェントです。

注

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

B.1 拡張性

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

本仕様は拡張可能に設計されています。他の仕様はマニフェストの新しいメンバーを定義することが推奨されますが、その際は本仕様の慣習に従ってください。 特に、処理拡張ポイントを使ってマニフェストの処理手順にフックしてください。また、独自メンバーの処理手順も本仕様の定める形式で記述してください。これにより、この部分のプラットフォームの一貫性を保つことができます。

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

新しいメンバーを定義する場合は、本仕様で定義されている内容の上書きやモンキーパッチは行わないでください。 また、自分のメンバーが他のメンバーより前後に処理されることを前提にしないでください。新しいメンバーとその処理は、原子的かつ自己完結型にしてください。 さらに、実装は認識・サポートしないメンバーを自由に無視できることにも留意してください。

編集者が仕様を執筆中に一時的に本仕様へパッチを適用し、実装を助けたい場合は、バグを報告してコミュニティに意図を伝えてください。

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

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

独自拡張は望ましくないものですが、現実的には避けられません。ユーザーエージェントが本仕様に記載されていないマニフェストJSON内のメンバーを解釈する場合、慎重に行ってください。

独自拡張を追加する実装者は、その拡張が標準化可能か（例えば、他のプラットフォームの第2のユーザーエージェントでもそのメンバーを利用できるか）を検討してください。 標準化可能であれば、著者はベンダ中立的な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スキーマ

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

マニフェスト文書のバリデーションに関心のある開発者は、 マニフェスト形式用の非公式JSONスキーマをschemastore.orgで見つけることができます。 これはApache 2.0ライセンスです。 Mads Kristensenによって親切にメンテナンスされています。 JSONスキーマに問題があれば、バグを報告してください。 GitHub上のSchemaStoreリポジトリです。

注: Web Manifest JSON Schema

F. 国際化

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

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

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

上記のような手段を使う場合、開発者はエンドユーザーの言語選択に関するプライバシーにも注意が必要です。 エンドユーザーがウェブアプリケーションに対して明示的に言語選択をした場合（＝単にユーザーエージェントのデフォルト言語設定を使う場合ではなく）、 その言語選択をネットワーク上で平文で送信するのは原則としてNGです。 これによりエンドユーザーの個人情報が漏れる可能性があります。 したがって、開発者はWebアプリケーションの広範な監視を避けるために、 [TLS]の利用を推奨します。 [RFC7258]参照。

G. ユースケースと要件

本書はインストール可能なウェブアプリのユースケースと要件に対応することを目的としています。

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. Bryan Garaventa; Melanie Sumner. W3C. 2025年4月3日. W3C作業草案. URL: https://www.w3.org/TR/accname-1.2/
[BCP47]
言語識別用タグ. A. Phillips, Ed.; M. Davis, Ed. IETF. 2009年9月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[CSP3]
Content Security Policy Level 3. Mike West; Antonio Sartori. W3C. 2025年4月30日. W3C作業草案. URL: https://www.w3.org/TR/CSP3/
[css-color-4]
CSS Color Module Level 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. 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. 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]
Scripting Media Types. B. Hoehrmann. IETF. 2006年4月. Informational. 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]
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]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. 2017年12月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[MEDIAQUERIES-5]
Media Queries Level 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. N. Freed; N. Borenstein. IETF. 1996年11月. Draft Standard. URL: https://www.rfc-editor.org/rfc/rfc2046
[permissions]
Permissions. Marcos Caceres; Mike Taylor. W3C. 2024年12月20日. W3C作業草案. URL: https://www.w3.org/TR/permissions/
[RFC2119]
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. T. Bray, Ed. IETF. 2014年3月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7159
[RFC8174]
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双方向アルゴリズム. Manish Goregaokar マニシュ・ゴレガオンカル; Robin Leroy. Unicode Consortium. 2024年9月2日. Unicode Standard Annex #9. URL: https://www.unicode.org/reports/tr9/tr9-50.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 Technical Report #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 Technical Standard #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 Sniffing現行標準. Gordon P. Hemsley. WHATWG. 現行標準. 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セマンティクス. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. 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. T. Dierks; E. Rescorla. IETF. 2008年8月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc5246
[webidl]
Web IDL現行標準. Edgar Chen; Timothy Gu. WHATWG. 現行標準. URL: https://webidl.spec.whatwg.org/