訳注: この文書はSuperseded Recommendationとして廃止された仕様です。この日本語訳は歴史的な意味しか持ちません。WHATWGによる最新のHTML仕様を参照ください。

WHATWG HTML日本語訳も参照することができます。

5 ウェブページの読み込み

This section describes features that apply most directly to Web browsers. Having said that, except where specified otherwise, the requirements defined in this section do apply to all user agents, whether they are Web browsers or not.

5.1 ブラウジングコンテキスト

ブラウジングコンテキストDocumentオブジェクトがユーザーに提示される環境である。

A tab or window in a Web browser typically contains a browsing context, as does an iframe or frames in a frameset.

ブラウジングコンテキストは、対応するWindowProxyオブジェクトを持つ。

ブラウジングコンテキストは、ブラウジングコンテキストが提示されていた、している、またはするだろうDocumentオブジェクトを一覧表示するセッション履歴を持つ。任意の時点で、それぞれのブラウジングコンテキストで1つのDocumentアクティブドキュメントを指定される。Documentブラウジングコンテキストは、もしあれば、セッション履歴Documentを含むブラウジングコンテキストである。(createDocument()などのAPIを使用して作成されたDocumentは、一切ブラウジングコンテキストを持たない。)

ブラウジングコンテキスト内の各Documentは、Windowオブジェクトに関連づけるブラウジングコンテキストWindowProxyオブジェクトは、すべてブラウジングコンテキストアクティブドキュメントWindowオブジェクトへ転送する。

一般に、WindowオブジェクトからDocumentオブジェクトへ1対1の対応が存在する。2つの例外が存在する。まず、Windowは、マッピングが1対2になるような、同じブラウジングコンテキストにおける2番目のDocumentのプレゼンテーションに対して再利用できる。交換が有効になっているブラウジングコンテキストは初期about:blank Documentから別のものにナビゲートしたとき、これは起こる。次に、Documentは、マッピングが多対1であるような、document.open()メソッドが使用される場合、複数のWindowオブジェクトを再利用されて終わることができる。

Documentは、関連付けられたブラウジングコンテキストを必ずしも持たない。具体的には、データマイニングツールはブラウジングコンテキストをインスタンス化できないだろう。


ブラウジングコンテキストは、その作成に関与するブラウジングコンテキストクリエーターブラウジングコンテキストを持つことができる。ブラウジングコンテキスト親ブラウジングコンテキストを持つ場合、それは、そのクリエーターブラウジングコンテキストである。そうでなければ、ブラウジングコンテキストオープナーブラウジングコンテキストを持つ場合、それがそのクリエイターブラウジングコンテキストである。そうでなければ、ブラウジングコンテキスト作成者ブラウジングコンテキストを持たない。

ブラウジングコンテキストAクリエーターブラウジングコンテキストを持つ場合、DocumentAクリエーターDocumentを作成された時点で、そのクリエイターブラウジングコンテキストアクティブドキュメントであった。

When a browsing context is first created, it must be created with a single Document in its session history, whose address is about:blank, which is marked as being an HTML document, whose character encoding is UTF-8, and which is both ready for post-load tasks and completely loaded immediately, along with a new Window object that the Document is associated with. The Document must have a single child html node, which itself has two empty child nodes: a head element, and a body element. As soon as this Document is created, the user agent must implement the sandboxing for it. If the browsing context has a creator Document, then the browsing context's Document's referrer must be set to the address of that creator Document at the time of the browsing context's creation.

If the browsing context is created specifically to be immediately navigated, then that initial navigation will have replacement enabled.

The origin and effective script origin of the about:blank Document are set when the Document is created. If the new browsing context has a creator browsing context, then the origin of the about:blank Document is an alias to the origin of the creator Document and the effective script origin of the about:blank Document is initially an alias to the effective script origin of the creator Document. Otherwise, the origin of the about:blank Document is a globally unique identifier assigned when the new browsing context is created and the effective script origin of the about:blank Document is initially an alias to its origin.

5.1.1 ネストされたブラウジングコンテキスト

特定の要素(たとえば、iframe要素)は、ブラウジングコンテキストをさらにインスタンス化できる。これらは、ネストされたブラウジングコンテキストと呼ばれる。ブラウジングコンテキストPが、その中に別のブラウジングコンテキストCをネストする要素EとともにDocument Dを持つ場合、CD介してネストされると言い、ECブラウジングコンテキストコンテナであると言われる。ブラウジングコンテキストコンテナ要素EDocument D中にある場合、PC親ブラウジングコンテキストであると言われ、CP子ブラウジングコンテキストであると言われる。そうでなければ、ネストされたブラウジングコンテキストC親ブラウジングコンテキストを持たない。

A子ブラウジングコンテキストであるブラウジングコンテキストA'が存在し、それがB祖先自身である場合、または、ブラウジングコンテキストAB親ブラウジングコンテキストである場合、ブラウジングコンテキストAはブラウジングコンテキストB祖先であると言われる。

ブラウジングコンテキストはネストされたブラウジングコンテキスト親ブラウジングコンテキストを持たないものでなく、祖先のブラウジングコンテキストであるすべてのブラウジングコンテキストのレベルレベルブラウジングコンテキストである。

ネストされたブラウジングコンテキストへの親ブラウジングコンテキストの推移クロージャは、先祖ブラウジングコンテキストのリストを提供する。

Document d子孫ブラウジングコンテキストのリストは、以下のアルゴリズムによって返される(順序の)リストである:

  1. listを空にする。

  2. dの各子ブラウジングコンテキストd Document存在する要素を介してネストされるので、要素のこれらブラウジングコンテキストをネストするツリー順に、次のサブステップを実行する:

    1. リストlistにその子ブラウジングコンテキストを追加する。

    2. リストlistにその子ブラウジングコンテキストアクティブドキュメントに属する子孫ブラウジングコンテキストのリストを追加する。

  3. 構築されたlistを返す。

それがそのブラウジングコンテキストアクティブドキュメントであり、かつそのブラウジングコンテキストがトップレベルブラウジングコンテキストであるか、それが親ブラウジングコンテキストおよびそれ自身が完全にアクティブネストされる経由でDocumentを持つかのいずれかである場合、Document完全にアクティブであると言われる。

それらは要素を介してネストされるため、子ブラウジングコンテキストは常に、親ブラウジングコンテキスト内の特定のDocumentに関連付けられる。ユーザーエージェントは、ユーザーにがいない自身が完全にアクティブでないDocumentにある要素の子ブラウジングコンテキストと対話することを許可してはならない。

ネストされたブラウジングコンテキストは、遅延loadイベントモードにすることができる。これは、新しいDocumentが作成される前にブラウジングコンテキストコンテナiframe要素のloadイベントを遅らせるために、移動された際に使用される。

ブラウジングコンテキストドキュメントファミリーは、そのブラウジングコンテキストセッション履歴ですべてのDocumentオブジェクト およびすべてのそれらDocumentオブジェクトのドキュメントファミリーの結合で構成される。Documentオブジェクトのドキュメントファミリーは、Documentオブジェクトを介してネストされるブラウジングコンテキストの所有するすべてのドキュメントファミリーの結合で構成される。

window . top

トップレベルブラウジングコンテキストWindowProxyを返す。

window . parent

親ブラウジングコンテキストに対するWindowProxyを返す。

window . frameElement

ブラウジングコンテキストコンテナElementを返す。

存在しない場合nullを返す。

クロスオリジンの状況でSecurityError例外を投げる。

The top IDL attribute on the Window object of a Document in a browsing context b must return the WindowProxy object of its top-level browsing context (which would be its own WindowProxy object if it was a top-level browsing context itself), if it has one, or its own WindowProxy object otherwise (e.g. if it was a detached nested browsing context).

The parent IDL attribute on the Window object of a Document in a browsing context b must return the WindowProxy object of the parent browsing context, if there is one (i.e. if b is a child browsing context), or the WindowProxy object of the browsing context b itself, otherwise (i.e. if it is a top-level browsing context or a detached nested browsing context).

The frameElement IDL attribute on the Window object of a Document d, on getting, must run the following algorithm:

  1. If d is not a Document in a nested browsing context, return null and abort these steps.

  2. If the browsing context container's Document does not have the same effective script origin as the effective script origin specified by the entry settings object, then throw a SecurityError exception and abort these steps.

  3. Return the browsing context container for b.

5.1.2 補助ブラウジングコンテキスト

要素を通じてネストせずにトップレベルブラウジングコンテキストに関連する新しいブラウジングコンテキストを作成することが可能である。このようなブラウジングコンテキストは、補助ブラウジングコンテキストと呼ばれる。補助ブラウジングコンテキストは常にトップレベルブラウジングコンテキストである。

補助ブラウジングコンテキストは、補助ブラウジングコンテキストから作成されたブラウジングコンテキストである、オープナーブラウジングコンテキストを持つ。

存在し、利用可能であり、かつ現在のブラウジングコンテキストが、そのオープナーを解消するのでない場合、取得時に、WindowオブジェクトのopenerIDL属性は、現在のブラウジングコンテキストが(そのオープナーブラウジングコンテキスト)を作成されたブラウジングコンテキストWindowProxyオブジェクトを返さなければならない。そうでなければ、nullを返さなければならない。On setting, if the new value is null then the current browsing context must disown its opener; if the new value is anything else then the user agent must call the [[DefineOwnProperty]] internal method of the Window object, passing the property name "opener" as the property key, and the Property Descriptor { [[Value]]: value, [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } as the property descriptor, where value is the new value.

5.1.3 セカンダリブラウジングコンテキスト

ユーザーエージェントは、主要コンテンツ領域から離れて、ユーザーエージェントのインターフェースの一部を形成するブラウジングコンテキストである、セカンダリブラウジングコンテキストをサポートしてもよい。

5.1.4 Security

A browsing context A is familiar with a second browsing context B if one of the following conditions is true:


A browsing context A is allowed to navigate a second browsing context B if the following algorithm terminates positively:

  1. If A is not the same browsing context as B, and A is not one of the ancestor browsing contexts of B, and B is not a top-level browsing context, and A's active document's active sandboxing flag set has its sandboxed navigation browsing context flag set, then abort these steps negatively.

  2. Otherwise, if B is a top-level browsing context, and is one of the ancestor browsing contexts of A, and A's Document's active sandboxing flag set has its sandboxed top-level navigation browsing context flag set, then abort these steps negatively.

  3. Otherwise, if B is a top-level browsing context, and is neither A nor one of the ancestor browsing contexts of A, and A's Document's active sandboxing flag set has its sandboxed navigation browsing context flag set, and A is not the one permitted sandboxed navigator of B, then abort these steps negatively.

  4. Otherwise, terminate positively!


An element has a browsing context scope origin if its Document's browsing context is a top-level browsing context or if all of its Document's ancestor browsing contexts all have active documents whose origin are the same origin as the element's Document's origin. If an element has a browsing context scope origin, then its value is the origin of the element's Document.

5.1.5 Groupings of browsing contexts

Each browsing context is defined as having a list of one or more directly reachable browsing contexts. These are:

The transitive closure of all the browsing contexts that are directly reachable browsing contexts forms a unit of related browsing contexts.

Each unit of related browsing contexts is then further divided into the smallest number of groups such that every member of each group has an active document with an effective script origin that, through appropriate manipulation of the document.domain attribute, could be made to be the same as other members of the group, but could not be made the same as members of any other group. Each such group is a unit of related similar-origin browsing contexts.

There is also at most one event loop per unit of related similar-origin browsing contexts (though several units of related similar-origin browsing contexts can have a shared event loop).

5.1.6 ブラウジングコンテキスト名

ブラウジングコンテキストは、ブラウジングコンテキスト名を持つことができる。デフォルトでは、ブラウジングコンテキストは名前を持たない(名前が設定されない)。

妥当なブラウジングコンテキスト名は、U+005F LOW LINE文字で始まらない少なくとも1文字をもつ任意の文字列である。(アンダースコアで始まる名前は、特別なキーワードのために予約されている。)

妥当なブラウジングコンテキスト名またはキーワードは、妥当なブラウジングコンテキスト名またはASCII大文字・小文字不区別_blank_self_parent、または_topの1つにマッチするいずれかとなる任意の文字列である。

これらの値は、以下の(非規範的な)テーブルで要約されるように、ページがサンドボックス化されるかどうかに基づいて異なる意味を持つ。この表において、"current"はリンクまたはスクリプト内にあるブラウジングコンテキストを意味し、"parent"はリンクまたはスクリプト内にあるいずれかの親ブラウジングコンテキストを意味し、"master"はリンクまたはスクリプトのいずれかである最も近い祖先ブラウジングコンテキストを意味し、"top"はリンクまたはスクリプトがあるいずれかのトップレベルブラウジングコンテキストを意味し、"new"はさまざまなユーザー設定とユーザーエージェントのポリシーに次第で、新しいトップレベルブラウジングコンテキストまたは補助ブラウジングコンテキストが作成されることを意味し、"none"は何も起こらないことを意味し、"maybe new"は"allow-popups"キーワードはまたsandbox属性で指定される場合(またはユーザーがサンドボックスを覆う場合)、"new"と同じであり、そうでなければ"none"と同じである。

キーワード 普通の効果 iframeでの効果
sandbox="" sandbox="allow-top-navigation"
リンクおよびフォーム送信に対して、何も指定しない current current current
空文字列 current current current
_blank new maybe new maybe new
_self current current current
親が存在しない場合の_parent current current current
親がまたトップである場合の_parent parent/top なし parent/top
存在するがトップでない場合の_parent parent なし なし
トップが現在である場合の_top current current current
トップが現在でない場合の_top top なし top
名前が存在しない new maybe new maybe new
名前が存在しかつ子孫である specified descendant specified descendant specified descendant
名前が存在し現在である current current current
名前が存在しかつトップとなる祖先である specified ancestor なし specified ancestor/top
名前が存在しかつトップでない祖先である specified ancestor なし なし
他の名前が共通のトップとともに存在する specified なし なし
familiarかつある許可されたサンドボックス化されたナビゲーターである場合、異なるトップをもつ名前が存在する specified specified specified
familiarだがある許可されたサンドボックス化されたナビゲーターでない場合、異なるトップをもつ名前が存在する specified なし なし
familiarでない、異なるトップをもつ名前が存在する new maybe new maybe new

サンドボックス化されたブラウジングコンテキストの制限のほとんどは、他のアルゴリズムにより適用される。たとえば、下記で与えられるブラウジングコンテキスト名で与えられたをブラウジングコンテキストを選択するための規則でなく、ナビゲーションアルゴリズムとして。


An algorithm is allowed to show a popup if any of the following conditions is true:


The rules for choosing a browsing context given a browsing context name are as follows. The rules assume that they are being applied in the context of a browsing context, as part of the execution of a task.

  1. If the given browsing context name is the empty string or _self, then the chosen browsing context must be the current one.

    If the given browsing context name is _self, then this is an explicit self-navigation override.

  2. If the given browsing context name is _parent, then the chosen browsing context must be the parent browsing context of the current one, unless there isn't one, in which case the chosen browsing context must be the current browsing context.

  3. If the given browsing context name is _top, then the chosen browsing context must be the top-level browsing context of the current one, if there is one, or else the current browsing context.

  4. If the given browsing context name is not _blank and there exists a browsing context whose name is the same as the given browsing context name, and the current browsing context is familiar with that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related.

    If the browsing context is chosen by this step to be the current browsing context, then this is also an explicit self-navigation override.

  5. Otherwise, a new browsing context is being requested, and what happens depends on the user agent's configuration and abilities — it is determined by the rules given for the first applicable option from the following list:

    There is no chosen browsing context. The user agent may inform the user that a popup has been blocked.

    If the current browsing context's active document's active sandboxing flag set has the sandboxed auxiliary navigation browsing context flag set.

    Typically, there is no chosen browsing context.

    The user agent may offer to create a new top-level browsing context or reuse an existing top-level browsing context. If the user picks one of those options, then the designated browsing context must be the chosen one (the browsing context's name isn't set to the given browsing context name). The default behaviour (if the user agent doesn't offer the option to the user, or if the user declines to allow a browsing context to be used) must be that there must not be a chosen browsing context.

    If this case occurs, it means that an author has explicitly sandboxed the document that is trying to open a link.

    If the user agent has been configured such that in this instance it will create a new browsing context, and the browsing context is being requested as part of following a hyperlink whose link types include the noreferrer keyword

    A new top-level browsing context must be created. If the given browsing context name is not _blank, then the new top-level browsing context's name must be the given browsing context name (otherwise, it has no name). The chosen browsing context must be this new browsing context. The creation of such a browsing context is a new start for session storage.

    If it is immediately navigated, then the navigation will be done with replacement enabled.

    If the user agent has been configured such that in this instance it will create a new browsing context, and the noreferrer keyword doesn't apply

    A new auxiliary browsing context must be created, with the opener browsing context being the current one. If the given browsing context name is not _blank, then the new auxiliary browsing context's name must be the given browsing context name (otherwise, it has no name). The chosen browsing context must be this new browsing context.

    If it is immediately navigated, then the navigation will be done with replacement enabled.

    If the user agent has been configured such that in this instance it will reuse the current browsing context

    The chosen browsing context is the current browsing context.

    If the user agent has been configured such that in this instance it will not find a browsing context

    There must not be a chosen browsing context.

    User agent implementors are encouraged to provide a way for users to configure the user agent to always reuse the current browsing context.

    If the current browsing context's active document's active sandboxing flag set has the sandboxed navigation browsing context flag set and the chosen browsing context picked above, if any, is a new browsing context (whether top-level or auxiliary), then all the flags that are set in the current browsing context's active document's active sandboxing flag set when the new browsing context is created must be set in the new browsing context's popup sandboxing flag set, and the current browsing context must be set as the new browsing context's one permitted sandboxed navigator.

5.2 Windowオブジェクト

[Global]
/*sealed*/ interface Window : EventTarget {
  // the current browsing context
  [Unforgeable] readonly attribute WindowProxy window;
  [Replaceable] readonly attribute WindowProxy self;
  [Unforgeable] readonly attribute Document document;
           attribute DOMString name; 
  [PutForwards=href, Unforgeable] readonly attribute Location location;
  readonly attribute History history;
  [Replaceable] readonly attribute BarProp locationbar;
  [Replaceable] readonly attribute BarProp menubar;
  [Replaceable] readonly attribute BarProp personalbar;
  [Replaceable] readonly attribute BarProp scrollbars;
  [Replaceable] readonly attribute BarProp statusbar;
  [Replaceable] readonly attribute BarProp toolbar;
           attribute DOMString status;
  void close();
  readonly attribute boolean closed;
  void stop();
  void focus();
  void blur();

  // other browsing contexts
  [Replaceable] readonly attribute WindowProxy frames;
  [Replaceable] readonly attribute unsigned long length;
  [Unforgeable] readonly attribute WindowProxy top;
           attribute WindowProxy? opener;
  readonly attribute WindowProxy parent;
  readonly attribute Element? frameElement;
  WindowProxy open(optional DOMString url = "about:blank", optional DOMString target = "_blank", optional DOMString features = "", optional boolean replace = false);
  getter WindowProxy (unsigned long index);
  getter object (DOMString name);

  // the user agent
  readonly attribute Navigator navigator; 
  readonly attribute External external;
  readonly attribute ApplicationCache applicationCache;

  // user prompts
  void alert(optional DOMString message = "");
  boolean confirm(optional DOMString message = "");
  DOMString? prompt(optional DOMString message = "", optional DOMString default = "");
  void print();


};
Window implements GlobalEventHandlers;
Window implements WindowEventHandlers;
window . window
window . frames
window . self

これらの属性すべてはwindowを返す。

window . document

windowと関連するDocumentを返す。

document . defaultView

アクティブドキュメントWindowオブジェクトを返す。

The Window interface must only be exposed to JavaScript if the JavaScript global environment is a document environment.

The window, frames, and self IDL attributes must all return the Window object's browsing context's WindowProxy object.

The document IDL attribute must return the Window object's newest Document object.

The defaultView IDL attribute of the Document interface must return the Document's browsing context's WindowProxy object, if there is one, or null otherwise.


For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object.

5.2.1 Security

This section describes a security model that is underdefined, imperfect, and does not match implementations. Work is ongoing to attempt to resolve this, but in the meantime, please do not rely on this section for precision. Implementors are urged to send their feedback on how cross-origin cross-global access to Window and Location objects should work. See bug 20701.

User agents must throw a SecurityError exception whenever any properties of a Window object are accessed when the incumbent settings object specifies an effective script origin that is not the same as the Window object's Document's effective script origin, with the following exceptions:

When the incumbent settings object specifies an effective script origin that is different than a Window object's Document's effective script origin, the user agent must act as if any changes to that Window object's properties, getters, setters, etc, were not present, and as if all the properties of that Window object had their [[Enumerable]] attribute set to false.

For members that return objects (including function objects), each distinct effective script origin that is not the same as the Window object's Document's effective script origin must be provided with a separate set of objects. These objects must have the prototype chain appropriate for the script for which the objects are created (not those that would be appropriate for scripts whose global object, as specified by their settings object, is the Window object in question).

For instance, if two frames containing Documents from different origins access the same Window object's postMessage() method, they will get distinct objects that are not equal.

5.2.2 名前でブラウジングコンテキストを作成および操作するためのAPI

window = window . open( [ url [, target [, features [, replace ] ] ] ] )

url(デフォルトでabout:blank)を表示するためのウィンドウを開き、それを返す。target引数は、新しいウィンドウの名前を与える。すでにその名前をもつウィンドウが存在する場合、それが再利用される。replace属性がtrueの場合、どのページでも、ウィンドウがウィンドウのセッション履歴から削除される現在開いていることを意味する。features引数は無視される。

window . name [ = value ]

ウィンドウの名前を返す。

名前を変更する設定が可能である。

window . close()

ウィンドウを閉じる。

window . closed

ウィンドウが閉じられている場合はtrueを返し、そうでなければfalseを返す。

window . stop()

ドキュメントの読み込みを中止する。

The open() method on Window objects provides a mechanism for navigating an existing browsing context or opening and navigating an auxiliary browsing context.

The method has four arguments, though they are all optional.

The first argument, url, must be a valid non-empty URL for a page to load in the browsing context. If the first argument is the empty string, then the url argument must be interpreted as "about:blank". Otherwise, the argument must be resolved to an absolute URL (or an error), relative to the API base URL specified by the entry settings object when the method was invoked.

The second argument, target, specifies the name of the browsing context that is to be navigated. It must be a valid browsing context name or keyword.

The third argument, features, has no defined effect and is mentioned for historical reasons only. User agents may interpret this argument as instructions to set the size and position of the browsing context, but are encouraged to instead ignore the argument entirely.

The fourth argument, replace, specifies whether or not the new page will replace the page currently loaded in the browsing context, when target identifies an existing browsing context (as opposed to leaving the current page in the browsing context's session history).

When the method is invoked, the user agent must first select a browsing context to navigate by applying the rules for choosing a browsing context given a browsing context name using the target argument as the name and the browsing context of the script as the context in which the algorithm is executed, unless the user has indicated a preference, in which case the browsing context to navigate may instead be the one indicated by the user.

For example, suppose there is a user agent that supports control-clicking a link to open it in a new tab. If a user clicks in that user agent on an element whose onclick handler uses the window.open() API to open a page in an iframe, but, while doing so, holds the control key down, the user agent could override the selection of the target browsing context to instead target a new tab.

If applying the rules for choosing a browsing context given a browsing context name using the target argument would result in there not being a chosen browsing context, then throw an InvalidAccessError exception and abort these steps.

Otherwise, if url is not "about:blank", the user agent must navigate the selected browsing context to the absolute URL obtained from resolving url earlier, with exceptions enabled. If the replace is true or if the browsing context was just created as part of the rules for choosing a browsing context given a browsing context name, then replacement must be enabled also. The navigation must be done with the responsible browsing context specified by the incumbent settings object as the source browsing context. If the resolve a URL algorithm failed, then the user agent may either instead navigate to an inline error page, with exceptions enabled and using the same replacement behavior and source browsing context behavior as described earlier in this paragraph; or treat the url as "about:blank", acting as described in the next paragraph.

If url is "about:blank", and the browsing context was just created as part of the rules for choosing a browsing context given a browsing context name, then the user agent must instead queue a task to fire a simple event named load at the selected browsing context's Window object, but with its target set to the selected browsing context's Window object's Document object (and the currentTarget set to the Window object).

The method must return the WindowProxy object of the browsing context that was navigated, or null if no browsing context was navigated.


The name attribute of the Window object must, on getting, return the current name of the browsing context, and, on setting, set the name of the browsing context to the new value.

The name gets reset when the browsing context is navigated to another domain.


The close() method on Window objects should, if all the following conditions are met, close the browsing context A:

A browsing context is script-closable if it is an auxiliary browsing context that was created by a script (as opposed to by an action of the user), or if it is a browsing context whose session history contains only one Document.

The closed attribute on Window objects must return true if the Window object's browsing context has been discarded, and false otherwise.

The stop() method on Window objects should, if there is an existing attempt to navigate the browsing context and that attempt is not currently running the unload a document algorithm, cancel that navigation; then, it must abort the active document of the browsing context of the Window object on which it was invoked.

5.2.3 他のブラウジングコンテキストへのアクセス

window . length

子ブラウジングコンテキストの数を返す。

window[index]

指示された子ブラウジングコンテキストを返す。

The length IDL attribute on the Window interface must return the number of child browsing contexts that are nested through elements that are in the Document that is the active document of that Window object, if that Window's browsing context shares the same event loop as the responsible document specified by the entry settings object accessing the IDL attribute; otherwise, it must return zero.

The supported property indices on the Window object at any instant are the numbers in the range 0 .. n-1, where n is the number returned by the length IDL attribute. If n is zero then there are no supported property indices.

To determine the value of an indexed property index of a Window object, the user agent must return the WindowProxy object of the indexth child browsing context of the Document that is nested through an element that is in the Document, sorted in the tree order of the elements nesting those browsing contexts.

These properties are the dynamic nested browsing context properties.

5.2.4 Windowオブジェクトの名前付きアクセス

window[name]

指示された要素または要素のコレクションを返す。

The Window interface supports named properties. The supported property names at any moment consist of the following, in tree order, ignoring later duplicates:

To determine the value of a named property name when the Window object is indexed for property retrieval, the user agent must return the value obtained using the following steps:

  1. Let objects be the list of named objects with the name name in the active document.

    There will be at least one such object, by definition.

  2. If objects contains a nested browsing context, then return the WindowProxy object of the nested browsing context corresponding to the first browsing context container in tree order whose browsing context is in objects, and abort these steps.

  3. Otherwise, if objects has only one element, return that element and abort these steps.

  4. Otherwise return an HTMLCollection rooted at the Document node, whose filter matches only named objects with the name name. (By definition, these will all be elements.)

Named objects with the name name, for the purposes of the above algorithm, are those that are either:

5.2.5 Garbage collection and browsing contexts

A browsing context has a strong reference to each of its Documents and its WindowProxy object, and the user agent itself has a strong reference to its top-level browsing contexts.

A Document has a strong reference to its Window object.

A Window object has a strong reference to its Document object through its document attribute. Thus, references from other scripts to either of those objects will keep both alive. Similarly, both Document and Window objects have implied strong references to the WindowProxy object.

Each script has a strong reference to its settings object, and each script settings object has strong references to its global object, responsible browsing context, and responsible document.

When a browsing context is to discard a Document, the user agent must run the following steps:

  1. Set the Document's salvageable state to false.

  2. Run any unloading document cleanup steps for the Document that are defined by this specification and other applicable specifications.

  3. Abort the Document.

  4. Remove any tasks associated with the Document in any task source, without running those tasks.

  5. Discard all the child browsing contexts of the Document.

  6. Lose the strong reference from the Document's browsing context to the Document.

Whenever a Document object is discarded, it is also removed from the list of the worker's Documents of each worker whose list contains that Document.

When a browsing context is discarded, the strong reference from the user agent itself to the browsing context must be severed, and all the Document objects for all the entries in the browsing context's session history must be discarded as well.

User agents may discard top-level browsing contexts at any time (typically, in response to user requests, e.g. when a user force-closes a window containing one or more top-level browsing contexts). Other browsing contexts must be discarded once their WindowProxy object is eligible for garbage collection.

5.2.6 ブラウジングコンテキストを閉じる

ユーザーエージェントは、ブラウジングコンテキストを閉じることを供給される場合、以下のステップを実行しなければならない:

  1. specified browsing contextを閉じられているブラウジングコンテキストとする。

  2. specified browsing contextアクティブなドキュメントアンロードするように要求する。ユーザーが文書をアンロードできるようにすることを拒否した場合、これらの手順を中止する。

  3. falseに設定するrecycleパラメータをもつspecified browsing contextアクティブなドキュメントアンロードする

  4. ユーザーインターフェース(たとえばタブブラウザでタブを閉じる、または非表示にする)から、specified browsing contextを削除する。

  5. specified browsing context破棄する

ユーザーエージェントは、ユーザーが任意に任意のトップレベルブラウジングコンテキスト閉じる機能を提供すべきである。

5.2.7 ブラウザインターフェース要素

ウェブページがウェブブラウザと統合できるようにするために、特定のウェブブラウザインターフェース要素はウェブページ内のスクリプトに限られた方法で公開される。

各インターフェース要素はBarPropオブジェクトによって表される:

interface BarProp {
           attribute boolean visible;
};
window . locationbar . visible

ロケーションバーが表示される場合はtrueを返し、そうでなければfalseを返す。

window . menubar . visible

メニューバーが表示される場合はtrueを返し、そうでなければfalseを返す。

window . personalbar . visible

パーソナルバーが表示される場合はtrueを返し、そうでなければfalseを返す。

window . scrollbars . visible

スクロールバーが表示される場合はtrueを返し、そうでなければfalseを返す。

window . statusbar . visible

ステータスバーが表示される場合はtrueを返し、そうでなければfalseを返す。

window . toolbar . visible

ツールバーが表示される場合はtrueを返し、そうでなければfalseを返す。

The visible attribute, on getting, must return either true or a value determined by the user agent to most accurately represent the visibility state of the user interface element that the object represents, as described below. On setting, the new value must be discarded.

The following BarProp objects exist for each Document object in a browsing context. Some of the user interface elements represented by these objects might have no equivalent in some user agents; for those user agents, except when otherwise specified, the object must act as if it was present and visible (i.e. its visible attribute must return true).

The location bar BarProp object
Represents the user interface element that contains a control that displays the URL of the active document, or some similar interface concept.
The menu bar BarProp object
Represents the user interface element that contains a list of commands in menu form, or some similar interface concept.
The personal bar BarProp object
Represents the user interface element that contains links to the user's favorite pages, or some similar interface concept.
The scrollbar BarProp object
Represents the user interface element that contains a scrolling mechanism, or some similar interface concept.
The status bar BarProp object
Represents a user interface element found immediately below or after the document, as appropriate for the user's media. If the user agent has no such user interface element, then the object may act as if the corresponding user interface element was absent (i.e. its visible attribute may return false).
The toolbar BarProp object
Represents the user interface element found immediately above or before the document, as appropriate for the user's media. If the user agent has no such user interface element, then the object may act as if the corresponding user interface element was absent (i.e. its visible attribute may return false).

The locationbar attribute must return the location bar BarProp object.

The menubar attribute must return the menu bar BarProp object.

The personalbar attribute must return the personal bar BarProp object.

The scrollbars attribute must return the scrollbar BarProp object.

The statusbar attribute must return the status bar BarProp object.

The toolbar attribute must return the toolbar BarProp object.


For historical reasons, the status attribute on the Window object must, on getting, return the last string it was set to, and on setting, must set itself to the new value. When the Window object is created, the attribute must be set to the empty string. It does not do anything else.

5.2.8 The WindowProxy object

As mentioned earlier, each browsing context has a WindowProxy object. This object is unusual in that all operations that would be performed on it must be performed on the Window object of the browsing context's active document instead. It is thus indistinguishable from that Window object in every way until the browsing context is navigated.

There is no WindowProxy interface object.

The WindowProxy object allows scripts to act as if each browsing context had a single Window object, while still keeping separate Window objects for each Document.

In the following example, the variable x is set to the WindowProxy object returned by the window accessor on the global object. All of the expressions following the assignment return true, because in every respect, the WindowProxy object acts like the underlying Window object.

var x = window;
x instanceof Window; // true
x === this; // true

5.3 生成元

生成元は、ウェブのセキュリティーモデルの基本的な通貨である。生成元を共有するウェブプラットフォーム内の2つの当事者が互いに信頼し、同一の権限を有すると仮定される。異なる生成元をもつ当事者は、互いに潜在的に悪意があると見なされ、互いから程度を変化させるよう隔離される。

たとえば、bank.example.comでホストされるExample Bankのウェブサイトは、charity.example.orgでホストExample CharityのウェブサイトのDOMを検査しようとすると、例外SecurityError例外が発生する。


リソースの生成元とリソースの効果的なスクリプトの生成元は、スキームコンポーネント、ホストコンポーネント、ポートコンポーネント、および任意で追加データで構成される曖昧な識別子またはタプルいずれか両方である。

追加データは、サイトの安全な証明書が変更されたかどうか、同様に生成元が変化すると考えられることを保証するために、暗号化された接続を使用する際、サイトの証明書を含めることができる。

An origin or effective script origin can be defined as an alias to another origin or effective script origin. The value of the origin or effective script origin is then the value of the origin or effective script origin to which it is an alias.

These characteristics are defined as follows:

For URLs

The origin and effective script origin of the URL are the origin defined in The Web Origin Concept. [ORIGIN]

For Document objects
If a Document's active sandboxing flag set has its sandboxed origin browsing context flag set

The origin is a globally unique identifier assigned when the Document is created.

The effective script origin is initially an alias to the origin of the Document.

If a Document was served over the network and has an address that uses a URL scheme with a server-based naming authority

The origin is an alias to the origin of the Document's address.

The effective script origin is initially an alias to the origin of the Document.

If a Document was generated from a data: URL found in another Document or in a script

The origin is an alias to the origin specified by the incumbent settings object when the navigate algorithm was invoked, or, if no script was involved, of the Document of the element that initiated the navigation to that URL.

The effective script origin is initially an alias to the effective script origin of that same script settings object or Document.

If a Document is the initial "about:blank" document

The origin and effective script origin of the Document are those it was assigned when its browsing context was created.

If a Document was created as part of the processing for javascript: URLs

The origin is an alias to the origin of the active document of the browsing context being navigated when the navigate algorithm was invoked.

The effective script origin is initially an alias to the effective script origin of that same Document.

If a Document is an iframe srcdoc document

The origin of the Document is an alias to the origin of the Document's browsing context's browsing context container's Document.

The effective script origin is initially an alias to the effective script origin of the Document's browsing context's browsing context container's Document.

If a Document was obtained in some other manner (e.g. a data: URL typed in by the user or that was returned as the location of an HTTP redirect (or equivalent in other protocols), a Document created using the createDocument() API, etc)

The default behavior as defined in the DOM standard applies. [DOM].

The origin is a globally unique identifier assigned when the Document is created, and the effective script origin is initially an alias to the origin of the Document.

The effective script origin of a Document can be manipulated using the document.domain IDL attribute.

For images of img elements
If the image data is CORS-cross-origin
The origin is a globally unique identifier assigned when the image is created.
If the image data is CORS-same-origin
The origin is an alias to the origin of the img element's Document.

Images do not have an effective script origin.

For audio and video elements
If the media data is CORS-cross-origin
The origin is a globally unique identifier assigned when the media data is fetched.
If the media data is CORS-same-origin
The origin is an alias to the origin of the media element's Document.

Media elements do not have an effective script origin.

For fonts

The origin of a downloadable Web font is an alias to the origin of the absolute URL used to obtain the font (after any redirects). [CSSFONTS] [CSSFONTLOAD]

The origin of a locally installed system font is an alias to the origin of the Document in which that font is being used.

Fonts do not have an effective script origin.

Other specifications can override the above definitions by themselves specifying the origin of a particular URL, Document, image, media element, or font.


The Unicode serialization of an origin is the string obtained by applying the following algorithm to the given origin:

  1. If the origin in question is not a scheme/host/port tuple, then return the literal string "null" and abort these steps.

  2. Otherwise, let result be the scheme part of the origin tuple.

  3. Append the string "://" to result.

  4. Apply the IDNA ToUnicode algorithm to each component of the host part of the origin tuple, and append the results — each component, in the same order, separated by "." (U+002E) characters — to result. [RFC5890]

  5. If the port part of the origin tuple gives a port that is different from the default port for the protocol given by the scheme part of the origin tuple, then append a ":" (U+003A) character and the given port, in base ten, to result.

  6. Return result.

The ASCII serialization of an origin is the string obtained by applying the following algorithm to the given origin:

  1. If the origin in question is not a scheme/host/port tuple, then return the literal string "null" and abort these steps.

  2. Otherwise, let result be the scheme part of the origin tuple.

  3. Append the string "://" to result.

  4. Apply the IDNA ToASCII algorithm to the host part of the origin tuple, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, and append the results to result.

    If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then return the empty string and abort these steps. [RFC5890]

  5. If the port part of the origin tuple gives a port that is different from the default port for the protocol given by the scheme part of the origin tuple, then append a ":" (U+003A) character and the given port, in base ten, to result.

  6. Return result.

Two origins are said to be the same origin if the following algorithm returns true:

  1. Let A be the first origin being compared, and B be the second origin being compared.

  2. If A and B are both opaque identifiers, and their value is equal, then return true.

  3. Otherwise, if either A or B or both are opaque identifiers, return false.

  4. If A and B have scheme components that are not identical, return false.

  5. If A and B have host components that are not identical, return false.

  6. If A and B have port components that are not identical, return false.

  7. If either A or B have additional data, but that data is not identical for both, return false.

  8. Return true.

5.3.1 同一生成元制限を緩和する

document . domain [ = domain ]

セキュリティーチェックのために使用される現在のドメインを返す。

(それらが同じことをする場合)互いにアクセスするために同じドメインの他のサブドメインのページを許可するために効果的なスクリプトの生成元を変更するために、サブドメインを削除した値に設定可能である。(サンドボックス化されたiframeにおいて設定できない。)

The domain attribute on Document objects must be initialized to the document's domain, if it has one, and the empty string otherwise. If the document's domain starts with a "[" (U+005B) character and ends with a "]" (U+005D) character, it is an IPv6 address; these square brackets must be omitted when initializing the attribute's value.

On getting, the attribute must return its current value, unless the Document has no browsing context, in which case it must return the empty string.

On setting, the user agent must run the following algorithm:

  1. If the Document has no browsing context, throw a SecurityError exception and abort these steps.

  2. If the Document's active sandboxing flag set has its sandboxed document.domain browsing context flag set, throw a SecurityError exception and abort these steps.

  3. If the new value is an IPv4 or IPv6 address, let new value be the new value. Otherwise, apply the IDNA ToASCII algorithm to the new value, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, and let new value be the result of the ToASCII algorithm.

    If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then throw a SecurityError exception and abort these steps. [RFC5890]

  4. If new value is not exactly equal to the current value of the document.domain attribute, then run these substeps:

    1. If the current value is an IPv4 or IPv6 address, throw a SecurityError exception and abort these steps.

    2. If new value, prefixed by a "." (U+002E), does not exactly match the end of the current value, throw a SecurityError exception and abort these steps.

      If the new value is an IPv4 or IPv6 address, it cannot match the new value in this way and thus an exception will be thrown here.

    3. If new value matches a suffix in the Public Suffix List, or, if new value, prefixed by a "." (U+002E), matches the end of a suffix in the Public Suffix List, then throw a SecurityError exception and abort these steps. [PSL]

      Suffixes must be compared after applying the IDNA ToASCII algorithm to them, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, in an ASCII case-insensitive manner. [RFC5890]

  5. Release the storage mutex.

  6. Set the attribute's value to new value.

  7. If the effective script origin of the Document is an alias, set it to the value of the effective script origin (essentially de-aliasing the effective script origin).

  8. If new value is not the empty string, then run these substeps:

    1. Set the host part of the effective script origin tuple of the Document to new value.

    2. Set the port part of the effective script origin tuple of the Document to "manual override" (a value that, for the purposes of comparing origins, is identical to "manual override" but not identical to any other value).

The domain of a Document is the host part of the document's origin, if the value of that origin is a scheme/host/port tuple. If it isn't, then the document does not have a domain.

domain属性は、ドメインの異なるホスト上の有効なページに互いのDOMをアクセスするために使用される。

共有ホスティングを使用する際document.domainの属性を使用しない。信頼できない第三者が同じIPアドレスだが別のポート上でHTTPサーバーをホストできる場合、document.domain属性が使用された後に生成元を比較する際にポートは無視されるように、通常同じホスト上の2つの異なるサイトを保護する同一生成元の保護は失敗するだろう。

5.4 サンドボックス

サンドボックスフラグ設定は、潜在的に信頼されないリソースが持つ能力を制限するために使用される、以下のフラグに属するゼロ個以上のセットである:

サンドボックス化されたナビゲーションブラウジングコンテキストフラグ

このフラグは、サンドボックス化されたブラウジングコンテキスト自身以外のコンテンツのナビゲーションブラウジングコンテキスト(またはその中にさらにネストされたブラウジングコンテキスト)、(次の定義されたサンドボックス化された補助ナビゲーションブラウジングコンテキストフラグにより保護される)補助ブラウジングコンテキスト、および(以下に定義するサンドボックス化されたトップレベルナビゲーションブラウジングコンテキストフラグによって保護される)トップレベルブラウジングコンテキストを阻止する。

サンドボックス化された補助ナビゲーションブラウジングコンテキストフラグが設定されない場合、それにもかかわらず一定の場合における制限はポップアップ(新しいトップレベルブラウジングコンテキスト)を開くことができる。これらのブラウジングコンテキストは常に、1つの許可されたサンドボックス化されたナビゲーターを持ち、実際に移動するために作成したブラウジングコンテキストを許可する、ブラウジングコンテキストが作成される際に設定を持つ。(そうでなければ、サンドボックス化されたナビゲーションブラウジングコンテキストフラグは、それらが開かれた場合であってもナビゲートされていくのを防ぐだろう。)

サンドボックス化された補助ナビゲーションブラウジングコンテキストフラグ

このフラグは、たとえばtarget属性、またはwindow.open()の使用など、新しい補助ブラウジングコンテキストの作成からコンテンツを防ぐ

サンドボックス化されたトップレベルナビゲーションブラウジングコンテキストフラグ

このフラグは、それらのトップレベルブラウジングコンテキストのナビゲートからコンテンツを防ぎ、かつそれらのトップレベルブラウジングコンテキストの遮断からコンテンツを防ぐ

サンドボックス化されたトップレベルナビゲーションブラウジングコンテキストフラグが設定されない場合、コンテンツはそのトップレベルブラウジングコンテキストをナビゲートできるが、他のブラウジングコンテキストは依然としてサンドボックス化されたナビゲーションブラウジングコンテキストフラグおよびおそらくサンドボックス化された補助ナビゲーションブラウジングコンテキストフラグによって保護される。

サンドボックス化されたプラグインブラウジングコンテキストフラグ

これらのプラグイン安全でない限り、embed要素object要素applet要素を使用しているかどうか、またはネストされたブラウジングコンテキストナビゲーションを介して、このフラグは、プラグインをインスタンス化するコンテンツを防ぐ。

サンドボックス化された生成元ブラウジングコンテキストフラグ

このフラグは、一意な生成元にコンテンツを強制する。したがって、同一生成元から他のコンテンツにアクセスすることを防止する。

このフラグはまた、document.cookieIDL属性からの読み取りまたは書き込みをするスクリプトを防止しlocalStorageへのアクセスをブロックする。[WEBSTORAGE]

サンドボックス化されたフォームブラウジングコンテキストフラグ

このフラグはフォーム送信をブロックする

サンドボックス化されたポインタロックブラウジングコンテキストフラグ

このフラグはPointer Lock APIを無効にする。[POINTERLOCK]

サンドボックス化されたスクリプトブラウジングコンテキストフラグ

このフラグは、スクリプトの実行をブロックする

サンドボックス化された自動機能ブラウジングコンテキストフラグ

このフラグは、自動ビデオ再生自動フォームコントロールフォーカスなどの、自動的に切り替える機能をブロックする。

サンドボックス化されたフルスクリーンブラウジングコンテキストフラグ

このフラグは、requestFullscreen()メソッドの使用からコンテンツを保護する。

サンドボックス化されたdocument.domainブラウジングコンテキストフラグ

このフラグは、有効なスクリプトの生成元を変更するdocument.domain機能の使用からコンテンツを防止する。

ユーザーエージェントがサンドボックスディレクティブを解析する場合、文字列inputサンドボックスフラグ設定output、および任意でallow fullscreen flagを与え、次の手順を実行しなければならない:

  1. tokensを取得するために、スペースでのinputを分割する

  2. outputを空にする。

  3. outputに次のフラグを追加する:


すべてのトップレベルブラウジングコンテキストは、サンドボックスフラグが設定される、ポップアップサンドボックスフラグ設定を持つ。ブラウジングコンテキストが作成される場合、そのポップアップサンドフラグ設定は空でなければならない。これは、ブラウジングコンテキスト名を指定されるブラウジングコンテキストを選択するための規則によって移入される。

すべてのネストされたブラウジングコンテキストは、サンドボックスフラグが設定される、iframeサンドボックスフラグ設定を持つ。ネストされたブラウジングコンテキストiframeサンドボックスフラグ設定で任意の特定の時間に設定されるそれぞれのフラグは、iframe要素のsandbox属性によって決定される。

すべてのDocumentは、サンドボックスフラグ設定である、アクティブサンドボックスフラグ設定を持つ。Documentが作成される場合、そのアクティブサンドボックスフラグ設定が空でなければならない。それは、ナビゲーションアルゴリズムによって追加される。

ナビゲーションアルゴリズムによって得られるすべてのリソースは、サンドボックスフラグが設定される、強制サンドボックスフラグ設定を持つ。デフォルトでリソースは、その強制サンドボックスフラグセットで設定されるフラグを持たないが、他の仕様は、特定のフラグが設定されていることを定義できる。

具体的には、強制サンドボックスフラグセットがコンテンツセキュリティーポリシー仕様によって使用される。[CSP]


ユーザーエージェントがDocumentサンドボックスを実装する際に、Documentオブジェクトが作成された時点で、次のサンドボックスフラグセットに存在するフラグの組合とともにDocumentアクティブなサンドボックスフラグセットを追加しなければならない:

5.5 セッション履歴およびナビゲーション

5.5.1 ブラウジングコンテキストのセッション履歴

ブラウジングコンテキスト内のDocumentの配列は、そのセッション履歴である。ネストされたブラウジングコンテキストを含む各ブラウジングコンテキストは、個別のセッション履歴を持つ。ブラウジングコンテキストのセッション履歴は、セッション履歴のエントリのフラットなリストから成る。各セッション履歴のエントリは、少なくとも、URL、およびさらに状態オブジェクトを持ってもよい各エントリ、タイトル、Documentオブジェクト、フォームデータ、スクロールポジション、および関連する他の情報から構成される。

最初に作成される際、各エントリはDocumentを持つ。しかし、Document活性化でない場合、リソースを解放するために廃棄することができる。セッション履歴のエントリにおいてURLなどのデータは、新しいDocumentに元の場所を取るものをもたらすために使用され、ユーザーエージェントは自身にそのDocumentを再活性化する必要を見つけるべきである。

セッション履歴エントリに関連付けられたタイトルは、Documentの現在のtitleと関係をもつ必要はない。セッション履歴エントリのタイトルは、ユーザーが文書の履歴をナビゲートできるように、その時点で文書の状態を説明しようとするものである。

セッション履歴関連付けられるURLが、ユーザー(またはスクリプト)がページからページへ移動するように状態に追加される。


ブラウジングコンテキストセッション履歴における各Documentオブジェクトは、同じ基礎となるセッション履歴をすべてモデル化しなければならない、一意なHistoryオブジェクトに関連付けられる。

The history attribute of the Window interface must return the object implementing the History interface for that Window object's newest Document.


状態オブジェクトは、ユーザーインターフェースの状態を表すオブジェクトである。

ページは、セッション履歴に状態オブジェクト追加できる。このように著者に一つでもページのアプリケーションでは"ナビゲーション"メタファーを使用できるように、これらは、ユーザー(またはスクリプト)が履歴に戻る際にその後スクリプトに返される

状態オブジェクトは、2つの主な目的に使用されることを意図される:1つ目は、(それがユーザーによって扱うURLを渡されるものに対して解析する必要が依然としてあるので、マイナー最適化のみであるが)単純なケース場合において、著者が解析を行う必要がないように、URL内の状態の事前解析された説明を格納し、2つ目は、新しいDocumentが開かれた場合、現在のDocumentインスタンスのみに適用され、再構築しなければならないため、著者はそれがURLに格納しない状態を保存できるようにする。

後者の例は、ユーザーが戻った場合同じ場所にアニメーションさせることができるように、ポップアップdivがアニメーション化するために作られた正確な座標を追跡するようなものになるだろう。またその代わりに、前後に行く際に、情報が再度フェッチする必要がないよう、URL内の情報に基づいてサーバーからフェッチされるデータのキャッシュにポインタを保持するために使用できる。


任意の時点で、セッション履歴のエントリの一つは、現在のエントリである。これは、ブラウジングコンテキストアクティブドキュメントを表すエントリである。現在のエントリであるそれぞれのエントリは、この仕様で定義されるアルゴリズムによって変更される。たとえばセッション履歴走査中など。

現在のエントリは通常、Documentアドレスのエントリである。しかし、それはまた、その文書によって履歴に追加された状態オブジェクトのエントリのいずれかを指定できる。

永続ユーザー状態を持つエントリはまた、ユーザーエージェント定義の状態を持つ。この仕様は、何が状態の種類を格納できるのかを指定しない。

たとえば、一部のユーザーエージェントは、スクロール位置またはフォームコントロールの値を永続化したいかもしれない。

フォームコントロールの値を永続化するユーザーエージェントはまた、それらの方向(要素のdir属性の値)を保持することが推奨される。これは、ユーザーが最初明示的にデフォルト以外の方向をもつ値を入力した場合、履歴走査の後に誤って値を表示することを防ぐ。

状態オブジェクトから成るエントリは、追加された際にアクティブであったページのエントリと同じDocumentを共有する。

フラグメント識別子が異なる連続したエントリはまた、同じDocumentを共有する。

(単にある特定の文書の異なる状態である)同じDocumentを共有するすべてのエントリは、定義により連続する。

ブラウジングコンテキスト内の各Documentはまた、最新のエントリを持つことができる。これは、エントリまたは直近に走査されたDocumentである。Documentが作成される場合、最初に最新のエントリを持たない。

User agents may discard the Document objects of entries other than the current entry that are not referenced from any script, reloading the pages afresh when the user or script navigates back to such pages. This specification does not specify when user agents should discard Document objects and when they should cache them.

Entries that have had their Document objects discarded must, for the purposes of the algorithms given below, act as if they had not. When the user or script navigates back or forwards to a page which has no in-memory DOM objects, any other entries that shared the same Document object with it must share the new object as well.

5.5.2 Historyインターフェース

interface History {
  readonly attribute long length;
  readonly attribute any state;
  void go(optional long delta);
  void back();
  void forward();
  void pushState(any data, DOMString title, optional DOMString? url = null);
  void replaceState(any data, DOMString title, optional DOMString? url = null);
};
window . history . length

ジョイントセッション履歴内のエントリの数を返す。

window . history . state

現在の状態オブジェクトを返す。

window . history . go( [ delta ] )

ジョイントセッション履歴内のステップの指定した数の前後に進む。

ゼロ差分は、現在のページをリロードする。

差分が範囲外の場合、何もしない。

window . history . back()

ジョイントセッション履歴内の1つのステップに戻る。

前のページが存在しない場合、何もしない。

window . history . forward()

ジョイントセッション履歴内の1つのステップに進む。

次のページが存在しない場合、何もしない。

window . history . pushState(data, title [, url ] )

指定されたURLが供給される場合、指定されたタイトルとともに、セッション履歴上に与えられたデータをプッシュする。

window . history . replaceState(data, title [, url ] )

指定されたデータ、タイトルおよび、提供される場合にURLを持つ、セッション履歴の現在のエントリを更新する。

トップレベルブラウジングコンテキストジョイントセッション履歴は、ジョイントセッション履歴の現在のエントリを除いて削除されたそれぞれのセッション履歴において現在のエントリであるすべてのエントリとともに、トップレベルブラウジングコンテキストを共有するすべての完全にアクティブなDocumentオブジェクトのすべてのブラウジングコンテキストに属するすべてのセッション履歴の結合である。

ジョイントセッション履歴の現在のエントリは、最近そのセッション履歴内の現在のエントリになったエントリである。

ジョイントセッション履歴内のエントリは、それぞれのセッション履歴に追加された時点で時系列に並べられる。各エントリはインデックスを持つ。最古のエントリのインデックスは0を持ち、後続のエントリは連続して増加する整数(1、2、3など)を番号付けされる。

ブラウジングコンテキスト内の各Documentは、異なるイベントループがあるかもしれないので、ジョイントセッション履歴の実際の状態は、不明瞭にできる。たとえば、2つの兄弟iframe要素は、同時に1つのユニークな原点から別のものに互いに横断でき、それらの正確な順序は明確に定義されないかもしれない。それらは後にお互いを知るかもしれないので、同様に、それらはジョイントセッション履歴の長さについて同意しないかもしれない。

All the getters and setters for attributes, and all the methods, defined on the History interface, when invoked on a History object associated with a Document that is not fully active, must throw a SecurityError exception instead of operating as described below.

The length attribute of the History interface must return the number of entries in the top-level browsing context's joint session history.

The actual entries are not accessible from script.

The state attribute of the History interface must return the last value it was set to by the user agent. Initially, its value must be null.

When the go(delta) method is invoked, if the argument to the method was omitted or has the value zero, the user agent must act as if the location.reload() method was called instead. Otherwise, the user agent must traverse the history by a delta whose value is the value of the method's argument.

When the back() method is invoked, the user agent must traverse the history by a delta −1.

When the forward()method is invoked, the user agent must traverse the history by a delta +1.


Each top-level browsing context has a session history traversal queue, initially empty, to which tasks can be added.

Each top-level browsing context, when created, must asynchronously begin running the following algorithm, known as the session history event loop for that top-level browsing context:

  1. Wait until this top-level browsing context's session history traversal queue is not empty.

  2. Pull the first task from this top-level browsing context's session history traversal queue, and execute it.

  3. Return to the first step of this algorithm.

The session history event loop helps coordinate cross-browsing-context transitions of the joint session history: since each browsing context might, at any particular time, have a different event loop (this can happen if the user agent has more than one event loop per unit of related browsing contexts), transitions would otherwise have to involve cross-event-loop synchronisation.


To traverse the history by a delta delta, the user agent must append a task to this top-level browsing context's session history traversal queue, the task consisting of running the following steps:

  1. Let delta be the argument to the method.

  2. If the index of the current entry of the joint session history plus delta is less than zero or greater than or equal to the number of items in the joint session history, then abort these steps.

  3. Let specified entry be the entry in the joint session history whose index is the sum of delta and the index of the current entry of the joint session history.

  4. Let specified browsing context be the browsing context of the specified entry.

  5. If the specified browsing context's active document's unload a document algorithm is currently running, abort these steps.

  6. Queue a task that consists of running the following substeps. The relevant event loop is that of the specified browsing context's active document. The task source for the queued task is the history traversal task source.

    1. If there is an ongoing attempt to navigate specified browsing context that has not yet matured (i.e. it has not passed the point of making its Document the active document), then cancel that attempt to navigate the browsing context.

    2. If the specified browsing context's active document is not the same Document as the Document of the specified entry, then run these substeps:

      1. Fully exit fullscreen.

      2. specified browsing contextアクティブなドキュメントアンロードするように要求する。ユーザーが文書をアンロードできるようにすることを拒否した場合、これらの手順を中止する。

      3. falseに設定するrecycleパラメータをもつspecified browsing contextアクティブなドキュメントアンロードする

    3. Traverse the history of the specified browsing context to the specified entry.

When the user navigates through a browsing context, e.g. using a browser's back and forward buttons, the user agent must traverse the history by a delta equivalent to the action specified by the user.


The pushState(data, title, url) method adds a state object entry to the history.

The replaceState(data, title, url) method updates the state object, title, and optionally the URL of the current entry in the history.

When either of these methods is invoked, the user agent must run the following steps:

  1. Let cloned data be a structured clone of the specified data. If this throws an exception, then rethrow that exception and abort these steps.

  2. If the third argument is not null, run these substeps:

    1. Resolve the value of the third argument, relative to the API base URL specified by the entry settings object.
    2. If that fails, throw a SecurityError exception and abort these steps.
    3. Compare the resulting parsed URL to the result of applying the URL parser algorithm to the document's address. If any component of these two URLs differ other than the path, query, and fragment components, then throw a SecurityError exception and abort these steps.
    4. If the origin of the resulting absolute URL is not the same as the origin of the responsible document specified by the entry settings object, and either the path or query components of the two parsed URLs compared in the previous step differ, throw a SecurityError exception and abort these steps. (This prevents sandboxed content from spoofing other pages on the same origin.)
    5. Let new URL be the resulting absolute URL.

    For the purposes of the comparisons in the above substeps, the path and query components can only be the same if the scheme component of both parsed URLs are relative schemes.

  3. If the third argument is null, then let new URL be the URL of the current entry.

  4. If the method invoked was the pushState() method:

    1. Remove all the entries in the browsing context's session history after the current entry. If the current entry is the last entry in the session history, then no entries are removed.

      This doesn't necessarily have to affect the user agent's user interface.

    2. Remove any tasks queued by the history traversal task source that are associated with any Document objects in the top-level browsing context's document family.

    3. If appropriate, update the current entry to reflect any state that the user agent wishes to persist. The entry is then said to be an entry with persisted user state.

    4. Add a state object entry to the session history, after the current entry, with cloned data as the state object, the given title as the title, and new URL as the URL of the entry.

    5. Update the current entry to be this newly added entry.

    Otherwise, if the method invoked was the replaceState() method:

    1. Update the current entry in the session history so that cloned data is the entry's new state object, the given title is the new title, and new URL is the entry's new URL.

  5. If the current entry in the session history represents a non-GET request (e.g. it was the result of a POST submission) then update it to instead represent a GET request (or equivalent).

  6. Set the document's address to new URL.

    Since this is neither a navigation of the browsing context nor a history traversal, it does not cause a hashchange event to be fired.

  7. Set history.state to a structured clone of cloned data.

  8. Let the latest entry of the Document of the current entry be the current entry.

The title is purely advisory. User agents might use the title in the user interface.

User agents may limit the number of state objects added to the session history per page. If a page hits the UA-defined limit, user agents must remove the entry immediately after the first entry for that Document object in the session history after having added the new entry. (Thus the state history acts as a FIFO buffer for eviction, but as a LIFO buffer for navigation.)

ユーザーはいくつかの座標に常にあり、ユーザーが後で再開するための特定の座標に対応するページをブックマークできるような、ユーザーがラインに沿って移動できるゲームを考える。

そのようなゲームでx=5位置を実装する静的ページは次のようになる:

<!DOCTYPE HTML>
<!-- this is http://example.com/line?x=5 -->
<title>Line Game - 5</title>
<p>You are at coordinate 5 on the line.</p>
<p>
 <a href="?x=6">Advance to 6</a> or
 <a href="?x=4">retreat to 4</a>?
</p>

このようなシステムの問題点は、毎回ユーザーがクリックするとページ全体をリロードする必要があることにある。ここで、代わりにスクリプトを使用して、リロードを行うための別の方法:

<!DOCTYPE HTML>
<!-- this starts off as http://example.com/line?x=5 -->
<title>Line Game - 5</title>
<p>You are at coordinate <span id="coord">5</span> on the line.</p>
<p>
 <a href="?x=6" onclick="go(1); return false;">Advance to 6</a> or
 <a href="?x=4" onclick="go(-1); return false;">retreat to 4</a>?
</p>
<script>
 var currentPage = 5; // prefilled by server
 function go(d) {
   setupPage(currentPage + d);
   history.pushState(currentPage, document.title, '?x=' + currentPage);
 }
 onpopstate = function(event) {
   setupPage(event.state);
 }
 function setupPage(page) {
   currentPage = page;
   document.title = 'Line Game - ' + currentPage;
   document.getElementById('coord').textContent = currentPage;
   document.links[0].href = '?x=' + (currentPage+1);
   document.links[0].textContent = 'Advance to ' + (currentPage+1);
   document.links[1].href = '?x=' + (currentPage-1);
   document.links[1].textContent = 'retreat to ' + (currentPage-1);
 }
</script>

スクリプトをもたないシステムにおいて、前の例と同じように動作する。しかし、同じ体験に対するネットワークアクセスが存在しないので、スクリプトをサポートするユーザーは現在はるかに速く移動できる。さらに、経験に反して、ユーザーは単にナイーブなスクリプトベースのアプローチ、ブックマーク、およびセッション履歴の移動が依然として動作する必要がある。

上記の例において、pushState()メソッドへのdata引数は、サーバに送信されるものと同じ情報であるが、スクリプトはURLにユーザーが移動するたびに解析する必要はないので、より便利な形式となる。

アプリケーションは、その時点で文書のtitle要素の値としてセッション履歴エントリの同じタイトルを使用しないかもしれない。たとえば、これはtitle要素内のブロックを示す単純なページである。明らかに、後方に以前の状態に移動する際にユーザーは時間内に戻らず、したがって、セッション履歴のタイトルに時間を置くことは不適切だろう。

<!DOCTYPE HTML>
<TITLE>Line</TITLE>
<SCRIPT>
 setInterval(function () { document.title = 'Line - ' + new Date(); }, 1000);
 var i = 1;
 function inc() {
   set(i+1);
   history.pushState(i, 'Line - ' + i);
 }
 function set(newI) {
   i = newI;
   document.forms.F.I.value = newI;
 }
</SCRIPT>
<BODY ONPOPSTATE="set(event.state)">
<FORM NAME=F>
State: <OUTPUT NAME=I>1</OUTPUT> <INPUT VALUE="Increment" TYPE=BUTTON ONCLICK="inc()">
</FORM>

5.5.3 Locationインターフェース

ブラウジングコンテキストのセッション履歴における各Documentオブジェクトは、Locationオブジェクトの一意なインスタンスに関連付けられる。

document . location [ = value ]
window . location [ = value ]

現在のページの位置とLocationオブジェクトを返す。

別のページにナビゲートするために、設定可能である。

The location attribute of the Document interface must return the Location object for that Document object, if it is in a browsing context, and null otherwise.

The location attribute of the Window interface must return the Location object for that Window object's Document.

Locationオブジェクトは、そのDocumentブラウジングコンテキストアクティブなドキュメントアドレスの表現を提供し、かつブラウジングコンテキストのセッション履歴に属する現在のエントリの変更をhistoryオブジェクト内のエントリを追加または交換することによって許可する。

[Unforgeable] interface Location {
  void assign(DOMString url);
  void replace(DOMString url);
  void reload();
};
Location implements URLUtils;
location . assign(url)

特定のページに移動する。

location . replace(url)

セッション履歴から現在のページを削除して、指定されたページに移動する。

location . reload()

現在のページをリロードする。

The relevant Document is the Location object's associated Document object's browsing context's active document.

When the assign(url) method is invoked, the UA must resolve the argument, relative to the API base URL specified by the entry settings object, and if that is successful, must navigate the browsing context to the specified url, with exceptions enabled. If the browsing context's session history contains only one Document, and that was the about:blank Document created when the browsing context was created, then the navigation must be done with replacement enabled.

When the replace(url) method is invoked, the UA must resolve the argument, relative to the API base URL specified by the entry settings object, and if that is successful, navigate the browsing context to the specified url with replacement enabled and exceptions enabled.

Navigation for the assign() and replace() methods must be done with the responsible browsing context specified by the incumbent settings object as the source browsing context.

If the resolving step of the assign() and replace() methods is not successful, then the user agent must instead throw a SyntaxError exception.

When the reload() method is invoked, the user agent must run the appropriate steps from the following list:

If the currently executing task is the dispatch of a resize event in response to the user resizing the browsing context

Repaint the browsing context and abort these steps.

If the browsing context's active document is an iframe srcdoc document

Reprocess the iframe attributes of the browsing context's browsing context container.

If the browsing context's active document has its reload override flag set

Perform an overridden reload, with the browsing context being navigated as the responsible browsing context.

そうでなければ

Navigate the browsing context to the document's address with replacement enabled and exceptions enabled. The source browsing context must be the browsing context being navigated.

When a user requests that the active document of a browsing context be reloaded through a user interface element, the user agent should navigate the browsing context to the same resource as that Document, with replacement enabled. In the case of non-idempotent methods (e.g. HTTP POST), the user agent should prompt the user to confirm the operation first, since otherwise transactions (e.g. purchases or database modifications) could be repeated. User agents may allow the user to explicitly override any caches when reloading. If browsing context's active document's reload override flag is set, then the user agent may instead perform an overridden reload rather than the navigation described in this paragraph (with the browsing context being reloaded as the source browsing context).


LocationはまたURLUtilsインターフェースをサポートする。[URL]

When the object is created, and whenever the the address of the relevant Document changes, the user agent must invoke the object's URLUtils interface's set the input algorithm with the address of the relevant Document as the given value.

The object's URLUtils interface's get the base algorithm must return the API base URL specified by the entry settings object, if there is one, or null otherwise.

The object's URLUtils interface's query encoding is the document's character encoding.

When the object's URLUtils interface invokes its update steps with the string value, the user agent must run the following steps:

  1. If any of the following conditions are met, let mode be normal navigation; otherwise, let it be replace navigation:

  2. If mode is normal navigation, then act as if the assign() method had been called with value as its argument. Otherwise, act as if the replace() method had been called with value as its argument.

5.5.3.1 Security

This section describes a security model that is underdefined, imperfect, and does not match implementations. Work is ongoing to attempt to resolve this, but in the meantime, please do not rely on this section for precision. Implementors are urged to send their feedback on how cross-origin cross-global access to Window and Location objects should work. See bug 20701.

User agents must throw a SecurityError exception whenever any properties of a Location object are accessed when the entry settings object specifies an effective script origin that is not the same as the Location object's associated Document's browsing context's active document's effective script origin, with the following exceptions:

When the effective script origin specified by the entry settings object is different than a Location object's associated Document's effective script origin, the user agent must act as if any changes to that Location object's properties, getters, setters, etc, were not present, and as if all the properties of that Location object had their [[Enumerable]] attribute set to false.

For members that return objects (including function objects), each distinct effective script origin that is not the same origin as the Location object's Document's effective script origin must be provided with a separate set of objects. These objects must have the prototype chain appropriate for the script for which the objects are created (not those that would be appropriate for scripts whose settings object specifies a global object that is the Location object's Document's Window object).

5.5.4 Implementation notes for session history

この節は非規範的である。

The History interface is not meant to place restrictions on how implementations represent the session history to the user.

For example, session history could be implemented in a tree-like manner, with each page having multiple "forward" pages. This specification doesn't define how the linear list of pages in the history object are derived from the actual session history as seen from the user's perspective.

Similarly, a page containing two iframes has a history object distinct from the iframes' history objects, despite the fact that typical Web browsers present the user with just one "Back" button, with a session history that interleaves the navigation of the two inner frames and the outer page.

Security: It is suggested that to avoid letting a page "hijack" the history navigation facilities of a UA by abusing pushState(), the UA provide the user with a way to jump back to the previous page (rather than just going back to the previous state). For example, the back button could have a drop down showing just the pages in the session history, and not showing any of the states. Similarly, an aural browser could have two "back" commands, one that goes back to the previous state, and one that jumps straight back to the previous page.

In addition, a user agent could ignore calls to pushState() that are invoked on a timer, or from event listeners that are not triggered in response to a clear user action, or that are invoked in rapid succession.

5.6 ウェブを閲覧する

Features described in this section can at times prove difficult to test in order to assess interoperability. As a result, at present, their test coverage is less than much of the other features with all the stability implications this may have.

Certain actions cause the browsing context to navigate to a new resource. A user agent may provide various ways for the user to explicitly cause a browsing context to navigate, in addition to those defined in this specification.

For example, following a hyperlink, form submission, and the window.open() and location.assign() methods can all cause a browsing context to navigate.

A resource has a URL, but that might not be the only information necessary to identify it. For example, a form submission that uses HTTP POST would also have the HTTP method and payload. Similarly, an iframe srcdoc document needs to know the data it is to use.

Navigation always involves source browsing context, which is the browsing context which was responsible for starting the navigation.

When a browsing context is navigated to a new resource, the user agent must run the following steps:

  1. Release the storage mutex.

  2. If there is a preexisting attempt to navigate the browsing context, and the source browsing context is the same as the browsing context being navigated, and that attempt is currently running the unload a document algorithm, and the origin of the URL of the resource being loaded in that navigation is not the same origin as the origin of the URL of the resource being loaded in this navigation, then abort these steps without affecting the preexisting attempt to navigate the browsing context.

  3. If a task queued by the traverse the history by a delta algorithm is running the unload a document algorithm for the active document of the browsing context being navigated, then abort these steps without affecting the unload a document algorithm or the aforementioned history traversal task.

  4. If the prompt to unload a document algorithm is being run for the active document of the browsing context being navigated, then abort these steps without affecting the prompt to unload a document algorithm.

  5. Let gone async be false.

    The handle redirects step later in this algorithm can in certain cases jump back to the step labeled fragment identifiers. Since, between those two steps, this algorithm goes from operating synchronously in the context of the calling task to operating asynchronously independent of the event loop, some of the intervening steps need to be able to handle both being synchronous and being asynchronous. The gone async flag is thus used to make these steps aware of which mode they are operating in.

  6. If gone async is false, cancel any preexisting but not yet mature attempt to navigate the browsing context, including canceling any instances of the fetch algorithm started by those attempts. If one of those attempts has already created a new Document object, abort that Document also. (Navigation attempts that have matured already have session history entries, and are therefore handled during the update the session history with the new page algorithm, later.)

  7. If the new resource is to be handled using a mechanism that does not affect the browsing context, e.g. ignoring the navigation request altogether because the specified scheme is not one of the supported protocols, then abort these steps and proceed with that mechanism instead.

  8. If gone async is false, prompt to unload the Document object. If the user refused to allow the document to be unloaded, then abort these steps.

    If this instance of the navigation algorithm gets canceled while this step is running, the prompt to unload a document algorithm must nonetheless be run to completion.

  9. If gone async is false, abort the active document of the browsing context.

  10. If the new resource is to be handled by displaying some sort of inline content, e.g. an error message because the specified scheme is not one of the supported protocols, or an inline prompt to allow the user to select a registered handler for the given scheme, then display the inline content and abort these steps.

    In the case of a registered handler being used, the algorithm will be reinvoked with a new URL to handle the request.

  11. If the browsing context being navigated is a nested browsing context, then put it in the delaying load events mode.

    The user agent must take this nested browsing context out of the delaying load events mode when this navigation algorithm later matures, or when it terminates (whether due to having run all the steps, or being canceled, or being aborted), whichever happens first.

  12. This is the step that attempts to obtain the resource, if necessary. Jump to the first appropriate substep:

    If the resource has already been obtained (e.g. because it is being used to populate an object element's new child browsing context)

    Skip this step. The data is already available.

    If the new resource is a URL whose scheme is javascript

    Queue a task to run these "javascript: URL" steps, associated with the active document of the browsing context being navigated:

    1. If the origin of the source browsing context is not the same origin as the origin of the active document of the browsing context being navigated, then act as if the result of evaluating the script was the void value, and jump to the step labeled process results below.

    2. Apply the URL parser to the URL being navigated.

    3. Let parsed URL be the result of the URL parser.

    4. Let script source be the empty string.

    5. Append parsed URL's scheme data component to script source.

    6. If parsed URL's query component is not null, then first append a "?" (U+003F) character to script source, and then append parsed URL's query component to script source.

    7. If parsed URL's fragment component is not null, then first append a "#" (U+0023) character to script source, and then append parsed URL's fragment component to script source.

    8. Replace script source with the result of applying the percent decode algorithm to script source.

    9. Replace script source with the result of applying the UTF-8 decode algorithm to script source.

    10. Let address be the address of the active document of the browsing context being navigated.

    11. Create a script, using script source as the script source, address as the script source URL, JavaScript as the scripting language, and the script settings object of the Window object of the active document of the browsing context being navigated.

      Let result be the return value of the code entry-point of this script. If an exception was thrown, let result be void instead. (The result will be void also if scripting is disabled.)

    12. Process results: If the result of executing the script is void (there is no return value), then the result of obtaining the resource for the URL is equivalent to an HTTP resource with an HTTP 204 No Content response.

      Otherwise, the result of obtaining the resource for the URL is equivalent to an HTTP resource with a 200 OK response whose Content-Type metadata is text/html and whose response body is the return value converted to a string value.

      ナビゲーションアルゴリズム文書のアドレスを設定する時間が来ると、上書きURLとしてaddressを使用する。

    The task source for this task is the DOM manipulation task source.

    So for example a javascript: URL in an href attribute of an a element would only be evaluated when the link was followed, while such a URL in the src attribute of an iframe element would be evaluated in the context of the iframe's own nested browsing context when the iframe is being set up; once evaluated, its return value (if it was not void) would replace that browsing context's document, thus also changing the Window object of that browsing context.

    If the new resource is to be fetched using HTTP GET or equivalent, and there are relevant application caches that are identified by a URL with the same origin as the URL in question, and that have this URL as one of their entries, excluding entries marked as foreign, and whose mode is fast, and the user agent is not in a mode where it will avoid using application caches

    Fetch the resource from the most appropriate application cache of those that match.

    For example, imagine an HTML page with an associated application cache displaying an image and a form, where the image is also used by several other application caches. If the user right-clicks on the image and chooses "View Image", then the user agent could decide to show the image from any of those caches, but it is likely that the most useful cache for the user would be the one that was used for the aforementioned HTML page. On the other hand, if the user submits the form, and the form does a POST submission, then the user agent will not use an application cache at all; the submission will be made to the network.

    そうでなければ

    Fetch the new resource, with the manual redirect flag set.

    If the steps above invoked the fetch algorith, the following requirements also apply:

    If the resource is being fetched using a method other than one equivalent to HTTP's GET, or, if the navigation algorithm was invoked as a result of the form submission algorithm, then the fetching algorithm must be invoked from the origin of the active document of the source browsing context, if any.

    Otherwise, if the browsing context being navigated is a child browsing context, then the fetching algorithm must be invoked from the browsing context scope origin of the browsing context container of the browsing context being navigated, if it has one.

  13. If gone async is false, return to whatever algorithm invoked the navigation steps and continue running these steps asynchronously.

  14. Let gone async be true.

  15. Wait for one or more bytes to be available or for the user agent to establish that the resource in question is empty. During this time, the user agent may allow the user to cancel this navigation attempt or start other navigation attempts.

  16. Fallback in prefer-online mode: If the resource was not fetched from an application cache, and was to be fetched using HTTP GET or equivalent, and there are relevant application caches that are identified by a URL with the same origin as the URL in question, and that have this URL as one of their entries, excluding entries marked as foreign, and whose mode is prefer-online, and the user didn't cancel the navigation attempt during the earlier step, and the navigation attempt failed (e.g. the server returned a 4xx or 5xx status code or equivalent, or there was a DNS error), then:

    Let candidate be the resource identified by the URL in question from the most appropriate application cache of those that match.

    If candidate is not marked as foreign, then the user agent must discard the failed load and instead continue along these steps using candidate as the resource. The user agent may indicate to the user that the original page load failed, and that the page used was a previously cached resource.

    This does not affect the address of the resource from which Request-URIs are obtained, as used to set the document's referrer in the create a Document object steps below; they still use the value as computed by the original fetch algorithm.

  17. Fallback for fallback entries: If the resource was not fetched from an application cache, and was to be fetched using HTTP GET or equivalent, and its URL matches the fallback namespace of one or more relevant application caches, and the most appropriate application cache of those that match does not have an entry in its online whitelist that has the same origin as the resource's URL and that is a prefix match for the resource's URL, and the user didn't cancel the navigation attempt during the previous step, and the navigation attempt failed (e.g. the server returned a 4xx or 5xx status code or equivalent, or there was a DNS error), then:

    Let candidate be the fallback resource specified for the fallback namespace in question. If multiple application caches match, the user agent must use the fallback of the most appropriate application cache of those that match.

    If candidate is not marked as foreign, then the user agent must discard the failed load and instead continue along these steps using candidate as the resource. The document's address, if appropriate, will still be the originally requested URL, not the fallback URL, but the user agent may indicate to the user that the original page load failed, that the page used was a fallback resource, and what the URL of the fallback resource actually is.

    This does not affect the address of the resource from which Request-URIs are obtained, as used to set the document's referrer in the create a Document object steps below; they still use the value as computed by the original fetch algorithm.

  18. Resource handling: If the resource's out-of-band metadata (e.g. HTTP headers), not counting any type information (such as the Content-Type HTTP header), requires some sort of processing that will not affect the browsing context, then perform that processing and abort these steps.

    Such processing might be triggered by, amongst other things, the following:

    • HTTP status codes (e.g. 204 No Content or 205 Reset Content)
    • Network errors (e.g. the network interface being unavailable)
    • Cryptographic protocol failures (e.g. an incorrect TLS certificate)

    Responses with HTTP Content-Disposition headers specifying the attachment disposition type must be handled as a download.

    HTTP 401 responses that do not include a challenge recognized by the user agent must be processed as if they had no challenge, e.g. rendering the entity body as if the response had been 200 OK.

    User agents may show the entity body of an HTTP 401 response even when the response does include a recognized challenge, with the option to login being included in a non-modal fashion, to enable the information provided by the server to be used by the user before authenticating. Similarly, user agents should allow the user to authenticate (in a non-modal fashion) against authentication challenges included in other responses such as HTTP 200 OK responses, effectively allowing resources to present HTTP login forms without requiring their use.

  19. Let type be the sniffed type of the resource.

  20. If the user agent has been configured to process resources of the given type using some mechanism other than rendering the content in a browsing context, then skip this step. Otherwise, if the type is one of the following types, jump to the appropriate entry in the following list, and process the resource as described there:

    "text/html"
    Follow the steps given in the HTML document section, and then, once they have completed, abort this navigate algorithm.
    "application/xml"
    "text/xml"
    "image/svg+xml"
    "application/xhtml+xml"
    Any other type ending in "+xml" that is not an explicitly supported XML type
    Follow the steps given in the XML document section. If that section determines that the content is not to be displayed as a generic XML document, then proceed to the next step in this overall set of steps. Otherwise, once the steps given in the XML document section have completed, abort this navigate algorithm.
    "text/plain"
    Follow the steps given in the plain text file section, and then, once they have completed, abort this navigate algorithm.
    "multipart/x-mixed-replace"
    Follow the steps given in the multipart/x-mixed-replace section, and then, once they have completed, abort this navigate algorithm.
    A supported image, video, or audio type
    Follow the steps given in the media section, and then, once they have completed, abort this navigate algorithm.
    A type that will use an external application to render the content in the browsing context
    Follow the steps given in the plugin section, and then, once they have completed, abort this navigate algorithm.

    An explicitly supported XML type is one for which the user agent is configured to use an external application to render the content (either a plugin rendering directly in the browsing context, or a separate application), or one for which the user agent has dedicated processing rules (e.g. a Web browser with a built-in Atom feed viewer would be said to explicitly support the application/atom+xml MIME type), or one for which the user agent has a dedicated handler (e.g. one registered using registerContentHandler()).

    Setting the document's address: If there is no override URL, then any Document created by these steps must have its address set to the URL that was originally to be fetched, ignoring any other data that was used to obtain the resource (e.g. the entity body in the case of a POST submission is not part of the document's address, nor is the URL of the fallback resource in the case of the original load having failed and that URL having been found to match a fallback namespace). However, if there is an override URL, then any Document created by these steps must have its address set to that URL instead.

    An override URL is set when dereferencing a javascript: URL and when performing an overridden reload.

    Creating a new Document object: when a Document is created as part of the above steps, the user agent must additionally run the following algorithm as part of creating the new object:

    1. Create a new Window object, and associate it with the Document, with one exception: if the browsing context's only entry in its session history is the about:blank Document that was added when the browsing context was created, and navigation is occurring with replacement enabled, and that Document has the same origin as the new Document, then use the Window object of that Document instead, and change the document attribute of the Window object to point to the new Document.

    2. Set the document's referrer to the address of the resource from which Request-URIs are obtained as determined when the fetch algorithm obtained the resource, if that algorithm was used and determined such a value; otherwise, set it to the empty string.

    3. Implement the sandboxing for the Document.

    4. If the active sandboxing flag set of the Document's browsing context or any of its ancestor browsing contexts (if any) have the sandboxed fullscreen browsing context flag set, then skip this step.

      If the Document's browsing context has a browsing context container and either it is not an iframe element, or its Document does not have the fullscreen enabled flag set, then also skip this step.

      Otherwise, set the Document's fullscreen enabled flag.

  21. Otherwise, the document's type is such that the resource will not affect the browsing context, e.g. because the resource is to be handed to an external application or because it is an unknown type that will be processed as a download. Process the resource appropriately.


Some of the sections below, to which the above algorithm defers in certain cases, require the user agent to update the session history with the new page. When a user agent is required to do this, it must queue a task (associated with the Document object of the current entry, not the new one) to run the following steps:

  1. Unload the Document object of the current entry, with the recycle parameter set to false.

    If this instance of the navigation algorithm is canceled while this step is running the unload a document algorithm, then the unload a document algorithm must be allowed to run to completion, but this instance of the navigation algorithm must not run beyond this step. (In particular, for instance, the cancelation of this algorithm does not abort any event dispatch or script execution occurring as part of unloading the document or its descendants.)

  2. If the navigation was initiated for entry update of an entry
    1. Replace the Document of the entry being updated, and any other entries that referenced the same document as that entry, with the new Document.

    2. Traverse the history to the new entry.

    This can only happen if the entry being updated is not the current entry, and can never happen with replacement enabled. (It happens when the user tried to traverse to a session history entry that no longer had a Document object.)

    そうでなければ
    1. Remove all the entries in the browsing context's session history after the current entry. If the current entry is the last entry in the session history, then no entries are removed.

      This doesn't necessarily have to affect the user agent's user interface.

    2. Append a new entry at the end of the History object representing the new resource and its Document object and related state.

    3. Traverse the history to the new entry. If the navigation was initiated with replacement enabled, then the traversal must itself be initiated with replacement enabled.

  3. The navigation algorithm has now matured.

  4. Fragment identifier loop: Spin the event loop for a user-agent-defined amount of time, as desired by the user agent implementor. (This is intended to allow the user agent to optimize the user experience in the face of performance concerns.)

  5. If the Document object has no parser, or its parser has stopped parsing, or the user agent has reason to believe the user is no longer interested in scrolling to the fragment identifier, then abort these steps.

  6. Scroll to the fragment identifier given in the document's address. If this fails to find an indicated part of the document, then return to the fragment identifier loop step.

The task source for this task is the networking task source.

5.6.2 Page load processing model for HTML files

When an HTML document is to be loaded in a browsing context, the user agent must queue a task to create a Document object, mark it as being an HTML document, set its content type to "text/html", create an HTML parser, and associate it with the document. Each task that the networking task source places on the task queue while the fetching algorithm runs must then fill the parser's input byte stream with the fetched bytes and cause the HTML parser to perform the appropriate processing of the input stream.

The input byte stream converts bytes into characters for use in the tokenizer. This process relies, in part, on character encoding information found in the real Content-Type metadata of the resource; the "sniffed type" is not used for this purpose.

When no more bytes are available, the user agent must queue a task for the parser to process the implied EOF character, which eventually causes a load event to be fired.

After creating the Document object, but before any script execution, certainly before the parser stops, the user agent must update the session history with the new page.

Application cache selection happens in the HTML parser.

The task source for the two tasks mentioned in this section must be the networking task source.

5.6.3 Page load processing model for XML files

When faced with displaying an XML file inline, user agents must first create a Document object, following the requirements of the XML and Namespaces in XML recommendations, RFC 7303, DOM, and other relevant specifications. [XML] [XMLNS] [RFC7303] [DOM]

The actual HTTP headers and other metadata, not the headers as mutated or implied by the algorithms given in this specification, are the ones that must be used when determining the character encoding according to the rules given in the above specifications. Once the character encoding is established, the document's character encoding must be set to that character encoding.

If the root element, as parsed according to the XML specifications cited above, is found to be an html element with an attribute manifest whose value is not the empty string, then, as soon as the element is inserted into the document, the user agent must resolve the value of that attribute relative to that element, and if that is successful, must apply the URL serializer algorithm to the resulting parsed URL with the exclude fragment flag set to obtain manifest URL, and then run the application cache selection algorithm with manifest URL as the manifest URL, passing in the newly-created Document. Otherwise, if the attribute is absent, its value is the empty string, or resolving its value fails, then as soon as the root element is inserted into the document, the user agent must run the application cache selection algorithm with no manifest, and passing in the Document.

Because the processing of the manifest attribute happens only once the root element is parsed, any URLs referenced by processing instructions before the root element (such as and PIs) will be fetched from the network and cannot be cached.

User agents may examine the namespace of the root Element node of this Document object to perform namespace-based dispatch to alternative processing tools, e.g. determining that the content is actually a syndication feed and passing it to a feed handler. If such processing is to take place, abort the steps in this section, and jump to the next step (labeled non-document content) in the navigate steps above.

Otherwise, then, with the newly created Document, the user agent must update the session history with the new page. User agents may do this before the complete document has been parsed (thus achieving incremental rendering), and must do this before any scripts are to be executed.

Error messages from the parse process (e.g. XML namespace well-formedness errors) may be reported inline by mutating the Document.

5.6.4 Page load processing model for text files

When a plain text document is to be loaded in a browsing context, the user agent must queue a task to create a Document object, mark it as being an HTML document, set its content type to "text/plain", create an HTML parser, associate it with the document, act as if the tokenizer had emitted a start tag token with the tag name "pre" followed by a single "LF" (U+000A) character, and switch the HTML parser's tokenizer to the PLAINTEXT state. Each task that the networking task source places on the task queue while the fetching algorithm runs must then fill the parser's input byte stream with the fetched bytes and cause the HTML parser to perform the appropriate processing of the input stream.

The rules for how to convert the bytes of the plain text document into actual characters, and the rules for actually rendering the text to the user, are defined in RFC 2046, RFC 3676, and subsequent versions thereof. [RFC2046] [RFC3676]

The document's character encoding must be set to the character encoding used to decode the document.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, and passing in the newly-created Document.

When no more bytes are available, the user agent must queue a task for the parser to process the implied EOF character, which eventually causes a load event to be fired.

After creating the Document object, but potentially before the page has finished parsing, the user agent must update the session history with the new page.

User agents may add content to the head element of the Document, e.g. linking to a style sheet or an XBL binding, providing script, giving the document a title, etc.

In particular, if the user agent supports the Format=Flowed feature of RFC 3676 then the user agent would need to apply extra styling to cause the text to wrap correctly and to handle the quoting feature. This could be performed using, e.g., an XBL binding or a CSS extension.

The task source for the two tasks mentioned in this section must be the networking task source.

5.6.5 Page load processing model for multipart/x-mixed-replace resources

When a resource with the type multipart/x-mixed-replace is to be loaded in a browsing context, the user agent must parse the resource using the rules for multipart types. [RFC2046]

For each body part obtained from the resource, the user agent must run a new instance of the navigate algorithm, starting from the resource handling step, using the new body part as the resource being navigated, with replacement enabled if a previous body part from the same resource resulted in a Document object being created, and otherwise using the same setup as the navigate attempt that caused this section to be invoked in the first place.

For the purposes of algorithms processing these body parts as if they were complete stand-alone resources, the user agent must act as if there were no more bytes for those resources whenever the boundary following the body part is reached.

Thus, load events (and for that matter unload events) do fire for each body part loaded.

5.6.6 Page load processing model for media

When an image, video, or audio resource is to be loaded in a browsing context, the user agent should create a Document object, mark it as being an HTML document, set its content type to the sniffed MIME type of the resource (type in the navigate algorithm), append an html element to the Document, append a head element and a body element to the html element, append an element host element for the media, as described below, to the body element, and set the appropriate attribute of the element host element, as described below, to the address of the image, video, or audio resource.

The element host element to create for the media is the element given in the table below in the second cell of the row whose first cell describes the media. The appropriate attribute to set is the one given by the third cell in that same row.

Type of media Element for the media Appropriate attribute
画像 img src
Video video src
Audio audio src

Then, the user agent must act as if it had stopped parsing.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, and passing in the newly-created Document.

After creating the Document object, but potentially before the page has finished fully loading, the user agent must update the session history with the new page.

User agents may add content to the head element of the Document, or attributes to the element host element, e.g. to link to a style sheet or an XBL binding, to provide a script, to give the document a title, to make the media autoplay, etc.

5.6.7 Page load processing model for content that uses plugins

When a resource that requires an external resource to be rendered is to be loaded in a browsing context, the user agent should create a Document object, mark it as being an HTML document and mark it as being a plugin document, set its content type to the sniffed MIME type of the resource (type in the navigate algorithm), append an html element to the Document, append a head element and a body element to the html element, append an embed to the body element, and set the src attribute of the embed element to the address of the resource.

The term plugin document is used by the Content Security Policy specification as part of the mechanism that ensures iframes can't be used to evade plugin-types directives. [CSP]

Then, the user agent must act as if it had stopped parsing.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, and passing in the newly-created Document.

After creating the Document object, but potentially before the page has finished fully loading, the user agent must update the session history with the new page.

User agents may add content to the head element of the Document, or attributes to the embed element, e.g. to link to a style sheet or an XBL binding, or to give the document a title.

If the Document's active sandboxing flag set has its sandboxed plugins browsing context flag set, the synthesized embed element will fail to render the content if the relevant plugin cannot be secured.

5.6.8 Page load processing model for inline content that doesn't have a DOM

When the user agent is to display a user agent page inline in a browsing context, the user agent should create a Document object, mark it as being an HTML document, set its content type to "text/html", and then either associate that Document with a custom rendering that is not rendered using the normal Document rendering rules, or mutate that Document until it represents the content the user agent wants to render.

Once the page has been set up, the user agent must act as if it had stopped parsing.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, passing in the newly-created Document.

After creating the Document object, but potentially before the page has been completely set up, the user agent must update the session history with the new page.

5.6.9 Navigating to a fragment identifier

When a user agent is supposed to navigate to a fragment identifier, then the user agent must run the following steps:

  1. Remove all the entries in the browsing context's session history after the current entry. If the current entry is the last entry in the session history, then no entries are removed.

    This doesn't necessarily have to affect the user agent's user interface.

  2. Remove any tasks queued by the history traversal task source that are associated with any Document objects in the top-level browsing context's document family.

  3. Append a new entry at the end of the History object representing the new resource and its Document object and related state. Its URL must be set to the address to which the user agent was navigating. The title must be left unset.

  4. Traverse the history to the new entry, with the asynchronous events flag set. This will scroll to the fragment identifier given in what is now the document's address.

If the scrolling fails because the relevant ID has not yet been parsed, then the original navigation algorithm will take care of the scrolling instead, as the last few steps of its update the session history with the new page algorithm.


When the user agent is required to scroll to the fragment identifier and the indicated part of the document, if any, is being rendered, the user agent must either change the scrolling position of the document using the following algorithm, or perform some other action such that the indicated part of the document is brought to the user's attention. If there is no indicated part, or if the indicated part is not being rendered, then the user agent must do nothing. The aforementioned algorithm is as follows:

  1. Let target be the indicated part of the document, as defined below.

  2. If target is the top of the document, then scroll to the beginning of the document for the Document, and abort these steps. [CSSOMVIEW]

  3. Use the scroll an element into view algorithm to scroll target into view, with the align to top flag set. [CSSOMVIEW]

  4. If target is a focusable element, run the focusing steps for that element.

The indicated part of the document is the one that the fragment identifier, if any, identifies. The semantics of the fragment identifier in terms of mapping it to a specific DOM Node is defined by the specification that defines the MIME type used by the Document (for example, the processing of fragment identifiers for XML MIME types is the responsibility of RFC7303). [RFC7303]

For HTML documents (and HTML MIME types), the following processing model must be followed to determine what the indicated part of the document is.

  1. Apply the URL parser algorithm to the URL, and let fragid be the fragment component of the resulting parsed URL.

  2. If fragid is the empty string, then the indicated part of the document is the top of the document; stop the algorithm here.

  3. Let fragid bytes be the result of percent-decoding fragid.

  4. Let decoded fragid be the result of applying the UTF-8 decoder algorithm to fragid bytes. If the UTF-8 decoder emits a decoder error, abort the decoder and instead jump to the step labeled no decoded fragid.

  5. If there is an element in the DOM that has an ID exactly equal to decoded fragid, then the first such element in tree order is the indicated part of the document; stop the algorithm here.

  6. No decoded fragid: If there is an a element in the DOM that has a name attribute whose value is exactly equal to fragid (not decoded fragid), then the first such element in tree order is the indicated part of the document; stop the algorithm here.

  7. If fragid is an ASCII case-insensitive match for the string top, then the indicated part of the document is the top of the document; stop the algorithm here.

  8. Otherwise, there is no indicated part of the document.

For the purposes of the interaction of HTML with Selectors' :target pseudo-class, the target element is the indicated part of the document, if that is an element; otherwise there is no target element. [SELECTORS]

The task source for the task mentioned in this section must be the DOM manipulation task source.

5.6.10 履歴走査

When a user agent is required to traverse the history to a specified entry, optionally with replacement enabled, and optionally with the asynchronous events flag set, the user agent must act as follows.

This algorithm is not just invoked when explicitly going back or forwards in the session history — it is also invoked in other situations, for example when navigating a browsing context, as part of updating the session history with the new page.

  1. If there is no longer a Document object for the entry in question, navigate the browsing context to the resource for that entry to perform an entry update of that entry, and abort these steps. The "navigate" algorithm reinvokes this "traverse" algorithm to complete the traversal, at which point there is a Document object and so this step gets skipped. The navigation must be done using the same source browsing context as was used the first time this entry was created. (This can never happen with replacement enabled.)

    If the resource was obtained usign a non-idempotent action, for example a POST form submission, or if the resource is no longer available, for example because the computer is now offline and the page wasn't cached, navigating to it again might not be possible. In this case, the navigation will result in a different page than previously; for example, it might be an error message explaining the problem or offering to resubmit the form.

  2. If the current entry's title was not set by the pushState() or replaceState() methods, then set its title to the value returned by the document.title IDL attribute.

  3. If appropriate, update the current entry in the browsing context's Document object's History object to reflect any state that the user agent wishes to persist. The entry is then said to be an entry with persisted user state.

  4. If the specified entry has a different Document object than the current entry, then run the following substeps:

    1. Remove any tasks queued by the history traversal task source that are associated with any Document objects in the top-level browsing context's document family.

    2. If the origin of the Document of the specified entry is not the same as the origin of the Document of the current entry, then run the following sub-sub-steps:

      1. The current browsing context name must be stored with all the entries in the history that are associated with Document objects with the same origin as the active document and that are contiguous with the current entry.

      2. If the browsing context is a top-level browsing context, but not an auxiliary browsing context, then the browsing context's browsing context name must be unset.

    3. Make the specified entry's Document object the active document of the browsing context.

    4. If the specified entry has a browsing context name stored with it, then run the following sub-sub-steps:

      1. Set the browsing context's browsing context name to the name stored with the specified entry.

      2. Clear any browsing context names stored with all entries in the history that are associated with Document objects with the same origin as the new active document and that are contiguous with the specified entry.

    5. If the specified entry's Document has any form controls whose autofill field name is "off", invoke the reset algorithm of each of those elements.

    6. If the current document readiness of the specified entry's Document is "complete", queue a task to run the following sub-sub-steps:

      1. If the Document's page showing flag is true, then abort this task (i.e. don't fire the event below).

      2. Set the Document's page showing flag to true.

      3. Run any session history document visibility change steps for Document that are defined by other applicable specifications.

        This is specifically intended for use by the Page Visibility specification. [PAGEVIS]

      4. Fire a trusted event with the name pageshow at the Window object of that Document, but with its target set to the Document object (and the currentTarget set to the Window object), using the PageTransitionEvent interface, with the persisted attribute initialized to true. This event must not bubble, must not be cancelable, and has no default action.

  5. Set the document's address to the URL of the specified entry.

  6. If the specified entry has a URL whose fragment identifier differs from that of the current entry's when compared in a case-sensitive manner, and the two share the same Document object, then let hash changed be true, and let old URL be the URL of the current entry and new URL be the URL of the specified entry. Otherwise, let hash changed be false.

  7. If the traversal was initiated with replacement enabled, remove the entry immediately before the specified entry in the session history.

  8. If the specified entry is not an entry with persisted user state, but its URL has a fragment identifier, scroll to the fragment identifier.

  9. If the entry is an entry with persisted user state, the user agent may update aspects of the document and its rendering, for instance the scroll position or values of form fields, that it had previously recorded.

    This can even include updating the dir attribute of textarea elements or input elements whose type attribute is in either the Text state or the Search state, if the persisted state includes the directionality of user input in such controls.

  10. If the entry is a state object entry, let state be a structured clone of that state object. Otherwise, let state be null.

  11. Set history.state to state.

  12. Let state changed be true if the Document of the specified entry has a latest entry, and that entry is not the specified entry; otherwise let it be false.

  13. Let the latest entry of the Document of the specified entry be the specified entry.

  14. If the asynchronous events flag is not set, then run the following steps synchronously. Otherwise, the asynchronous events flag is set; queue a task to run the following substeps.

    1. If state changed is true, fire a trusted event with the name popstate at the Window object of the Document, using the PopStateEvent interface, with the state attribute initialized to the value of state. This event must bubble but not be cancelable and has no default action.

    2. If hash changed is true, then fire a trusted event with the name hashchange at the browsing context's Window object, using the HashChangeEvent interface, with the oldURL attribute initialized to old URL and the newURL attribute initialized to new URL. This event must bubble but not be cancelable and has no default action.

  15. The current entry is now the specified entry.

The task source for the tasks mentioned above is the DOM manipulation task source.

5.6.10.1 Event definitions

セッション履歴のエントリに移動する際に、popstateイベントは特定の場合に発生する。

[Constructor(DOMString type, optional PopStateEventInit eventInitDict)]
interface PopStateEvent : Event {
  readonly attribute any state;
};

dictionary PopStateEventInit : EventInit {
  any state;
};
event . state

pushState()またはreplaceState()へ提供される情報のコピーを返す。

The state attribute must return the value it was initialized to. オブジェクトが作成される際、この属性はnullに初期化しなければならない。It represents the context information for the event, or null, if the state represented is the initial state of the Document.


URLが前のものとはフラグメント識別子のみ異なるセッション履歴のエントリに移動する際にhashchangeイベントは発火する。

[Constructor(DOMString type, optional HashChangeEventInit eventInitDict)]
interface HashChangeEvent : Event {
  readonly attribute DOMString oldURL;
  readonly attribute DOMString newURL;
};

dictionary HashChangeEventInit : EventInit {
  DOMString oldURL;
  DOMString newURL;
};
event . oldURL

以前に現在であったセッション履歴のエントリURLを返す。

event . newURL

今現在であるセッション履歴のエントリURLを返す。

The oldURL attribute must return the value it was initialized to. オブジェクトが作成される際、この属性はnullに初期化しなければならない。It represents context information for the event, specifically the URL of the session history entry that was traversed from.

The newURL attribute must return the value it was initialized to. オブジェクトが作成される際、この属性はnullに初期化しなければならない。It represents context information for the event, specifically the URL of the session history entry that was traversed to.


セッション履歴エントリ横断する際にpageshowイベントは発火する。セッション履歴のエントリから横断する際にpagehideイベントは発火する。仕様は、そのスクリプトが一貫した方法で(それらが、彼らは介在するpageshowなしの行で2つのpagehideイベントを受信しない、またはその逆で)これらのイベントを受け取ることを確認するためのpage showingフラグを使用する。

[Constructor(DOMString type, optional PageTransitionEventInit eventInitDict)]
interface PageTransitionEvent : Event {
  readonly attribute boolean persisted;
};

dictionary PageTransitionEventInit : EventInit {
  boolean persisted;
};
event . persisted

pageshowに対して、ページが新しく読み込まれている(およびloadイベントが発生する)場合にfalseを返す。そうでなければ、trueを返す。

pagehideイベントに対して、ページが最後の時間まで出かける場合はfalseを返す。そうでなければ、(何もページを最上にしないよう共謀しない場合)、ユーザーがこのページに戻る場合、ページが再利用されるかもしれないことを意味し、trueを返す。

最上でないページを含む可能性があるもの:

The persisted attribute must return the value it was initialized to. When the object is created, this attribute must be initialized to false. It represents the context information for the event.

5.6.11 文書の解放

A Document has a salvageable state, which must initially be true, a fired unload flag, which must initially be false, and a page showing flag, which must initially be false.

Event loops have a termination nesting level counter, which must initially be zero.

When a user agent is to prompt to unload a document, it must run the following steps.

  1. Increase the event loop's termination nesting level by one.

  2. Increase the Document's ignore-opens-during-unload counter by one.

  3. Let event be a new trusted BeforeUnloadEvent event object with the name beforeunload, which does not bubble but is cancelable.

  4. Dispatch: Dispatch event at the Document's Window object.

  5. Decrease the event loop's termination nesting level by one.

  6. Release the storage mutex.

  7. If any event listeners were triggered by the earlier dispatch step, then set the Document's salvageable state to false.

  8. If the returnValue attribute of the event object is not the empty string, or if the event was canceled, then the user agent should ask the user to confirm that they wish to unload the document.

    The prompt shown by the user agent may include the string of the returnValue attribute, or some leading subset thereof. (A user agent may want to truncate the string to 1024 characters for display, for instance.)

    The user agent must pause while waiting for the user's response.

    If the user did not confirm the page navigation, then the user agent refused to allow the document to be unloaded.

  9. If this algorithm was invoked by another instance of the "prompt to unload a document" algorithm (i.e. through the steps below that invoke this algorithm for all descendant browsing contexts), then jump to the step labeled end.

  10. Let descendants be the list of the descendant browsing contexts of the Document.

  11. If descendants is not an empty list, then for each browsing context b in descendants run the following substeps:

    1. Prompt to unload the active document of the browsing context b. If the user refused to allow the document to be unloaded, then the user implicitly also refused to allow this document to be unloaded; jump to the step labeled end.

    2. If the salvageable state of the active document of the browsing context b is false, then set the salvageable state of this document to false also.

  12. End: Decrease the Document's ignore-opens-during-unload counter by one.

When a user agent is to unload a document, it must run the following steps. These steps are passed an argument, recycle, which is either true or false, indicating whether the Document object is going to be re-used. (This is set by the document.open() method.)

  1. Increase the event loop's termination nesting level by one.

  2. Increase the Document's ignore-opens-during-unload counter by one.

  3. If the Document's page showing flag is false, then jump to the step labeled unload event below (i.e. skip firing the pagehide event and don't rerun the unloading document visibility change steps).

  4. Set the Document's page showing flag to false.

  5. Fire a trusted event with the name pagehide at the Window object of the Document, but with its target set to the Document object (and the currentTarget set to the Window object), using the PageTransitionEvent interface, with the persisted attribute initialized to true if the Document object's salvageable state is true, and false otherwise. This event must not bubble, must not be cancelable, and has no default action.

  6. Run any unloading document visibility change steps for Document that are defined by other applicable specifications.

    This is specifically intended for use by the Page Visibility specification. [PAGEVIS]

  7. Unload event: If the Document's fired unload flag is false, fire a simple event named unload at the Document's Window object.

  8. Decrease the event loop's termination nesting level by one.

  9. Release the storage mutex.

  10. If any event listeners were triggered by the earlier unload event step, then set the Document object's salvageable state to false and set the Document's fired unload flag to true.

  11. Run any unloading document cleanup steps for Document that are defined by this specification and other applicable specifications.

  12. If this algorithm was invoked by another instance of the "unload a document" algorithm (i.e. by the steps below that invoke this algorithm for all descendant browsing contexts), then jump to the step labeled end.

  13. Let descendants be the list of the descendant browsing contexts of the Document.

  14. If descendants is not an empty list, then for each browsing context b in descendants run the following substeps:

    1. Unload the active document of the browsing context b with the recycle parameter set to false.

    2. If the salvageable state of the active document of the browsing context b is false, then set the salvageable state of this document to false also.

  15. If both the Document's salvageable state and recycle are false, then the Document's browsing context must discard the Document.

  16. End: Decrease the Document's ignore-opens-during-unload counter by one.

This specification defines the following unloading document cleanup steps. Other specifications can define more.

  1. Make disappear any WebSocket objects that were created by the WebSocket() constructor from the Document's Window object.

    If this affected any WebSocket objects, then set Document's salvageable state to false.

  2. If the Document's salvageable state is false, forcibly close any EventSource objects that whose constructor was invoked from the Document's Window object.

  3. If the Document's salvageable state is false, empty the Document's Window's list of active timers.

5.6.11.1 Event definition
interface BeforeUnloadEvent : Event {
           attribute DOMString returnValue;
};
event . returnValue [ = value ]

イベントの現在の戻り値(ユーザーに表示するメッセージ)を返す。

メッセージを更新する設定が可能である。

BeforeUnloadEvent固有の初期化メソッドは存在しない。

The returnValue attribute represents the message to show the user. When the event is created, the attribute must be set to the empty string. On getting, it must return the last value it was set to. On setting, the attribute must be set to the new value.

5.6.12 Aborting a document load

If a Document is aborted, the user agent must run the following steps:

  1. Abort the active documents of every child browsing context. If this results in any of those Document objects having their salvageable state set to false, then set this Document's salvageable state to false also.

  2. Cancel any instances of the fetch algorithm in the context of this Document, discarding any tasks queued for them, and discarding any further data received from the network for them. If this resulted in any instances of the fetch algorithm being canceled or any queued tasks or any network data getting discarded, then set the Document's salvageable state to false.

  3. If the Document has an active parser, then abort that parser and set the Document's salvageable state to false.

User agents may allow users to explicitly invoke the abort a document algorithm for a Document. If the user does so, then, if that Document is an active document, the user agent should queue a task to fire a simple event named abort at that Document's Window object before invoking the abort algorithm.

5.7 オフラインウェブアプリケーション

5.7.1 導入

この節は非規範的である。

ネットワーク接続が利用できない場合―たとえば、ユーザーがISPのカバレッジエリアの外に移動しているため―でも、ユーザーにウェブアプリケーションおよび文書との対話を継続できるようにするために、著者は、オフラインで作業し、オフラインで使用のためにファイルのコピーを保持するためにユーザーのブラウザになる、ウェブアプリケーション用に必要とされるファイルの一覧を示したマニフェストを提供できる。

これを説明するために、HTMLページ"clock.html"、CSSスタイルシート"clock.css"、およびJavaScriptスクリプト"clock.js"から成る単純な時計アプレットを考えてみる。

マニフェストを追加する前に、これらの3つのファイルは次のようになる:

EXAMPLE offline/clock/clock1.html
EXAMPLE offline/clock/clock1.css
EXAMPLE offline/clock/clock1.js

ユーザーがオフライン時に"clock.html"ページを開こうとする場合、しかし、(ローカルキャッシュにまだ持つ場合を除いて)ユーザーエージェントはエラーとともに失敗する。

著者は、代わりに"clock.appcache"という、3つのファイルのマニフェストを提供できる:

EXAMPLE offline/clock/clock2.appcache

HTMLファイルへの小さな変化とともに、(text/cache-manifestで提供される)マニフェストがアプリケーションにリンクされている:

EXAMPLE offline/clock/clock2.html

さて、ユーザーがページに行く場合、ブラウザはファイルをキャッシュし、ユーザーがオフラインである場合でも、それらを使用できるようにする。

著者はまた、マニフェストのメインページを含めることを推奨するが、実際にマニフェストを参照されるページは、明示的に言及されない場合でも、自動的にキャッシュされる。

"no-store"ディレクティブ例外とともに、TLSで供給される(https:を使用して暗号化される)キャッシュページでのHTTPキャッシュヘッダーと制限は、マニフェストによって上書きされる。したがって、ページは、ユーザーエージェントがそれを更新する前にアプリケーションキャッシュから期限切れにならず、TLS経由で提供されるアプリケーションはオフラインで動作させることができる。

この例をオンラインで見る

5.7.1.1 レガシーアプリケーションへのオフラインキャッシュのサポート

この節は非規範的である。

マニフェストに記載されかつアプリケーションキャッシュに格納されたロジック(マークアップ、スクリプト、スタイルシート、画像など)とともに、アプリケーションに対する有限数の静的HTMLページとともに、およびウェブストレージまたはサーバ側にインデックス付けされたデータベースに格納されたアプリケーションおよびユーザデーターとともに、アプリケーションロジックがアプリケーションとユーザデータから別れる場合、アプリケーションキャッシュ機能は最も機能的に動作し、ウェブソケット、XMLHttpRequest、サーバに送信されるイベント、または他の同様の機構を使用して動的に更新される。

このモデルはユーザーに対して高速な経験をもたらす:(おそらく古いデータを示しつつ)アプリケーション即時に読み込み、ネットワークがそれを可能にするように、新鮮なデータを高速に得られる。

しかし、レガシーアプリケーションは、サーバから新しいHTMLページで得られた各操作とともに、ユーザーデータおよびロジックがHTMLと一緒に混合されるように設計される傾向にある。

たとえば、ニュースアプリケーションを考えてみよう。このようなアプリケーションの典型的なアーキテクチャは、アプリケーションキャッシュ機能を使用しない場合、ユーザーはメインページをフェッチし、サーバーは現在の見出しとユーザーインタフェースロジックを一緒に混合した動的に生成されるページを返す。

しかし、アプリケーションキャッシュ機能のために設計されたニュースアプリケーションは、ロジックでのみ構成されるメインページを代わりに持つだろうし、メインページがサーバとは別にデータをフェッチしているだろう。たとえば、XMLHttpRequestを使用して。

混合コンテンツモデルは、アプリケーションのキャッシュ機能とともにうまく動作しない:コンテンツがキャッシュされているので、常にキャッシュが更新された前回から古いデータを見て、ユーザーにもたらすだろう。

分離されたモデルと同じ速さで、従来のモデルを動作させる方法がないが、それは少なくとも好ましいオンラインアプリケーションキャッシュモードを使用してオフライン利用で使用するために改造できる。これを行うには、アプリケーションキャッシュマニフェストでオフライン作業をしたいHTMLページによって使用されるすべての静的リソースを一覧表示し、HTMLファイルからそのマニフェストを選択するmanifest属性を使用し、マニフェストの一番下に次の行を追加する:

SETTINGS:
prefer-online
NETWORK:
*

ユーザーがオフラインである際に、許可するすべてのリソースが通常アクセスされるマニフェストに記載されていない一方で、これは、マスターエントリにのみ使用されるアプリケーションキャッシュを引き起こし、(本質的にマニフェストに記載されているリソースをピン留めする)分割不能なHTTPキャッシュとして使用されるアプリケーションキャッシュを引き起こす。

5.7.1.2 イベントの概要

この節は非規範的である。

ユーザーがマニフェストを宣言するページを訪問する際に、ブラウザはキャッシュを更新しようとする。これは、ユーザーエージェントが最後にそれを見てからマニフェストが変更された場合、それが言及されているすべてのリソースを再ダウンロードして改めてキャッシュし、マニフェストのコピーを取得することによってこれを行う。

これが起こっているように、ユーザーに適切な方法で通知できるように、イベントの数は、キャッシュの更新の状態へと更新されたスクリプトを保つためにApplicationCacheオブジェクトで発火する。イベントは次のとおり:

イベント名 インターフェース 発火条件 次のイベント
checking Event ユーザーエージェントは、更新をチェックする、または初回のマニフェストをダウンロードしようとしている。これは、常にシーケンスの最初のイベントである。 noupdatedownloadingobsoleteerror
noupdate Event マニフェストは変更されなかった。 シーケンス内の最後のイベント。
downloading Event ユーザーエージェントは更新を発見し、それをフェッチしている、または初回のマニフェストで記載されたリソースをダウンロードしている。 progresserrorcachedupdateready
progress ProgressEvent ユーザーエージェントは、マニフェストで記載されたリソースをダウンロードしている。イベントオブジェクトのtotal属性は、ダウンロードされたファイルの合計数を返す。イベントオブジェクトのloaded属性は、これまでに処理されたファイルの数を返す。 progresserrorcachedupdateready
cached Event マニフェストに記載されたリソースがダウンロードされ、アプリケーションがキャッシュされた。 シーケンス内の最後のイベント。
updateready Event マニフェストに記載されたリソースは新しく再ダウンロードされており、スクリプトは新しいキャッシュに切り替えるためにswapCache()を使用できる。 シーケンス内の最後のイベント。
obsolete Event マニフェストは404または410ページになっていることが判明し、アプリケーションのキャッシュを削除している。 シーケンス内の最後のイベント。
error Event マニフェストが404または410ページだったので、アプリケーションをキャッシュする試みが中止された。 シーケンス内の最後のイベント。
マニフェストは変更されなかったが、マニフェストを参照するページが正しくダウンロードでなかった。
マニフェストに記載されたリソースを取得するときに致命的なエラーが発生した。
更新されている間にマニフェストが変更された。 ユーザーエージェントは、再び一時的にファイルを取得しようする。

これらのイベントはキャンセル可能である。それらのデフォルトアクションは、ダウンロードの進捗情報を表示するためのユーザエージェントに対するものである。ページが独自のアップデートのUIが表示する場合、イベントのキャンセルは、冗長な進捗情報の表示からユーザーエージェントを防ぐだろう。

5.7.2 Application caches

An application cache is a set of cached resources consisting of:

Each application cache has a completeness flag, which is either complete or incomplete.


An application cache group is a group of application caches, identified by the absolute URL of a resource manifest which is used to populate the caches in the group.

An application cache is newer than another if it was created after the other (in other words, application caches in an application cache group have a chronological order).

Only the newest application cache in an application cache group can have its completeness flag set to incomplete; the others are always all complete.

Each application cache group has an update status, which is one of the following: idle, checking, downloading.

A relevant application cache is an application cache that is the newest in its group to be complete.

Each application cache group has a list of pending master entries. Each entry in this list consists of a resource and a corresponding Document object. It is used during the application cache download process to ensure that new master entries are cached even if the application cache download process was already running for their application cache group when they were loaded.

An application cache group can be marked as obsolete, meaning that it must be ignored when looking at what application cache groups exist.


A cache host is a Document or a SharedWorkerGlobalScope object. A cache host can be associated with an application cache. [WEBWORKERS]

A Document initially is not associated with an application cache, but can become associated with one early during the page load process, when steps in the parser and in the navigation sections cause cache selection to occur.

A SharedWorkerGlobalScope can be associated with an application cache when it is created. [WEBWORKERS]

Each cache host has an associated ApplicationCache object.


Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following:


A URL matches a fallback namespace if there exists a relevant application cache whose manifest's URL has the same origin as the URL in question, and that has a fallback namespace that is a prefix match for the URL being examined. If multiple fallback namespaces match the same URL, the longest one is the one that matches. A URL looking for a fallback namespace can match more than one application cache at a time, but only matches one namespace in each cache.

If a manifest http://example.com/app1/manifest declares that http://example.com/resources/images is a fallback namespace, and the user navigates to HTTP://EXAMPLE.COM:80/resources/images/cat.png, then the user agent will decide that the application cache identified by http://example.com/app1/manifest contains a namespace with a match for that URL.

5.7.3 キャッシュマニフェスト構文

5.7.3.1 サンプルマニフェスト

この節は非規範的である。

この例のマニフェストは、2つの画像およびキャッシュされたスタイルシートおよびホワイトリストのCGIスクリプトを要求する。

CACHE MANIFEST
# the above line is required

# this is a comment
# there can be as many of these anywhere in the file
# they are all ignored
  # comments can have spaces before them
  # but must be alone on the line

# blank lines are ignored too

# these are files that need to be cached they can either be listed
# first, or a "CACHE:" header could be put before them, as is done
# lower down.
images/sound-icon.png
images/background.png
# note that each file has to be put on its own line

# here is a file for the online whitelist -- it isn't cached, and
# references to this file will bypass the cache, always hitting the
# network (or trying to, if the user is offline).
NETWORK:
comm.cgi

# here is another set of files to cache, this time just the CSS file.
CACHE:
style/default.css

同様に次のように記述できる:

CACHE MANIFEST
NETWORK:
comm.cgi
CACHE:
style/default.css
images/sound-icon.png
images/background.png

オフラインアプリケーションキャッシュマニフェストは、絶対パスまたは絶対URLを使用できる:

CACHE MANIFEST

/main/home
/main/app.js
/settings/home
/settings/app.js
http://img.example.com/logo.png
http://img.example.com/check.png
http://img.example.com/cross.png

次のマニフェストは、ユーザーがオフラインの間にサイト上の任意のページに表示されている汎用のエラーページを定義する。これはまた、オンラインホワイトワイルドカードフラグopenであることを指定し、他のサイト上のリソースにアクセスがブロックされないことを意味する。(汎用フォールバック名前空間なので、同じサイト上のリソースがすでにブロックされない。)

このマニフェスト上のすべてのページのように、同じページにヒットする後続はキャッシュからすぐに読み込まれるので、それらが取得されるようにローカルでキャッシュされるだろう。マニフェストが変更されるまで、これらのページは、再度サーバから取得されることはない。マニフェストが変更される際、次にすべてのファイルが再ダウンロードされる。

スタイルシートや画像などのようなサブリソースは、しかし、通常のHTTPキャッシングセマンティックを使用してのみキャッシュされる。

CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*
5.7.3.2 キャッシュマニフェストの記述

マニフェストは、text/cache-manifestMIMEタイプを使用して配信しなければならない。text/cache-manifestMIMEタイプを使用して配信されるすべてのリソースは、この節で説明するように、アプリケーションキャッシュマニフェストの構文に従わなければならない。

アプリケーションキャッシュマニフェストは、テキストがUTF-8を使用してエンコードされるテキストファイルである。アプリケーションキャッシュマニフェストでのデータは行ベースである。改行は、"LF"(U+000A)文字、"CR"(U+000D)文字、または"CR"(U+000D)"LF"(U+000A)のペアで表されなければならない。[RFC3629]

これは、すべてのtext/*型が唯一のCRLF改行を許可する必要がある、RFC 2046の故意の違反である。しかし、この要件は時代遅れである。CR、LFおよびCRLFの改行の使用は一般的に支持されており、実際に時にCRLFはテキストエディタでサポートされない[RFC2046]

アプリケーションキャッシュマニフェストの最初の行は、文字列"CACHE"、単一のU+0020 SPACE文字、文字列"MANIFEST"、およびU+0020 SPACE文字、"tab"(U+0009)文字、"LF"(U+000A)文字、または"CR"(U+000D)文字のいずれかで構成しなければならない。最初の行は、任意で"BOM"(U+FEFF)文字を付けてもよい。他のテキストが最初の行にある場合、無視される。

後続の行がもしあれば、すべて次のいずれかでなければならない:

空白行

空白行は、ゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字のみで構成しなければならない。

コメント

コメント行は、ゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字に続いて、単一の"#"(U+0023)文字が続き、0個以上の"LF"(U+000A)および"CR"(U+000D)文字以外の文字が続くもので構成されなければならない。

コメントは自身のみで行になければならない。コメントがURLを持つ行に含まれる場合、"#"はフラグメント識別子の一部に間違えられるだろう。

セクションヘッダ

セクションヘッダは、現在のセクションを変更する。可能な4つのセクションヘッダが存在する:

CACHE:
明示的なセクションに切り替える。
FALLBACK:
代替セクションに切り替える。
NETWORK:
オンラインホワイトリストセクションに切り替える。
SETTINGS:
設定セクションに切り替える。

セクションヘッダ行は、ゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字に続き、上記の名前(":)"(U+003A)文字を含む)のいずれかの後にゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字で構成されなければならない。

皮肉なことに、デフォルトでは、現在のセクションは、明示的なセクションである。

現在のセクションのデータ

データ行が取得しなければならない形式は、現在のセクションに依存する。

現在のセクションが明示的なセクションである場合、データ行は、ゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字、マニフェスト自体以外のリソースを識別する妥当なURL、ゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字で構成されなければならない。

現在のセクションがフォールバックセクションである場合、データ行は、ゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字、マニフェスト自身以外のリソースを識別する妥当なURL、1つ以上のU+0020 SPACEおよび"tab"(U+0009)文字、マニフェスト自身以外のリソースを識別する別の妥当なURL、およびゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字で構成されなければならない。

When the current section is the online whitelist section, data lines must consist of zero or more U+0020 SPACE and "tab" (U+0009) characters, either a single "*" (U+002A) character or a valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and "tab" (U+0009) characters.

現在のセクションが設定セクションである場合、データ行は、ゼロ個以上のU+0020 SPACEおよび"tab"(U+0009)文字、設定、およびその後にゼロ個以上のU+0020 SPACEと"tab"(U+0009)文字で構成されなければならない。

現在のところ1つの設定のみが定義される:

キャッシュモード設定
これは、文字列"prefer-online"で構成される。この文字列は、キャッシュモード優先オンラインに設定する。(キャッシュモードはデフォルトで高速になる。)

設定セクション内で、各設定は1回以上出現してはならない。

マニフェストは、複数回のセクションを含んでもよい。セクションは空であってもよい。

フォールバック名前空間自体に関連付けられたフォールバックページであるURL、およびそれらの名前空間は、データ行の最初のURLである名前空間、および2番目のURLであるフォールバックページ対応する、フォールバックセクションで指定されなければならない。キャッシュされる他のすべてのページは、明示的なセクションに記載されなければならない。

フォールバック名前空間およびフォールバックエントリは、マニフェスト自身と同じ生成元を持たなければならない。

フォールバック名前空間は、複数回記載されてはならない。

ユーザーエージェントがオンラインホワイトリストに入れる名前空間は、すべてオンラインホワイトリストセクションで指定されなければならない。(これは、ページがサーバーに通信するために使用しようとされている任意のURLを指定するために必要である。)このようにしてすべてのURLは自動的にホワイトリストに登録されることを指定するために、"*"(U+002A)は文字はURLの1つとして指定されてもよい。

著者は、オンラインホワイトリスト内の別の名前空間が接頭辞一致であるオンラインホワイトリストにある名前空間を含めるべきでない。

相対URLはマニフェスト自身のURLを基準に指定されなければならない。マニフェスト内のすべてのURLは、(明示的または暗黙的に、相対URLを使用して)マニフェスト自身と同じschemeを持たなければならない。[URL]

マニフェスト内のURLは、フラグメント識別子を持たなければならない(すなわち、U+0023 NUMBER SIGN文字はマニフェスト内のURLで許可されない)。

フォールバック名前空間オンラインホワイト内名前空間は、接頭辞一致で一致する。

5.7.3.3 Parsing cache manifests

When a user agent is to parse a manifest, it means that the user agent must run the following steps:

  1. UTF-8 decode the byte stream corresponding with the manifest to be parsed.

    The UTF-8 decode algorithm strips a leading BOM, if any.

  2. Let base URL be the absolute URL representing the manifest.

  3. Apply the URL parser steps to the base URL, so that the components from its parsed URL can be used by the subseqent steps of this algorithm.

  4. Let explicit URLs be an initially empty list of absolute URLs for explicit entries.

  5. Let fallback URLs be an initially empty mapping of fallback namespaces to absolute URLs for fallback entries.

  6. Let online whitelist namespaces be an initially empty list of absolute URLs for an online whitelist.

  7. Let online whitelist wildcard flag be blocking.

  8. Let cache mode flag be fast.

  9. Let input be the decoded text of the manifest's byte stream.

  10. Let position be a pointer into input, initially pointing at the first character.

  11. If the characters starting from position are "CACHE", followed by a U+0020 SPACE character, followed by "MANIFEST", then advance position to the next character after those. Otherwise, this isn't a cache manifest; abort this algorithm with a failure while checking for the magic signature.

  12. If the character at position is neither a U+0020 SPACE character, a "tab" (U+0009) character, "LF" (U+000A) character, nor a "CR" (U+000D) character, then this isn't a cache manifest; abort this algorithm with a failure while checking for the magic signature.

  13. This is a cache manifest. The algorithm cannot fail beyond this point (though bogus lines can get ignored).

  14. Collect a sequence of characters that are not "LF" (U+000A) or "CR" (U+000D) characters, and ignore those characters. (Extra text on the first line, after the signature, is ignored.)

  15. Let mode be "explicit".

  16. Start of line: If position is past the end of input, then jump to the last step. Otherwise, collect a sequence of characters that are "LF" (U+000A), "CR" (U+000D), U+0020 SPACE, or "tab" (U+0009) characters.

  17. Now, collect a sequence of characters that are not "LF" (U+000A) or "CR" (U+000D) characters, and let the result be line.

  18. Drop any trailing U+0020 SPACE and "tab" (U+0009) characters at the end of line.

  19. If line is the empty string, then jump back to the step labeled start of line.

  20. If the first character in line is a "#" (U+0023) character, then jump back to the step labeled start of line.

  21. If line equals "CACHE:" (the word "CACHE" followed by a ":)" (U+003A) character, then set mode to "explicit" and jump back to the step labeled start of line.

  22. If line equals "FALLBACK:" (the word "FALLBACK" followed by a ":)" (U+003A) character, then set mode to "fallback" and jump back to the step labeled start of line.

  23. If line equals "NETWORK:" (the word "NETWORK" followed by a ":)" (U+003A) character, then set mode to "online whitelist" and jump back to the step labeled start of line.

  24. If line equals "SETTINGS:" (the word "SETTINGS" followed by a ":)" (U+003A) character, then set mode to "settings" and jump back to the step labeled start of line.

  25. If line ends with a ":" (U+003A) character, then set mode to "unknown" and jump back to the step labeled start of line.

  26. This is either a data line or it is syntactically incorrect.

  27. Let position be a pointer into line, initially pointing at the start of the string.

  28. Let tokens be a list of strings, initially empty.

  29. While position doesn't point past the end of line:

    1. Let current token be an empty string.

    2. While position doesn't point past the end of line and the character at position is neither a U+0020 SPACE nor a "tab" (U+0009) character, add the character at position to current token and advance position to the next character in input.

    3. Add current token to the tokens list.

    4. While position doesn't point past the end of line and the character at position is either a U+0020 SPACE or a "tab" (U+0009) character, advance position to the next character in input.

  30. Process tokens as follows:

    If mode is "explicit"

    Resolve the first item in tokens, relative to base URL, with the URL character encoding set to UTF-8; ignore the rest.

    If this fails, then jump back to the step labeled start of line.

    If the resulting parsed URL has a different scheme component than base URL (the manifest's URL), then jump back to the step labeled start of line.

    Let new URL be the result of applying the URL serializer algorithm to the resulting parsed URL, with the exclude fragment flag set.

    Add new URL to the explicit URLs.

    If mode is "fallback"

    Let part one be the first token in tokens, and let part two be the second token in tokens.

    Resolve part one and part two, relative to base URL, with the URL character encoding set to UTF-8.

    If either fails, then jump back to the step labeled start of line.

    If the absolute URL corresponding to either part one or part two does not have the same origin as the manifest's URL, then jump back to the step labeled start of line.

    Let part one be the result of applying the URL serializer algorithm to the first resulting parsed URL, with the exclude fragment flag set.

    Let part two be the result of applying the URL serializer algorithm to the second resulting parsed URL, with the exclude fragment flag set.

    If part one is already in the fallback URLs mapping as a fallback namespace, then jump back to the step labeled start of line.

    Otherwise, add part one to the fallback URLs mapping as a fallback namespace, mapped to part two as the fallback entry.

    If mode is "online whitelist"

    If the first item in tokens is a "*" (U+002A) character, then set online whitelist wildcard flag to open and jump back to the step labeled start of line.

    Otherwise, resolve the first item in tokens, relative to base URL, with the URL character encoding set to UTF-8; ignore the rest.

    If this fails, then jump back to the step labeled start of line.

    If the resulting parsed URL has a different scheme component than base URL (the manifest's URL), then jump back to the step labeled start of line.

    Let new URL be the result of applying the URL serializer algorithm to the resulting parsed URL, with the exclude fragment flag set.

    Add new URL to the online whitelist namespaces.

    If mode is "settings"

    If tokens contains a single token, and that token is a case-sensitive match for the string "prefer-online", then set cache mode flag to prefer-online and jump back to the step labeled start of line.

    Otherwise, the line is an unsupported setting: do nothing; the line is ignored.

    If mode is "unknown"

    何もしない。The line is ignored.

  31. Jump back to the step labeled start of line. (That step jumps to the next, and last, step when the end of the file is reached.)

  32. Return the explicit URLs list, the fallback URLs mapping, the online whitelist namespaces, the online whitelist wildcard flag, and the cache mode flag.

The resource that declares the manifest (with the manifest attribute) will always get taken from the cache, whether it is listed in the cache or not, even if it is listed in an online whitelist namespace.

If a resource is listed in the explicit section or as a fallback entry in the fallback section, the resource will always be taken from the cache, regardless of any other matching entries in the fallback namespaces or online whitelist namespaces.

When a fallback namespace and an online whitelist namespace overlap, the online whitelist namespace has priority.

The online whitelist wildcard flag is applied last, only for URLs that match neither the online whitelist namespace nor the fallback namespace and that are not listed in the explicit section.

5.7.4 Downloading or updating an application cache

When the user agent is required (by other parts of this specification) to start the application cache download process for an absolute URL purported to identify a manifest, or for an application cache group, potentially given a particular cache host, and potentially given a master resource, the user agent must run the steps below. These steps are always run asynchronously, in parallel with the event loop tasks.

Some of these steps have requirements that only apply if the user agent shows caching progress. Support for this is optional. Caching progress UI could consist of a progress bar or message panel in the user agent's interface, or an overlay, or something else. Certain events fired during the application cache download process allow the script to override the display of such an interface. (Such events are delayed until after the load event has fired.) The goal of this is to allow Web applications to provide more seamless update mechanisms, hiding from the user the mechanics of the application cache mechanism. User agents may display user interfaces independent of this, but are encouraged to not show prominent update progress notifications for applications that cancel the relevant events.

The application cache download process steps are as follows:

  1. Optionally, wait until the permission to start the application cache download process has been obtained from the user and until the user agent is confident that the network is available. This could include doing nothing until the user explicitly opts-in to caching the site, or could involve prompting the user for permission. The algorithm might never get past this point. (This step is particularly intended to be used by user agents running on severely space-constrained devices or in highly privacy-sensitive environments).

  2. Atomically, so as to avoid race conditions, perform the following substeps:

    1. Pick the appropriate substeps:

      If these steps were invoked with an absolute URL purported to identify a manifest

      Let manifest URL be that absolute URL.

      If there is no application cache group identified by manifest URL, then create a new application cache group identified by manifest URL. Initially, it has no application caches. One will be created later in this algorithm.

      If these steps were invoked with an application cache group

      Let manifest URL be the absolute URL of the manifest used to identify the application cache group to be updated.

      If that application cache group is obsolete, then abort this instance of the application cache download process. This can happen if another instance of this algorithm found the manifest to be 404 or 410 while this algorithm was waiting in the first step above.

    2. Let cache group be the application cache group identified by manifest URL.

    3. If these steps were invoked with a master resource, then add the resource, along with the resource's Document, to cache group's list of pending master entries.

    4. If these steps were invoked with a cache host, and the status of cache group is checking or downloading, then queue a post-load task to fire a simple event named checking that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking to see if it can download the application.

    5. If these steps were invoked with a cache host, and the status of cache group is downloading, then also queue a post-load task to fire a simple event named downloading that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user the application is being downloaded.

    6. If the status of the cache group is either checking or downloading, then abort this instance of the application cache download process, as an update is already in progress.

    7. Set the status of cache group to checking.

    8. For each cache host associated with an application cache in cache group, queue a post-load task to fire a simple event that is cancelable named checking at the ApplicationCache singleton of the cache host. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking for the availability of updates.

    The remainder of the steps run asynchronously.

    If cache group already has an application cache in it, then this is an upgrade attempt. Otherwise, this is a cache attempt.

  3. If this is a cache attempt, then this algorithm was invoked with a cache host; queue a post-load task to fire a simple event named checking that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking for the availability of updates.

  4. Fetching the manifest: Fetch the resource from manifest URL with the synchronous flag set, and let manifest be that resource. HTTP caching semantics should be honored for this request.

    Parse manifest according to the rules for parsing manifests, obtaining a list of explicit entries, fallback entries and the fallback namespaces that map to them, entries for the online whitelist, and values for the online whitelist wildcard flag and the cache mode flag.

    The MIME type of the resource is ignored — it is assumed to be text/cache-manifest. In the future, if new manifest formats are supported, the different types will probably be distinguished on the basis of the file signatures (for the current format, that is the "CACHE MANIFEST" string at the top of the file).

  5. If fetching the manifest fails due to a 404 or 410 response or equivalent, then run these substeps:

    1. Mark cache group as obsolete. This cache group no longer exists for any purpose other than the processing of Document objects already associated with an application cache in the cache group.

    2. Let task list be an empty list of tasks.

    3. For each cache host associated with an application cache in cache group, create a task to fire a simple event named obsolete that is cancelable at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application is no longer available for offline use.

    4. For each entry in cache group's list of pending master entries, create a task to fire a simple event that is cancelable named error (not obsolete!) at the ApplicationCache singleton of the Document for this entry, if there still is one, and append it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

    5. If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.

    6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

    7. Let the status of cache group be idle.

    8. For each task in task list, queue that task as a post-load task.

    9. Abort the application cache download process.

  6. Otherwise, if fetching the manifest fails in some other way (e.g. the server returns another 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download, or the parser for manifests fails when checking the magic signature), or if the server returned a redirect, then run the cache failure steps. [HTTP]

  7. If this is an upgrade attempt and the newly downloaded manifest is byte-for-byte identical to the manifest found in the newest application cache in cache group, or the server reported it as "304 Not Modified" or equivalent, then run these substeps:

    1. Let cache be the newest application cache in cache group.

    2. Let task list be an empty list of tasks.

    3. For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.

      If the download failed (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, the connection times out, or the user cancels the download), or if the resource is labeled with the "no-store" cache directive, then create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one, and append it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

      Otherwise, associate the Document for this entry with cache; store the resource for this entry in cache, if it isn't already there, and categorize its entry as a master entry. If applying the URL parser algorithm to the resource's URL results in a parsed URL that has a non-null fragment component, the URL used for the entry in cache must instead be the absolute URL obtained from applying the URL serializer algorithm to the parsed URL with the exclude fragment flag set (application caches never include fragment identifiers).

    4. For each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named noupdate at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application is up to date.

    5. Empty cache group's list of pending master entries.

    6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

    7. Let the status of cache group be idle.

    8. For each task in task list, queue that task as a post-load task.

    9. Abort the application cache download process.

  8. Let new cache be a newly created application cache in cache group. Set its completeness flag to incomplete.

  9. For each entry in cache group's list of pending master entries, associate the Document for this entry with new cache.

  10. Set the status of cache group to downloading.

  11. For each cache host associated with an application cache in cache group, queue a post-load task to fire a simple event that is cancelable named downloading at the ApplicationCache singleton of the cache host. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a new version is being downloaded.

  12. Let file list be an empty list of URLs with flags.

  13. Add all the URLs in the list of explicit entries obtained by parsing manifest to file list, each flagged with "explicit entry".

  14. Add all the URLs in the list of fallback entries obtained by parsing manifest to file list, each flagged with "fallback entry".

  15. If this is an upgrade attempt, then add all the URLs of master entries in the newest application cache in cache group whose completeness flag is complete to file list, each flagged with "master entry".

  16. If any URL is in file list more than once, then merge the entries into one entry for that URL, that entry having all the flags that the original entries had.

  17. For each URL in file list, run the following steps. These steps may be run in parallel for two or more of the URLs at a time. If, while running these steps, the ApplicationCache object's abort() method sends a signal to this instance of the application cache download process algorithm, then run the cache failure steps instead.

    1. If the resource URL being processed was flagged as neither an "explicit entry" nor or a "fallback entry", then the user agent may skip this URL.

      This is intended to allow user agents to expire resources not listed in the manifest from the cache. Generally, implementors are urged to use an approach that expires lesser-used resources first.

    2. For each cache host associated with an application cache in cache group, queue a post-load task to fire a trusted event with the name progress, which does not bubble, which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to true, the total attribute must be set to the number of files in file list, and the loaded attribute must be set to the number of files in file list that have been either downloaded or skipped so far. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a file is being downloaded in preparation for updating the application. [PROGRESS-EVENTS]

    3. Fetch the resource, from the origin of the URL manifest URL, with the synchronous flag set and the manual redirect flag set. If this is an upgrade attempt, then use the newest application cache in cache group as an HTTP cache, and honor HTTP caching semantics (such as expiration, ETags, and so forth) with respect to that cache. User agents may also have other caches in place that are also honored.

      If the resource in question is already being downloaded for other reasons then the existing download process can sometimes be used for the purposes of this step, as defined by the fetching algorithm.

      An example of a resource that might already be being downloaded is a large image on a Web page that is being seen for the first time. The image would get downloaded to satisfy the img element on the page, as well as being listed in the cache manifest. According to the rules for fetching that image only need be downloaded once, and it can be used both for the cache and for the rendered Web page.

    4. If the previous step fails (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download), or if the server returned a redirect, or if the resource is labeled with the "no-store" cache directive, then run the first appropriate step from the following list: [HTTP]

      If the URL being processed was flagged as an "explicit entry" or a "fallback entry"

      If these steps are being run in parallel for any other URLs in file list, then abort these steps for those other URLs. Run the cache failure steps.

      Redirects are fatal because they are either indicative of a network problem (e.g. a captive portal); or would allow resources to be added to the cache under URLs that differ from any URL that the networking model will allow access to, leaving orphan entries; or would allow resources to be stored under URLs different than their true URLs. All of these situations are bad.

      If the error was a 404 or 410 HTTP response or equivalent
      If the resource was labeled with the "no-store" cache directive

      Skip this resource. It is dropped from the cache.

      そうでなければ

      Copy the resource and its metadata from the newest application cache in cache group whose completeness flag is complete, and act as if that was the fetched resource, ignoring the resource obtained from the network.

      User agents may warn the user of these errors as an aid to development.

      These rules make errors for resources listed in the manifest fatal, while making it possible for other resources to be removed from caches when they are removed from the server, without errors, and making non-manifest resources survive server-side errors.

      Except for the "no-store" directive, HTTP caching rules that would cause a file to be expired or otherwise not cached are ignored for the purposes of the application cache download process.

    5. Otherwise, the fetching succeeded. Store the resource in the new cache.

      If the user agent is not able to store the resource (e.g. because of quota restrictions), the user agent may prompt the user or try to resolve the problem in some other manner (e.g. automatically pruning content in other caches). If the problem cannot be resolved, the user agent must run the cache failure steps.

    6. If the URL being processed was flagged as an "explicit entry" in file list, then categorize the entry as an explicit entry.

    7. If the URL being processed was flagged as a "fallback entry" in file list, then categorize the entry as a fallback entry.

    8. If the URL being processed was flagged as an "master entry" in file list, then categorize the entry as a master entry.

    9. As an optimization, if the resource is an HTML or XML file whose root element is an html element with a manifest attribute whose value doesn't match the manifest URL of the application cache being processed, then the user agent should mark the entry as being foreign.

  18. For each cache host associated with an application cache in cache group, queue a post-load task to fire a trusted event with the name progress, which does not bubble, which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to true, the total and the loaded attributes must be set to the number of files in file list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that all the files have been downloaded. [PROGRESS-EVENTS]

  19. Store the list of fallback namespaces, and the URLs of the fallback entries that they map to, in new cache.

  20. Store the URLs that form the new online whitelist in new cache.

  21. Store the value of the new online whitelist wildcard flag in new cache.

  22. Store the value of the new cache mode flag in new cache.

  23. For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.

    If the download failed (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, the connection times out, or the user cancels the download), or if the resource is labeled with the "no-store" cache directive, then run these substeps:

    1. Unassociate the Document for this entry from new cache.

    2. Queue a post-load task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

    3. If this is a cache attempt and this entry is the last entry in cache group's list of pending master entries, then run these further substeps:

      1. Discard cache group and its only application cache, new cache.

      2. If appropriate, remove any user interface indicating that an update for this cache is in progress.

      3. Abort the application cache download process.

    4. Otherwise, remove this entry from cache group's list of pending master entries.

    Otherwise, store the resource for this entry in new cache, if it isn't already there, and categorize its entry as a master entry.

  24. Fetch the resource from manifest URL again, with the synchronous flag set, and let second manifest be that resource. HTTP caching semantics should again be honored for this request.

    Since caching can be honored, authors are encouraged to avoid setting the cache headers on the manifest in such a way that the user agent would simply not contact the network for this second request; otherwise, the user agent would not notice if the cache had changed during the cache update process.

  25. If the previous step failed for any reason, or if the fetching attempt involved a redirect, or if second manifest and manifest are not byte-for-byte identical, then schedule a rerun of the entire algorithm with the same parameters after a short delay, and run the cache failure steps.

  26. Otherwise, store manifest in new cache, if it's not there already, and categorize its entry as the manifest.

  27. Set the completeness flag of new cache to complete.

  28. Let task list be an empty list of tasks.

  29. If this is a cache attempt, then for each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named cached at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application has been cached and that they can now use it offline.

    Otherwise, it is an upgrade attempt. For each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named updateready at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a new version is available and that they can activate it by reloading the page.

  30. If appropriate, remove any user interface indicating that an update for this cache is in progress.

  31. Set the update status of cache group to idle.

  32. For each task in task list, queue that task as a post-load task.

The cache failure steps are as follows:

  1. Let task list be an empty list of tasks.

  2. For each entry in cache group's list of pending master entries, run the following further substeps. These steps may be run in parallel for two or more entries at a time.

    1. Wait for the resource for this entry to have either completely downloaded or failed.

    2. Unassociate the Document for this entry from its application cache, if it has one.

    3. Create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

  3. For each cache host still associated with an application cache in cache group, create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

  4. Empty cache group's list of pending master entries.

  5. If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.

  6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

  7. Let the status of cache group be idle.

  8. If this was a cache attempt, discard cache group altogether.

  9. For each task in task list, queue that task as a post-load task.

  10. Abort the application cache download process.

Attempts to fetch resources as part of the application cache download process may be done with cache-defeating semantics, to avoid problems with stale or inconsistent intermediary caches.


User agents may invoke the application cache download process, in the background, for any application cache group, at any time (with no cache host). This allows user agents to keep caches primed and to update caches even before the user visits a site.


Each Document has a list of pending application cache download process tasks that is used to delay events fired by the algorithm above until the document's load event has fired. When the Document is created, the list must be empty.

When the steps above say to queue a post-load task task, where task is a task that dispatches an event on a target ApplicationCache object target, the user agent must run the appropriate steps from the following list:

If target's Document is ready for post-load tasks

Queue the task task.

そうでなければ

Add task to target's Document's list of pending application cache download process tasks.

The task source for these tasks is the networking task source.

5.7.5 The application cache selection algorithm

When the application cache selection algorithm algorithm is invoked with a Document document and optionally a manifest URL manifest URL, the user agent must run the first applicable set of steps from the following list:

If there is a manifest URL, and document was loaded from an application cache, and the URL of the manifest of that cache's application cache group is not the same as manifest URL

Mark the entry for the resource from which document was taken in the application cache from which it was loaded as foreign.

Restart the current navigation from the top of the navigation algorithm, undoing any changes that were made as part of the initial load (changes can be avoided by ensuring that the step to update the session history with the new page is only ever completed after this application cache selection algorithm is run, though this is not required).

The navigation will not result in the same resource being loaded, because "foreign" entries are never picked during navigation.

User agents may notify the user of the inconsistency between the cache manifest and the document's own metadata, to aid in application development.

If document was loaded from an application cache, and that application cache still exists (it is not now obsolete)

Associate document with the application cache from which it was loaded. Invoke, in the background, the application cache download process for that application cache's application cache group, with document as the cache host.

If document was loaded using HTTP GET or equivalent, and, there is a manifest URL, and manifest URL has the same origin as document

Invoke, in the background, the application cache download process for manifest URL, with document as the cache host and with the resource from which document was parsed as the master resource.

If there are relevant application caches that are identified by a URL with the same origin as the URL of document, and that have this URL as one of their entries, excluding entries marked as foreign, then the user agent should use the most appropriate application cache of those that match as an HTTP cache for any subresource loads. User agents may also have other caches in place that are also honored.

そうでなければ

The Document is not associated with any application cache.

If there was a manifest URL, the user agent may report to the user that it was ignored, to aid in application development.

5.7.6 Changes to the networking model

When a cache host is associated with an application cache whose completeness flag is complete, any and all loads for resources related to that cache host other than those for child browsing contexts must go through the following steps instead of immediately invoking the mechanisms appropriate to that resource's scheme:

  1. If the resource is not to be fetched using the HTTP GET mechanism or equivalent, or if applying the URL parser algorithm to both its URL and the application cache's manifest's URL results in two parsed URLs with different scheme components, then fetch the resource normally and abort these steps.

  2. If the resource's URL is a master entry, the manifest, an explicit entry, or a fallback entry in the application cache, then get the resource from the cache (instead of fetching it), and abort these steps.

  3. If there is an entry in the application cache's online whitelist that has the same origin as the resource's URL and that is a prefix match for the resource's URL, then fetch the resource normally and abort these steps.

  4. If the resource's URL has the same origin as the manifest's URL, and there is a fallback namespace f in the application cache that is a prefix match for the resource's URL, then:

    Fetch the resource normally. If this results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors (but not if the user canceled the download), then instead get, from the cache, the resource of the fallback entry corresponding to the fallback namespace f. Abort these steps.

  5. If the application cache's online whitelist wildcard flag is open, then fetch the resource normally and abort these steps.

  6. Fail the resource load as if there had been a generic network error.

The above algorithm ensures that so long as the online whitelist wildcard flag is blocking, resources that are not present in the manifest will always fail to load (at least, after the application cache has been primed the first time), making the testing of offline applications simpler.

5.7.7 Expiring application caches

As a general rule, user agents should not expire application caches, except on request from the user, or after having been left unused for an extended period of time.

Application caches and cookies have similar implications with respect to privacy (e.g. if the site can identify the user when providing the cache, it can store data in the cache that can be used for cookie resurrection). Implementors are therefore encouraged to expose application caches in a manner related to HTTP cookies, allowing caches to be expunged together with cookies and other origin-specific data.

For example, a user agent could have a "delete site-specific data" feature that clears all cookies, application caches, local storage, databases, etc, from an origin all at once.

5.7.8 Disk space

User agents should consider applying constraints on disk usage of application caches, and care should be taken to ensure that the restrictions cannot be easily worked around using subdomains.

User agents should allow users to see how much space each domain is using, and may offer the user the ability to delete specific application caches.

For predictability, quotas should be based on the uncompressed size of data stored.

How quotas are presented to the user is not defined by this specification. User agents are encouraged to provide features such as allowing a user to indicate that certain sites are trusted to use more than the default quota, e.g. by asynchronously presenting a user interface while a cache is being updated, or by having an explicit whitelist in the user agent's configuration interface.

5.7.9 アプリケーションキャッシュAPI

interface ApplicationCache : EventTarget {

  // update status
  const unsigned short UNCACHED = 0;
  const unsigned short IDLE = 1;
  const unsigned short CHECKING = 2;
  const unsigned short DOWNLOADING = 3;
  const unsigned short UPDATEREADY = 4;
  const unsigned short OBSOLETE = 5;
  readonly attribute unsigned short status;

  // updates
  void update();
  void abort();
  void swapCache();

  // events
           attribute EventHandler onchecking;
           attribute EventHandler onerror;
           attribute EventHandler onnoupdate;
           attribute EventHandler ondownloading;
           attribute EventHandler onprogress;
           attribute EventHandler onupdateready;
           attribute EventHandler oncached;
           attribute EventHandler onobsolete;
};
cache = window . applicationCache

(ウィンドウで)そのWindowアクティブドキュメントに適用するApplicationCacheオブジェクトを返す。

cache = self . applicationCache

(共有ワーカーで)現在の共有ワーカーに適用するApplicationCacheオブジェクトを返す。

cache . status

以下に定義された定数で与えられるように、アプリケーションキャッシュの現在のステータスを返す。

cache . update()

アプリケーションキャッシュのダウンロードプロセスを起動する。

更新すべきアプリケーションキャッシュが存在しない場合にInvalidStateError例外を投げる。

ユーザーエージェントは通常、自動的にアプリケーションキャッシュを更新する処理をするので、通常このメソッドを呼び出す必要はない。

このメソッドは、長期のアプリケーションのような状況で役立つ。たとえば、ウェブメールアプリケーションは一度に何週間もブラウザタブで開いたままかもしれない。このようなアプリケーションは、毎日更新をテストできるだろう。

cache . abort()

アプリケーションキャッシュのダウンロード処理を中止する。

このメソッドは、(帯域幅が限られるためなどで)ユーザーが更新を停止したい場合に、独自のキャッシング進捗UIを表示するウェブアプリケーションで使用されることを意図する。

cache . swapCache()

新しいものが存在する場合、最新のアプリケーションキャッシュに切り替わる。存在しない場合、InvalidStateError例外を投げる。

これは、以前にロードされたリソースが再読み込みされることはない。たとえば、画像が急にリロードされないと、スタイルシートやスクリプトが再解析または再評価されない。唯一の変更点は、キャッシュされたリソースに対する後続の要求が新しいコピーを取得することである。

このメソッドが呼び出される前にupdatereadyイベントが発火する。一度発火すると、ウェブアプリケーションは、その余暇で、より最近のアップデートで一つに基礎となるキャッシュを切り替えるためにこのメソッドを呼び出す。これを適切に使うためには、アプリケーションは動作に新しい機能をもたらすことができるようにする必要がある。たとえば、新しい機能を有効にするためにスクリプトをリロードするなど。

swapCache()の代替は、location.reload()を使用して、ユーザーに適した時点で単にページ全体をリロードすることである。

There is a one-to-one mapping from cache hosts to ApplicationCache objects. The applicationCache attribute on Window objects must return the ApplicationCache object associated with the Window object's active document. The applicationCache attribute on SharedWorkerGlobalScope objects must return the ApplicationCache object associated with the worker.

A Window or SharedWorkerGlobalScope object has an associated ApplicationCache object even if that cache host has no actual application cache.


The status attribute, on getting, must return the current state of the application cache that the ApplicationCache object's cache host is associated with, if any. This must be the appropriate value from the following list:

UNCACHED(数値0)

ApplicationCacheオブジェクトのキャッシュホストは、この時点でアプリケーションキャッシュに関連付けられていない。

IDLE(数値1)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスidleであるアプリケーションキャッシュに関連付けられ、そのアプリケーションキャッシュは、そのアプリケーションキャッシュグループ最新のキャッシュであり、アプリケーションキャッシュグループは、obsoleteとマークされない。

CHECKING(数値2)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスcheckingであるアプリケーションキャッシュに関連付けられる。

DOWNLOADING(数値3)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスdownloadingであるアプリケーションキャッシュに関連付けられる。

UPDATEREADY(数値4)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスidleであるアプリケーションキャッシュに関連付けられ、そのアプリケーションキャッシュグループobsoleteとしてマークされないが、そのアプリケーションキャッシュは、そのグループ内の最新のキャッシュではない

OBSOLETE(数値5)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループobsoleteとマークされるアプリケーションキャッシュに関連付けられる。


If the update() method is invoked, the user agent must invoke the application cache download process, in the background, for the application cache group of the application cache with which the ApplicationCache object's cache host is associated, but without giving that cache host to the algorithm. If there is no such application cache, or if its application cache group is marked as obsolete, then the method must throw an InvalidStateError exception instead.

If the abort() method is invoked, the user agent must send a signal to the current application cache download process for the application cache group of the application cache with which the ApplicationCache object's cache host is associated, if any. If there is no such application cache, or it does not have a current application cache download process, then do nothing.

If the swapCache() method is invoked, the user agent must run the following steps:

  1. Check that ApplicationCache object's cache host is associated with an application cache. If it is not, then throw an InvalidStateError exception and abort these steps.

  2. Let cache be the application cache with which the ApplicationCache object's cache host is associated. (By definition, this is the same as the one that was found in the previous step.)

  3. If cache's application cache group is marked as obsolete, then unassociate the ApplicationCache object's cache host from cache and abort these steps. (Resources will now load from the network instead of the cache.)

  4. Check that there is an application cache in the same application cache group as cache whose completeness flag is complete and that is newer than cache. If there is not, then throw an InvalidStateError exception and abort these steps.

  5. Let new cache be the newest application cache in the same application cache group as cache whose completeness flag is complete.

  6. Unassociate the ApplicationCache object's cache host from cache and instead associate it with new cache.

The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by all objects implementing the ApplicationCache interface:

イベントハンドラ イベントハンドライベント型
onchecking checking
onerror error
onnoupdate noupdate
ondownloading downloading
onprogress progress
onupdateready updateready
oncached cached
onobsolete obsolete

5.7.10 ブラウザの状態

[NoInterfaceObject]
interface NavigatorOnLine {
  readonly attribute boolean onLine;
};
window . navigator . onLine

ユーザーエージェントが正確にオフラインである(ネットワークから切断されている)場合にfalseを返すユーザーエージェントがオンラインかもしれない場合にtrueを返す。

この属性値が変更される場合、イベントonlineおよびofflineが発火する。

The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page (or knows that such an attempt would fail), and must return true otherwise.

When the value that would be returned by the navigator.onLine attribute of a Window or WorkerGlobalScope changes from true to false, the user agent must queue a task to fire a simple event named offline at the Window or WorkerGlobalScope object.

On the other hand, when the value that would be returned by the navigator.onLine attribute of a Window or WorkerGlobalScope changes from false to true, the user agent must queue a task to fire a simple event named online at the Window or WorkerGlobalScope object.

The task source for these tasks is the networking task source.

この属性は、本質的に信頼できない。コンピュータは、インターネット接続がなくてもネットワークに接続できる。

この例において、ブラウザがオンラインおよびオフラインになるように、インジケータが更新される。

<!DOCTYPE HTML>
<html>
 <head>
  <title>Online status</title>
  <script>
   function updateIndicator() {
     document.getElementById('indicator').textContent = navigator.onLine ? 'online' : 'offline';
   }
  </script>
 </head>
 <body onload="updateIndicator()" ononline="updateIndicator()" onoffline="updateIndicator()">
  <p>The network is: <span id="indicator">(state unknown)</span>
 </body>
</html>