BFキャッシュされた文書のサポート法

2.1.1. 動作は、全部的に作動中か検査することで通過制御すること

文書の状態を更新し得る動作を遂行するときは、 当の文書は，［ `全部的に作動中$でないかもしれず、 利用者の視点からは “存在しないもの” と見なされる ］ことを自覚すること。 このことは、 そのような文書は，［ 更新を受信する／動作を遂行する ］べきでないことを意味する。 ◎ When performing actions that might update the state of a document, be aware that the document might not be fully active and is considered as "non-existent" from the user’s perspective. This means they should not receive updates or perform actions.

注記： 文書が`全部的に作動中$であっても， 利用者にとっては “存在しないもの” として知覚されることはアル — 当の文書が，`予め具現化された内容を表示している＠https://wicg.github.io/nav-speculation/prerendering.html$ときなど。 そのような文書の挙動は、 `全部的に作動中$でない文書とは異なり得る — ここに与える指針は、［ `全部的に作動中$でない（~BF~cacheされた）文書を取扱うために限り書された ］ものなので，適用-可能でないであろう。 ◎ Note: It is possible for a fully active document to be perceived as "non-existent" by users, such as when the document is displaying prerendered content. These documents might behave differently than non-fully active documents, and the guidelines here might not be applicable to them, as it is written only for handling non-fully active (BFCached) documents.

文書が`全部的に作動中$でない間に起こるものは、 多くの事例では，決して起こらなかったかのように扱われるべきである。 文書が［ 再び`全部的に作動中$になった後には、 非新鮮な情報を保持しない ］ことを確保するために，文書を “更新する” 方がイミを成す場合、［ `§ 全部的に作動中かどうかの変化を~listenすること＠#listen-fully-active$による~pattern ］を考慮すること。 ◎ In many cases, anything that happens while the document is not fully active should be treated as if it never happened. If it makes more sense to "update" a document to ensure it does not hold stale information after it becomes fully active again, consider the § 2.1.2 Listen for changes to fully active status pattern below.

注記： 当の動作が［ 当の文書が`全部的に作動中$である場合に限り満たされ得る，ある種の検査 ］ — 当の~top-level閲覧~文脈は`~system~focus$を有しているか否か検査するなど — によりすでに保護されている場合、 全部的に作動中かどうかの検査は必要ないかもしれない。 しかしながら、 ある種の検査 — 例：`一過な作動化を有して$いるか否か — は，［ 文書が全部的に作動中でない場合でも満たされ得る ］ことに気を付けること。 次も見よ ⇒ `§ 文書ごとの状態や~dataは~naviの後も持続し得ることを自覚すること＠#per-document-state$ ◎ Note: If the actions are already protected by certain checks that can only be satisfied if the document is fully active, such as checking if the top-level browsing context has system focus, fully active checks might not be needed. However, be careful of certain checks like transient user activation, which can be true even if a document is not fully active. See also the § 2.1.5 Be aware that per-document state/data might persist after navigation section.

2.1.2. 全部的に作動中かどうかの変化を~listenすること

`全部的に作動中$であった文書が そうでなくなったときは、 破棄された文書と類似な仕方で扱われるべきである。 文書は、 共用~資源への排他的な~accessを維持してはナラナイ — ［ 新たに発行される要請はないこと， 新たに入って来る要請を許容する接続は終了されること ］を確保しなければナラナイ。 `全部的に作動中$でなかった文書が，再びそうなったときは、 適切な場合には，接続を復旧できる。 ◎ When a document goes from fully active to non-fully active, it should be treated similarly to the way discarded documents are treated. The document must not retain exclusive access to shared resources and must ensure that no new requests are issued and that connections that allow for new incoming requests are terminated. When a document goes from non-fully active to fully active again, it can restore connections if appropriate.

`全部的に作動中$であった文書が そうでなくなる変化を~listenするためには、 `文書~unload時の片付け手続き$内に段を追加すること。 `全部的に作動中$でなかった文書が そうなる変化を~listenするためには、 `文書を作動化し直す$手続き内に段を追加すること。 ◎ To listen to changes from fully active to non-fully active, add a step in unloading document cleanup steps.＼ Meanwhile, to listen to changes from non-fully active to fully active, add a step to reactivate a document.

~web作者は，［ `pagehide＠~HTMLindex#event-pagehide$et ~eventの中から片付けを手動で行うことも （例：当の資源を解放する／接続を断つ）， `pageshow＠~HTMLindex#event-pageshow$et ~eventの中から，それを復旧することも ］できるが、 これを~API設計から自動的に行うようにすれば，［ 既定では、 当の文書は，~naviの後も生きたまま保たれる ］ことを許容する — その結果、 ~web~appがきちんと機能する方へ導く見込みも高まる。 ◎ While web authors can manually do cleanup (e.g. release the resources, sever connections) from within the pagehide event and restore them from the pageshow event themselves, doing this automatically from the API design allows the document to be kept alive after navigation by default, and is more likely to lead to well-functioning web applications.

注記： 資源の型によっては、 これは，適切にならないこともある — 例：排他的な~lockが保持されていた場合、［ 別の~pageが，解放された~lockを~~獲得することもある ］ので，単に［ 当の~lockを解放して，`全部的に作動中$になったとき獲得し直す ］ことはできない。 そうすることは、［ これが起きたことを当の~pageに通達する~APIがある場合は、 受容-可能になり得る ］が，［ これが~BF~cacheでしか起こらない場合、 多くの~pageは，それ用に準備されないと見込まれる ］ことに注意。 ~BF~cacheを~supportするのはアリでない場合、 下に述べる［ `§ 全部的に作動中でない文書は、~supportし得ない状況では破棄すること＠#discard$ ］による~patternに従うこと。 ◎ Note: this might not be appropriate for all types of resources, e.g. if an exclusive lock is held, we cannot just release it and reacquire when fully active since another page could then take that lock. If there is an API to signal to the page that this has happened, it may be acceptable but beware that if the only time this happens is with BFCache, then it’s likely many pages are not prepared for it. If it is not possible to support BFCache, follow the § 2.1.4 Discard non-fully active documents for situations that can’t be supported pattern described below.

加えて，ある文書が再び`全部的に作動中$になったとき、 `全部的に作動中$でない間に変化したものがある場合には， 外の世界の現在の状態で更新することが有用になり得る。 しかしながら，文書が~BF~cache内にある間に生じた~eventに対しては、 ~careする必要がある。 文書が`全部的に作動中$でないとき、［ すべての~eventを落とすべき事例／ 単独の~event内に最新な状態を送達するべき事例／ 各~eventを~queueするか結合された~eventを送達するのが適切になる事例 ］いずれもある。 正しい~approachは、 事例ごとに異なり，［ ~privacy, 正しさ, 処理能, 人間工学 ］を考慮するべきである。 ◎ Additionally, when a document becomes fully active again, it can be useful to update it with the current state of the world, if anything has changed while it is in the non-fully active state. However, care needs to be taken with events that occurred while in the BFCache. When not fully active, for some cases, all events should be dropped, in some the latest state should be delivered in a single event, in others it may be appropriate to queue events or deliver a combined event. The correct approach is case by case and should consider privacy, correctness, performance and ergonomics.

注記： ［ 再び`全部的に作動中$になった文書へ最新な状態が送信されるようにする ］ことは、 とりわけ，既存の~APIを補修するときに重要になる — これらの~APIの現在の利用者は、 常に最新な情報が伴われるものと期待するからである。 状態~更新を落とすと、 当の文書は非新鮮な情報を伴ったままになり得る — その結果、 既存の~siteを［ 期待されない, かつ検出するのが難しい非互換化 ］に至らせ得る。 ◎ Note: Making sure the latest state is sent to a document that becomes fully active again is especially important when retrofitting existing APIs. This is because current users of these APIs expect to always have the latest information. Dropping state updates can leave the document with stale information, which can lead to unexpected and hard-to-detect breakage of existing sites.

2.1.3. 複数~文書にわたる~APIからは、全部的に作動中でない文書は省略すること

`全部的に作動中$でない文書は，観測-不能になるべきなので、 ~APIは，それらを存在しないものとして扱うべきである。 それらは、 複数~文書にわたる~API （例： `clients.matchAll()＠~SW1#dom-clients-matchall$c, `window.opener＠~WINDOW#dom-window-opener$c ） を通して “外側の世界” から可視になるべきでない。 ◎ Non-fully active documents should not be observable, so APIs should treat them as if they no longer exist. They should not be visible to the "outside world" through document-spanning APIs (e.g. clients.matchAll(), window.opener).

注記： 複数~文書にわたる~API自体が比較的~稀なので、 これは，稀にしかないはずである。 ◎ Note: This should be rare since cross-document-spanning APIs are themselves relatively rare.

2.1.4. 全部的に作動中でない文書は、~supportし得ない状況では破棄すること

`全部的に作動中$でない文書を~supportするのは， ある種の事例ではアリでない場合： ◎ If supporting non-fully active documents is not possible for certain cases,＼

• 当の状況が利用者が他所へ~navigateした後に起こる場合には ⇒ `文書を破壊する$ことにより，~supportし得ないことを明示的に指定すること。 ◎ explicitly specify it by discarding the document| if the situation happens after the user navigated away,＼
• 当の状況が当の文書から他所へ~navigateする前か その間に起こる場合には ⇒ ~naviの後に自動的に破棄されるよう，文書の`回復可能~状態$docを ~F に設定すること。 ◎ or setting the document’s salvageable) bit to false if the situation happens before or during the navigation away from the document, to cause it to be automatically discarded after navigation.

注記： これは，稀であり、 おそらく，旧い~APIを補修するときに限り利用されるべきである — 新たな~APIは、 常に，~BF~cacheと伴にきちんと働くよう~~努めるべきなので。 ◎ Note: this should be rare and probably should only be used when retrofitting old APIs, as new APIs should always strive to work well with BFCache.

2.1.5. 文書ごとの状態や~dataは~naviの後も持続し得ることを自覚すること

文書は，~naviの後であっても再利用され得るので、［ 文書の存続期間に何かを束ねることは、 ~naviの後にも それを再利用することを意味する ］ことを自覚すること。 これが望ましくない場合、 次を考慮すること ⇒ `全部的に作動中$かどうかの状態に対する変化を~listenして， 必要に応じて片付けを行う （`§ 全部的に作動中かどうかの変化を~listenすること＠#listen-fully-active$ を見よ）。 ◎ As a document might be reused even after navigation, be aware that tying something to a document’s lifetime also means reusing it after navigations. If this is not desirable, consider listening to changes to the fully active state and doing cleanup as necessary (see the § 2.1.2 Listen for changes to fully active status pattern above).