Chromium が出荷済みだが、他のユーザーエージェントからの コミットメント/実装がない、Web Application Manifest 拡張およびインキュベーションのための機能仕様。 これらの機能を explainer として保持する代わりに、ここでより 公式に文書化する。
これは非公式な提案である。
display_override メンバー
高度な用途では、[=manifest/display_override=] メンバーを使用して、 開発者が Web アプリケーションに対して好ましい 表示モードを選択できるように、 表示モードリスト値の カスタムフォールバック順序を指定できる。その値は [=display mode=] である。
[=application manifest=] の [=manifest/display_override=] メンバーは、 [=display mode/window-controls-overlay=] や [=display mode/unframed=] などの 拡張を含む sequence の 表示モードリスト値である。 このメンバーは、[=display mode=] に対する開発者の好ましい フォールバックチェーンを表す。このフィールドは [=manifest/display=] メンバーを上書きする。ユーザーエージェントがここで指定された [=display mode=] のいずれもサポートしていない場合、 [=manifest/display=] メンバーを考慮することへフォールバックする。 アルゴリズム手順については、 display メンバーの処理を参照。
次の手順は、 Web アプリの選択された表示モードを決定するにおける [=application manifest/processing extension-point=] に追加される。
このメンバーは、開発者が自分の表示モードのフォールバック順序を 明示的に制御したい場合、または基本の 表示モード リストでは利用できないモードのためなど、高度な場合にのみ 使用されることを意図している。そうでない場合、ほとんどのユースケースでは [=manifest/display=] メンバーで十分である。
通常の 表示モードに加えて、 [=manifest/display_override=] はそれに対する特定の拡張もサポートする。
次は、standalone よりも minimal-ui
表示モードを優先するが、
minimal-ui がサポートされていない場合は
browser ではなく standalone へフォールバックする
[=manifest=] を示す。
{
"name": "Recipe Zone",
"description": "All of the recipes!",
"icons": [{
"src": "icon/hd_hi",
"sizes": "128x128"
}],
"start_url": "/index.html",
"display_override": ["minimal-ui"],
"display": "standalone",
"theme_color": "yellow",
"background_color": "red"
}
[=app-region=] CSS プロパティはどのユーザーエージェントにも実装されて いないため、at risk である。なお、一部のユーザーエージェントは 同じ目的のために非標準 CSS プロパティ `-webkit-app-region` を使用する。
`app-region` プロパティは、たとえばタイトルバー内のどの領域または要素が ドラッグ可能であるかを CSS で定義するために使用できる。
この仕様によって追加される新しい拡張およびインキュベーション機能 すべてを容易にするため、ユーザーエージェントは [=processing a manifest=] における 拡張 ポイントで、[=URL=] |document URL:URL|、[=URL=] |manifest URL:URL|、[=ordered map=] |json:ordered map|、および [=ordered map=] |manifest:ordered map| に アクセスして、次を実行するべきである:
tab_strip メンバー
Web Application Manifest の `tab_strip` メンバーは、アプリケーションが [=display mode/tabbed=] 表示モードでどのように挙動することを意図しているか についての情報を含む オブジェクトである。 これは次のメンバーを持つ:
home_tab メンバー
[=tab_strip=] オブジェクトの `home_tab` メンバーは、アプリケーションの トップレベルメニューとして機能することを意図した特別な「ホームタブ」に 関する情報を含む ordered map である。これは次のメンバーを含む:
scope_patterns メンバーは、
[=manifest URL=] に相対的な [=within home tab scope|ホームタブのスコープ=]
を定義する {{URLPatternInput}} のリストである。
アプリケーションの適用済み [=display mode=] が [=display mode/tabbed=] であり、 [=Document/processed manifest=] が [=tab_strip=] メンバーの非 null な [=home_tab=] メンバーを含む場合、そのアプリケーションは ホームタブを持つ。
ホームタブコンテキストは、他の application contexts と比べて 特別なプロパティを持つ任意の [=application context=] である。 アプリケーションが [=has a home tab=] 場合、すべてのアプリケーション ウィンドウは [=home tab context=] を備えるべきである。そうでない場合、 アプリケーションウィンドウは [=home tab context=] を持つべきではない。
[=home tab context=] がどのように提示されるかはユーザーエージェントの 裁量に委ねられるが、通常の application contexts とは異なる外観を 持つべきである。
[=URL=] |url:URL| は、次の場合に限り ホームタブスコープ内であると言われる:
URL は [=within home tab scope=] でない場合、ホームタブスコープ外である。
アプリケーションが [=has a home tab=] 場合、新しいアプリケーション ウィンドウが作成されるたびに(たとえばアプリケーションの起動時、 またはタブを新しいウィンドウへ移動するとき)、ユーザーエージェントは そのウィンドウ内に新しい [=home tab context=] を作成しなければならない。 新しく作成された [=home tab context=] は、定義上 [=within home tab scope=] である [=start URL=] へナビゲートされるべきである。
[=home tab context=] に関連付けられた [=top-level traversable=] を、 [=outside of home tab scope=] である [=URL=] |url:URL| へ [=navigate|ナビゲート=] するとき、次の手順が実行される:
"_blank" のターゲットおよび noopener true で
navigable を選択した結果を、[=top-level traversable=]
|tab:toplevel traversable| とする。
[=display mode/tabbed=] の [=display mode=] を持つ [=top-level traversable=] であって [=home tab context=] に関連付けられて いないもの(すなわち非ホームタブ)を、[=within home tab scope=] である [=URL=] |url:URL| へ [=navigate|ナビゲート=] するとき、次の手順が 実行される:
上記の規則は、[=has a home tab|ホームタブを持つ=] アプリケーションについて、 次の不変条件が常に真であることを保証することを意図している:
ユーザーエージェントは、文書が [=URL/fragment=] を変更したり、 {{History}} API を使用して表示 URL をホームタブスコープ内外へ変更したり しても、ナビゲーションが発生していないため、文書をホームタブコンテキストと 非ホームタブコンテキストの間で動的に移動しない。このため、上記の不変条件は、 文書が作成された時点で持っていた [=Document/URLs=] のみを考慮する。
URL を変更することで「ナビゲートしたふり」をする single-page applications では、 これにより、上記の不変条件を破る望ましくない挙動が生じる可能性がある (例:ユーザーがホームタブ内のリンクをクリックして URL を非ホームページへ 動的に変更しても、実際にはナビゲートしていないため、ホームタブ内に 留まる)。この状況を避けるため、アプリケーションは tabbed application mode にあることを検出し、URL を変更する代わりに、ホームタブスコープの内外へ 実際のナビゲーションを行うように挙動を変更できる。
new_tab_button メンバー
[=tab_strip/new_tab_button=] メンバーは、クリック/有効化されたときに アプリケーションウィンドウ内で新しい [=application context=] を開く UI アフォーダンス(ボタンなど)の挙動を記述する ordered map である。 これは次のメンバーを持つ:
url メンバーは、
[=manifest URL=] に相対的な URL を表す文字列であり、
[=Document/processed manifest=] の [=manifest/within scope=] である。
[=Document/processed manifest=] の [=new_tab_button=] の [=new_tab_button/url=] メンバーが [=outside of home tab scope=] である場合、 アプリケーションは 新しいタブボタンを持つ。アプリケーションが [=has a new tab button|新しいタブボタンを持たない=] 場合、 ユーザーエージェントは「新しいタブ」アフォーダンスをエンドユーザーに 利用可能にするべきではない。
エンドユーザーによって新しいタブボタンが有効化されたとき、次の手順が 実行される:
[=ordered map=] |json:ordered map|、[=ordered map=] |manifest:ordered map|、 および [=URL=] |manifest URL:URL| が与えられたとき、 process the `tab_strip` member するには、 [=processing a manifest=] における 拡張ポイントで次を実行する:
[=ordered map=] |json tab strip:ordered map|、[=ordered map=] |manifest tab strip:ordered map|、および [=URL=] |manifest URL:URL| が 与えられたとき、process the `home_tab` member するには、 次を実行する:
[=ordered map=] |json tab strip:ordered map|、[=ordered map=] |manifest tab strip:ordered map|、[=URL=] |manifest URL:URL|、および [=URL=] |start URL:URL| が与えられたとき、 process the `new_tab_button` member するには、次を実行する:
[=ordered map=] |json home tab:ordered map|、[=ordered map=] |manifest home tab:ordered map| および [=URL=] |manifest URL:URL| が 与えられたとき、process the `scope_patterns` member するには、 次を実行する:
{
"name": "Tabbed App Example",
"start_url": "/",
"display": "standalone",
"display_override": ["tabbed"],
"tab_strip": {
"home_tab": {
"scope_patterns": [
{"pathname": "/"},
{"pathname": "/index.html"}
]
},
"new_tab_button": {
"url": "/create"
}
}
}
この例は、tabbed mode がサポートされていない場合に単一文書の
standalone window へフォールバックする tabbed web app である。
メイン index ページ(/ または
/index.html)へのすべてのナビゲーションは
[=home tab context=] で開かれる。新しいタブボタンは
/create で新しいタブを開く。
[=tab_strip/home_tab/scope_patterns=] と照合するとき、URL の
[=URL/query=] 部分は既定で無視されることに注意
(したがって /index.html?utm_source=foo への
ナビゲーションはホームタブで開かれる)。しかし、[=start URL=] と
照合するとき、[=URL/query=] は正確に一致しなければならないため、
クエリを無視したいサイトは、[=start URL=] の
[=URL/path=] をスコープパターンとして明示的に含めることが推奨される。
`share_target` メンバーは、Web アプリケーションを共有アクション (例:テキスト、URL、またはファイルの共有)の「ターゲット」として登録する。 `share_target` メンバーは [[[web-share-target]]] 仕様の一部である。
note_taking メンバー
Web Application Manifest の `note_taking` メンバーは、ノート作成に関連する情報を 含む オブジェクトである。 これは次のメンバーを持つ:
ユーザーエージェントは、これらのメンバーを使用して、その Web アプリケーションを ノート作成機能を持つアプリケーションとして異なる扱いにしてもよい (例:オペレーティングシステムのノート作成サーフェスとの統合)。
new_note_url
メンバー
[=note_taking=] `new_note_url` メンバーは、ユーザーが Web アプリケーションを 使用して新しいノートを取りたいとき(例:オペレーティングシステムの ショートカットアイコンやキーボードショートカットから)に、 ユーザーエージェントに読み込ませることを開発者が望む URL を表す [=string=] である。
`new_note_url` メンバーは純粋に助言的であり、ユーザーエージェントは それを無視してもよく、 それを使用するかどうかをエンドユーザーが選択できるようにしてもよい。 ユーザーエージェントは、エンドユーザーがそれを変更できるようにしてもよい。
次は、ノート作成アプリケーション用の [=manifest=] を示す。
{
"name": "My Note Taking App",
"description": "You can take notes!",
"icons": [{
"src": "icon/hd_hi",
"sizes": "128x128"
}],
"start_url": "/index.html",
"display": "standalone",
"note_taking": {
"new_note_url": "/new_note.html"
}
}
[=ordered map=] |json:ordered map|、[=ordered map=] |manifest:ordered map|、 [=URL=] |manifest_URL:URL| が与えられたとき、 process the `note_taking` member するには、 [=processing a manifest=] における 拡張 ポイントで次を実行する:
[=ordered map=] |json_note_taking:ordered map|、[=ordered map=] |manifest_note_taking:ordered map|、[=URL=] |manifest_URL:URL| が 与えられたとき、process the `new_note_url` member するには、 次を実行する:
処理済み manifest |manifest:processed manifest| が与えられたとき、 launch the `new_note_url` するには、次の手順を実行する:
ユーザーエージェントは、通常はユーザーアフォーダンスへの応答として、 任意の時点で、与えられた [=installed web application=] について [=launch the `new_note_url`=] してもよい。
[=manifest's=] protocol_handlers メンバーは、
Web アプリケーションが URL プロトコルを処理できるようにする
protocol handler description の配列である。
インストール時、ユーザーエージェントは次と整合する対話を通じて、 オペレーティングシステムに protocol handler を登録するべきである:
[=object=] |json:JSON|、|manifest:ordered map| が与えられたとき、 process the `protocol_handlers` member するには:
ユーザーエージェントは、ホストオペレーティングシステムでプロトコルの 既定 handler として [=protocol handler description=] protocol_handlers を登録する前に、ユーザーに許可を求めるべきである。 ユーザーエージェントは、ホストオペレーティングシステムの慣例または制限との 一貫性を保つため、提示される [=protocol handler description=] protocol_handlers のリストを切り詰めてもよい。
各 protocol handler description は、Web アプリケーションが 処理したいプロトコルを表す [=object=] であり、 [=manifest/protocol_handlers=] メンバーに対応する。 これは次のメンバーを持つ:
ユーザーエージェントは、これらの値を使用して、Web アプリケーションを operating system の handler として登録するべきである。 ユーザーが protocol handler URL を有効化したとき、ユーザーエージェントは handling a protocol launch を実行するべきである。
[[HTML]] の {{NavigatorContentUtils/registerProtocolHandler()}} は、
Web サイトが特定のプロトコルの可能な handler として自分自身を登録することを
可能にする。protocol handler description に対する
有効な [=protocol handler description/protocol=] および
[=protocol handler description/url=] の値を構成するものは、その API で定義される。
なお、[[HTML]] API は、ここで [=protocol handler description/protocol=] を
使用する場所で scheme を使用するが、同じ制限が適用される。
protocol handler description の protocol メンバーは、
処理されるプロトコル(`mailto` または
`web+auth` など)を表す string である。
protocol handler description の
[=protocol handler description/protocol=] メンバーは、
[[HTML]] で定義される
{{NavigatorContentUtils/registerProtocolHandler()}} の
scheme 引数と同等である。
protocol handler description の url メンバーは、
関連付けられたプロトコルが有効化されたときに開かれる、
アプリケーションの [=manifest/within scope=] である
URL である。
protocol
handler description の [=protocol handler description/url=] メンバーは、
[[HTML]] で定義される {{NavigatorContentUtils/registerProtocolHandler()}} の
url 引数と同等である。
[=manifest=] manifest を持つ protocol handler description protocol_handler が呼び出されたとき、 それは [=invoke a protocol handler=] に使用される同じ手順を通る。 その際、ユーザーエージェントは resultURL へ [=navigating=] する代わりに、manifest と resultURL を渡して [=launch a web application=] するべきである。
これはこのように [=invoke a protocol handler=] を呼び出して変更するべきではない。 resultURL の計算は、汎用の別個のアルゴリズムへ 抽出されるべきである。
オペレーティングシステムの機能によっては、protocol handler は、ユーザーが 明示的に知ることなく、与えられたプロトコルの「既定」handler (例:与えられたプロトコルの起動を自動的に処理する)になる可能性がある。 起こり得る悪用を防ぐため、ユーザーエージェントは次のような保護を 採用してもよい:
ユーザーエージェントが protocol handler entity の登録を削除する場合、 ユーザーが Web アプリおよびプロトコルをオペレーティングシステムに 再登録できる UX を提供するべきである。
[=manifest's=] file_handlers メンバーは、
アプリ自体の外部から発生するファイルを開くアクションをアプリがどのように
処理するかについての指示を提供する [=list=] である。
登録済み file-handling applications の管理、提示、および選択は、 オペレーティングシステムの裁量に委ねられる。
[=ordered map=] |json:ordered map|、[=ordered map=] |manifest:ordered map|、 [=URL=] |manifest_url:URL| が与えられたとき、 process the `file_handlers` member するには:
[=installation=] 時に、ユーザーエージェントは [=register file handlers=] する処理を実行するべきである。
各 file handler は、 アプリケーションのスコープ内の URL であって、それが受け入れる [=file types=] を伴う起動を処理できるものを表す。 これは次のメンバーを持つ:
ユーザーエージェントは、これらのメンバーを使用して Web アプリケーションを オペレーティングシステム上の [=file type=] と関連付けることができる。
file type は [=MIME type=] および/または [=file extension=] によって定義できる。OS がそのファイルに [=MIME type=] があると判断する場合、またはその名前が特定の [=file extension=] で終わる場合、そのファイルは file type に属する。 file extension は "." で始まり、 有効な suffix code pointsのみを含む文字列である。さらに、[=file extensions=] は 16 コードポイントの長さに制限される。
[=file handler=] の action メンバーは、
manifest URL に
相対的な URL を表す string であり、
処理済み
manifest の [=manifest/within scope=] である。
この URL は [=execute a file handler
launch=] する手順でナビゲートされる。
[=file handler=] の name メンバーは、
ユーザーに対して file type を識別する string である。
[=User agents=] は、file handler の登録中にこの情報を
オペレーティングシステムへ渡してもよい。
file handler の icons メンバーは、
[=file type=] のグラフィカルな表現として機能するアイコンを列挙する。
ユーザーエージェントは、file handler の登録中にこの情報を
オペレーティングシステムへ渡してもよい。
[=file handler=] の accept メンバーは、
[=MIME types=] を [=file extensions=] のリストに対応付ける
dictionary である。
[=User agents=] は、[=file handler/accept=] エントリが一致する拡張子を 持つファイルにのみ適用されることを強制しなければならない。
[=register file handlers=] するために、一部のオペレーティングシステムは [=MIME types=] を必要とし、一部は [=file extensions=] を必要とする。 したがって manifest は、各 [=file handler/accept=] エントリについて常に両方を提供しなければならない。
完全な [=MIME types=] に加えて、たとえば
"image/*" ですべての画像形式を(提供された
[=file extensions=] のリストにも適用されるものとして)照合するために、
[=MIME type=] の subtype として "*" を使用できる。
[=file handler=] の launch_type メンバーは、
この handler にルーティングされたファイルに対してアプリがどのように
起動されるかを決定する string である。可能な値は
`"single-client"` と `"multiple-clients"` である。提供されない場合、
既定で `"single-client"` になる。
[=file handler=] が一連のファイルに一致すると判断された場合、 [=user agent=] は [=file handler/launch_type=] を使用して、アプリが 各ファイルに対して 1 回ずつ起動されるか (`"multiple-clients"`)、すべてのファイルに対して 1 回だけ起動されるか (`"single-client"`)を制御するべきである。{{LaunchParams/files}} を参照。 ユーザーエージェントは、異なる [=file handlers=] からのファイルを 1 つの起動イベントに結合してはならない。
[=ordered map=] |item:ordered map|、[=URL=] |start_url:URL|、 [=URL=] |scope:URL|、および [=URL=] |manifest URL:URL| が与えられたとき、 process a file handler item するには:
execute a file handler launch する手順は、 次のアルゴリズムで与えられる。このアルゴリズムは [=list=] |files:list| と、 [=processing a manifest=] からの結果を保持する [=ordered map=] |manifest:ordered_map| を取る。
ユーザーエージェントは、次と整合するように、ホスト オペレーティングシステムに register file handlers するべきである:
ユーザーエージェントは、機能を維持し乱用を防ぐため、 [=file extensions=] の総集合を切り詰めてもよい。 ユーザーエージェントは、特定の filetypes との関連付けを防いでもよい。
オペレーティングシステムの機能によっては、[=file handler=] はユーザーが 明示的に知ることなく、与えられた [=file type=] の既定 handler となり、 与えられた file type の起動を自動的に処理する可能性がある。 起こり得る悪用を防ぐため、[=user agents=] は [=execute a file handler launch=] する処理を開始するために、 明示的なユーザー同意を要求してもよい。同意が求められる場合、 ユーザーエージェントは、その決定が永続的であることをユーザーが指定できるように するべきであり、そのように指定された場合は、Web アプリケーションの OS 登録を file handling entity として削除するべきである。
各 file handler の名前とアイコンは、ユーザーがそれらを確認するための 指定された方法がないため、プライバシーおよびセキュリティ上センシティブで あり得る。このため、[=user agents=] は、代替の文字列やアイコンを優先して これらを無視する、または OS の既定値へフォールバックすることを選択してもよい。
次の例では、Web アプリケーションは 3 つの異なる file handler を持つ。
related application は、基盤となるアプリケーションプラットフォームから アクセス可能であり、Web アプリケーションと関係を持つアプリケーションである。
[=manifest's=] related_applications メンバーは
related
applications を列挙し、Web アプリケーションと
related applications の間のそのような関係を示すものとして機能する。
この関係は一方向であり、列挙されたアプリケーションが同じ関係を主張しない限り、
user agent は双方向の endorsement を仮定してはならない。
`related_applications` の使用例としては、その情報を使用して Web アプリケーションに 関する詳細情報を収集する crawler、またはユーザーが Web アプリケーションを インストールしたい場合に、列挙されたアプリケーションを代替として提案する ブラウザーなどが考えられる。
[=ordered map=] |json:ordered map| および [=ordered map=] |manifest:ordered map| が与えられたとき、 process the `related_applications` member するには:
[=manifest's=] `prefer_related_applications` メンバーは、
related applications が Web アプリケーションより優先されるべきであると
ユーザーエージェントに伝えるヒントとして使用される [=boolean=] である。
`prefer_related_applications` メンバーが `true` に設定されており、
ユーザーエージェントが Web アプリケーションのインストールを提案したい場合、
代わりに related applications の 1 つのインストールを提案したいと
考えるかもしれない。
[=manifest's=] scope_extensions メンバーは、アプリケーションが望む
[=scope extensions=] のリストを表す。
scope extension は、[=within extended scope=] として扱われるべき 追加の [=URLs=] を記述することで、[=manifest/navigation scope of a manifest=] を拡張する。
ユーザーエージェントは、追加の [=URLs=] を [=within extended scope=] と できるように [=apply extended scope=] する前に、 [=process the scope_extensions member=] および [=validate scope extensions=] しなければならない。
[=URL=] |target:URL| は、|target| が manifest の [=manifest/within scope=] である、または [=matches a validated scope extension=] である場合、 |manifest:processed manifest| の extended scope 内である。
[=URL=] |target:URL| は、[=URL=] |target:URL| と [=list=] |validated_scope_extensions:list| が与えられたときに 次のアルゴリズムが `true` を返す場合、検証済み scope extension に一致する:
次の例は、`scope_extensions` メンバーを使用するアプリケーションの [=manifest=] を示す。
{
"id": "https://example.com/app",
"name": "My App",
"icons": [{
"src": "icon/hd_hi",
"sizes": "128x128"
}],
"start_url": "/app/index.html",
"scope": "/app",
"display": "standalone",
"scope_extensions": [
{ "type": "origin", "origin": "https://example.co.uk" },
{ "type": "origin", "origin": "https://help.example.com" }]
}
次は、`scope_extensions` メンバーに列挙された [=origins=] の `.well-known` パスからダウンロードできる 2 つの [=web-app-origin-association=] ファイルを示す。
{
"https://example.com/app": {
"scope": "/app"
}
}
{
"https://example.com/app": {
"scope": "/"
}
}
このアプリの navigation scope は、次の [=URLs=] のいずれかの [=URL/within scope=] である URL から成る: `https://example.com/app`, `https://example.co.uk/app`, および `https://help.example.com`。
[=ordered map=] |json:ordered map|、[=ordered map=] |manifest:ordered map|、 および [=URL=] |manifest_id:URL| が与えられたとき、 process the `scope_extensions` member するには:
[=ordered map=] |extension:ordered map| および [=URL=] |manifest_id:URL| が 与えられたとき、validate scope extensions するには:
ユーザーエージェントは、シナリオによって apply extended scope を 適用し、別のシナリオでは [=manifest/scope=] を適用することを選択してもよい。
[=application context=] の [=navigable/active document=] の [=URL=] が [=manifest/within scope=] ではないが [=within extended scope=] である場合、ユーザーエージェントは、ユーザーがその [=URL=] または 少なくともその [=origin=] を判断できる UI を提供するべきであり、 それが安全な接続で提供されているかどうかも含めるべきである。 この UI は、[=URL=] が [=application context=] の [=Document/processed manifest=] の [=manifest/within scope=] でない場合に 使用される UI とは異なるべきである。これは、ユーザーがアプリケーションの 意図された内容をナビゲートしていることを明確にしつつ、異なる [=origin=] へナビゲートすることのプライバシーおよびセキュリティ上の 影響についてユーザーに情報を与え続けるためである。
web-app-origin-association ファイルは、[=validate scope extensions=] または [=validate origin migration=] に使用できる JSON ファイルである。それは、自身が存在する origin と 1 つ以上の Web アプリケーションとの関連付けを確認する。 これは manifest [=manifest/ids=] を参照することによってアプリを一意に識別する。
[=origin=] |origin:origin| が与えられた場合、
[=web-app-origin-association=] ファイルは
[origin]/.well-known/web-app-origin-association
からダウンロード可能であることが期待される。
Web Application Origin Migration は、Web アプリケーションがユーザーエージェントに対して、 ある origin から別の origin(同じ site 内)へ移動したことを示せるようにする。 これにより、ユーザーエージェントは、ユーザーのインストールおよび場合によっては その設定を保持しながら、インストール済み Web アプリケーションを移行できる。
次の例は、https://old.example.com でホストされていた
Web アプリケーションを https://new.example.com へ移行する方法を示す。
両方の origins は [=same site=] でなければならず、移行に明示的に
同意しなければならない。
まず、古いアプリケーションの manifest は、ユーザーエージェントに移動する 意図を知らせるために、任意で `migrate_to` メンバーを含めることができる (あるいは古いアプリケーションが新しいアプリケーションへリダイレクトできる):
{
"name": "My App",
"id": "/",
"migrate_to": {
"id": "https://new.example.com/",
"install_url": "https://new.example.com/install"
}
}
次に、新しいアプリケーションの manifest は、古いアプリケーションからの 移行を主張するために `migrate_from` メンバーを含める:
{
"name": "My New App",
"id": "/",
"migrate_from": [
{
"id": "https://old.example.com/",
"install_url": "https://old.example.com/install",
"behavior": "force"
}
]
}
最後に、古い origin は、新しいアプリケーションによる引き継ぎを許可することを 確定的に検証するために、`web-app-origin-association` ファイルをホストしなければ ならない。このファイルがないと、悪意ある新しいアプリケーションが許可なく 古いアプリケーションからの移行を主張できる。
{
"https://new.example.com/": {
"allow_migration": true
}
}
migrate_from メンバー
[=manifest/migrate_from=] メンバーは、移行元である古い Web アプリケーションを識別する [=strings=] または [=ordered maps=] の [=list=] である。
エントリが [=string=] である場合、それは古いアプリケーションの [=manifest/id=] として扱われる。
エントリが [=ordered map=] である場合、次のメンバーを持つことができる:
id:
古いアプリケーションの [=manifest/id=] を表す [=string=]。
install_url:古いアプリケーションの
manifest へリンクするページの URL を表す [=string=]。
ユーザーエージェントは、古いアプリケーションの一部である他のすべての
URL が新しいアプリケーションへリダイレクトする場合でも、更新を適用するために
古いアプリケーションの manifest を取得する目的でこのフィールドを使用できる。
behavior:
`"suggest"` または `"force"` のいずれかである [=string=]。
これは、移行についてユーザーに通知するためにユーザーエージェントが提示する
UI がどの程度強制的であるかに影響し得るヒントである。
migrate_to メンバー
[=manifest/migrate_to=] メンバーは、新しいアプリケーションへの移行を 先回りして通知する任意の [=ordered map=] である。これは次のメンバーを持つ:
id:
新しいアプリケーションの [=manifest/id=] を表す [=string=]。
install_url:新しいアプリケーションの
manifest へリンクするページの URL を表す [=string=]。
このページ上の manifest は、移行が処理されるために、このアプリケーションへ
戻る [=manifest/migrate_from=] フィールドを含む必要がある。
[=URL=] |old_manifest_id:URL| および [=URL=] |new_manifest_id:URL| が 与えられたとき、validate origin migration するには:
[=ordered map=] |json:ordered map|、[=ordered map=] |manifest:ordered map|、 および [=URL=] |manifest URL:URL| が与えられたとき、 process the `migrate_from` member するには:
[=ordered map=] |json:ordered map|、[=ordered map=] |manifest:ordered map|、 および [=URL=] |manifest URL:URL| が与えられたとき、 process the `migrate_to` member するには:
悪意ある主体がアプリケーションを密かに乗っ取ること(例:単純な電卓が自身を更新して 銀行アプリを模倣すること)を防ぐため、[=validate origin migration=] アルゴリズムは 双方向のハンドシェイクを強制する。新旧両方のアプリケーション origin は、 [=web-app-origin-association=] ファイルを介して移行に明示的に同意しなければならない。
さらに、移行は [=same site=] であることに制限され、未検証の第三者へ所有権を移すのではなく、 組織の管理下での正当なリブランディングおよびアーキテクチャ変更に使用されることを保証する。
ユーザーエージェントは、特にセキュリティ上センシティブなフィールド (アプリ名やアイコンなど)の更新が含まれる場合、移行フローの一部として 明示的なユーザー確認ダイアログを含めることを検討するべきである。
各 外部 アプリケーションリソースは、Web アプリケーションに関連する アプリケーションを表す。
[=external application resource=] は次のメンバーを持つことができ、 その一部は [=valid external application resource=] であるために必須である:
valid external application resource は、 [=external application resource/platform=] メンバー、および [=external application resource/url=] または [=external application resource/id=] メンバー(またはその両方)を持たなければならない。
platform メンバーは、
この [=external application resource=] が関連付けられている
[=platform=] を表す。platform は、
ソフトウェア配布エコシステム、または場合によってはオペレーティングシステムを
表す。この仕様は platform メンバーの特定の値を定義しない。
[=external application resource's=] url メンバーは、
アプリケーションを見つけることができる URL である。
process the `url` member of an application するには:
[=external application resource's=] id メンバーは、
プラットフォーム上でアプリケーションを表すために使用される id を表す。
[=external application resource's=] min_version メンバーは、
この Web アプリに関連すると見なされるアプリケーションの最小バージョンを表す。
このバージョンは、プラットフォーム固有の構文および意味を持つ
string である。
[=external application resource's=] fingerprints メンバーは、
[=fingerprints=] の [=list=] を表す。
fingerprint は、 アプリケーションの検証に使用される暗号学的 fingerprint の集合を表す。 fingerprint は次の 2 つのメンバーを持つ:type と value。これらはいずれも string であるが、その構文と意味はプラットフォーム定義である。
インストール処理は、複数の方法でトリガーされ得る:
いずれの場合も、文書が installable でない場合、ユーザーエージェントは present an install prompt してはならない。
ユーザーエージェントは、文書が installable である場合に限り、任意の時点で steps to notify that an install prompt is available を 任意の時点で実行してもよく、サイトに、ユーザーがユーザーエージェント UI と 対話する必要なく site-triggered install prompt を表示する機会を与える。
インストールプロンプトを 提示するには:
steps to notify that an install prompt is available は、 次のアルゴリズムで与えられる:
steps to install the web application は次のアルゴリズムで与えられる:
設計上、この仕様は、Web アプリケーションを「インストール」するための 明示的な API を開発者に提供しない。代わりに、 manifest は、Web アプリケーションがインストール可能であることを ユーザーエージェントに示す installability signal として機能できる。 これらのシグナルはユーザーエージェントごとに異なる。各ユーザーエージェントは、 Web サイトがインストールプロンプトに適格であるかどうかを判断するための 独自のヒューリスティックを持つためである。実装者は一般に、 特定の installabilty signals や、Web アプリケーションが installable と見なされるために 満たす必要があるその他の関連基準を説明する文書を提供する。
ユーザーエージェントが実装する可能性のある Web アプリケーションの installability signals の例:
このリストは網羅的ではなく、一部の installability signals は すべてのユーザーエージェントに適用されない場合がある。ユーザーエージェントが これらの installability signals をどのように使用して Web アプリケーションがインストール可能かを判断するかは、実装者に委ねられる。
この仕様の [=event|イベント=] は、application life-cycle task source に依存する。
[Exposed=Window]
interface BeforeInstallPromptEvent : Event {
constructor(DOMString type, optional EventInit eventInitDict = {});
Promise<PromptResponseObject> prompt();
};
dictionary PromptResponseObject {
AppBannerPromptOutcome userChoice;
};
enum AppBannerPromptOutcome {
"accepted",
"dismissed"
};
{{BeforeInstallPromptEvent}} は、サイトが site-triggered install prompt を提示することを許可されたとき、 またはユーザーエージェントが automated install prompt を提示する前に dispatch される。これは、サイトが automated install prompt を cancel できるようにし、さらに site-triggered install prompt を 手動で提示できるようにする。
PromptResponseObject は {{BeforeInstallPromptEvent/prompt()}} を呼び出した結果を含む。 それは 1 つのメンバー、 userChoice を含み、 ユーザーが選択した結果を表す。
{{BeforeInstallPromptEvent}} のインスタンスは、次の内部スロットを持つ:
prompt() メソッド
prompt メソッドは、呼び出されたときに次の手順を実行する:
{{BeforeInstallPromptEvent}} event とともに request to present an install prompt するには:
この例は、ユーザーがボタンをクリックして site-triggered install prompt を表示するまで、 automated install prompt が表示されないようにする方法を示す。 このようにして、サイトは、任意の時点でプロンプトするのではなく、 インストールをユーザーの裁量に任せつつ、そのための目立つ UI を提供できる。
window.addEventListener("beforeinstallprompt", event => {
// Suppress automatic prompting.
event.preventDefault();
// Show the (disabled-by-default) install button. This button
// resolves the installButtonClicked promise when clicked.
installButton.disabled = false;
// Wait for the user to click the button.
installButton.addEventListener("click", async e => {
// The prompt() method can only be used once.
installButton.disabled = true;
// Show the prompt.
const userChoice = await event.prompt();
console.info(`user choice was: ${userChoice}`);
});
});
AppBannerPromptOutcome enum
AppBannerPromptOutcome enum の値は、 presenting an install prompt からの結果を表す。
partial interface Window {
attribute EventHandler onappinstalled;
attribute EventHandler onbeforeinstallprompt;
};
onappinstalled 属性
onappinstalled event handler IDL attribute は "appinstalled" イベントを処理する。
onbeforeinstallprompt 属性
onbeforeinstallprompt event handler IDL attribute は "beforeinstallprompt" イベントを処理する。