HTML Standard — Speculative loading（日本語訳）

【この訳に特有な表記規約】

◎表記記号

7.6. 投機的な読込ng

投機的な読込ngは、 ~navi動作を遂行する実施である — ~naviを開始するに先立って，~prefetchするなど。これは、後続な~naviを速くする。 ◎ Speculative loading is the practice of performing navigation actions, such as prefetching, ahead of navigation starting. This makes subsequent navigations faster.

開発者は、 `投機~規則~集合$を利用することにより，投機的な読込nを起動できる。 ~UAも，ある種の`実装定義$な局面 — ~URL~barの中へ打込んでいるときなど — において投機的な読込nを遂行するかもしれない。 ◎ Developers can initiate speculative loads by using speculation rules. User agents might also perform speculative loads in certain implementation-defined scenarios, such as typing into the address bar.

7.6.1. 投機~規則

開発者は、 `投機~規則~集合$により［自身が有益になるものと予見する投機的な読込ng演算］について~browserに指図する。この集合は、次に挙げるいずれかを介した~JSON文書として送達される： ◎ Speculation rules are how developers instruct the browser about speculative loading operations that the developer believes will be beneficial. They are delivered as JSON documents, via either:

~inlineな `script$e 要素のうち， `type$a 属性が `speculationrules^l に設定されたもの。 ◎ inline script elements with their type attribute set to "speculationrules"; or
`Speculation-Rules$h ~HTTP応答~header内に指定された~URLから~fetchされる資源。 ◎ resources fetched from a URL specified in the `Speculation-Rules` HTTP response header.

次の~JSON文書は、 `投機~規則~集合$に構文解析される — それは、 ~UAが`~referrerにより起動された~naviな~prefetchを開始する$ために欲されるいくつかの条件を指定する： ◎ The following JSON document is parsed into a speculation rule set specifying a number of desired conditions for the user agent to start a referrer-initiated navigational prefetch:

{
  "prefetch": [
    {
      "urls": ["/chapters/5"]
    },
    {
      "eagerness": "moderate",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "selector_matches": ".no-prefetch" } }
        ]
      }
    }
  ]
}

`投機~規則~集合$を表現している~JSON文書は、 `投機~規則~集合の著作~要件@ — ~AND ↓ — を満たさなければナラナイ： ◎ A JSON document representing a speculation rule set must meet the following speculation rule set authoring requirements:

妥当な~JSONである `JSON$r ◎ It must be valid JSON. [JSON]
当の~JSONは ~AND↓ を満たす~JSON~objを表現している： ◎ The JSON must represent a JSON object,＼
- 次に挙げるもの以外の~keyを伴わない ⇒＃ `tag^l, `prefetch^l, `prerender^l ◎ with at most three keys "tag", "prefetch" and "prerender".
  
  注記：この標準においては、 `prerender^l は，`構文解析-時点＠#note-speculation-rules-parse-prerender-as-prefetch$に任意選択で `prefetch^l へ変換される。一部の実装は、 ~prerender用には異なる挙動を — `PRERENDERING-REVAMPED$r にて指定されとおりに — 実装するかもしれない。 ◎ In this standard, "prerender" is optionally converted to "prefetch" at parse time. Some implementations might implement different behavior for prerender, as specified in Prerendering Revamped. [PRERENDERING-REVAMPED]
- ~key `tag^l を伴うならば、対応する値は`投機~規則~tag$である ◎ The value corresponding to the "tag" key, if present, must be a speculation rule tag.
- ~key［ `prefetch^l, `prerender^l ］いずれに対しても，それを伴うならば、対応する値は`妥当な投機~規則$たちが成す配列である ◎ The values corresponding to the "prefetch" and "prerender" keys, if present, must be arrays of valid speculation rules.

`妥当な投機~規則@ は、 ~AND↓ を満たす~JSON~objでなければナラナイ： ◎ A valid speculation rule is a JSON object that meets the following requirements:

次に挙げるもの以外の~keyを伴わない ⇒＃ `source^l, `urls^l, `where^l, `relative_to^l, `eagerness^l, `referrer_policy^l, `tag^l, `requires^l, `expects_no_vary_search^l, `target_hint^l ◎ It must have at most the following keys: "source", "urls", "where", "relative_to", "eagerness", "referrer_policy", "tag", "requires", "expects_no_vary_search", or "target_hint".

注記：この標準においては、 `target_hint^l は`無視される＠#note-speculation-rules-parse-target-hint$。 ◎ In this standard, "target_hint" is ignored.
~key `source^l を伴うならば、対応する値は［ `list^l, `document^l ］いずれかである ◎ The value corresponding to the "source" key, if present, must be either "list" or "document".
~key `source^l に対応する値 ~EQ `list^l ならば、次が満たされる ⇒ ［ ~key `urls^l を伴う］~AND［ ~key `where^l を伴わない］ ◎ If the value corresponding to the "source" key is "list", then the "urls" key must be present, and the "where" key must be absent.
~key `source^l に対応する値 ~EQ `document^l ならば、 ~key `urls^l を伴わない ◎ If the value corresponding to the "source" key is "document", then the "urls" key must be absent.
~key［ `urls^l, `where^l ］のうち，どちらかを伴わない ◎ The "urls" and "where" keys must not both be present.
［ ~key `source^l に対応する値 ~EQ `document^l ］~OR［ ~key `where^l を伴う］ならば、 ~key `relative_to^l を伴わない ◎ If the value corresponding to the "source" key is "document" or the "where" key is present, then the "relative_to" key must be absent.
~key `urls^l を伴うならば、対応する値は`妥当な~URL文字列$たちが成す配列である ◎ The value corresponding to the "urls" key, if present, must be an array of valid URL strings.
~key `where^l を伴うならば、対応する値は`妥当な文書~規則~述部$である ◎ The value corresponding to the "where" key, if present, must be a valid document rule predicate.
~key `relative_to^l を伴うならば、対応する値は［ `ruleset^l, `document^l ］いずれかである ◎ The value corresponding to the "relative_to" key, if present, must be either "ruleset" or "document".
~key `eagerness^l を伴うならば、対応する値は`投機~規則~早急度$である ◎ The value corresponding to the "eagerness" key, if present, must be a speculation rule eagerness.
~key `referrer_policy^l を伴うならば、対応する値は`~referrer施策$である ◎ The value corresponding to the "referrer_policy" key, if present, must be a referrer policy.
~key `tag^l を伴うならば、対応する値は`投機~規則~tag$である ◎ The value corresponding to the "tag" key, if present, must be a speculation rule tag.
~key `requires^l を伴うならば、対応する値は`投機~規則~要件$たちが成す配列である ◎ The value corresponding to the "requires" key, if present, must be an array of speculation rule requirements.
~key `expects_no_vary_search^l を伴うならば、次の結果は`文字列$になる ⇒ `~URL~search多様度を構文解析する$( 当の~keyに対応する値 ) （すなわち、当の値を `No-Vary-Search$h ~header値として構文解析する） ◎ The value corresponding to the "expects_no_vary_search" key, if present, must be a string that is parseable as a `No-Vary-Search` header value.

`妥当な文書~規則~述部@ は、 ~AND↓ を満たす~JSON~objでなければナラナイ： ◎ A valid document rule predicate is a JSON object that meets the following requirements:

次に挙げる~keyのうち，どれか一つだけを伴う ⇒＃ `and^l, `or^l, `not^l, `href_matches^l , `selector_matches^l ◎ It must contain exactly one of the keys "and", "or", "not", "href_matches", or "selector_matches".
［前項に挙げたもの, `relative_to^l ］以外の~keyを伴わない ◎ It must not contain any keys apart from the above or "relative_to".
~key `relative_to^l に対応する値が在るならば、 ~key `href_matches^l に対応する値も在る ◎ If it contains the key "relative_to", then it must also contain the key "href_matches".
~key `relative_to^l を伴うならば、対応する値は［ `ruleset^l, `document^l ］いずれかである ◎ The value corresponding to the "relative_to" key, if present, must be either "ruleset" or "document".
~key［ `and^l, `or^l ］いずれに対しても，それを伴うならば、対応する値は`妥当な文書~規則~述部$たちが成す配列である ◎ The value corresponding to the "and" or "or" keys, if present, must be arrays of valid document rule predicates.
~key `not^l を伴うならば、対応する値は`妥当な文書~規則~述部$である。 ◎ The value corresponding to the "not" key, if present, must be a valid document rule predicate.
~key `href_matches^l を伴うならば、対応する値は次に挙げるいずれかである ⇒＃ `妥当な~URL~pattern入力$／ `妥当な~URL~pattern入力$たちが成す配列 ◎ The value corresponding to the "href_matches" key, if present, must be either a valid URL pattern input or an array of valid URL pattern inputs.
~key `selector_matches^l を伴うならば、対応する値は次に挙げるいずれかである ⇒＃ `selector-list$t に合致している`文字列$／ `selector-list$t に合致している`文字列$たちが成す配列 ◎ The value corresponding to the "selector_matches" key, if present, must be either a string matching <selector-list> or an array of strings that match <selector-list>.

`妥当な~URL~pattern入力@ は、次に挙げるいずれかである： ◎ A valid URL pattern input is either:

次を満たす`~scalar値~文字列$である ⇒ 成功裡に`~URL~pattern構築子~文字列として構文解析できる＠~URLPATTERN#parse-a-constructor-string$ ◎ a scalar value string that can be successfully parsed as a URL pattern constructor string, or;

【参照された~algoは、ほとんど（~protocol成分~以外）においては “失敗しない” 。本当は、 “等価な `URLPatternInit$I を `URLPattern^I の構築子に渡したとするとき，例外を投出しない” と解釈するべき？】
次を満たす~JSON~objである ⇒ ［各~keyは、 `URLPatternInit$I 辞書を成すいずれかの~memberの識別子に一致する］~AND［各~keyに対応する値は`~scalar値~文字列$である］ ◎ a JSON object whose keys are drawn from the members of the URLPatternInit dictionary and whose values are scalar value strings.

7.6.1.1. ~data~model

`投機~規則~集合@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A speculation rule set is a struct with the following items:

`~prefetch規則~群@srs ⇒ `投機~規則$たちが成す`~list$ — 初期~時は空とする。 ◎ prefetch rules, a list of speculation rules, initially empty

注記：将来においては、他の規則 — 例： ~prerender規則 — もアリになる。そのようなまだ受容されていない拡張については、 `PRERENDERING-REVAMPED$r を見よ。 ◎ In the future, other rules will be possible, e.g., prerender rules. See Prerendering Revamped for such not-yet-accepted extensions. [PRERENDERING-REVAMPED]

`投機~規則@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A speculation rule is a struct with the following items:

`~URL群@sr ⇒ `~URL$たちが成す`有順序~集合$ ◎ URLs, an ordered set of URLs
`述部@sr ⇒ ~NULL ／ある`文書~規則~述部$ ◎ predicate, a document rule predicate or null
`早急度@sr ⇒ ある`投機~規則~早急度$ ◎ eagerness, a speculation rule eagerness
`~referrer施策@sr ⇒ ある`~referrer施策$ ◎ referrer policy, a referrer policy
`~tag群@sr ⇒ `投機~規則~tag$たちが成す`有順序~集合$ ◎ tags, an ordered set of speculation rule tags
`要件~群@sr ⇒ `投機~規則~要件$たちが成す`有順序~集合$ ◎ requirements, an ordered set of speculation rule requirements
`~No-Vary-Search~hint@sr ⇒ ある`~URL~search多様度$ ◎ No-Vary-Search hint, a URL search variance

`文書~規則~述部@ は、次に挙げるいずれかである ⇒＃ `文書~規則~論理積$／ `文書~規則~論理和$／ `文書~規則~否定$／ `文書~規則~URL~pattern述部$／ `文書~規則~選択子~述部$ ◎ A document rule predicate is one of the following: • a document rule conjunction; • a document rule disjunction; • a document rule negation; • a document rule URL pattern predicate; or • a document rule selector predicate.

`文書~規則~論理積@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A document rule conjunction is a struct with the following items:

`条項~群@drC ⇒ `文書~規則~述部$たちが成す`~list$ ◎ clauses, a list of document rule predicates

`文書~規則~論理和@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A document rule disjunction is a struct with the following items:

`条項~群@drD ⇒ `文書~規則~述部$たちが成す`~list$ ◎ clauses, a list of document rule predicates

`文書~規則~否定@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A document rule negation is a struct with the following items:

`条項@drN ⇒ ある`文書~規則~述部$ ◎ clause, a document rule predicate

`文書~規則~URL~pattern述部@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A document rule URL pattern predicate is a struct with the following items:

`~pattern群@ ⇒ `~URL~pattern$たちが成す`~list$ ◎ patterns, a list of URL patterns

`文書~規則~選択子~述部@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A document rule selector predicate is a struct with the following items:

`選択子~群@ ⇒ `選択子$たちが成す`~list$ ◎ selectors, a list of selectors

`投機~規則~早急度@ は、次に挙げるいずれかの`文字列$である — 以下の記述における “当の候補” は、所与の［投機的な読込n候補【投機的な読込nの対象になる~link】］を意味する： ◎ A speculation rule eagerness is one of the following strings:

`immediate@l 【 “~~即時” 】: 開発者は、［当の候補に結付けられた投機的な読込nは，ほぼ遂行するに価するものと見込まれる］ものと予見している — 加えて，［読込nを完了するまで有意な `lead^en 時間が要求される］ものと予期しているかもしれない。 ~UAは、通例的に［当の候補を実用的になる限り早く動作化する］ベキである — 実用的か否かを裁定する際に考慮する~subjectは、［利用者-選好, 機器~条件, 資源~制限s ］などに限るとする。 ◎ The developer believes that performing the associated speculative loads is very likely to be worthwhile, and they might also expect that load to require significant lead time to complete. User agents should usually enact the speculative load candidate as soon as practical, subject only to considerations such as user preferences, device conditions, and resource limits.
`eager@l 【 “~~早急” 】: ~UAは、［利用者は，未来に当の候補の~URLへ~navigateし得る］ことが少しでも示唆されたなら，当の候補を動作化するベキである。一例として、利用者が，ある~linkに対し［そこへ向けて一瞬でも~cursorを移動した／そこで一瞬でも~cursorを~hoverした／それが表示域~内で他の~linkより~~目立つものであるとき，そこで~scrollすることを静止した］とき。作者は、アリな限り多くの~naviをアリな限り早期に捕捉するよう追求している。 ◎ User agents should enact the speculative load candidate on even a slight suggestion that the user may navigate to this URL in the future. For instance, the user might have moved the cursor toward a link or hovered it, even momentarily, or paused scrolling when the link is one of the more prominent ones in the viewport. The author is seeking to capture as many navigations as possible, as early as possible.
`moderate@l 【 “~~中庸” 】: ~UAは、利用者の挙動により［利用者は，近い未来に当の候補の~URLへ~navigateし得る］ことが示唆された場合には，当の候補を動作化するベキである。一例として、利用者は，ある~linkに対し［それを表示域の中へ~scrollして，それを~clickする見込みが高そうな兆しを — 例：そこに何秒か~cursorを移動することにより — 示した］とき。開発者は、 `eager$l と `conservative$l の間で~balanceを追求している。 ◎ User agents should enact the candidate if user behavior suggests the user may navigate to this URL in the near future. For instance, the user might have scrolled a link into the viewport and shown signs of being likely to click it, e.g., by moving the cursor over it for some time. The developer is seeking a balance between "eager" and "conservative".
`conservative@l 【 “~~保守的” 】: ~UAは、［利用者は，ほぼ当の候補の~URLへ~navigateするものと見込まれる］ときに限り，当の候補を動作化するベキである。一例として，利用者がある~linkとヤリトリし始めたとき。開発者は、投機的な読込ngの便益を成す一部を相応に少ない資源と引き換えに捕捉するよう追求している。 ◎ User agents should enact the candidate only when the user is very likely to navigate to this URL at any moment. For instance, the user might have begun to interact with a link. The developer is seeking to capture some of the benefits of speculative loading with a fairly small tradeoff of resources.

所与の`投機~規則~早急度$ %A, %B に対し， %A は %B `以上に早急@ であるとは、［上の~listにおいて %A は %B に後続して挙げられられたものではない］ことをいう。 ◎ A speculation rule eagerness A is less eager than another speculation rule eagerness B if A follows B in the above list. ◎ A speculation rule eagerness A is at least as eager as another speculation rule eagerness B if A is not less eager than B.

【原文には，この用語の否定を意味する用語も定義されているが、この訳では利用しない（単に， “以上に早急でない” と記すことにする）。】

`投機~規則~tag@ は、［ ~NULL／次を満たす`~ASCII文字列$ ］である ⇒ それを成す各`文字$は範囲 { `0020^U 〜 `007E^U } に入る【すなわち，`制御~文字$でない】 ◎ A speculation rule tag is either an ASCII string whose code points are all in the range U+0020 to U+007E inclusive, or null.

注記：符号位置~範囲に関するこの制約は、［値を~HTTP~header内に~escape法や改変を伴わずに送信できる］ことを確保する。 ◎ This code point range restriction ensures the value can be sent in an HTTP header with no escaping or modification.

`投機~規則~要件@ は、文字列 `anonymous-client-ip-when-cross-origin^l である。 ◎ A speculation rule requirement is the string "anonymous-client-ip-when-cross-origin".

注記：将来においては、アリな要件がもっと定義されるかもしれない。 ◎ In the future, more possible requirements might be defined.

7.6.1.2. 構文解析-法

注記：投機的な読込ngは漸進的な増補なので、この標準は，その構文解析の挙動において相応に保守的である。特に，未知な~keyや妥当でない値は、通例的に，構文解析を失敗させる — 何もしない方が［場合によっては，投機~規則を誤って解釈する］よりも安全なので。 ◎ Since speculative loading is a progressive enhancement, this standard is fairly conservative in its parsing behavior. In particular, unknown keys or invalid values usually cause parsing failure, since it is safer to do nothing than to possibly misinterpret a speculation rule.

それでも、ある投機~規則に対する構文解析に失敗しても，他の投機~規則の処理は許容される。投機~規則~集合の全体が破棄される事例は、 ~top-levelの環境設定に誤りがある場合に限られる。 ◎ That said, parsing failure for a single speculation rule still allows other speculation rules to be processed. It is only in the case of top-level misconfiguration that the entire speculation rule set is discarded.

`投機~規則~集合~文字列を構文解析する@ ~algoは、所与の ( `文字列$ %入力, `文書$ %文書, `~URL$ %基底~URL ) に対し： ◎ To parse a speculation rule set string given a string input, a Document document, and a URL baseURL:

%構文解析-済み ~LET `~JSON文字列を~Infra値に構文解析する$( %入力 ) ◎ Let parsed be the result of parsing a JSON string to an Infra value given input.
~IF［ %構文解析-済みは`有順序~map$でない］ ⇒ ~THROW `TypeError$E — 次を指示するような ⇒ “~top-levelの値は~JSON~objである必要がある” ◎ If parsed is not a map, then throw a TypeError indicating that the top-level value needs to be a JSON object.
%結果 ~LET 新たな`投機~規則~集合$ ◎ Let result be a new speculation rule set.
%~tag ~LET %構文解析-済み[ `tag^l ] ~DF ~NULL ◎ Let tag be null.
~IF［ %~tag ~NEQ ~NULL ］： ◎ If parsed["tag"] exists:
1. ~IF［ %~tag は`投機~規則~tag$でない］ ⇒ ~THROW `TypeError$E — 次を指示するような ⇒ 当の投機~規則~tagは妥当でない ◎ If parsed["tag"] is not a speculation rule tag, then throw a TypeError indicating that the speculation rule tag is invalid. ◎ ↑ Set tag to parsed["tag"].
%~prefetchとして扱う種別~群 ~LET « `prefetch^l » ◎ Let typesToTreatAsPrefetch be « "prefetch" ».
任意選択で【！may】 ⇒ %~prefetchとして扱う種別~群に `prerender^l を`付加する$ ◎ The user agent may append "prerender" to typesToTreatAsPrefetch.

注記：この仕様は，~prefetch法しか含まないので、この段は，［ ~prerenderするための要請を~prefetchするための要請として扱う］ことを~UAに許容する。 ~prerender法を実装する~UAは、 `PRERENDERING-REVAMPED$r 仕様に従って， `prerender^l を~prerender要請として解釈することになる。 ◎ Since this specification only includes prefetching, this allows user agents to treat requests for prerendering as requests for prefetching. User agents which implement prerendering, per the Prerendering Revamped specification, will instead interpret these as prerender requests. [PRERENDERING-REVAMPED]
%~prefetchとして扱う種別~群を成す ~EACH( %種別 ) に対し： ◎ For each type of typesToTreatAsPrefetch:
1. %規則~群 ~LET %構文解析-済み[ %種別 ] ◎ ↓
2. ~IF［ %規則~群 ~NEQ ε ］： ◎ If parsed[type] exists:
  1. ~IF［ %規則~群は`~list$である］ ⇒ %規則~群を成す ~EACH( %規則 ) に対し： ◎ If parsed[type] is a list, then for each rule of parsed[type]:
    1. %規則 ~LET `投機~規則を構文解析する$( %規則, %~tag, %文書, %基底~URL ) ◎ Let rule be the result of parsing a speculation rule given rule, tag, document, and baseURL.
    2. ~IF［ %規則 ~NEQ ~NULL ］ ⇒ %結果の`~prefetch規則~群$srsに %規則を`付加する$ ◎ If rule is null, then continue. ◎ Append rule to result's prefetch rules.
  2. ~ELSE ⇒ 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “%種別用の規則~listは~JSON配列にする必要がある” ) ◎ Otherwise, the user agent may report a warning to the console indicating that the rules list for type needs to be a JSON array.
~RET %結果 ◎ Return result.

`投機~規則を構文解析する@ ~algoは、所与の ( `有順序~map$ %入力, `投機~規則~tag$ %規則~集合~levelの~tag, `文書$ %文書, `~URL$ %基底~URL ) に対し： ◎ To parse a speculation rule given a map input, a speculation rule tag rulesetLevelTag, a Document document, and a URL baseURL:

~IF［ %入力は`有順序~map$でない］： ◎ If input is not a map:
1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “当の規則は~JSON~objにする必要がある” ) ◎ The user agent may report a warning to the console indicating that the rule needs to be a JSON object.
2. ~RET ~NULL ◎ Return null.
%入力の`~key群$mapを成す ~EACH( %~key ) に対し： ◎ If input has any key＼
1. ~IF［ %~key ~IN { `source^l, `urls^l, `where^l, `relative_to^l, `eagerness^l, `referrer_policy^l, `tag^l, `requires^l, `expects_no_vary_search^l, `target_hint^l } ］ ⇒ ~CONTINUE ◎ other than "source", "urls", "where", "relative_to", "eagerness", "referrer_policy", "tag", "requires", "expects_no_vary_search", or "target_hint":
2. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “当の規則は認識されない~keyを有する” ) ◎ The user agent may report a warning to the console indicating that the rule has unrecognized keys.
3. ~RET ~NULL ◎ Return null.
注記： `target_hint^l は、この標準においては処理~modelに対する影響iは何も無いが， `PRERENDERING-REVAMPED$r の実装においては~prerender用の規則~用に利用され得る。なので、そのような規則の構文解析に失敗するよう~UAに要求することは，反生産的になる。 ◎ "target_hint" has no impact on the processing model in this standard. However, implementations of Prerendering Revamped can use it for prerendering rules, and so requiring user agents to fail parsing such rules would be counterproductive. [PRERENDERING-REVAMPED].
%~source ~LET %入力[ `source^l ] ◎ Let source be null. ◎ If input["source"] exists, then set source to input["source"].
~IF［ %~source ~EQ ε ］：
1. ~IF［ %入力[ `urls^l ] ~NEQ ε ］~AND［ %入力[ `where^l ] ~EQ ε ］ ⇒ %~source ~SET `list^l
2. ~ELIF［ %入力[ `urls^l ] ~EQ ε ］~AND［ %入力[ `where^l ] ~NEQ ε ］ ⇒ %~source ~SET `document^l
◎ Otherwise, if input["urls"] exists and input["where"] does not exist, then set source to "list". ◎ Otherwise, if input["where"] exists and input["urls"] does not exist, then set source to "document".
~IF［ %~source ~NIN { `list^l, `document^l } ］： ◎ If source is neither "list" nor "document":
1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “~sourceを推定できないか妥当でない~sourceが指定された” ) ◎ The user agent may report a warning to the console indicating that a source could not be inferred or an invalid source was specified.
2. ~RET ~NULL ◎ Return null.
%~URL群 ~LET 新たな`~list$ ◎ Let urls be an empty list.
%述部 ~LET ~NULL ◎ Let predicate be null.
~IF［ %~source ~EQ `list^l ］： ◎ If source is "list":
1. ~IF［ %入力[ `where^l ] ~NEQ ε ］： ◎ If input["where"] exists:
  1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “この規則~用には競合している~sourceたちが在る” ) ◎ The user agent may report a warning to the console indicating that there were conflicting sources for this rule.
  2. ~RET ~NULL ◎ Return null.
2. ~IF［ %入力[ `relative_to^l ] ~NEQ ε ］： ◎ If input["relative_to"] exists:
  1. ~IF［ %入力[ `relative_to^l ] ~NIN { `ruleset^l, `document^l } ］： ◎ If input["relative_to"] is neither "ruleset" nor "document":
    1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “`relative-to^c に給された値は妥当でない” ) ◎ The user agent may report a warning to the console indicating that the supplied relative-to value was invalid.
    2. ~RET ~NULL ◎ Return null.
  2. ~IF［ %入力[ `relative_to^l ] ~EQ `document^l ］ ⇒ %基底~URL ~SET %文書の`文書~基底~URL$ ◎ If input["relative_to"] is "document", then set baseURL to document's document base URL.
3. ~IF［ %入力[ `urls^l ] は`~list$でない］： ◎ If input["urls"] does not exist or is not a list:
  1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “給された~URL~listは妥当でない” ) ◎ The user agent may report a warning to the console indicating that the supplied URL list was invalid.
  2. ~RET ~NULL ◎ Return null.
4. %入力[ `urls^l ] を成す ~EACH( %~URL文字列 ) に対し： ◎ For each urlString of input["urls"]:
  1. ~IF［ %~URL文字列は文字列でない］： ◎ If urlString is not a string:
    1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “給された~URLは文字列でなければならない” ) ◎ The user agent may report a warning to the console indicating that the supplied URL must be a string.
    2. ~RET ~NULL ◎ Return null.
  2. %構文解析-済み~URL ~LET `~URL構文解析する$( %~URL文字列, %基底~URL ) ◎ Let parsedURL be the result of URL parsing urlString with baseURL.
  3. ~IF［ %構文解析-済み~URL ~EQ `失敗^i ］~OR［ %構文解析-済み~URL の`~scheme$urlは`~HTTP_S~scheme$でない］： ◎ If parsedURL is failure, or parsedURL's scheme is not an HTTP(S) scheme:
    1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “給された~URL文字列は構文解析-不能である” ) ◎ The user agent may report a warning to the console indicating that the supplied URL string was unparseable.
    2. ~CONTINUE ◎ Continue.
  4. %~URL群に %構文解析-済み~URL を`付加する$ ◎ Append parsedURL to urls.
~IF［ %~source ~EQ `document^l ］： ◎ If source is "document":
1. ~IF［ %入力[ `urls^l ] ~NEQ ε ~OR %入力[ `relative_to^l ] ~NEQ ε ］： ◎ If input["urls"] or input["relative_to"] exists:
  1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “この規則~用には競合している~sourceたちが在る” ) ◎ The user agent may report a warning to the console indicating that there were conflicting sources for this rule.
  2. ~RET ~NULL ◎ Return null.
2. ~IF［ %入力[ `where^l ] ~EQ ε ］ ⇒ %述部 ~SET 新たな`文書~規則~論理積$ — その ⇒＃ `条項~群$drC ~SET 新たな`~list$ ◎ If input["where"] does not exist, then set predicate to a document rule conjunction whose clauses is an empty list.
  
  注記：そのような述部は、すべての~linkに合致することになる。 ◎ Such a predicate will match all links.
3. ~ELSE ⇒ %述部 ~SET `文書~規則~述部を構文解析する$( %入力[ `where^l ], %文書, %基底~URL ) ◎ Otherwise, set predicate to the result of parsing a document rule predicate given input["where"], document, and baseURL.
4. ~IF［ %述部 ~EQ ~NULL ］ ⇒ ~RET ~NULL ◎ If predicate is null, then return null.
%早急度 ~LET %~source に応じて ⇒＃ `list^l ならば `immediate$l ／ `document^l ならば【！~ELSE_ 】 `conservative$l ◎ Let eagerness be "immediate" if source is "list"; otherwise, "conservative".
%早急度 ~SET %入力[ `eagerness^l ] ~DF %早急度 ◎ ↓
~IF［ %早急度は`投機~規則~早急度$でない］：
1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “早急度は妥当でない” )
2. ~RET ~NULL
◎ If input["eagerness"] exists: • If input["eagerness"] is not a speculation rule eagerness: •• The user agent may report a warning to the console indicating that the eagerness was invalid. •• Return null. • Set eagerness to input["eagerness"].
%~referrer施策 ~LET %入力[ `referrer_policy^l ] ~DF 空~文字列 ◎ Let referrerPolicy be the empty string. ◎ ↓
~IF［ %~referrer施策は`~referrer施策$でない］：
1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “~referrer施策は妥当でない” )
2. ~RET ~NULL
◎ If input["referrer_policy"] exists: • If input["referrer_policy"] is not a referrer policy: •• The user agent may report a warning to the console indicating that the referrer policy was invalid. •• Return null. • Set referrerPolicy to input["referrer_policy"].
%~tag群 ~LET 新たな`有順序~集合$ ◎ Let tags be an empty ordered set.
~IF［ %規則~集合~levelの~tag ~NEQ ~NULL ］ ⇒ %~tag群に %規則~集合~levelの~tag を`付加する$set ◎ If rulesetLevelTag is not null, then append rulesetLevelTag to tags.
%~tag ~LET %入力[ `tag^l ] ~DF ~NULL ◎ ↓
~IF［ %~tag は`投機~規則~tag$でない］：
1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “~tagは妥当でない” )
2. ~RET ~NULL
◎ If input["tag"] exists: • If input["tag"] is not a speculation rule tag: •• The user agent may report a warning to the console indicating that the tag was invalid. •• Return null. • Append input["tag"] to tags. ◎ If tags is empty, then append null to tags.
%~tag群に %~tag を`付加する$set ◎ ↑
~Assert： %~tag群の`~size$ ~IN { 1, 2 } ◎ Assert: tags's size is either 1 or 2.
%要件~群 ~LET 新たな`有順序~集合$ ◎ Let requirements be an empty ordered set.
~IF［ %入力[ `requires^l ] ~NEQ ε ］： ◎ If input["requires"] exists:
1. ~IF［ %入力[ `requires^l ] は`~list$でない］： ◎ If input["requires"] is not a list:
  1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “要件は解されなかった” ) ◎ The user agent may report a warning to the console indicating that the requirements were not understood.
  2. ~RET ~NULL ◎ Return null.
2. %入力[ `requires^l ] を成す ~EACH( %要件 ) に対し： ◎ For each requirement of input["requires"]:
  1. ~IF［ %要件は`投機~規則~要件$でない］： ◎ If requirement is not a speculation rule requirement:
    1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “要件は解されなかった” ) ◎ The user agent may report a warning to the console indicating that the requirement was not understood.
    2. ~RET ~NULL ◎ Return null.
  2. %要件~群に %要件を`付加する$set ◎ Append requirement to requirements.
%~No-Vary-Search~hint ~LET `既定の~URL~search多様度$ ◎ Let noVarySearchHint be the default URL search variance.
~IF［ %入力[ `expects_no_vary_search^l ] ~NEQ ε ］： ◎ If input["expects_no_vary_search"] exists:
1. ~IF［ %入力[ `expects_no_vary_search^l ] は`文字列$でない］： ◎ If input["expects_no_vary_search"] is not a string:
  1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “`No-Vary-Search$h ~hintは妥当でない” ) ◎ The user agent may report a warning to the console indicating that the `No-Vary-Search` hint was invalid.
  2. ~RET ~NULL ◎ Return null.
2. %~No-Vary-Search~hint ~SET `~URL~search多様度を構文解析する$( %入力[ `expects_no_vary_search^l ] ) ◎ Set noVarySearchHint to the result of parsing a URL search variance given input["expects_no_vary_search"].
~RET 新たな`投機~規則$ — その ⇒＃ `~URL群$sr ~SET %~URL群, `述部$sr ~SET %述部, `早急度$sr ~SET %早急度, `~referrer施策$sr ~SET %~referrer施策, `~tag群$sr ~SET %~tag群, `要件~群$sr ~SET %要件~群, `~No-Vary-Search~hint$sr ~SET %~No-Vary-Search~hint ◎ Return a speculation rule with: • URLs •• urls • predicate •• predicate • eagerness •• eagerness • referrer policy •• referrerPolicy • tags •• tags • requirements •• requirements • No-Vary-Search hint •• noVarySearchHint

`文書~規則~述部を構文解析する@ ~algoは、所与の ( 値 %入力, `文書$ %文書, `~URL$ %基底~URL ) に対し： ◎ To parse a document rule predicate given a value input, a Document document, and a URL baseURL:

~IF［ %入力は`有順序~map$でない］： ◎ If input is not a map:
1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “文書~規則~述部は妥当でない” ) ◎ The user agent may report a warning to the console indicating that the document rule predicate was invalid.
2. ~RET ~NULL ◎ Return null.
%述部~種別 ~LET ε ◎ ↓
« `and^l, `or^l, `not^l, `href_matches^l, `selector_matches^l » を成す ~EACH( %~key ) に対し：
1. ~IF［ %入力[ %~key ] ~EQ ε ］ ⇒ ~CONTINUE
2. ~IF［ %述部~種別 ~NEQ ε ］ ⇒＃ %述部~種別 ~SET ε； ~BREAK
3. %述部~種別 ~SET %入力[ %~key ]
◎ ↓
~IF［ %述部~種別 ~EQ ε ］：
1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “文書~規則~述部は空であるか多義的である” )
2. ~RET ~NULL
◎ If input does not contain exactly one of "and", "or", "not", "href_matches", or "selector_matches": • The user agent may report a warning to the console indicating that the document rule predicate was empty or ambiguous. • Return null. ◎ ↑ Let predicateType be the single key found in the previous step.
%入力の`~key群$mapを成す ~EACH( %~key ) に対し：
1. ~IF［ %~key ~EQ %述部~種別］ ⇒ ~CONTINUE
2. ~IF［ %~key ~EQ `relative_to^l ］~AND［ %述部~種別 ~EQ `href_matches^l ］ ⇒ ~CONTINUE
3. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “文書~規則~述部には期待されない余計な~optionが有る” )
4. ~RET ~NULL
【この訳では、以下の各所における検査をこの段の中へ集約することにする。】
~IF［ %述部~種別 ~IN { `and^l, `or^l } ］： ◎ If predicateType is "and" or "or": ◎ • ↑↑ If input has any key other than predicateType: •• The user agent may report a warning to the console indicating that the document rule predicate had unexpected extra options. •• Return null.
1. ~IF［ %入力[ %述部~種別 ] は`~list$でない］： ◎ If input[predicateType] is not a list:
  1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “文書~規則~述部には妥当でない条項~listが有る” ) ◎ The user agent may report a warning to the console indicating that the document rule predicate had an invalid clause list.
  2. ~RET ~NULL ◎ Return null.
2. %条項~群 ~LET 新たな`~list$ ◎ Let clauses be an empty list.
3. %入力[ %述部~種別 ] を成す ~EACH( %生の条項 ) に対し： ◎ For each rawClause of input[predicateType]:
  1. %条項 ~LET `文書~規則~述部を構文解析する$( %生の条項, %文書, %基底~URL ) ◎ Let clause be the result of parsing a document rule predicate given rawClause, document, and baseURL.
  2. ~IF［ %条項 ~EQ ~NULL ］ ⇒ ~RET ~NULL ◎ If clause is null, then return null.
  3. %条項~群に %条項を`付加する$ ◎ Append clause to clauses.
4. %述部~種別に応じて：
  - `and^l ⇒ ~RET 新たな`文書~規則~論理積$ — その ⇒＃ `条項~群$drC ~SET %条項~群
  - `or^l ⇒ ~RET 新たな`文書~規則~論理和$ — その ⇒＃ `条項~群$drD ~SET %条項~群
  ◎ If predicateType is "and", then return a document rule conjunction whose clauses is clauses. ◎ Return a document rule disjunction whose clauses is clauses.
~IF［ %述部~種別 ~EQ `not^l ］： ◎ If predicateType is "not": • ↑↑ If input has any key other than "not": •• The user agent may report a warning to the console indicating that the document rule predicate had unexpected extra options. •• Return null.
1. %条項 ~LET `文書~規則~述部を構文解析する$( %入力[ %述部~種別 ], %文書, %基底~URL ) ◎ Let clause be the result of parsing a document rule predicate given input[predicateType], document, and baseURL.
2. ~IF［ %条項 ~EQ ~NULL ］ ⇒ ~RET ~NULL ◎ If clause is null, then return null.
3. ~RET 新たな`文書~規則~否定$ — その ⇒＃ `条項$drN ~SET %条項 ◎ Return a document rule negation whose clause is clause.
~IF［ %述部~種別 ~EQ `href_matches^l ］： ◎ If predicateType is "href_matches": • ↑↑ If input has any key other than "href_matches" or "relative_to": •• The user agent may report a warning to the console indicating that the document rule predicate had unexpected extra options. •• Return null.
1. ~IF［ %入力[ `relative_to^l ] ~NEQ ε ］： ◎ If input["relative_to"] exists:
  1. ~IF［ %入力[ `relative_to^l ] ~NIN { `ruleset^l, `document^l } ］： ◎ If input["relative_to"] is neither "ruleset" nor "document":
    1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “給された `relative-to^c 値は妥当でない” ) ◎ The user agent may report a warning to the console indicating that the supplied relative-to value was invalid.
    2. ~RET ~NULL ◎ Return null.
  2. ~IF［ %入力[ `relative_to^l ] ~EQ `document^l ］ ⇒ %基底~URL ~SET %文書の`文書~基底~URL$ ◎ If input["relative_to"] is "document", then set baseURL to document's document base URL.
2. %生の~pattern群 ~LET %入力[ `href_matches^l ] ◎ Let rawPatterns be input["href_matches"].
3. ~IF［ %生の~pattern群は`~list$でない］ ⇒ %生の~pattern群 ~SET « %生の~pattern群 » ◎ If rawPatterns is not a list, then set rawPatterns to « rawPatterns ».
4. %~pattern群 ~LET 新たな`~list$ ◎ Let patterns be an empty list.
5. %生の~pattern群を成す ~EACH( %生の~pattern ) に対し： ◎ For each rawPattern of rawPatterns:
  1. %~pattern ~LET `~Infra値から~URL~patternを築く$( %生の~pattern, %基底~URL )
    
    例外が投出された場合，~catchして ⇒ %~pattern ~SET ~NULL
    ◎ Let pattern be the result of building a URL pattern from an Infra value given rawPattern and baseURL. If this step throws an exception, catch the exception and set pattern to null.
  2. ~IF［ %~pattern ~EQ ~NULL ］： ◎ If pattern is null:
    1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “給された~URL~patternは妥当でない” ) ◎ The user agent may report a warning to the console indicating that the supplied URL pattern was invalid.
    2. ~RET ~NULL ◎ Return null.
  3. %~pattern群に %~pattern を`付加する$ ◎ Append pattern to patterns.
6. ~RET 新たな`文書~規則~URL~pattern述部$ — その ⇒＃ `~pattern群$ ~SET %~pattern群 ◎ Return a document rule URL pattern predicate whose patterns is patterns.
~IF［ %述部~種別 ~EQ `selector_matches^l ］： ◎ If predicateType is "selector_matches": • ↑↑ If input has any key other than "selector_matches": •• The user agent may report a warning to the console indicating that the document rule predicate had unexpected extra options. •• Return null.
1. %生の選択子~群 ~LET %入力[ `selector_matches^l ] ◎ Let rawSelectors be input["selector_matches"].
2. ~IF［ %生の選択子~群は`~list$でない］ ⇒ %生の選択子~群 ~SET « %生の選択子~群 » ◎ If rawSelectors is not a list, then set rawSelectors to « rawSelectors ».
3. %選択子~群 ~LET 新たな`~list$ ◎ Let selectors be an empty list.
4. %生の選択子~群を成す ~EACH( %生の選択子 ) に対し： ◎ For each rawSelector of rawSelectors:
  1. %構文解析-済み選択子~list ~LET `失敗^i ◎ Let parsedSelectorList be failure.
  2. ~IF［ %生の選択子は文字列である］ ⇒ %構文解析-済み選択子~list ~SET `選択子として構文解析する$( %生の選択子 ) ◎ If rawSelector is a string, then set parsedSelectorList to the result of parsing a selector given rawSelector.
  3. ~IF［ %構文解析-済み選択子~list ~EQ `失敗^i ］： ◎ If parsedSelectorList is failure:
    1. 任意選択で【！may】 ⇒ `~consoleに警告を報告する$( “給された選択子~listは妥当でない” ) ◎ The user agent may report a warning to the console indicating that the supplied selector list was invalid.
    2. ~RET ~NULL ◎ Return null.
  4. %構文解析-済み選択子~list を成す ~EACH( %選択子 ) に対し ⇒ %選択子~群に %選択子を`付加する$ ◎ For each selector of parsedSelectorList, append selector to selectors.
5. ~RET 新たな`文書~規則~選択子~述部$ — その ⇒＃ `選択子~群$ ~SET %選択子~群 ◎ Return a document rule selector predicate whose selectors is selectors.
~Assert：この段に達することは決してない。 ◎ Assert: this step is never reached, as one of the previous branches was taken.

7.6.1.3. 処理~model

`投機的な読込nの候補@ は、次に挙げる`~item$sctを伴う`構造体$である： ◎ A speculative load candidate is a struct with the following items:

`~URL@slC ⇒ ある`~URL$ ◎ URL, a URL
`~No-Vary-Search~hint@slC ⇒ ある`~URL~search多様度$ ◎ No-Vary-Search hint, a URL search variance
`早急度@slC ⇒ ある`投機~規則~早急度$ ◎ eagerness, a speculation rule eagerness
`~referrer施策@slC ⇒ ある`~referrer施策$ ◎ referrer policy, a referrer policy
`~tag群@slC ⇒ `投機~規則~tag$たちが成す`有順序~集合$ ◎ tags, an ordered set of speculation rule tags

`~prefetch候補@ は、次に挙げる追加的な`~item$sctを伴う`投機的な読込nの候補$である： ◎ A prefetch candidate is a speculative load candidate with the following additional item:

`匿名~化~施策@ ⇒ ある`~prefetch~IP匿名~化~施策$ ◎ anonymization policy, a prefetch IP anonymization policy

`~prefetch~IP匿名~化~施策@ は［ ~NULL／`非同一-生成元~prefetch~IP匿名~化~施策$ ］である。 ◎ A prefetch IP anonymization policy is either null or a cross-origin prefetch IP anonymization policy.

`非同一-生成元~prefetch~IP匿名~化~施策@ は、次に挙げる`~item$sctを伴う`構造体$である：

`生成元@copiap ⇒ ある`生成元$

◎ A cross-origin prefetch IP anonymization policy is a struct whose single item is its origin, an origin.

所与の ( `投機的な読込nの候補$ %候補~A, `投機的な読込nの候補$ %候補~B ) が `互いに冗長@ であるとは、 ~AND↓ が満たされることをいう：

( %候補~A の`~No-Vary-Search~hint$slC, %候補~B の`~No-Vary-Search~hint$slC ) は等しい【この同等性が，どう定義されるかはっきりしない。】
( %候補~A の`~URL$slC, %候補~B の`~URL$slC ) は `~URL~search多様度$ %候補~A の`~No-Vary-Search~hint$slC の`下で等価$である

◎ A speculative load candidate candidateA is redundant with another speculative load candidate candidateB if the following steps return true: • If candidateA's No-Vary-Search hint is not equal to candidateB's No-Vary-Search hint, then return false. • If candidateA's URL is not equivalent modulo search variance to candidateB's URL given candidateA's No-Vary-Search hint, then return false. • Return true.

注記： `~No-Vary-Search~hint$slCも等価であるよう要求することは、いくぶん厳密である。それは、一部の［理論的には合致しているものと扱える事例］を，そのように扱わないことを意味する。したがって，冗長な投機的な読込nが起こることもある。 ◎ The requirement that the No-Vary-Search hints be equivalent is somewhat strict. It means that some cases which could theoretically be treated as matching, are not treated as such. Thus, redundant speculative loads could happen.

しかしながら、より~~寛容な照合を許容すると，この検査はもはや同値~関係にならなくなり、そのような合致-を生産することは、【`~cache~key＠~HTTPcache#cache-key$として】より単純な正規化された~URL~keyを利用する代わりに，全部的な比較を行う実装~策を要求することになる。このことは、 `NOVARYSEARCH$r `§ 6＠~HTTPnvs#section-6$ 【§ 7？】内の［ ~server運用者~向けの最善な実施］および［ ~~付随する~HTTP~cache実装~注記］に倣う。 ◎ However, allowing more lenient matching makes the check no longer an equivalence relation, and producing such matches would require an implementation strategy that does a full comparison, instead of a simpler one using normalized URL keys. This is in line with the best practices for server operators, and attendant HTTP cache implementation notes, in No Vary Search § 6 Comparing.

実施においては、これが冗長な投機的な読込nの原因になるものとは予期されない — ［ ~server運用者, 対応している投機~規則を書いている~web開発者］は、最善な実施に従って，静的な［ `No-Vary-Search$h ~header値／投機~規則~hint ］を利用することになるので。 ◎ In practice, we do not expect this to cause redundant speculative loads, since server operators and the corresponding speculation rules-writing web developers will follow best practices and use static `No-Vary-Search` header values/speculation rule hints.

次に挙げる`投機的な読込nの候補$ — %A, %B, %C — を考える： ◎ Consider three speculative load candidates:

%A は次を有する ⇒＃ `~URL$slC として `https://example.com?a=1&b=1^c, `~No-Vary-Search~hint$slCとして `params=("a")^c を構文解析した結果 ◎ A has a URL of https://example.com?a=1&b=1 and a No-Vary-Search hint parsed from params=("a").
%B は次を有する ⇒＃ `~URL$slC として `https://example.com?a=2&b=1^c, `~No-Vary-Search~hint$slCとして `params=("b")^c を構文解析した結果 ◎ B has a URL of https://example.com?a=2&b=1 and a No-Vary-Search hint parsed from params=("b").
%C は次を有する ⇒＃ `~URL$slC として `https://example.com?a=2&b=2^c, `~No-Vary-Search~hint$slCとして `params=("a")^c を構文解析した結果 ◎ C has a URL of https://example.com?a=2&b=2 and a No-Vary-Search hint parsed from params=("a").

`互いに冗長$を成す現在の定義では、これらの候補は，どれも互いに冗長でない — これら各`投機~規則~集合$は、別々な投機的な読込nを生じさせ得る。 ◎ With the current definition of redundant with, none of these candidates are redundant with each other. A speculation rule set which contained all three could cause three separate speculative loads.

等価な`~No-Vary-Search~hint$slCを要求しない定義では、 ( %A, %B ) は合致する（ %A の`~No-Vary-Search~hint$slCを利用する下で）, ( %B, %C ) は合致する（ %B の`~No-Vary-Search~hint$slCを利用する下で）と見なすが， ( %A, %C ) は合致しないものと見なすので、推移的でない — したがって，同値~関係にならない。 ◎ A definition which did not require equivalent No-Vary-Search hints could consider A and B to match (using A's No-Vary-Search hint), and B and C to match (using B's No-Vary-Search hint). But it could not consider A and C to match, so it would not be transitive, and thus not an equivalence relation.

各`文書$は、次に挙げるものを有する： ◎ ↓

`投機~規則~集合~群@doc ⇒ `投機~規則~集合$たちが成す`~list$ — 初期~時は空とする。 ◎ Every Document has speculation rule sets, a list of speculation rule sets, initially empty.
`~queueされた投機的な読込n小taskを考慮するか@ ⇒ ある真偽値 — 初期~時は ~F とする。 ◎ Every Document has a consider speculative loads microtask queued, a boolean, initially false.

`投機的な読込nを考慮する@ ~algoは、所与の ( `文書$ %文書 ) に対し： ◎ To consider speculative loads for a Document document:

~IF［ %文書の`~node~navigable$は`~top-level辿可能$でない］ ⇒ ~RET ◎ If document's node navigable is not a top-level traversable, then return.

注記：投機的な読込nを`子~navigable$の中でも~supportすることには、何らかの複階性が有り，現時点では定義されない — 将来には定義することがアリになるかもしれない。 ◎ Supporting speculative loads into child navigables has some complexities and is not currently defined. It might be possible to define it in the future.
~IF［ %文書の`~queueされた投機的な読込n小taskを考慮するか$ ~EQ ~T ］ ⇒ ~RET ◎ If document's consider speculative loads microtask queued is true, then return.
%文書の`~queueされた投機的な読込n小taskを考慮するか$ ~SET ~T ◎ Set document's consider speculative loads microtask queued to true.
`小taskを~queueする$( %文書, 次の手続き ) ◎ Queue a microtask given document to run＼
手続きは： ◎ the following steps:
1. %文書の`~queueされた投機的な読込n小taskを考慮するか$ ~SET ~F ◎ Set document's consider speculative loads microtask queued to false.
2. `投機的な読込nを考慮する内縁~手続き$( %文書 ) ◎ Run the inner consider speculative loads steps for document.

この標準においては、明示的に与えられた~call元に加えて，~UAは： ◎ In addition to the call sites explicitly given in this standard:

~styleの再~計算に伴い選択子の照合~結果が変化するときには、関連な`文書$用に`投機的な読込nを考慮する$モノトスル。 ◎ When style recalculation would cause selector matching results to change, the user agent must consider speculative loads for the relevant Document.
利用者が`~hyperlink$に対する関心を指示したときには、いずれかの［ `投機~規則~早急度$用の経験則を実装するために利用する`実装定義$な仕方］で［当の~hyperlinkの`~node文書$用に`投機的な読込nを考慮する$ ］ようにしてもヨイ。 ◎ When the user indicates interest in hyperlinks, in one of the implementation-defined ways that the user agent uses to implement the speculation rule eagerness heuristics, the user agent may consider speculative loads for the hyperlink's node document.

例えば， `pointerdown$et ~eventを注視することにより `conservative$l な早急度を実装する~UAは、［そのような~eventに反応することを成す一部として`投機的な読込nを考慮する$ ］よう求めることになろう。 ◎ For example, a user agent which implements "conservative" eagerness by watching for pointerdown events would want to consider speculative loads as part of reacting to such events.

注記：この標準においては、 `投機的な読込nを考慮する$各~callには，`文書$だけが与えられる — 当の~algoは、アリなすべての候補を~statelessな仕方で算出し直す。本物の実装は、もっと効率的に更新するため，以前の算出を~cacheした上で~call元からの情報も渡す見込みが高い。例えば， `a$e 要素の `href$a 属性が変化した場合、関係する`投機的な読込nの候補$のみを更新するよう，当の要素も渡すこともできる。 ◎ In this standard, every call to consider speculative loads is given just a Document, and the algorithm re-computes all possible candidates in a stateless way. A real implementation would likely cache previous computations, and pass along information from the call site to make updates more efficient. For example, if an a element's href attribute is changed, that specific element could be passed along in order to update only the related speculative load candidate.

`投機的な読込nを考慮する$~algoは，小taskを~queueすることにより`投機的な読込nを考慮する内縁~手続き$を走らすので、それが走る時点までに複数の更新（または`取消n＠#step-prefetch-record-cancel-and-discard$）が，一緒に処理されるかもしれないことに注意。 ◎ Note that because of how consider speculative loads queues a microtask, by the time the inner consider speculative loads steps are run, multiple updates (or cancelations) might be processed together.

`投機的な読込nを考慮する内縁~手続き@ は、所与の ( `文書$ %文書 ) に対し： ◎ The inner consider speculative loads steps for a Document document are:

~IF［ %文書は`全部的に作動中$でない］ ⇒ ~RET ◎ If document is not fully active, then return.
%~prefetch候補~群 ~LET 新たな`~list$ ◎ Let prefetchCandidates be an empty list.
%文書の`投機~規則~集合~群$docを成す ~EACH( %規則~集合 ) に対し： ◎ For each ruleSet of document's speculation rule sets:
1. %規則~集合の`~prefetch規則~群$srsを成す ~EACH( %規則 ) に対し： ◎ For each rule of ruleSet's prefetch rules:
  1. %匿名~化~施策 ~LET ~NULL ◎ Let anonymizationPolicy be null.
  2. ~IF［ `anonymous-client-ip-when-cross-origin^l ~IN %規則の`要件~群$sr ］ ⇒ %匿名~化~施策 ~SET 新たな`非同一-生成元~prefetch~IP匿名~化~施策$ — その ⇒＃ `生成元$copiap ~SET %文書の`生成元$doc ◎ If rule's requirements contains "anonymous-client-ip-when-cross-origin", then set anonymizationPolicy to a cross-origin prefetch IP anonymization policy whose origin is document's origin.
  3. %規則の`~URL群$srを成す ~EACH( %~URL ) に対し： ◎ For each url of rule's URLs:
    1. %~referrer施策 ~LET `投機的な読込nの~referrer施策を算出する$( %規則, ~NULL ) ◎ Let referrerPolicy be the result of computing a speculative load referrer policy given rule and null.
    2. %~prefetch候補 ~LET 新たな`~prefetch候補$ — その ⇒＃ `~URL$slC ~SET %~URL, `~No-Vary-Search~hint$slC ~SET %規則の`~No-Vary-Search~hint$sr, `早急度$slC ~SET %規則の`早急度$sr, `~referrer施策$slC ~SET %~referrer施策, `~tag群$slC ~SET %規則の`~tag群$sr, `匿名~化~施策$ ~SET %匿名~化~施策 ◎ Append a new prefetch candidate with • URL •• url • No-Vary-Search hint •• rule's No-Vary-Search hint • eagerness •• rule's eagerness • referrer policy •• referrerPolicy • tags •• rule's tags • anonymization policy •• anonymizationPolicy to prefetchCandidates.
    3. %~prefetch候補~群に %~prefetch候補を`付加する$ ◎ ↑
  4. ~IF［ %規則の`述部$sr ~NEQ ~NULL ］： ◎ If rule's predicate is not null:
    1. %~link群 ~LET `合致している~linkたちを見出す$( %文書, %規則の`述部$sr ) ◎ Let links be the result of finding matching links given document and rule's predicate.
    2. %~link群を成す ~EACH( %~link ) に対し： ◎ For each link of links:
      1. %~referrer施策 ~LET `投機的な読込nの~referrer施策を算出する$( %規則, %~link ) ◎ Let referrerPolicy be the result of computing a speculative load referrer policy given rule and link.
      2. %~prefetch候補 ~LET 新たな`~prefetch候補$ — その ⇒＃ `~URL$slC ~SET %~link の`~URL$el, `~No-Vary-Search~hint$slC ~SET %規則の`~No-Vary-Search~hint$sr, `早急度$slC ~SET %規則の`早急度$sr, `~referrer施策$slC ~SET %~referrer施策, `~tag群$slC ~SET %規則の`~tag群$sr, `匿名~化~施策$ ~SET %匿名~化~施策 ◎ Append a new prefetch candidate with • URL •• link's url • No-Vary-Search hint •• rule's No-Vary-Search hint • eagerness •• rule's eagerness • referrer policy •• referrerPolicy • tags •• rule's tags • anonymization policy •• anonymizationPolicy to prefetchCandidates.
      3. %~prefetch候補~群に %~prefetch候補を`付加する$ ◎ ↑
%文書の`~prefetch~record群$docを成す ~EACH( %~prefetch~record ) に対し： ◎ For each prefetchRecord of document's prefetch records:
1. ~IF［ %~prefetch~record の`~source$pfR ~NEQ `speculation rules^l ］ ⇒ ~CONTINUE ◎ If prefetchRecord's source is not "speculation rules", then continue.
2. ~Assert： %~prefetch~record の`状態$pfR ~NEQ `canceled^l ◎ Assert: prefetchRecord's state is not "canceled".
3. ~IF［ `依然として投機されている$( %~prefetch~record, %~prefetch候補~群 ) ~EQ ~F ］ ⇒ `取消して破棄する$( %~prefetch~record, %文書 ) ◎ If prefetchRecord is not still being speculated given prefetchCandidates, then cancel and discard prefetchRecord given document.
%~prefetch候補~group群 ~LET 新たな`~list$ ◎ Let prefetchCandidateGroups be an empty list.
%~prefetch候補~群を成す ~EACH( %~item ) に対し： ◎ For each candidate of prefetchCandidates:
1. %~group ~LET « %候補 » ◎ Let group be « candidate ».
2. 【！`拡張する$】 %~prefetch候補~群を成す ~EACH( %候補 ) に対し ⇒ ~IF［ %~item ~NEQ %候補］~AND［ ( %候補, %~item ) は`互いに冗長$である］~AND［ %~item の`早急度$slCは %候補の`早急度$slC`以上に早急$である］ ⇒ %~group に %~item を`付加する$ ◎ Extend group with all items in prefetchCandidates, apart from candidate itself, which are redundant with candidate and whose eagerness is at least as eager as candidate's eagerness.
3. %~prefetch候補~group群を成す ~EACH( %別の~group ) に対し ⇒ ~IF［ %別の~group と %~group は順序を無視して同じ`~item$たちからなる【！~itemどうしの同等性が定義されていない】］ ⇒ ~CONTINUE ◎ If prefetchCandidateGroups contains another group whose items are the same as group, ignoring order, then continue.
4. %~prefetch候補~group群に %~group を`付加する$ ◎ Append group to prefetchCandidateGroups.
次の投機~規則は、 2 個の`互いに冗長$な`~prefetch候補$を生成する： ◎ The following speculation rules generate two redundant prefetch candidates:
```
{
  "prefetch": [
    {
      "tag": "a",
      "urls": ["next.html"]
    },
    {
      "tag": "b",
      "urls": ["next.html"],
      "referrer_policy": "no-referrer"
    }
  ]
}
```
この段は，それら両者を所与の順序で包含している 1 個の~groupを作成することになる。（上の~loopにおける 2 回目の反復は~groupを作成しないことになる — その内容は順序が異なるだけで 1 個目の~groupと同じになるので）。このことは、 ~UAが［以下の “任意選択な”【！may】段で当の~groupを動作化することを実行することを選ぶ場合］には［ 1 個目の候補を動作化して， 2 個目を無視する］ようになることを意味する。したがって，当の要請は［ `no-referrer$v を利用する代わりに`既定の~referrer施策$ ］を伴って為されることになる。 ◎ This step will create a single group containing them both, in the given order. (The second pass through will not create a group, since its contents would be the same as the first group, just in a different order.) This means that if the user agent chooses to execute the "may" step below to enact the group, it will enact the first candidate, and ignore the second. Thus, the request will be made with the default referrer policy, instead of using "no-referrer".

しかしながら、 `投機的な読込nの候補たちから~tag群を収集する$~algoは，当の~group内の両~候補から~tagたちを収集するので、 `Sec-Speculation-Tags$h ~headerの値は `"a", "b"^bl になる。このことは、［どちらの規則も投機的な読込nを生じさせ得たこと］を~server運用者に指示する。 ◎ However, the collect tags from speculative load candidates algorithm will collect tags from both candidates in the group, so the `Sec-Speculation-Tags` header value will be `"a", "b"`. This indicates to server operators that either rule could have caused the speculative load.
%~prefetch候補~group群を成す ~EACH( %~group ) に対し： ◎ For each group of prefetchCandidateGroups:
1. 任意選択で【！may】： ◎ The user agent may run the following steps:
  1. %~prefetch候補 ~LET %~group[ 0 ] ◎ Let prefetchCandidate be group[0].
  2. %送信する~tag群 ~LET `投機的な読込nの候補たちから~tag群を収集する$( %~group ) ◎ Let tagsToSend be the result of collecting tags from speculative load candidates given group.
  3. %~prefetch~record ~LET 新たな`~prefetch~record$ — その ⇒＃ `~source$pfR ~SET `speculation rules^l, `~URL$pfR ~SET %~prefetch候補の`~URL$slC, `~No-Vary-Search~hint$pfR ~SET %~prefetch候補の`~No-Vary-Search~hint$slC, `~referrer施策$pfR ~SET %~prefetch候補の`~referrer施策$slC, `匿名~化~施策$pfR ~SET %~prefetch候補の`匿名~化~施策$, `~tag群$pfR ~SET %送信する~tag群 ◎ Let prefetchRecord be a new prefetch record with • source •• "speculation rules" • URL •• prefetchCandidate's URL • No-Vary-Search hint •• prefetchCandidate's No-Vary-Search hint • referrer policy •• prefetchCandidate's referrer policy • anonymization policy •• prefetchCandidate's anonymization policy • tags •• tagsToSend
  4. `~referrerにより起動された~naviな~prefetchを開始する$( %~prefetch~record, %文書 ) ◎ Start a referrer-initiated navigational prefetch given prefetchRecord and document.
  ~UAは、この “任意選択な”【！may】段を実行するかどうか裁定するときは， %~prefetch候補の`早急度$slCを［利用者の現在の挙動, 各種`投機~規則~早急度$の定義］に則って考慮するベキである。 ◎ When deciding whether to execute this "may" step, user agents should consider prefetchCandidate's eagerness, in accordance to the current behavior of the user and the definitions of speculation rule eagerness.
  
  %~prefetch候補の`~No-Vary-Search~hint$slCは、 `投機~規則~早急度$値~用に定義される経験則を実装する際にも有用になり得る。例えば，利用者がある~linkを~hoverしていて，［ ( 当の~linkの`~URL$el, %~prefetch候補の`~URL$slC ) は %~prefetch候補の`~No-Vary-Search~hint$slC の`下で等価$である］ならば、この段を遂行することが有用になることも~UAに指示し得る。 ◎ prefetchCandidate's No-Vary-Search hint can also be useful in implementing the heuristics defined for the speculation rule eagerness values. For example, a user hovering of a link whose URL is equivalent modulo search variance to prefetchCandidate's URL given prefetchCandidate's No-Vary-Search hint could indicate to the user agent that performing this step would be useful.
  
  ~UAは、この “任意選択な”【！may】段を実行するかどうか裁定するときは，利用者~選好（~data節約~modeや~battery節約~modeなど，利用者が暗黙的に表出したものも含む）を~web開発者により給された早急度よりも優先するベキである。 ◎ When deciding whether to execute this "may" step, user agents should prioritize user preferences (express or implied, such as data-saver or battery-saver modes) over the eagerness supplied by the web developer.

`投機的な読込nの~referrer施策を算出する@ ~algoは、所与の ( `投機~規則$ %規則, ［ `a$e 要素／ `area$e 要素／ ~NULL ］ %~link ) に対し： ◎ To compute a speculative load referrer policy given a speculation rule rule and an a element, area element, or null link:

~IF［ %規則の`~referrer施策$sr ~NEQ 空~文字列］ ⇒ ~RET %規則の`~referrer施策$sr ◎ If rule's referrer policy is not the empty string, then return rule's referrer policy.
~IF［ %~link ~EQ ~NULL ］ ⇒ ~RET 空~文字列 ◎ If link is null, then return the empty string.
~RET %~link の`~hyperlink~referrer施策$ ◎ Return link's hyperlink referrer policy.

`投機的な読込nの候補たちから~tag群を収集する@ ~algoは、所与の ( `投機的な読込nの候補$たちが成す`~list$ %候補~群 ) に対し： ◎ To collect tags from speculative load candidates given a list of speculative load candidates candidates:

%~tag群 ~LET 新たな`有順序~集合$ ◎ Let tags be an empty ordered set.
%候補~群を成す ~EACH( %候補 ) に対し： ◎ For each candidate of candidates:
1. %候補の`~tag群$slCを成す ~EACH( %~tag ) に対し ⇒ %~tag群に %~tag を`付加する$set ◎ For each tag of candidate's tags: append tag to tags.
`~listを昇順に~sortする$( %~tag群, 次の手続き )

手続きは ⇒ ~RET ~IS ［［ %~tag~A ~EQ ~NULL ］~AND［ %~tag~B ~NEQ ~NULL 【この条件は，この訳による補完】］］~OR［ %~tag~A は %~tag~B `未満の符号単位~列$である］
◎ Sort in ascending order tags, with tagA being less than tagB if tagA is null, or if tagA is code unit less than tagB.
~RET %~tag群 ◎ Return tags.

`合致している~linkたちを見出す@ ~algoは、所与の ( `文書$ %文書, `文書~規則~述部$ %述部 ) に対し： ◎ To find matching links given a Document document and a document rule predicate predicate:

%~link群 ~LET 新たな`~list$ ◎ Let links be an empty list.
%文書を成す ~EACH( `~shadowも含めた子孫$ %子孫 ) に対し，`~shadowも含めた~tree順序$で： ◎ For each shadow-including descendant descendant of document, in shadow-including tree order:
1. ~IF［ %子孫は［ `a$e ／ `area$e ］要素でない］~OR［ %子孫は `href$a 属性を有さない］ ⇒ ~CONTINUE ◎ If descendant is not an a or area element with an href attribute, then continue.
2. ~IF［ %子孫は`具現化されて$いない］~OR［ %子孫は`飛ばされた内容$の一部を成す］ ⇒ ~CONTINUE ◎ If descendant is not being rendered or is part of skipped contents, then continue.
  
  注記：そのような~linkは、 %文書内には在るが，利用者がヤリトリするものとしては可用でない — したがって，良い候補にならない見込みが高い。加えて，それらの［ ~styleや~layout ］はまだ算出されていないかもしれず，［これらの要素~用の作業を一部でも飛ばす~UA ］における選択子~照合の効率を悪くするかもしれない。 ◎ Such links, though present in document, aren't available for the user to interact with, and thus are unlikely to be good candidates. In addition, they might not have their style or layout computed, which might make selector matching less efficient in user agents which skip some or all of that work for these elements.
3. ~IF［ %子孫の`~URL$el ~EQ ~NULL ］~OR［ %子孫の`~URL$elの`~scheme$urlは`~HTTP_S~scheme$でない］ ⇒ ~CONTINUE ◎ If descendant's url is null, or its scheme is not an HTTP(S) scheme, then continue.
4. ~IF［ %述部は %子孫に`合致-$する］ ⇒ %~link群に %子孫を`付加する$ ◎ If predicate matches descendant, then append descendant to links.
~RET %~link群 ◎ Return links.

所与の ( `文書~規則~述部$ %述部, ［ `a$e ／ `area$e ］要素 %要素 ) に対し， %述部は %要素に `合致-@ するとは、 %述部に応じて，次に挙げる手続きが ~T を返すことをいう： ◎ A document rule predicate predicate matches an a or area element el if the following steps return true, switching on predicate's type:

`文書~規則~論理積$： ◎ document rule conjunction
1. %述部の`条項~群$drCを成す ~EACH( %条項 ) に対し ⇒ ~IF［ %条項は %要素に`合致-$しない］ ⇒ ~RET ~F ◎ For each clause of predicate's clauses: • If clause does not match el, then return false.
2. ~RET ~T ◎ Return true.
`文書~規則~論理和$： ◎ document rule disjunction
1. %述部の`条項~群$drDを成す ~EACH( %条項 ) に対し ⇒ ~IF［ %条項は %要素に`合致-$する］ ⇒ ~RET ~T ◎ For each clause of predicate's clauses: • If clause matches el, then return true.
2. ~RET ~F ◎ Return false.
`文書~規則~否定$ ⇒ ~RET ~IS［ %述部の`条項$drN は %要素に`合致-$しない］ ◎ document rule negation • If predicate's clause matches el, then return false. • Return true.
`文書~規則~URL~pattern述部$： ◎ document rule URL pattern predicate
1. %述部の`~pattern群$を成す ~EACH( %~pattern ) に対し ⇒ ~IF［ `~URL~patternを照合する$( %~pattern, %要素の`~URL$el ) の結果 ~NEQ ~NULL ］ ⇒ ~RET ~T ◎ For each pattern of predicate's patterns: • If performing a match given pattern and el's url gives a non-null value, then return true.
2. ~RET ~F ◎ Return false.
`文書~規則~選択子~述部$： ◎ document rule selector predicate
1. %述部の`選択子~群$を成す ~EACH( %選択子 ) に対し ⇒ ~IF［ `要素に対し選択子を照合する$( %選択子, %要素, { %要素の`根$ } ) の結果 ~EQ `成功^i ］ ⇒ ~RET ~T ◎ For each selector of predicate's selectors: • If performing a match given selector and el with the scoping root set to el's root returns success, then return true.
2. ~RET ~F ◎ Return false.

投機~規則~特能は、 `~task~source$として `投機~規則~群~task~source@ を利用する。 ◎ Speculation rules features use the speculation rules task source, which is a task source.

注記：一般に，［投機的な読込ngの重要~度は，現在の文書の目的~用の処理~taskよりも低い］ので、実装は，ここで~enqueueされる`~task$の優先度をとりわけ低くするかもしれない。 ◎ Because speculative loading is generally less important than processing tasks for the purpose of the current document, implementations might give tasks enqueued here an especially low priority.

7.6.2. ~naviな~prefetch法

~naviな~prefetch法の処理nは、今の所は `PREFETCH$r 内に定義される。それをこの標準の中へ移動することは、 `課題 #11123＠~HTMLissue/11123$ において追跡される。 ◎ For now, the navigational prefetching process is defined in the Prefetch specification. Moving it into this standard is tracked in issue #11123. [PREFETCH]

この標準は、そこに定義される次に挙げる概念を参照rする： ◎ This standard refers to the following concepts defined there:

`~prefetch~record$, およびそれを成す次に挙げる~item：
- `~source$pfR
- `~URL$pfR
- `~No-Vary-Search~hint$pfR
- `~referrer施策$pfR
- `匿名~化~施策$pfR
- `~tag群$pfR
- `状態$pfR
◎ prefetch record, and its items source, URL, No-Vary-Search hint, referrer policy, anonymization policy, tags, and state
`取消して破棄する$ ◎ cancel and discard
`依然として投機されている$ ◎ still being speculated
`~prefetch~record群$doc ◎ prefetch records
`~referrerにより起動された~naviな~prefetchを開始する$ ◎ start a referrer-initiated navigational prefetch

7.6.3. `Speculation-Rules^h ~header

`Speculation-Rules@h ~HTTP応答~headerは、［所与の`投機~規則~集合$を~fetchして現在の`文書$に適用するよう~UAに要請する］ことを開発者に許容する。 ◎ The `Speculation-Rules` HTTP response header allows the developer to request that the user agent fetch and apply a given speculation rule set to the current Document.＼

この~headerは，`有構造~header$であり、その値は，次を満たさなければナラナイ ⇒ `~sf~list$であって，それを成す各~itemの値は次を満たす`~sf文字列$である ⇒ `妥当な~URL文字列$である ◎ It is a structured header whose value must be a list of strings that are all valid URL strings.

`~Speculation-Rules~headerを処理する@ ~algoは、所与の ( `文書$ %文書, `応答$ %応答 ) に対し： ◎ To process the `Speculation-Rules` header given a Document document and a response response:

%構文解析-済み~list ~LET %応答の`~header~list$rsから`有構造~field値を取得する$( `Speculation-Rules$h, `~list^i ) ◎ Let parsedList be the result of getting a structured field value given `Speculation-Rules` and "list" from response's header list.
~IF［ %構文解析-済み~list ~EQ ~NULL ］ ⇒ ~RET ◎ If parsedList is null, then return.
%構文解析-済み~listを成す ~EACH( %~item ) に対し： ◎ For each item of parsedList:
1. ~IF［ %~item は`文字列$【`~sf文字列$】でない］ ⇒ ~CONTINUE ◎ If item is not a string, then continue.
2. %~URL ~LET `~URL構文解析する$( %~item, %文書の`文書~基底~URL$ ) ◎ Let url be the result of URL parsing item with document's document base URL.
3. ~IF［ %~URL ~EQ `失敗^i ］ ⇒ ~CONTINUE ◎ If url is failure, then continue.
4. この段は`並列的$に遂行する： ◎ In parallel:
  1. 任意選択で【！may】 ⇒ `実装定義$な時間だけ待機する ◎ Optionally, wait for an implementation-defined amount of time.
    
    注記：これは、［投機~規則~群の読込ngに先立って，他の作業を優先する］ことを実装に許容する — とりわけ［ `文書$の作成, ~header処理］の間は，もっと重要な多くのものが進行中なことが多いので。 ◎ This allows the implementation to prioritize other work ahead of loading speculation rules, as especially during Document creation and header processing, there are often many more important things going on.
  2. `大域~taskを~queueする$( `投機~規則~群~task~source$, %文書の`関連な大域~obj$, 次の手続き ) ◎ Queue a global task on the speculation rules task source given document's relevant global object to perform＼
    手続きは： ◎ the following steps:
    1. %要請 ~LET 新たな`要請$ — その ⇒＃ `~URL$rq ~SET %~URL, `行先$rq ~SET `speculationrules^l, `~mode$rq ~SET `cors^l ◎ Let request be a new request whose URL is url, destination is "speculationrules", and mode is "cors".
    2. %要請を`~fetchする$ — 次を与える下で： ◎ Fetch request with the following＼
      
      `応答の本体を消費する処理n^i は、所与の ( `応答$ %応答, ［ ~NULL ／ `失敗^i ／ `~byte列$ ］ %本体~byte列 ) に対し： ◎ processResponseConsumeBody steps given response response and null, failure, or a byte sequence bodyBytes:
      
      ~IF［ %本体~byte列 ~IN { ~NULL, `失敗^i } ］ ⇒ ~RET ◎ If bodyBytes is null or failure, then abort these steps.
      
      ~IF［ %応答の`状態s$rsは`~ok状態s$でない］ ⇒ ~RET ◎ If response's status is not an ok status, then abort these steps.
      
      %~MIME型 ~LET `~header~listから~MIME型を抽出する$( %応答の`~header~list$rs ) ◎ ↓
      
      ~IF［ %~MIME型の`~essence$ ~NEQ `application/speculationrules+json$mt ］ ⇒ ~RET ◎ If the result of extracting a MIME type from response's header list does not have an essence of "application/speculationrules+json", then abort these steps.
      
      %本体~text ~LET `~UTF-8復号する$( %本体~byte列 ) ◎ Let bodyText be the result of UTF-8 decoding bodyBytes.
      
      %規則~集合 ~LET `投機~規則~集合~文字列を構文解析する$( %本体~text, %文書, %応答の`~URL$rs )
      
      例外が投出された場合，~catchして ⇒ ~RET
      ◎ Let ruleSet be the result of parsing a speculation rule set string given bodyText, document, and response's URL. If this throws an exception, then abort these steps.
      
      %文書の`投機~規則~集合~群$docに %規則~集合を`付加する$ ◎ Append ruleSet to document's speculation rule sets.
      
      `投機的な読込nを考慮する$( %文書 ) ◎ Consider speculative loads for document.

7.6.4. `Sec-Speculation-Tags$h ~header

`Sec-Speculation-Tags@h ~HTTP要請~headerは、 ~web開発者が供した［投機的な~navi要請に結付けられた~tagたち］を指定する。それは、投機的な~navi要請と投機的な下位資源~要請を判別するためにも利用され得る — どちらに~~分類される要請も， `Sec-Purpose$h を送信し得るので。 ◎ The `Sec-Speculation-Tags` HTTP request header specifies the web developer-provided tags associated with the speculative navigation request. It can also be used to distinguish speculative navigation requests from speculative subresource requests, since `Sec-Purpose` can be sent by both categories of requests.

この~headerは，`有構造~header$であり、その値は，`~sf~list$でなければナラナイ。この~listは，次に挙げるいずれかを値にとる~itemを包含し得る：

`~sf文字列$ ⇒ 開発者が供した~tagを表現する。
`~sf~token$ ⇒ 定義済みな~tagを表現する。定義済みな~tagは，今の所は `null^c しかない — それは、開発者~定義な~tagを伴わない投機的な~navi要請を指示する。

【他の型の~itemは［許容されないのか，単に無視されるのか］は、はっきりしない。】

◎ The header is a structured header whose value must be a list. The list can contain either token or string values. String values represent developer-provided tags, whereas token values represent predefined tags. As of now, the only predefined tag is null, which indicates a speculative navigation request with no developer-defined tag.

7.6.5. ~securityの考慮点

7.6.5.1. 非同一-~siteな要請

~web~pageは、非同一-~siteな行先へ向けても投機的な読込nを起動し得る。しかしながら、そのような非同一-~siteな投機的な読込nは — `以下＠#speculative-loading-state-partitioning$に説明されるとおり — 常に`資格証$を伴わずに行われるので， ~ambientな権限は［ ~web~platformを成す他の仕組みを介して，すでにアリな要請］に制限される。 ◎ Speculative loads can be initiated by web pages to cross-site destinations. However, because such cross-site speculative loads are always done without credentials, as explained below, ambient authority is limited to requests that are already possible via other mechanisms on the platform.

`Speculation-Rules$h ~headerは、 ~JSON文書 — その本体が`投機~規則~集合~文字列として構文解析される＠#parse-a-speculation-rule-set-string$ことになるそれ — への要請を発行するためにも利用され得る。しかしながら、そのような要請は［ `資格証~mode$rqには `same-origin^l, `~mode$rqには `cors^l ］を利用することに加え，対する応答が【~MIME型の】`~essence$として `application/speculationrules+json$mt を利用しない場合には無視されるので、攻撃を仕掛けることにおいては有用にならない。 ◎ The `Speculation-Rules` header can also be used to issue requests, for JSON documents whose body will be parsed as a speculation rule set string. However, they use the "same-origin" credentials mode, the "cors" mode, and responses which do not use the application/speculationrules+json MIME type essence are ignored, so they are not useful in mounting attacks.

7.6.5.2. 注入される内容

文書~内の各~linkは， `文書~規則~述部$を介して投機的な読込ng用に選定され得るので、開発者は，［そのような~linkが利用者が生成した~markupを包含するかもしれない場合］について用心する必要がある。例えば，［ある~linkの `href$a がある利用者により手入力され，他のすべての利用者へ表示される］場合、悪意的な利用者は `/logout^l の様な値を選ぶかもしれない — その~linkが投機的に読込まれたとき，他の利用者の~browserが~siteから自動的に~log-outさせるよう。このことに関して有用な技法として，次が挙げられる ⇒＃ `文書~規則~選択子~述部$を利用して，そのような危険にもなり得る~linkを除外する。 `文書~規則~URL~pattern述部$を利用して，既知な安全な~linkしか許容しないようにする。 ◎ Because links in a document can be selected for speculative loading via document rule predicates, developers need to be cautious if such links might contain user-generated markup. For example, if the href of a link can be entered by one user and displayed to all other users, a malicious user might choose a value like "/logout", causing other users' browsers to automatically log out of the site when that link is speculatively loaded. Using a document rule selector predicate to exclude such potentially-dangerous links, or using a document rule URL pattern predicate to allowlist known-safe links, are useful techniques in this regard.

`script$e 要素のすべての利用と同じく，開発者は、［利用者が供した内容を［ `type$a 属性が `speculationrules^l に設定された `script$e 要素］の`子~text内容$の中へ挿入すること］について用心する必要がある。特に，~escapeされない終了~tag `</script>^c の挿入は、 `script$e 要素~文脈を分断して，攻撃者により制御される~markupを注入するためにも利用され得る。 ◎ As with all uses of the script element, developers need to be cautious about inserting user-provided content into <script type=speculationrules>'s child text content. In particular, the insertion of an unescaped closing </script> tag could be used to break out of the script element context and inject attacker-controlled markup.

`<script type=speculationrules>^c 特能は，文書~内に見出された内容に呼応して活動を生じさせるので、 ~escapeされてない~HTMLを注入-可能な攻撃者がどの~optionをとり得るかは，考慮するに価する。そのような攻撃者は、すでに［ ~JS ／ `iframe$e 要素］を注入-可能である。一般に，投機的な読込nの危険~性は任意な~script実行よりも低い。しかしながら、 `文書~規則~述部$の利用は，文書~内の~linkを投機的に読込むためにも利用され得る — それらの読込nの存在は、それらの~linkについての情報を漏出する行路も供し得る。このアリ性に抗する多層防御は、 ~CSP `CSP$r により供される。特に， `script-src$dir 指令は、投機~規則~群を伴う `script$e 要素の構文解析を制約するために利用できる。また， `default-src$dir 指令は、そのような投機~規則~群から発生している~naviな~prefetch要請に適用される。追加的な防御は［投機的な読込nは`信用に価し得る~URL$に限り遂行される］とする要件により供されるので、経路上の攻撃者は，~metadataと流通~分析にしか~accessし得ず, ~URLを直に見ることはできない。 ◎ The <script type=speculationrules> feature causes activity in response to content found in the document, so it is worth considering the options open to an attacker able to inject unescaped HTML. Such an attacker is already able to inject JavaScript or iframe elements. Speculative loads are generally less dangerous than arbitrary script execution. However, the use of document rule predicates could be used to speculatively load links in the document, and the existence of those loads could provide a vector for exfiltrating information about those links. Defense-in-depth against this possibility is provided by Content Security Policy. In particular, the script-src directive can be used to restrict the parsing of speculation rules script elements, and the default-src directive applies to navigational prefetch requests arising from such speculation rules. Additional defense is provided by the requirement that speculative loads are only performed to potentially-trustworthy URLs, so an on-path attacker would only have access to metadata and traffic analysis, and could not see the URLs directly. [CSP]

一般に，［利用者が生成した内容が任意な応答~headerとして追加されること］は予期されない — これがアリな場合、 ~server運用者は，すでに有意な面倒事に遭遇しているはずである。したがって、 `Speculation-Rules$h ~headerが~XSS攻撃~表口を有意義に拡げる見込みは，およそない。この理由から、 ~CSPは，この~headerを介した規則~集合~群の読込ngには適用されない。 ◎ It's generally not expected that user-generated content will be added as arbitrary response headers: server operators are already going to encounter significant trouble if this is possible. It is therefore unlikely that the `Speculation-Rules` header meaningfully expands the XSS attack surface. For this reason, Content Security Policy does not apply to the loading of rule sets via that header.

7.6.5.3. ~IP匿名~化

この標準は、［ ~naviな~prefetchを［ ~UAにより供される~IP匿名~化~技術］を利用して遂行するよう要請する］ことを開発者に許容する。この匿名~化の詳細は，指定されないが、いくつかの一般な~security原則が適用される。 ◎ This standard allows developers to request that navigational prefetches are performed using IP anonymization technology provided by the user agent. The details of this anonymization are not specified, but some general security principles apply.

~IP匿名~化は、ある~proxy~serviceを利用して実装される場合には，~network経路~上の［ ~service運用者や他の実体］に可用な情報を最小~化することを勧める。これは、少なくとも［当の接続~用には~TLSを利用する］ことを孕む見込みが高い。 ◎ To the extent IP anonymization is implemented using a proxy service, it is advisable to minimize the information available to the service operator and other entities on the network path. This likely involves, at a minimum, the use of TLS for the connection.

~site運用者は、 ~HTTP~serverから見える~client~IP~addressは — ~VPN（ `virtual private network^en ）技術と類似に — ［利用者の実際の［ ~network~providerや所在］には正確に対応しないかもしれず，同じ~client~IP~addressから複数の別個な~subscriber用の流通が出生することもある］ことを自覚する必要がある。このことは、 ~site運用者の~securityと濫用~防止~措置に影響し得る。 ~IP匿名~化~措置は，出口~IP~addressとして［利用者と類似な地理所在にあるもの／利用者が属する管轄~内に所在するもの］を利用する労を為すかもしれないが、そのような挙動は，~UAに~~特有なので保証されない。 ◎ Site operators need to be aware that, similar to virtual private network (VPN) technology, the client IP address seen by the HTTP server might not exactly correspond to the user's actual network provider or location, and a traffic for multiple distinct subscribers could originate from a single client IP address. This can affect site operators' security and abuse prevention measures. IP anonymization measures might make an effort to use an egress IP address which has a similar geolocation or is located in the same jurisdiction as the user, but any such behavior is particular to the user agent and not guaranteed.

7.6.6. ~privacyの考慮点

【この節を成す内容は未訳。】

7.7. `X-Frame-Options^h ~header

`X-Frame-Options@h ~HTTP応答~headerは、［ `文書$は`子~navigable$の内側にどう読込まれてもよいか］を制御する仕方である。 ~CSPを利用している~site用には、 `frame-ancestors$dir 指令の方が，同じ状況に対し細やかな制御を供する。この~headerは，元々は `RFC7034$r にて定義されたが、ここでの定義と処理~modelは，その文書に取って代わる。 ◎ The `X-Frame-Options` HTTP response header is a way of controlling whether and how a Document may be loaded inside of a child navigable. For sites using CSP, the frame-ancestors directive provides more granular control over the same situations. It was originally defined in HTTP Header Field X-Frame-Options, but the definition and processing model here supersedes that document. [CSP] [RFC7034]

注記：特に， `RFC7034$r は、その~header値~用の変種として `ALLOW-FROM^bl も指定したが，それは実装されていない。 ◎ In particular, HTTP Header Field X-Frame-Options specified an `ALLOW-FROM` variant of the header, but that is not to be implemented.

注記：以下に与える処理~modelにより、 `X-Frame-Options$h ~headerは，同じ`応答$内に~CSP `frame-ancestors$dir 指令も利用された場合には無視される。 ◎ Per the below processing model, if both a CSP frame-ancestors directive and an `X-Frame-Options` header are used in the same response, then `X-Frame-Options` is ignored.

［ ~web開発者／適合性~検査器］向けとして，その値の`~ABNF$は： ◎ For web developers and conformance checkers, its value ABNF is:

X-Frame-Options
	= "DENY"
	/ "SAMEORIGIN"

`~navi応答の~X-Frame-Optionsに対する固守を検査する@ ~algoは、所与の ( `応答$ %応答, `~navigable$ %~navigable, `~CSP~list$ %~CSP~list, `生成元$ %行先~生成元 ) に対し： ◎ To check a navigation response's adherence to `X-Frame-Options`, given a response response, a navigable navigable, a CSP list cspList, and an origin destinationOrigin:

~IF［ %~navigable は`子~navigable$でない］ ⇒ ~RET ~T ◎ If navigable is not a child navigable, then return true.
%~CSP~list を成す ~EACH( %施策 ) に対し： ◎ For each policy of cspList:
1. ~IF［ %施策の`処置先$ ~NEQ `enforce^l ］ ⇒ ~CONTINUE ◎ If policy's disposition is not "enforce", then continue.
2. ~IF［ `frame-ancestors$dir 指令 ~IN %施策の`指令~集合$ ］ ⇒ ~RET ~T ◎ If policy's directive set contains a frame-ancestors directive, then return true.
%~X-Frame-Options ~LET `~header~listから値を取得して復号して分割する$( %応答の`~header~list$rs, `X-Frame-Options$h ) ◎ Let rawXFrameOptions be the result of getting, decoding, and splitting `X-Frame-Options` from response's header list.
~IF［ %~X-Frame-Options ~EQ ~NULL ］ ⇒ ~RET ~T

【この段は、この訳による補完（応答~内に `X-Frame-Options$h は無い）。】
%~frame~option群 ~LET 新たな`有順序~集合$ ◎ Let xFrameOptions be a new set.
%~X-Frame-Options を成す ~EACH( %値 ) に対し ⇒ %~frame~option群に次の結果を`付加する$set ⇒ `~ASCII小文字~化する$( %値 ) ◎ For each value of rawXFrameOptions, append value, converted to ASCII lowercase, to xFrameOptions.
~IF［ %~frame~option群の`~size$ ~GT 1 ］： ◎ ↓
1. %~frame~option群を成す ~EACH( %値 ) に対し ⇒ ~IF［ %値 ~IN { `deny^l, `allowall^l, `sameorigin^l } ］ ⇒ ~RET ~F ◎ If xFrameOptions's size is greater than 1, and xFrameOptions contains any of "deny", "allowall", or "sameorigin", then return false.
  
  注記：ここでの意図nは、 `X-Frame-Options$h が［妥当な何かを行おうと試行しているが，紛らわしく現れる］場合には，それを適用する際に【埋込もうとする】どの試みも阻止することにある。 ◎ The intention here is to block any attempts at applying `X-Frame-Options` which were trying to do something valid, but appear confused.
  
  注記：旧来の `ALLOWALL^bl 値による処理~modelに対する影響iは、ここに限られる。 ◎ This is the only impact of the legacy `ALLOWALL` value on the processing model.
2. ~RET ~T ◎ If xFrameOptions's size is greater than 1, then return true.
  
  注記： ~headerは、複数個の妥当でない値を包含している — この場合、 ~headerがまるごと省略されていたときと同じ仕方で扱う。 ◎ This means it contains multiple invalid values, which we treat the same way as if the header was omitted entirely.
~IF［ %~frame~option群[ 0 ] ~EQ `deny^l ］ ⇒ ~RET ~F ◎ If xFrameOptions[0] is "deny", then return false.
~IF［ %~frame~option群[ 0 ] ~EQ `sameorigin^bl ］： ◎ If xFrameOptions[0] is "sameorigin", then:
1. %容器~文書 ~LET %~navigable の`容器~文書$nav ◎ Let containerDocument be navigable's container document.
2. ~WHILE［ %容器~文書 ~NEQ ~NULL ］： ◎ While containerDocument is not null:
  1. ~IF［ ( %容器~文書の`生成元$doc, %行先~生成元 ) は`同一-生成元$でない］ ⇒ ~RET ~F ◎ If containerDocument's origin is not same origin with destinationOrigin, then return false.
  2. %容器~文書 ~SET %容器~文書の`容器~文書$doc ◎ Set containerDocument to containerDocument's container document.
~RET ~T ◎ Return true.

注記：ここまで達した場合、妥当でない 1 個の値からなる（旧来の［ `ALLOWALL^bl ／ `ALLOW-FROM^bl ］形も該当する） — この場合、 ~headerはまるごと省略されていたかのように扱う。 ◎ If we've reached this point then we have a lone invalid value (which could potentially be one the legacy `ALLOWALL` or `ALLOW-FROM` forms). These are treated as if the header were omitted entirely.

この~header用の様々な値の処理を — 不適合tなものも含め — 次の表tに示す： ◎ The following table illustrates the processing of various values for the header, including non-conformant ones:

`X-Frame-Options$h	妥当か？	結果
`DENY^bl	✅	埋込みは許容されない
`SAMEORIGIN^bl	✅	同一-生成元なら埋込みは許容される
`INVALID^bl	❌	埋込みは許容される
`ALLOWALL^bl	❌	埋込みは許容される
`ALLOW-FROM=https://example.com/^bl	❌	埋込みは許容される（どこからでも）

◎ `X-Frame-Options`｜Valid｜Result `DENY`｜✅｜embedding disallowed `SAMEORIGIN`｜✅｜same-origin embedding allowed `INVALID`｜❌｜embedding allowed `ALLOWALL`｜❌｜embedding allowed `ALLOW-FROM=https://example.com/`｜❌｜embedding allowed (from anywhere)

複数の値を孕んでいる，様々な不適合tな事例がどう処理されるかを，次の表tに示す： ◎ The following table illustrates how various non-conformant cases involving multiple values are processed:

`X-Frame-Options$h	結果
`SAMEORIGIN, SAMEORIGIN^bl	同一-生成元なら埋込みは許容される
`SAMEORIGIN, DENY^bl	埋込みは許容されない
`SAMEORIGIN,^bl	埋込みは許容されない
`SAMEORIGIN, ALLOWALL^bl	埋込みは許容されない
`SAMEORIGIN, INVALID^bl	埋込みは許容されない
`ALLOWALL, INVALID^bl	埋込みは許容されない
`ALLOWALL,^bl	埋込みは許容されない
`INVALID, INVALID^bl	埋込みは許容される

◎ `X-Frame-Options`｜Result `SAMEORIGIN, SAMEORIGIN`｜same-origin embedding allowed `SAMEORIGIN, DENY`｜embedding disallowed `SAMEORIGIN,`｜embedding disallowed `SAMEORIGIN, ALLOWALL`｜embedding disallowed `SAMEORIGIN, INVALID`｜embedding disallowed `ALLOWALL, INVALID`｜embedding disallowed `ALLOWALL,`｜embedding disallowed `INVALID, INVALID`｜embedding allowed

値たちが［ ~commaで区切られた値を伴う 1 個の~header, 複数個の~header ］どちらで送達されようが，得される結果は同じになる。 ◎ The same results are obtained whether the values are delivered in a single header whose value is comma-delimited, or in multiple headers.

7.8. `Refresh$h ~header

`Refresh@h ~HTTP応答~headerは、［ `meta$e 要素のうち，その `http-equiv$a 属性は `~refresh$st 状態にあるもの］を~HTTPにおいて等価に~~表現するものである。それは， `同じ値＠~HEmetadata#conformance-attr-meta-http-equiv-refresh$をとり，ほとんど同じに働く。その処理~modelの詳細は、 `文書を作成して初期化する$にて与えられる。 ◎ The `Refresh` HTTP response header is the HTTP-equivalent to a meta element with an http-equiv attribute in the Refresh state. It takes the same value and works largely the same. Its processing model is detailed in create and initialize a Document object.

7.9. ~browser~UIの考慮点

~browser~UAは、自身の`~top-level辿可能~集合$に属するどの`~top-level辿可能$に対しても，次に挙げる能を【利用者~向けに（以下同様）】供するベキである ⇒ `~navigateする$／ `読込直す$／ `読込ngを停止する$ ◎ Browser user agents should provide the ability to navigate, reload, and stop loading any top-level traversable in their top-level traversable set.

例えば、［ ~URL~bar／ “読込直す” ~button／ “停止する” ~button ］などの~UIを介して。 ◎ For example, via a location bar and reload/stop button UI.

~browser~UAは、自身の`~top-level辿可能~集合$に属するどの`~top-level辿可能$に対しても， `履歴を差分だけ辿る$能を供するベキである。 ◎ Browser user agents should provide the ability to traverse by a delta any top-level traversable in their top-level traversable set.

例えば、［戻る／進む］~buttonを介して — 場合によっては、長押しにより差分を変更する能も含めて。 ◎ For example, via back and forward buttons, possibly including long-press abilities to change the delta.

そのような~UAは、 2 以上の差分による辿りも許容することが示唆される — ~pageが［ ~session履歴に偽りな~entryを（例えば，［ `history.pushState()＠~WINDOW#dom-history-pushstate$c の~callや`素片へ~navigateする$こと］を繰返すことを介して）詰め込む］ことにより，利用者を “罠に嵌める” のを避けるため。 ◎ It is suggested that such user agents allow traversal by deltas greater than one, to avoid letting a page "trap" the user by stuffing the session history with spurious entries. (For example, via repeated calls to history.pushState() or fragment navigations.)

注記：一部の~UAは、特定的にそのような濫用を克服するために，［ “戻る” ／ “進む” ］~buttonが 1 回だけ押されたときより大きい差分に翻訳する経験則を備える。 `課題 #7832＠~HTMLissue/7832$ にて，これらの経験則を指定することが~~検討されている。 ◎ Some user agents have heuristics for translating a single "back" or "forward" button press into a larger delta, specifically to overcome such abuses. We are contemplating specifying these heuristics in issue #7832.

~browser~UAは、 `新鮮な~top-level辿可能を作成する$能を利用者に提供するベキである — ［利用者が供した／~UAにより決定される］初期`~URL$を与えて。 ◎ Browser user agents should offer users the ability to create a fresh top-level traversable, given a user-provided or user agent-determined initial URL.

例えば［ “新たな~UItab” ／ “新たな~UIwindow” ］~buttonを介して。 ◎ For example, via a "new tab" or "new window" button.

~browser~UAは、自身の`~top-level辿可能~集合$に属するどの`~top-level辿可能$に対しても，利用者が任意に`~top-level辿可能を閉じる$能を提供するベキである。 ◎ Browser user agents should offer users the ability to arbitrarily close any top-level traversable in their top-level traversable set.

例えば、 “~UItabを閉じる” ~buttonを~clickすることにより。 ◎ For example, by clicking a "close tab" button.

~browser~UAは、利用者~向けに，`~navigable$（`~top-level辿可能$に限らず）を明示的に［ `~navigateする$／`読込直す$／`読込ngを停止する$ ］仕方を供してもヨイ。 ◎ Browser user agents may provide ways for the user to explicitly cause any navigable (not just a top-level traversable) to navigate, reload, or stop loading.

例えば，文脈~menuを介して。 ◎ For example, via a context menu.

~browser~UAは、利用者~向けに，`~top-level辿可能を破壊する$能を供してもヨイ。 ◎ Browser user agents may provide the ability for users to destroy a top-level traversable.

例えば、［そのような`~top-level辿可能$を複数~個包含している~UIwindowを閉じる］よう強制することにより。 ◎ For example, by force-closing a window containing one or more such top-level traversables.

利用者から`~navigable$を`読込直す$よう要請されたとき，その`作動中な~entry$navの`文書~状態$shEの`資源$dSが`~POST資源$である場合には、 ~UAは，先ず利用者にその操作oを確認してもらうよう~promptするベキである — さもなければ、 ~transaction（例：購入や~database改変）が繰返され得るので。 ◎ When a user requests a reload of a navigable whose active session history entry's document state's resource is a POST resource, the user agent should prompt the user to confirm the operation first, since otherwise transactions (e.g., purchases or database modifications) could be repeated.

~UAは，利用者から`~navigable$を`読込直す$よう要請されたときは、読込直す際に~cacheを無視するための仕組みを供してもヨイ。 ◎ When a user requests a reload of a navigable, user agents may provide a mechanism for ignoring any caches when reloading.

`~navigateする$~callが上で言及した仕組みにより起動される場合、その引数 %利用者-関与i に `~browser~UI$i を渡すモノトスル。 ◎ All calls to navigate initiated by the mechanisms mentioned above must have the userInvolvement argument set to "browser UI".

`読込直す$~callが上で言及した仕組みにより起動される場合、その引数 %利用者-関与i に `~browser~UI$i を渡すモノトスル。 ◎ All calls to reload initiated by the mechanisms mentioned above must have the userInvolvement argument set to "browser UI".

`履歴を差分だけ辿る$ ~callが上で言及した仕組みにより起動される場合、その引数 %~source文書には値を渡さないモノトスル。 ◎ All calls to traverse the history by a delta initiated by the mechanisms mentioned above must not pass a value for the sourceDocument argument.

上に挙げた推奨, およびこの仕様における~data構造には、［ ~UAが利用者に~session履歴をどう表現するかに対し制約を設置する］ことは意味されない。 ◎ The above recommendations, and the data structures in this specification, are not meant to place restrictions on how user agents represent the session history to the user.

例えば、 `~top-level辿可能$の`~session履歴~entry群$tnは， ~listとして［格納され, 保守される］ — ~UAには、 `履歴を差分だけ辿る$ための~UIを与えることが推奨される — が、先進的な~UAは，それに［代えて／加えて］~treeの様な~viewを呈示して，［各~pageが複数の “進む” ~pageを備えていて，利用者がそれらを選べる］ようにすることもできる。 ◎ For example, although a top-level traversable's session history entries are stored and maintained as a list, and the user agent is recommended to give an interface for traversing that list by a delta, a novel user agent could instead or in addition present a tree-like view, with each page having multiple "forward" pages that the user can choose between.

類似に、 `辿可能な~navigable$内には，［そのすべての子孫`~navigable$ ］用の~session履歴が格納されるが、 ~UAは，もっと仔細に［ `~navigable$ごとに，~session履歴の~viewを利用者に呈示する］こともできる。 ◎ Similarly, although session history for all descendant navigables is stored in their traversable navigable, user agents could present the user with a more nuanced per-navigable view of the session history.

~browser~UAは、 `~top-level閲覧~文脈$の`~popupか$bcを次に挙げる目的に利用してもヨイ： ◎ Browser user agents may use a top-level browsing context's is popup boolean for the following purposes:

対応している`~top-level辿可能$用に必要最小限な~web~browser~UIを供するかどうかを裁定する。 ◎ Deciding whether or not to provide a minimal web browser user interface for the corresponding top-level traversable.
`閲覧~文脈の特能を設定しておく$とき，その中の任意選択な各~段を遂行する所。 ◎ Performing the optional steps in set up browsing context features.

どちらの事例においても、 ~UAは，それに加えて［利用者-選好を組入れる／ ~popup~routeを奥へ進む選択肢を呈示する］こともできよう。 ◎ In both cases user agents might additionally incorporate user preferences, or present a choice as to whether to go down the popup route.

~UAは、［そのような~popup用に必要最小限な~UIを供する場合でも， ~browserの~URL~barは隠さない］ことが奨励される。 ◎ User agents that provide a minimal user interface for such popups are encouraged to not hide the browser's location bar.