HTML — スクリプト処理

8. ~Web~app~API

8.1. ~scripting

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

◎表記記号

8.1.1. 序論

作者から供された実行-可能な~codeは、 種々の仕組みにより,文書の文脈において走らす。 これらの仕組みには、 (少なくとも)次に挙げるものが含まれる: ◎ Various mechanisms can cause author-provided executable code to run in the context of a document. These mechanisms include, but are probably not limited to:

  • `script$e 要素の処理。 ◎ Processing of script elements.
  • `javascript:@~HTMLnav#the-javascript:-url-special-case$sc ~URLへ~navigateするとき。 ◎ Navigating to javascript: URLs.
  • 次による~event~handler ⇒# ~DOMの `addEventListener()^m を利用して登録されたもの, 明示的な`~event~handler内容~属性$, `~event~handler~IDL属性$, その他 ◎ Event handlers, whether registered through the DOM using addEventListener(), by explicit event handler content attributes, by event handler IDL attributes, or otherwise.
  • ~SVGの様な,自前の~scripting特能を有する技術の処理。 ◎ Processing of technologies like SVG that have their own scripting features.

8.1.2. ~agentと~agent~cluster

8.1.2.1. ~JS~agent形式化との統合

~JSは、 `~agent$の概念を定義している。 この節では、 その言語~levelの概念から~web~platformへの対応付けを与える。 ◎ JavaScript defines the concept of an agent. This section gives the mapping of that language-level concept on to the web platform.

注記: `~agent$の概念は、 概念的には,~architectureに依存しない理想化された “~thread” である — その~thread内で~JS~codeを走らすような。 そのような~codeは,互いに同期的に~accessできる複数の[ 大域~obj / `~realm$gL ]を孕み得るので、 単独の実行~thread内で走らす必要がある。 ◎ Conceptually, the agent concept is an architecture-independent, idealized "thread" in which JavaScript code runs. Such code can involve multiple globals/realms that can synchronously access each other, and thus needs to run in a single execution thread.

2 つの`~window$は、 同じ`~agent$に属していても, 互いの~realm内に作成された すべての~objに直に~accessできるわけではない。 そのためには、 `同じ生成元~domain$に属する必要がある。 `IsPlatformObjectSameOrigin$A を見よ ◎ Two Window objects having the same agent does not indicate they can directly access all objects created in each other's realms. They would have to be same origin-domain; see IsPlatformObjectSameOrigin.

~web~platformには、 次に挙げる型の~agentが存在する: ◎ The following types of agents exist on the web platform:

`生成元が類似な~window~agent@ ◎ Similar-origin window agent
直に, または `document.domain$c を利用することにより,互いに到達し得るような、 様々な`~window$を包含する。 ◎ Contains various Window objects which can potentially reach each other, either directly or by using document.domain.
包摂している`~agent~cluster$の`生成元を~keyにするか$ ~EQ ~T の場合、 すべての`~window$は,[ 互いに`同一-生成元$になる/ 互いに直に到達し得る/ `document.domain$c は何もしない ]ことになる。 ◎ If the encompassing agent cluster's is origin-keyed is true, then all the Window objects will be same origin, can reach each other directly, and document.domain will no-op.
注記: `同一-生成元$に属する 2 個の`~window$は、 異なる`生成元が類似な~window~agent$に属することもある — 一例として、 それぞれが自前の`閲覧~文脈~group$に属する場合。 ◎ Two Window objects that are same origin can be in different similar-origin window agents, for instance if they are each in their own browsing context group.
`専用~worker~agent@ ◎ Dedicated worker agent
1 個の `DedicatedWorkerGlobalScope$I ~objを包含する。 ◎ Contains a single DedicatedWorkerGlobalScope.
`共用~worker~agent@ ◎ Shared worker agent
1 個の `SharedWorkerGlobalScope$I ~objを包含する。 ◎ Contains a single SharedWorkerGlobalScope.
`~sw~agent@ ◎ Service worker agent
1 個の `ServiceWorkerGlobalScope$I ~objを包含する。 ◎ Contains a single ServiceWorkerGlobalScope.
`~worklet~agent@ ◎ Worklet agent
1 個の `WorkletGlobalScope$I ~objを包含する。 ◎ Contains a single WorkletGlobalScope object.
注記: 所与の~workletは、 複数の~realmを有し得る。 そのような各~realmは、 互いに~codeを独立にかつ同時に実行できるので,それぞれに自前の~agentが必要になる。 ◎ Although a given worklet can have multiple realms, each such realm needs its own agent, as each realm can be executing code independently and at the same time as the others.

[ `共用~worker~agent$/`専用~worker~agent$ ]に限り,`前方-進捗$を阻み得る~JS `Atomics$jc ~APIの利用を許容する。 ◎ Only shared and dedicated worker agents allow the use of JavaScript Atomics APIs to potentially block.

`~agentを作成する@ ときは、 所与の ( 真偽値 %canBlock ) に対し: ◎ To create an agent, given a boolean canBlock:

  1. %signifier ~LET 新たな一意な内部的な値 ◎ Let signifier be a new unique internal value.
  2. %実行候補 ~LET 新たな`実行候補$ ◎ Let candidateExecution be a new candidate execution.
  3. %~agent ~LET 新たな`~agent$ — その ⇒# `CanBlock^sl ~SET %canBlock, `Signifier^sl ~SET %signifier, `CandidateExecution^sl ~SET %実行候補, `IsLockFree1^sl, `IsLockFree2^sl, `LittleEndian^sl ~SET いずれも,実装の裁量による何か ◎ Let agent be a new agent whose [[CanBlock]] is canBlock, [[Signifier]] is signifier, [[CandidateExecution]] is candidateExecution, and [[IsLockFree1]], [[IsLockFree2]], and [[LittleEndian]] are set at the implementation's discretion.
  4. %~agent の`~event~loop$aG ~SET 新たな`~event~loop$ ◎ Set agent's event loop to a new event loop.
  5. ~RET %~agent ◎ Return agent.

`~realm$ %~realm 用の `~agent@rM とは、 次を満たす`~agent$である ⇒ その `Signifier^sl ~EQ %~realm .`AgentSignifier^sl ◎ For a realm realm, the agent whose [[Signifier]] is realm.[[AgentSignifier]] is the realm's agent.

【 ~JS仕様における `Signifier^sl, `AgentSignifier^sl の記述から、 該当する~agentは常に在って,一つに限られるであろう。 】

`~platform~obj$ %O に `関連な~agent@ は、 %O に`関連な~realm$用の`~agent$rMとする。 ◎ The relevant agent for a platform object platformObject is platformObject's relevant realm's agent.

注記: `現在の~realm$に等価な~agentは、 `~surrounding~agent$である。 ◎ The agent equivalent of the current realm is the surrounding agent.

8.1.2.2. ~JS~agent~cluster形式化との統合

~JSは、 `~agent~cluster$の概念も定義する。 この標準は、[ `生成元が類似な~window~agentを得する$/ `~worker/~worklet~agentを得する$ ]~algoを利用して~agentが作成されたとき,それを適切に設置することにより、 その概念を~web~platformに対応付ける。 ◎ JavaScript also defines the concept of an agent cluster, which this standard maps to the web platform by placing agents appropriately when they are created using the obtain a similar-origin window agent or obtain a worker/worklet agent algorithms.

`~agent~cluster$の概念は、 ~JS~memory~model — 特に,どの`~agent$どうしが `SharedArrayBuffer$I ~objの~~下層~dataを共有できるか — を定義するために不可欠である。 ◎ The agent cluster concept is crucial for defining the JavaScript memory model, and in particular among which agents the backing data of SharedArrayBuffer objects can be shared.

注記: `~agent~cluster$の概念は、 概念的には,複数の “~thread” ( `~agent$ )を一緒に~group化するような, ~architectureに依存しない理想化された “~process境界” を成す。 仕様が定義する`~agent~cluster$は、 一般に,~UA内で実装される実際の~process境界より制約的である。 これらの理想化された区割りを仕様~levelで施行することにより、 ~process~modelが~UA間で様々でも, ある~UA内で変化しても, 共用~memoryの挙動は ~web開発者からは相互運用可能に見えることが確保される。 ◎ Conceptually, the agent cluster concept is an architecture-independent, idealized "process boundary" that groups together multiple "threads" (agents). The agent clusters defined by the specification are generally more restrictive than the actual process boundaries implemented in user agents. By enforcing these idealized divisions at the specification level, we ensure that web developers see interoperable behavior with regard to shared memory, even in the face of varying and changing user agent process models.

各`~agent~cluster$には、 次に挙げるものが結付けられる: ◎ ↓

  • `非同一-生成元~隔離~mode@agC ⇒ `非同一-生成元~隔離~mode$ — 初期~時は `none$l とする。 ◎ An agent cluster has an associated cross-origin isolation mode, which is a cross-origin isolation mode. It is initially "none".
  • `生成元を~keyにするか@ ⇒ 真偽値 — 初期~時は ~F とする。 ◎ An agent cluster has an associated is origin-keyed (a boolean), which is initially false.

`~agent~cluster$への`生成元が類似な~window~agent$の割振りは、 以下に従って定義される。 ◎ The following defines the allocation of the agent clusters of similar-origin window agents.

`~agent~cluster~key@ は、[ `~site$/`成分組~生成元$ ]である。 それは、 ~web開発者による `生成元を~keyにする~agent~cluster@~ORIGIN#origin-keyed-agent-clusters$ を達成する動作がなければ,`~site$になる。 ◎ An agent cluster key is a site or tuple origin. Without web developer action to achieve origin-keyed agent clusters, it will be a site.

注記: “`~agent~cluster~key$は[ `~scheme&~host$/`生成元$ ]である” としても等価な定式化を成す。 ◎ An equivalent formulation is that an agent cluster key can be a scheme-and-host or an origin.

【 `~agent~cluster~key$どうしの同等性は、 必然的に,成分ごとの比較 (`同じ~site$site/`同一-生成元$) に基づく。 】

`生成元が類似な~window~agentを得する@ ときは、 所与の ( `生成元$ %生成元, `閲覧~文脈~group$ %~group, 真偽値 %生成元~agent~clusterを要請するか ) に対し,次を走らす: ◎ To obtain a similar-origin window agent, given an origin origin, a browsing context group group, and a boolean requestsOAC, run these steps:

  1. %~key ~LET `~siteを得する$( %生成元 ) ◎ Let site be the result of obtaining a site with origin. ◎ Let key be site.
  2. ~IF[ %~group の`非同一-生成元~隔離~mode$bcG ~NEQ `none$l ] ⇒ %~key ~SET %生成元 ◎ If group's cross-origin isolation mode is not "none", then set key to origin.
  3. ~ELIF[ %~group の`履歴上の~agent~cluster~key~map$bcG[ %生成元 ] ~NEQ ε ] ⇒ %~key ~SET %~group の`履歴上の~agent~cluster~key~map$bcG[ %生成元 ] ◎ Otherwise, if group's historical agent cluster key map[origin] exists, then set key to group's historical agent cluster key map[origin].
  4. ~ELSE ◎ Otherwise:

    1. ~IF[ %生成元~agent~clusterを要請するか ~EQ ~T ] ⇒ %~key ~SET %生成元 ◎ If requestsOAC is true, then set key to origin.
    2. %~group の`履歴上の~agent~cluster~key~map$bcG[ %生成元 ] ~SET %~key ◎ Set group's historical agent cluster key map[origin] to key.
  5. ~IF[ %~group の`~agent~cluster~map$bcG[ %~key ] ~EQ ε ]: ◎ If group's agent cluster map[key] does not exist, then:

    1. %~agent~cluster ~SET 新たな`~agent~cluster$ ◎ Let agentCluster be a new agent cluster.
    2. %~agent~cluster の`非同一-生成元~隔離~mode$agC ~SET %~group の`非同一-生成元~隔離~mode$bcG ◎ Set agentCluster's cross-origin isolation mode to group's cross-origin isolation mode.
    3. %~agent~cluster の`生成元を~keyにするか$ ~SET ~IS[ %~key ~EQ %生成元 ] ◎ Set agentCluster's is origin-keyed to true if key equals origin; otherwise false.
    4. %~agent~cluster に次の結果を追加する ⇒ `~agentを作成する$( ~F ) ◎ Add the result of creating an agent, given false, to agentCluster.
    5. %~group の`~agent~cluster~map$bcG[ %~key ] ~SET %~agent~cluster ◎ Set group's agent cluster map[key] to agentCluster.
  6. ~RET %~group の`~agent~cluster~map$bcG[ %~key ] 内に 1 つだけ在る,`生成元が類似な~window~agent$ ◎ Return the single similar-origin window agent contained in group's agent cluster map[key].

注記: これは、 各 閲覧~文脈~agent~clusterには, `生成元が類似な~window~agent$は 1 つだけ在ることを意味する (しかしながら,[ `専用~worker~agent$/`~worklet~agent$ ]は、 同じ~cluster内に複数在るかもしれない)。 ◎ This means that there is only one similar-origin window agent per browsing context agent cluster. (However, dedicated worker and worklet agents might be in the same cluster.)


他のすべての型の~agentが成す`~agent~cluster$の割振りは、 以下で定義される。 ◎ The following defines the allocation of the agent clusters of all other types of agents.

`~worker/~worklet~agentを得する@ ときは、 所与の ( `環境~設定群~obj$または~NULL %外側~設定群, 真偽値 %~top-levelか, 真偽値 %canBlock ) に対し,次の手続きを走らす: ◎ To obtain a worker/worklet agent, given an environment settings object or null outside settings, a boolean isTopLevel, and a boolean canBlock, run these steps:

  1. %~agent~cluster ~LET ~NULL ◎ Let agentCluster be null.
  2. ~IF[ %~top-levelか ~EQ ~T ]: ◎ If isTopLevel is true, then:

    1. %~agent~cluster ~SET 新たな`~agent~cluster$ ◎ Set agentCluster to a new agent cluster.
    2. %~agent~cluster の`生成元を~keyにするか$ ~SET ~T ◎ Set agentCluster's is origin-keyed to true.

      注記: これらの~workerは、 生成元を~keyにするものと見なせる。 しかしながら、 これは,~APIを通しては公開されない ( `originAgentCluster$m が~window用に生成元を~keyにするか否かを公開するような仕方では)。 ◎ These workers can be considered to be origin-keyed. However, this is not exposed through any APIs (in the way that originAgentCluster exposes the origin-keyedness for windows).

  3. ~ELSE: ◎ Otherwise:

    1. ~Assert: %外側~設定群 ~NEQ ~NULL ◎ Assert: outside settings is not null.
    2. %所有者~agent ~LET %外側~設定群 の`~realm$enV用の`~agent$rM ◎ Let ownerAgent be outside settings's realm's agent.
    3. %~agent~cluster ~SET %所有者~agent を包含する~agent~cluster ◎ Set agentCluster to the agent cluster which contains ownerAgent.
  4. %~agent ~LET `~agentを作成する$( %canBlock ) ◎ Let agent be the result of creating an agent given canBlock.
  5. %~agent~cluster に %~agent を追加する ◎ Add agent to agentCluster.
  6. ~RET %~agent ◎ Return agent.

`専用/共用~worker~agentを得する@ ときは、 所与の ( `環境~設定群~obj$ %外側~設定群, 真偽値 %共用か ) に対し,次の結果を返す ⇒ `~worker/~worklet~agentを得する$( %外側~設定群, %共用か, ~T ) ◎ To obtain a dedicated/shared worker agent, given an environment settings object outside settings and a boolean isShared, return the result of obtaining a worker/worklet agent given outside settings, isShared, and true.

`~worklet~agentを得する@ ときは、 所与の ( `環境~設定群~obj$ %外側~設定群 ) に対し,次の結果を返す ⇒ `~worker/~worklet~agentを得する$( %外側~設定群, ~F, ~F ) ◎ To obtain a worklet agent, given an environment settings object outside settings, return the result of obtaining a worker/worklet agent given outside settings, false, and false.

`~sw~agentを得する@ ときは、次の結果を返す ⇒ `~worker/~worklet~agentを得する$( ~NULL, ~T, ~F ) ◎ To obtain a service worker agent, return the result of obtaining a worker/worklet agent given null, true, and false.


次に挙げる大域~objどうしは、 同じ`~agent~cluster$の中にあるので, 互いの~memoryを共有する `SharedArrayBuffer$I ~instanceを利用できる: ◎ The following pairs of global objects are each within the same agent cluster, and thus can use SharedArrayBuffer instances to share memory with each other:

  • `~window$と, それが作成した専用~worker ◎ A Window object and a dedicated worker that it created.
  • ~worker(型は問わない)と, それが作成した専用~worker ◎ A worker (of any type) and a dedicated worker it created.
  • `~window$と, それが作成した `iframe$e 要素の`~window$であって,互いに`同じ生成元~domain$になれるもの ◎ A Window object A and the Window object of an iframe element that A created that could be same origin-domain with A.
  • `~window$と, それを開いた`~window$であって,互いに`同じ生成元~domain$であるもの ◎ A Window object and a same origin-domain Window object that opened it.
  • `~window$と, それが作成した~worklet ◎ A Window object and a worklet that it created.

次に挙げる大域~objどうしは、 同じ`~agent~cluster$の中に`ない^emので,~memoryを共有できない: ◎ The following pairs of global objects are not within the same agent cluster, and thus cannot share memory:

  • `~window$と, それが作成した共用~worker ◎ A Window object and a shared worker it created.
  • ~worker(型は問わない)と, それが作成した共用~worker ◎ A worker (of any type) and a shared worker it created.
  • `~window$と, それが作成した~sw ◎ A Window object and a service worker it created.
  • `~window$と, それが作成した `iframe$e 要素の`~window$であって,互いに`同じ生成元~domain$になれないもの ◎ A Window object A and the Window object of an iframe element that A created that cannot be same origin-domain with A.
  • 次に挙げる関係性は無い 2 つの`~window$ ⇒# 一方が他方を開いた/ 一方が他方の先祖である

    このことは、 それらの`~window$が`同一-生成元$であっても,保持される。

    ◎ Any two Window objects with no opener or ancestor relationship. This holds even if the two Window objects are same origin.

8.1.3. ~realm, それに相応するもの

~JS仕様は、 `~realm$の概念を導入する — それは、 ~scriptを中で走らす大域~環境を表現する。 各~realmには、 `実装定義$な`大域~obj$が伴われる。 この仕様の大半は、 大域~objと その各~propを定義することに割かれている。 ◎ The JavaScript specification introduces the realm concept, representing a global environment in which script is run. Each realm comes with an implementation-defined global object; much of this specification is devoted to defining that global object and its properties.

~web仕様~用には、 値や~algoを ( ~realm / 大域~obj ) が成す~pairに結付けると有用になることが多い。 そのような値は、 特定0の型の~realmに特有であるときは,当の大域~objに直に結付けられる — 例:[ `Window$I / `WorkerGlobalScope$I ]~interfaceの定義~内に。 複数の~realmにまたがる有用性がある値には、 `環境~設定群~obj$の概念が利用する。 ◎ For web specifications, it is often useful to associate values or algorithms with a realm/global object pair. When the values are specific to a particular type of realm, they are associated directly with the global object in question, e.g., in the definition of the Window or WorkerGlobalScope interfaces. When the values have utility across multiple realms, we use the environment settings object concept.

一部の事例では、[ ~realm/大域~obj/環境~設定群~obj ]が存在するようになる前であっても (例えば,`~navi$の間に), 結付けられる値を追跡することが必要yである。 これらの値は、 `環境$の概念にて追跡される。 ◎ Finally, in some cases it is necessary to track associated values before a realm/global object/environment settings object even comes into existence (for example, during navigation). These values are tracked in the environment concept.

8.1.3.1. 環境

`環境@ とは、[ 現在の実行~環境, または そうなり得るもの ]の設定群を識別する~objである (そうなり得るものとは、 すなわち,[ `~navi~params$の`予約-済み環境$nvP / `要請$の`予約-済み~client$rq ]である)。 各 `環境$ %環境 は、 次に挙げるものを有する: ◎ An environment is an object that identifies the settings of a current or potential execution environment (i.e., a navigation params's reserved environment or a request's reserved client). An environment has the following fields:

`~ID@enV ◎ An id
不透明な文字列 — %環境 を一意に識別する。 ◎ An opaque string that uniquely identifies this environment.
`作成時の~URL@enV ◎ A creation URL
`~URL$ — %環境 が結付けられた資源の所在を表現する。 ◎ A URL that represents the location of the resource with which this environment is associated.
注記: %環境 は`環境~設定群~obj$であって,その`大域~obj$enVは`~window$である事例では、 この~URLは,[ 当の`大域~obj$enVに`結付けられた文書$の`~URL$doc ]とは — 後者を改変する `history.pushState()$c などの仕組みに因り — 別物にもなり得ることに注意 ◎ In the case of a Window environment settings object, this URL might be distinct from its global object's associated Document's URL, due to mechanisms such as history.pushState() which modify the latter.
`~top-level作成時の~URL@enV ◎ A top-level creation URL
~NULL / `~URL$ — 後者は、 “~top-level” `環境$の`作成時の~URL$enVを表現する。 [ ~worker/~worklet ]用には ~NULL になる。 ◎ Null or a URL that represents the creation URL of the "top-level" environment. It is null for workers and worklets.
`~top-level生成元@enV ◎ A top-level origin
今の所は`実装定義$な値 / ~NULL / `生成元$ ◎ A for now implementation-defined value, null, or an origin.\
“~top-level” 実行~環境になり得るもの用には ~NULL に (すなわち、まだ応答は無い)/ 他の場合は “~top-level” `環境$の`生成元$enVになる。 [ 専用~worker/~worklet ]用には、 その作成元の`~top-level生成元$enVになる。 [ 共用~worker/~sw ]用には、 `実装定義$な値になる。 ◎ For a "top-level" potential execution environment it is null (i.e., when there is no response yet); otherwise it is the "top-level" environment's origin. For a dedicated worker or worklet it is the top-level origin of its creator. For a shared or service worker it is an implementation-defined value.
注記: これは、[ ~sandbox法/~worker/~worklet ]が孕まれるときは、 `~top-level作成時の~URL$enVの`生成元$urlとは別物になる。 ◎ This is distinct from the top-level creation URL's origin when sandboxing, workers, and worklets are involved.
`~target閲覧~文脈@enV ◎ A target browsing context
~NULL / `~navi要請$用の~targetになる`閲覧~文脈$ ◎ Null or a target browsing context for a navigation request.
`作動中な~sw@enV ◎ An active service worker
~NULL / %環境 を`制御-$xしている`~sw$ ◎ Null or a service worker that controls the environment.
`実行は準備済みか@enV ◎ An execution ready flag
~T ならば、 %環境 はすでに設定しておかれたことを指示する。 初期~時は ~F とする。 ◎ A flag that indicates whether the environment setup is done. It is initially unset.

各~仕様は、 環境~用に `環境を破棄する手続き@ を定義してもヨイ。 この手続きは、 入力として`環境$をとる。 ◎ Specifications may define environment discarding steps for environments. The steps take an environment as input.

注記: `環境を破棄する手続き$が走るのは、 ごく限られた環境に限られる。 決して,実行~準備済みには — 例えば,読込むのに失敗したために — ならないものなど。 ◎ The environment discarding steps are run for only a select few environments: the ones that will never become execution ready because, for example, they failed to load.

8.1.3.2. 環境~設定群~obj

`環境~設定群~obj@ %設定群 とは、 `環境$であることに加え,次に挙げるものを得るための各種~algoも指定するものである: ◎ An environment settings object is an environment that additionally specifies algorithms for:

`~realm実行~文脈@enV ◎ A realm execution context
`~JS実行~文脈$【を返す(以下同様)】 — %設定群 を利用するすべての`~script$xから共有される。 すなわち、 これらの~scriptは,この`~realm$内にある。 [ `古典~scriptを走らす$/`~module~scriptを走らす$ ]ときは、 この実行~文脈が`~JS実行~文脈~stack$の一番上になり,その上に当の~scriptに特有な別の実行~文脈が~pushされる。 (こう設定しておけば、[ `~source~text~module~Record$の `Evaluate$jA ]は,どの~realmを利用するかを知れるようになる。) ◎ A JavaScript execution context shared by all scripts that use this settings object, i.e., all scripts in a given realm. When we run a classic script or run a module script, this execution context becomes the top of the JavaScript execution context stack, on top of which another execution context specific to the script in question is pushed. (This setup ensures Source Text Module Record's Evaluate knows which realm to use.)
`~module~map@enV ◎ A module map
`~module~map$ — ~JS~moduleを~importするときに利用される。 ◎ A module map that is used when importing JavaScript modules.
`~API用~基底~URL@enV ◎ An API base URL
`~URL$ — %設定群 を利用する~scriptから~callされる~APIが`~URLを符号化法の下で相対的に構文解析する$ときに利用される。 ◎ A URL used by APIs called by scripts that use this environment settings object to parse URLs.
`生成元@enV ◎ An origin
`生成元$ — ~security検査に利用される。 ◎ An origin used in security checks.
`施策~容器@enV ◎ A policy container
`施策~容器$ — ~security検査に利用される施策を包含する。 ◎ A policy container containing policies used for security checks.
`非同一-生成元~能力は隔離されるか?@enV ◎ A cross-origin isolated capability
次を表現する真偽値 ⇒ %設定群 を利用する~scriptには、[ 非同一-生成元~隔離を要求する~API ]を利用することは,許容されるかどうか ◎ A boolean representing whether scripts that use this environment settings object are allowed to use APIs that require cross-origin isolation.
`時刻~起点@enV ◎ A time origin
[ 処理能に関係する時刻印 ]用の~~起点として利用される数 `HRT$r ◎ A number used as the baseline for performance-related timestamps. [HRT]

`環境~設定群~obj$の `担当の~event~loop@enV は、 その`大域~obj$enVに`関連な~agent$の`~event~loop$aGとする。 ◎ An environment settings object's responsible event loop is its global object's relevant agent's event loop.

8.1.3.3. ~realm, 設定群~obj, 大域~obj

`大域~obj@ とは、 `~realm$の `GlobalObject^sl ~fieldである~JS~objである。 ◎ A global object is a JavaScript object that is the [[GlobalObject]] field of a realm.

注記: この仕様では、 すべての`~realm$は,`大域~obj$として[ `Window$I, `WorkerGlobalScope$I, `WorkletGlobalScope$I ]いずれかの~objを伴って`作成-@#creating-a-new-javascript-realm$される。 ◎ In this specification, all realms are created with global objects that are either Window, WorkerGlobalScope, or WorkletGlobalScope objects.

各`大域~obj$は、 次に挙げるものを有する: ◎ ↓

  • `~error報告ng~modeか@gL ⇒ 真偽値 — 初期~時は ~F とする。 ◎ A global object has an in error reporting mode boolean, which is initially false.
  • `未決な却下-済み~promiseへの弱い参照たちが成す集合@gL ⇒ `~promise$たちが成す`有順序~集合$ — 初期~時は空とする。 ◎ A global object has an outstanding rejected promises weak set, a set of Promise objects, initially empty.\

    この集合を成す どの~item【!member】に対しても、 それへの強い参照を作成しないモノトスル。 実装は、 この集合の~sizeを`実装定義$な方式で制限してもかまわない — 例: 新たな~itemが追加されたときは,旧い~item【!entry】を除去することにより。 ◎ This set must not create strong references to any of its members, and implementations are free to limit its size in an implementation-defined manner, e.g., by removing old entries from it when new ones are added.

  • `通知待ちな却下-済み~promise~list@gL ⇒ `~promise$たちが成す`~list$ — 初期~時は空とする。 ◎ A global object has an about-to-be-notified rejected promises list, a list of Promise objects, initially empty.
  • `~import~map@gL ⇒ 【ある`~import~map$】 — 初期~時は`空な~import~map$とする。 ◎ A global object has an import map, initially an empty import map.

    注記: 今の所は、[ `大域~obj$の`~import~map$gLが初期~時の空から改変される ]のは,[ 当の~objが `Window$I である場合 ]に限られる。 `~import~map$gLは、 根`~module~script$の解決~用に限り~accessされる。 ◎ For now, only Window global objects have their import map modified from the initial empty one. The import map is only accessed for the resolution of a root module script.

  • `解決-済み~module集合@gL ⇒ `指定子~解決~record$たちが成す`有順序~集合$ — 初期~時は空とする。 ◎ A global object has a resolved module set, a set of specifier resolution records, initially empty.

    注記: `解決-済み~module集合$gLは、 ~module指定子~解決が ( 同じ参照元, 同じ指定子 ) が成す~pairを伴って複数回~callされたときに, 同じ結果を返すことを確保する — `~import~map$を成す規則のうち[ それの参照元の~scopeに入る指定子に影響iするもの ]は[ それ【指定子?】の初期~解決より後には定義され得ない ]ことを確保することにより。 今の所は、[ `大域~obj$の~module集合~data構造が初期~時の空から改変される ]のは,[ 当の~objが `Window$I である場合 ]に限られる。 ◎ The resolved module set ensures that module specifier resolution returns the same result when called multiple times with the same (referrer, specifier) pair. It does that by ensuring that import map rules that impact the specifier in its referrer's scope cannot be defined after its initial resolution. For now, only Window global objects have their module set data structures modified from the initial empty one.


[ `~realm$ %R, `大域~obj$ %G, `環境~設定群~obj$ %S ]は、 常に,互いに 1:1:1 に対応する: ◎ There is always a 1-to-1-to-1 mapping between realms, global objects, and environment settings objects:

  • %R 視点からは:

    • %R の `HostDefined^sl ~fieldが, %S を与える — %S を指して %R の `設定群~obj@rM という。
    • %R の `GlobalObject^sl ~fieldが, %G を与える — %G を指して %R の `大域~obj@rM という。
    ◎ A realm has a [[HostDefined]] field, which contains the realm's settings object. ◎ A realm has a [[GlobalObject]] field, which contains the realm's global object.
  • %G 視点からは:

    • この仕様における %G は、 %R が`作成-@#creating-a-new-javascript-realm$される間に作成される。 %R を指して %G の `~realm@gL という。
    • この仕様における %G は、 %S と並行して作成される。 %S は %G に`関連な設定群~obj$と呼ばれる。
    ◎ Each global object in this specification is created during the creation of a corresponding realm, known as the global object's realm. ◎ Each global object in this specification is created alongside a corresponding environment settings object, known as its relevant settings object.
  • %S 視点からは:

    • %S の`~realm実行~文脈$enVの~Realm成分が, %R を与える — %R を指して %S の `~realm@enV という。
    • %G (すなわち, %S の`~realm$enVの `GlobalObject^sl ~field) を指して %S の `大域~obj@enV という。
    ◎ An environment settings object's realm execution context's Realm component is the environment settings object's realm. ◎ An environment settings object's realm then has a [[GlobalObject]] field, which contains the environment settings object's global object.

`~agent$ %~agent 内で `新たな~realmを作成する@ ときは、 次の手続きに従う: ◎ To create a new realm in an agent agent,\

  1. この手続きには、 次に挙げる指示書きも,それぞれ任意選択で供される ⇒# 大域~objを作成する / 利用する大域 `this^jv 束縛 ◎ optionally with instructions to create a global object or a global this binding (or both), the following steps are taken:

    この指示書きにより~custom化する下で, `InitializeHostDefinedRealm$jA() を遂行する ◎ Perform InitializeHostDefinedRealm() with the provided customizations for creating the global object and the global this binding.

  2. %~realm実行~文脈 ~LET `走っている~JS実行~文脈$ ◎ Let realm execution context be the running JavaScript execution context.

    注記: これは、 前~段で作成された`~JS実行~文脈$になる。 ◎ This is the JavaScript execution context created in the previous step.

  3. `~JS実行~文脈~stack$から %~realm実行~文脈 を除去する ◎ Remove realm execution context from the JavaScript execution context stack.
  4. %~realm ~LET %~realm実行~文脈 の~Realm成分 ◎ Let realm be realm execution context's Realm component.
  5. ~IF[ %~agent の`~agent~cluster$の`非同一-生成元~隔離~mode$agC ~EQ `none$l ]: ◎ If agent's agent cluster's cross-origin isolation mode is "none", then:

    1. %大域~obj ~LET %~realm の`大域~obj$rM ◎ Let global be realm's global object.
    2. %状態s ~LET ~NOABRUPT %大域~obj .`Delete^sl( `SharedArrayBuffer^l ) ◎ Let status be ! global.[[Delete]]("SharedArrayBuffer").
    3. ~Assert: %状態s ~EQ ~T ◎ Assert: status is true.

    注記: これは,~web内容との互換性を得るために行われるが、 将来には除去できる希望もある。 ~web開発者は,依然として、 次を通して構築子を入手できる ⇒ `new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor^c ◎ This is done for compatibility with web content and there is some hope that this can be removed in the future. Web developers can still get at the constructor through new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor.

  6. ~RET %~realm実行~文脈 ◎ Return realm execution context.

この仕様~全体を通して、 ~algoを成す手続きを定義するときに,どの`~realm$が利用されるか — あるいは,同じことだが、 どの[ `大域~obj$/`環境~設定群~obj$ ]が利用されるか — を指示することが重要になることは多い。 一般に、 少なくとも次に挙げる 4 種いずれかで指示される: ◎ When defining algorithm steps throughout this specification, it is often important to indicate what realm is to be used—or, equivalently, what global object or environment settings object is to be used. In general, there are at least four possibilities:

`入口~某@ ( `entry^en 某) ◎ Entry
これは、 現在~走っている~script動作を起動した~scriptに対応する 【もしあれば】 — すなわち、[ 作者~codeの中へ~callした~UA ]の中へ~callした[ 関数/~script ]。 ◎ This corresponds to the script that initiated the currently running script action: i.e., the function or script that the user agent called into when it called into author code.
`現任な某@ ( `incumbent^en 某) ◎ Incumbent

これは、 作者による[ 関数/~script ]のうち,次のいずれかに該当するものに対応する:

  • ~stack上で最も近過去に入ったもの
  • 現在~走っている~callbackを 元々~scheduleしたもの
◎ This corresponds to the most-recently-entered author function or script on the stack, or the author function or script that originally scheduled the currently-running callback.
`現在の某@ ( `current^en 某) ◎ Current
これは、 現在~走っている関数~objに対応する。 これには、 ~UAに組込みの — ~JSとして実装されていないかもしれない — 関数も含まれる。 (それは`現在の~realm$から導出される。) ◎ This corresponds to the currently-running function object, including built-in user-agent functions which might not be implemented as JavaScript. (It is derived from the current realm.)
`某に関連な@ (某に `relevant^en な) ◎ Relevant
どの`~platform~obj$にも`関連な~realm$がある — それは概ね,当の~objの作成-元である`~realm$である。 ~algoを書くときに,[ `関連な~realm$が重要になり得る`~platform~obj$ ]として真っ先に挙がるのは、[ 現在~走っている関数~objの `this^jv 値 ]になる。 一部の事例では、 他にも`関連な~realm$が重要になるものがあり得る — 引数のそれなど。 ◎ Every platform object has a relevant realm, which is roughly the realm in which it was created. When writing algorithms, the most prominent platform object whose relevant realm might be important is the this value of the currently-running function object. In some cases, there can be other important relevant realms, such as those of any arguments.

[ `入口~某$ / `現任な某$ / `現在の某$ ]の概念は,限定句なしに利用-可能な一方で、 `某に関連な$の概念は,特定0の`~platform~obj$に適用されなければナラナイことに注意。 ◎ Note how the entry, incumbent, and current concepts are usable without qualification, whereas the relevant concept must be applied to a particular platform object.

`現任な某$, `入口~某$ の概念は、 あまりに複雑で直感的でないので,新たな仕様には利用されるべきでない。 既存の利用は,~platformからほぼ除去すべく~~策定が進められている。 [ `現任な某$については`課題 #1430@~HTMLissue/1430$/ `入口~某$については`課題 #1431@~HTMLissue/1431$ ]を見よ。 ◎ The incumbent and entry concepts should not be used by new specifications, as they are excessively complicated and unintuitive to work with. We are working to remove almost all existing uses from the platform: see issue #1430 for incumbent, and issue #1431 for entry.

一般に,~web~platform仕様は、 `某に関連な$の概念を,演算-対象の~obj (通例的には現在の~methodの `this^jv 値になる) に適用して利用するべきである。 これは、 ~JS仕様と合致していない — そこでは、 一般に,`現在の某$が既定として利用されている (例: [ `Array.prototype.map^c の結果を構築する際に利用されるべき `Array^c 構築子 ]が属する`~realm$を決定するときなど)。 が,この不一致は、 策定を進めるためには受容する必要があるものとして,~platformに埋込まれている。 ◎ In general, web platform specifications should use the relevant concept, applied to the object being operated on (usually the this value of the current method). This mismatches the JavaScript specification, where current is generally used as the default (e.g., in determining the realm whose Array constructor should be used to construct the result in Array.prototype.map). But this inconsistency is so embedded in the platform that we have to accept it going forward.

次の各~pageを考える。 ここでは、 `a.html^s は~browser~window内に読込まれていて, `b.html^s は 示されるとおり `iframe$e 内に読込まれていて, `c.html^s, `d.html^s は省略されている (単純に,空~文書でもよい) とする: ◎ Consider the following pages, with a.html being loaded in a browser window, b.html being loaded in an iframe as shown, and c.html and d.html omitted (they can simply be empty documents):

<!-- a.html -->
<!DOCTYPE html>
<html lang="ja">
<title>入口~page</title>

<iframe src="b.html"></iframe>
<button onclick="frames[0].hello()">Hello</button>

<!--b.html -->
<!DOCTYPE html>
<html lang="ja">
<title>現任な~page</title>

<iframe src="c.html" id="c"></iframe>
<iframe src="d.html" id="d"></iframe>

<script>
  const %c = document.querySelector("#c").contentWindow;
  const %d = document.querySelector("#d").contentWindow;

  window.hello = () => {
    %c.print.call(%d);
  };
</script>

各~pageは、 自前の`閲覧~文脈$を有する — したがって、自前の[ `~realm$, `大域~obj$, `環境~設定群~obj$ ]を有する。 ◎ Each page has its own browsing context, and thus its own realm, global object, and environment settings object.

`a.html^s 内の~buttonの押下げに呼応して `print()$m ~methodが~callされたときは: ◎ When the print() method is called in response to pressing the button in a.html, then:

  • `入口~realm$は、 `a.html^s のそれになる。 ◎ The entry realm is that of a.html.
  • `現任な~realm$は、 `b.html^s のそれになる。 ◎ The incumbent realm is that of b.html.
  • `現在の~realm$は、 `c.html^s のそれになる (走っている~codeは、 `c.html^s に属する `print()$m ~methodなので)。 ◎ The current realm is that of c.html (since it is the print() method from c.html whose code is running).
  • `print()$m ~methodが~callされている~objに`関連な~realm$は、 `d.html^s のそれになる。 ◎ The relevant realm of the object on which the print() method is being called is that of d.html.

`某に関連な$の概念が,`現在の某$の概念よりも一般に良い既定になる理由の一つは、 複数回にわたり返されるような持続的な~objを作成するときに,その方が相応しくなるからである。 例えば `getBattery()$m ~method `BATTERY$r は、 それが呼出された `Navigator$I ~objに`関連な~realm$内に~promiseを作成する。 これは、 次に影響iする: ◎ One reason why the relevant concept is generally a better default choice than the current concept is that it is more suitable for creating an object that is to be persisted and returned multiple times. For example, the navigator.getBattery() method creates promises in the relevant realm for the Navigator object on which it is invoked. This has the following impact: [BATTERY]

<!-- outer.html -->
<!DOCTYPE html>
<html lang="ja">
<title>関連な~realmのデモ: outer ~page</title>
<script>
  function doTest() {
    const %promise = navigator.getBattery.call(frames[0].navigator);

    console.log(%promise instanceof Promise);           // logs false
    console.log(%promise instanceof frames[0].Promise); // logs true

    frames[0].hello();
  }
</script>
<iframe src="inner.html" onload="doTest()"></iframe>

<!-- inner.html -->
<!DOCTYPE html>
<html lang="ja">
<title>関連な~realmのデモ: inner ~page</title>
<script>
  function hello() {
    const %promise = navigator.getBattery();

    console.log(%promise instanceof Promise);        // logs true
    console.log(%promise instanceof parent.Promise); // logs false
  }
</script>

`getBattery()$m ~methodの~algoが,代わりに`現在の~realm$を利用した場合、 すべての結果が覆されることになる。 すなわち、 `outer.html^s 内の `getBattery()$m に対する最初の~callの後、 `inner.html^s 内の `Navigator$I ~objは, `outer.html^s の`~realm$にて作成された `Promise^jc ~objを恒久的に格納することになる結果、 `hello()^c 関数の内側における同様の~callは, “間違った” ~realmからの~promiseを返すことになる。 これは望ましくないので、 ~algoは,[ 上の~commentで指示されるような~~分別のある結果を与える,`関連な~realm$ ]を代わりに利用する。 ◎ If the algorithm for the getBattery() method had instead used the current realm, all the results would be reversed. That is, after the first call to getBattery() in outer.html, the Navigator object in inner.html would be permanently storing a Promise object created in outer.html's realm, and calls like that inside the hello() function would thus return a promise from the "wrong" realm. Since this is undesirable, the algorithm instead uses the relevant realm, giving the sensible results indicated in the comments above.


この節の以降では、 次に挙げる概念について,正式に定義する ⇒# `入口~某$, `現任な某$, `現在の某$, `某に関連な$ ◎ The rest of this section deals with formally defining the entry, incumbent, current, and relevant concepts.

8.1.3.3.1. 入口~某

`~scriptを~callする処理n@#calling-scripts$は、 `~realm実行~文脈$enVを`~JS実行~文脈~stack$に — 他の`~JS実行~文脈$の合間に挟みながら — [ ~push/~pop ]することになる。 ◎ The process of calling scripts will push or pop realm execution contexts onto the JavaScript execution context stack, interspersed with other execution contexts.

これをもって, `入口~実行~文脈@ は、 `~JS実行~文脈~stack$内の~itemのうち, 最も近過去に~pushされた`~realm実行~文脈$enVとして定義される。 `入口~realm@ は、 `入口~実行~文脈$の~Realm成分で与えられる。 ◎ With this in hand, we define the entry execution context to be the most recently pushed item in the JavaScript execution context stack that is a realm execution context. The entry realm is the entry execution context's Realm component.

これにより、 次も定義される: ◎ ↓

  • `入口~設定群~obj@ は、 `入口~realm$の`設定群~obj$rMである。 ◎ Then, the entry settings object is the environment settings object of the entry realm.
  • `入口~大域~obj@ は、 `入口~realm$の`大域~obj$rMである。 ◎ Similarly, the entry global object is the global object of the entry realm.
8.1.3.3.2. 現任な某

各`~JS実行~文脈$は、 自身の~code評価~状態を成す一部として, `現任な某の決定-時に飛ばす~counter@ 値 — 初期~時は 0 とする — を包含するモノトスル。 この値は、[ `~callbackを走らすために準備する$ / `走らせた~callbackを片付ける$ ]処理nにおいて,増減されることになる。 ◎ All JavaScript execution contexts must contain, as part of their code evaluation state, a skip-when-determining-incumbent counter value, which is initially zero. In the process of preparing to run a callback and cleaning up after running a callback, this value will be incremented and decremented.

どの`~event~loop$にも, `予備の現任な設定群~obj~stack@ が結付けられ、 初期~時は空にされる。 それは 大雑把に言えば、[ ~stack上に作者~codeは無いが、 走らされた現在の~algoは,作者~codeが 何らかの仕方で担当している ]ときに,`現任な設定群~obj$を決定するために利用される。 この~stackは,[ `~callbackを走らすために準備する$ / `走らせた~callbackを片付ける$ ]処理nから操作される。 `WEBIDL$r ◎ Every event loop has an associated backup incumbent settings object stack, initially empty. Roughly speaking, it is used to determine the incumbent settings object when no author code is on the stack, but author code is responsible for the current algorithm having been run in some way. The process of preparing to run a callback and cleaning up after running a callback manipulate this stack. [WEBIDL]

[ ~Web~IDLを利用して 作者~codeを`呼出す$x / `HostEnqueuePromiseJob$A が~promise~jobを呼出す ]とき、 それは,以下に与える各種~algoを利用して[ `現任な設定群~obj$を決定するための関連な~data ]を追跡する: ◎ When Web IDL is used to invoke author code, or when HostEnqueuePromiseJob invokes a promise job, they use the following algorithms to track relevant data for determining the incumbent settings object:

`~callbackを走らすために準備する@ ときは、 所与の ( `環境~設定群~obj$ %設定群 ) に対し,次を走らす: ◎ To prepare to run a callback with an environment settings object settings:

  1. `予備の現任な設定群~obj~stack$に %設定群 を~pushする ◎ Push settings onto the backup incumbent settings object stack.
  2. %文脈 ~LET `最上端の~scriptを有する実行~文脈$ ◎ Let context be the topmost script-having execution context.
  3. ~IF[ %文脈 ~NEQ ~NULL ] ⇒ %文脈 の`現任な某の決定-時に飛ばす~counter$ ~INCBY 1 ◎ If context is not null, increment context's skip-when-determining-incumbent counter.

`走らせた~callbackを片付ける@ ときは、 所与の ( `環境~設定群~obj$ %設定群 ) に対し,次に従う: ◎ To clean up after running a callback with an environment settings object settings:

  1. %文脈 ~LET `最上端の~scriptを有する実行~文脈$ ◎ Let context be the topmost script-having execution context.

    注記: これは、 この手続きの呼出nと対にされた[ `~callbackを走らすために準備する$呼出n ]の内側の,`最上端の~scriptを有する実行~文脈$と同じになる。 ◎ This will be the same as the topmost script-having execution context inside the corresponding invocation of prepare to run a callback.

  2. ~IF[ %文脈 ~NEQ ~NULL ] ⇒ %文脈 の`現任な某の決定-時に飛ばす~counter$ ~DECBY 1 ◎ If context is not null, decrement context's skip-when-determining-incumbent counter.
  3. ~Assert: `予備の現任な設定群~obj~stack$の最上端の~entry ~EQ %設定群 ◎ Assert: the topmost entry of the backup incumbent settings object stack is settings.
  4. `予備の現任な設定群~obj~stack$から %設定群 を除去する ◎ Remove settings from the backup incumbent settings object stack.

`最上端の~scriptを有する実行~文脈@ は、 `~JS実行~文脈~stack$内に[ 次を満たす~entry ]は[ 在るならば,それらのうち当の~stack内で最上端にあるもの/ 無いならば ~NULL ]とする ⇒ 当の~entryの~ScriptOrModule成分 ~NEQ ~NULL ◎ Here, the topmost script-having execution context is the topmost entry of the JavaScript execution context stack that has a non-null ScriptOrModule component, or null if there is no such entry in the JavaScript execution context stack.

以上をふまえた下で, `現任な設定群~obj@ は、 次に従って決定される: ◎ With all this in place, the incumbent settings object is determined as follows:

  1. %文脈 ~LET `最上端の~scriptを有する実行~文脈$ ◎ Let context be the topmost script-having execution context.
  2. ~IF[ %文脈 ~EQ ~NULL ]~OR[ %文脈 の`現任な某の決定-時に飛ばす~counter$ ~GT 0 ]: ◎ If context is null, or if context's skip-when-determining-incumbent counter is greater than zero, then:

    1. ~Assert: `予備の現任な設定群~obj~stack$は空でない ◎ Assert: the backup incumbent settings object stack is not empty.

      注記: この ~Assert は、[[ `~scriptを~callする@#calling-scripts$ / ~Web~IDLにより ~callbackを`呼出す$x ]ことにより誘発されたものではない~algo ]の内側から`現任な設定群~obj$を得するよう試行したときには,失敗することになる。 例えば、[ `~event~loop$の一部として定期的に走る~algoであって,作者~codeは孕まれていないもの ]が,それを試行したときなど。 そのような事例では、 `現任な某$ の概念は利用できない。 ◎ This assert would fail if you try to obtain the incumbent settings object from inside an algorithm that was triggered neither by calling scripts nor by Web IDL invoking a callback. For example, it would trigger if you tried to obtain the incumbent settings object inside an algorithm that ran periodically as part of the event loop, with no involvement of author code. In such cases the incumbent concept cannot be used.

    2. ~RET `予備の現任な設定群~obj~stack$の最上端の~entry ◎ Return the topmost entry of the backup incumbent settings object stack.
  3. ~RET %文脈 の~Realm成分の`設定群~obj$rM ◎ Return context's Realm component's settings object.

以上により、 次も定義される: ◎ ↓

  • `現任な~realm@ は、 `現任な設定群~obj$の`~realm$enVである。 ◎ Then, the incumbent realm is the realm of the incumbent settings object.
  • `現任な大域~obj@ は、 `現任な設定群~obj$の`大域~obj$enVである。 ◎ Similarly, the incumbent global object is the global object of the incumbent settings object.

以下に示す一連の例は、[ 各種 仕組みが `現任な某$ の概念の定義にどう関わるか ]を明瞭にすることが意図される: ◎ The following series of examples is intended to make it clear how all of the different mechanisms contribute to the definition of the incumbent concept:

手始めに,次の例を考える: ◎ Consider the following starter example:

<!DOCTYPE html>
<iframe></iframe>
<script>
  frames[0].postMessage("some data", "*");
</script>

ここで,注目する`環境~設定群~obj$には、[ `window^c のそれ, `frames[0]^c のそれ ]の 2 つがある。 ここでの懸案は、 `postMessage()$m 用の~algoを実行する時点で,何が`現任な設定群~obj$になるか? である。 ◎ There are two interesting environment settings objects here: that of window, and that of frames[0]. Our concern is: what is the incumbent settings object at the time that the algorithm for postMessage() executes?

その~algoを起こした担当の作者~scriptは, `frames[0]^c ではなく `window^c 内で実行されているので、 直感的に捉えるなら,`window^c のそれになるべきである。 これはイミを成す: `~windowに~messageを投函する手続き$は、 `現任な設定群~obj$を利用して,結果の `MessageEvent$I の `source$m ~propを決定する — この事例では、 当の~messageの~sourceは,確かに `window^c になる。 ◎ It should be that of window, to capture the intuitive notion that the author script responsible for causing the algorithm to happen is executing in window, not frames[0]. This makes sense: the window post message steps use the incumbent settings object to determine the source property of the resulting MessageEvent, and in this case window is definitely the source of the message.

上で与えた手続きが、 直感的に欲される結果として, `window^c に`関連な設定群~obj$をどう与えてくれるかを以下に説明する。 ◎ Let us now explain how the steps given above give us our intuitively-desired result of window's relevant settings object.

`~windowに~messageを投函する手続き$が`現任な設定群~obj$を検索するとき、 `最上端の~scriptを有する実行~文脈$は, `script$e 要素に対応している それになる。 それは、 `古典~scriptを走らす$~algoの間に, `ScriptEvaluation$jA() の一部として,`~JS実行~文脈~stack$に~pushされたものである。 ~Web~IDL~callbackの呼出nは孕まれないので、 この文脈の`現任な某の決定-時に飛ばす~counter$は 0 であり、 したがってそれが,`現任な設定群~obj$を決定するために利用される。 その結果は、 `window^c の`環境~設定群~obj$になる。 ◎ When the window post message steps look up the incumbent settings object, the topmost script-having execution context will be that corresponding to the script element: it was pushed onto the JavaScript execution context stack as part of ScriptEvaluation during the run a classic script algorithm. Since there are no Web IDL callback invocations involved, the context's skip-when-determining-incumbent counter is zero, so it is used to determine the incumbent settings object; the result is the environment settings object of window.

( `frames[0]^c の`環境~設定群~obj$は, `postMessage()$m ~methodが~callされた時点でコレに`関連な設定群~obj$になるので、 ~messageの`宛先^emを決定するときには,それが孕まれることに注意。 その一方,`~source^emを決定するときには、 現任な某が利用される。) ◎ (Note how the environment settings object of frames[0] is the relevant settings object of this at the time the postMessage() method is called, and thus is involved in determining the target of the message. Whereas the incumbent is used to determine the source.)

次に、 もっと複雑な例を考える: ◎ Consider the following more complicated example:

<!DOCTYPE html>
<iframe></iframe>
<script>
  const %bound = frames[0].postMessage.bind(frames[0], "some data", "*");
  window.setTimeout(%bound);
</script>

この例は,前の例によく似るが、 `Function.prototype.bind^c を通して間接-化され, `setTimeout()$m も伴う。 それでも,答えは同じになるべきである — `現任な某$の概念は、 非同期な~algoの呼出ngにより変化するべきでない。 ◎ This example is very similar to the previous one, but with an extra indirection through Function.prototype.bind as well as setTimeout(). But, the answer should be the same: invoking algorithms asynchronously should not change the incumbent concept.

今回の結果は、 より複雑な仕組みを孕む: ◎ This time, the result involves more complicated mechanisms:

%bound が ~Web~IDL~callback型に`変換-$xされるとき、 `現任な設定群~obj$は, (上の手始めの例と同じ方式で) `window^c に対応しているそれになる。 ~Web~IDLは、 これを,結果の~callback値の`~callback文脈$として格納する。 ◎ When bound is converted to a Web IDL callback type, the incumbent settings object is that corresponding to window (in the same manner as in our starter example above). Web IDL stores this as the resulting callback value's callback context.

`setTimeout()$m により~postされた`~task$が実行されるとき、 その~task用の~algoは,~Web~IDLを利用して 格納された~callback値を`呼出す$x。 それに応じて、 ~Web~IDLは,上述した[ `~callbackを走らすために準備する$ ]~algoを~callする。 これは、 格納された`~callback文脈$を,`予備の現任な設定群~obj~stack$に~pushする。 この時点(~timer~taskの内側)では,その~stack上には作者~codeは無いので、 `最上端の~scriptを有する実行~文脈$は ~NULL であり,`現任な某の決定-時に飛ばす~counter$は増やされない。 ◎ When the task posted by setTimeout() executes, the algorithm for that task uses Web IDL to invoke the stored callback value. Web IDL in turn calls the above prepare to run a callback algorithm. This pushes the stored callback context onto the backup incumbent settings object stack. At this time (inside the timer task) there is no author code on the stack, so the topmost script-having execution context is null, and nothing gets its skip-when-determining-incumbent counter incremented.

次に、 ~callbackの呼出ngは, %bound を~callする。 それに応じて、 `frames[0]^c の `postMessage()$m ~methodが~callされる。 `postMessage()$m ~algoが`現任な設定群~obj$を検索するとき,~stack上にはまだ作者~codeはない — `bound()^c 関数は、 単に組込みの~methodを直に~callするだけなので。 よって、 `最上端の~scriptを有する実行~文脈$は ~NULL になる: `~JS実行~文脈$ ~stackは、 `postMessage()$m に対応している実行~文脈 — それも,[ `ScriptEvaluation$jA 文脈や,それに類するもの ]を伴わないもの — のみを包含する。 ◎ Invoking the callback then calls bound, which in turn calls the postMessage() method of frames[0]. When the postMessage() algorithm looks up the incumbent settings object, there is still no author code on the stack, since the bound function just directly calls the built-in method. So the topmost script-having execution context will be null: the JavaScript execution context stack only contains an execution context corresponding to postMessage(), with no ScriptEvaluation context or similar below it.

`予備の現任な設定群~obj~stack$に~fall-backするのは、 ここである。 上で注記したとおり、 この~stackは,最上端の~entryとして `window^c に`関連な設定群~obj$を包含することになる。 よって、 それが `postMessage()$m ~algoを実行している間に`現任な設定群~obj$として利用されるものになる。 ◎ This is where we fall back to the backup incumbent settings object stack. As noted above, it will contain as its topmost entry the relevant settings object of window. So that is what is used as the incumbent settings object while executing the postMessage() algorithm.

~~最後に、 もっと込み入った例を考える: ◎ Consider this final, even more convoluted example:

<!-- a.html -->
<!DOCTYPE html>
<button>click me</button>
<iframe></iframe>
<script>
const %bound = frames[0].location.assign.bind(
    frames[0].location,
    "https://example.com/"
);
document.querySelector("button").addEventListener("click", %bound);
</script>
<!-- b.html -->
<!DOCTYPE html>
<iframe src="a.html"></iframe>
<script>
  const %iframe = document.querySelector("iframe");
  %iframe.onload = function onLoad() {
    %iframe.contentWindow.document.querySelector("button").click();
  };
</script>

ここでも,注目する`環境~設定群~obj$には、[ `a.html^c のそれ, `b.html^c のそれ ]の 2 つがある。 `assign()$m ~methodが`~Location~objにより~navigate$する~algoを誘発するとき、 何が`現任な設定群~obj$になるか? それは、 前のように直感的には, `a.html^c のそれになるべきである: `click$et ~listenerは,元々は `a.html^c により~scheduleされたので、 `b.html^c を孕んでいる何かが その~listenerを発火させたとしても, `現任な某$が担当するのは `a.html^c のそれになる。 ◎ Again there are two interesting environment settings objects in play: that of a.html, and that of b.html. When the location.assign() method triggers the Location-object navigate algorithm, what will be the incumbent settings object? As before, it should intuitively be that of a.html: the click listener was originally scheduled by a.html, so even if something involving b.html causes the listener to fire, the incumbent responsible is that of a.html.

ここでの~callbackに対する~~設定は、 前の例に類似する: %bound が ~Web~IDL~callback型に`変換-$xされるとき、 `現任な設定群~obj$は, `a.html^c に対応しているそれになり、 ~callbackの`~callback文脈$に格納される。 ◎ The callback setup is similar to the previous example: when bound is converted to a Web IDL callback type, the incumbent settings object is that corresponding to a.html, which is stored as the callback's callback context.

`b.html^c の内側で `click$m ~methodが~callされたとき、 ~methodは, `a.html^c の内側にある~buttonへ向けて `click$et ~eventを`配送-$する。 この~event配送-の一部として,`~callbackを走らすために準備する$~algoが実行される時点では、 ~stack上には作者~codeが`ある^em。 `最上端の~scriptを有する実行~文脈$は、 `onLoad()^c 関数のそれであり,その`現任な某の決定-時に飛ばす~counter$は 増やされる。 加えて、 `a.html^c の`環境~設定群~obj$ ( `EventHandler$I の`~callback文脈$として格納されている) が,`予備の現任な設定群~obj~stack$に~pushされる。 ◎ When the click() method is called inside b.html, it dispatches a click event on the button that is inside a.html. This time, when the prepare to run a callback algorithm executes as part of event dispatch, there is author code on the stack; the topmost script-having execution context is that of the onLoad function, whose skip-when-determining-incumbent counter gets incremented. Additionally, a.html's environment settings object (stored as the EventHandler's callback context) is pushed onto the backup incumbent settings object stack.

この時点で[ `~Location~objにより~navigate$する~algoが`現任な設定群~obj$を検索する ]ときの,`最上端の~scriptを有する実行~文脈$は、 依然として `onLoad^c 関数 のそれである ( `bound()^c 関数を~callbackとして利用している事実に因る)。 しかしながら,その`現任な某の決定-時に飛ばす~counter$ 値は 1 なので、 `予備の現任な設定群~obj~stack$に~fall-backする。 これは、 期待されるように `a.html^c の`環境~設定群~obj$を与えてくれる。 ◎ Now, when the Location-object navigate algorithm looks up the incumbent settings object, the topmost script-having execution context is still that of the onLoad function (due to the fact we are using a bound function as the callback). Its skip-when-determining-incumbent counter value is one, however, so we fall back to the backup incumbent settings object stack. This gives us the environment settings object of a.html, as expected.

これは、 ~navigateするのは `a.html^c の内側の `iframe$e であっても, ~source`文書$として利用されるのは `a.html^c 自身であることを意味することに注意。 それが、 `要請~client$rqを決定する。 たぶんこれが、 `~web~platform上で,現任な某の概念の利用を正当化できる唯一のものである@https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603#c36$。 他のすべての事例における その概念の利用は,単に~~理解を難しくするだけであり、 いつの日か[ `現在の某$ / `某に関連な$ ]のうち適切な方を利用するよう切替えられるものと希望されている。 ◎ Note that this means that even though it is the iframe inside a.html that navigates, it is a.html itself that is used as the source Document, which determines among other things the request client. This is perhaps the only justifiable use of the incumbent concept on the web platform; in all other cases the consequences of using it are simply confusing and we hope to one day switch them to use current or relevant as appropriate.

8.1.3.3.3. 現在の某

~JS仕様は、 `現在の~realm$を定義している — “現在の~Realm~Record” としても知られる。 `JAVASCRIPT$r ◎ The JavaScript specification defines the current realm, also known as the "current Realm Record". [JAVASCRIPT]

これにより、 次も定義される: ◎ ↓

  • `現在の設定群~obj@ は、 `現在の~realm$の`設定群~obj$rMである。 ◎ Then, the current settings object is the environment settings object of the current realm.
  • `現在の大域~obj@ は、 `現在の~realm$の`大域~obj$rMである。 ◎ Similarly, the current global object is the global object of the current realm.
8.1.3.3.4. 某に関連な

所与の`~platform~obj$ %O に対し: ◎ ↓

  • %O に `関連な~realm@ は、 %O の `Realm$sl ~fieldの値で与えられる。 ◎ The relevant realm for a platform object is the value of its [[Realm]] field.
  • %O に `関連な設定群~obj@ は、 %O に`関連な~realm$の`設定群~obj$rMを指す。 ◎ Then, the relevant settings object for a platform object o is the environment settings object of the relevant realm for o.
  • %O に `関連な大域~obj@ は、 %O に`関連な~realm$の`大域~obj$rMを指す。 ◎ Similarly, the relevant global object for a platform object o is the global object of the relevant realm for o.
8.1.3.4. ~scriptingの可能化-法と不能化-法

所与の時点で,`環境~設定群~obj$ %設定群 用の `~scriptingは可能化されて@stt いるとは、 ~AND↓ が満たされることをいう: ◎ Scripting is enabled for an environment settings object settings when all of the following conditions are true:

  • ~UAは~scriptingを~supportする。 ◎ The user agent supports scripting.
  • ◎追跡路 この時点で、 利用者は, %設定群 用の~scriptingを不能化していない。 (~UAは、 利用者に~scriptingを ~~全面的に, あるいは~~細部的に — 例えば,生成元ごとに, 個々の`環境~設定群~obj$の~levelまで降りて — 不能化する選択肢を供してもヨイ。) ◎ (This is a tracking vector.) The user has not disabled scripting for settings at this time. (User agents may provide users with the option to disable scripting globally, or in a finer-grained manner, e.g., on a per-origin basis, down to the level of individual environment settings objects.)
  • [ %設定群 の`大域~obj$enVは`~window$でない ]~OR[ `閲覧~文脈~sandbox化( ~script )~flag$ ~NIN [ %設定群 の`大域~obj$enVに`結付けられた文書$の`作動中な~sandbox法~flag集合$ ] ◎ Either settings's global object is not a Window object, or settings's global object's associated Document's active sandboxing flag set does not have its sandboxed scripts browsing context flag set.

`環境~設定群~obj$用の `~scriptingは不能化されて@stt いるとは、 `~scriptingは可能化されて$sttいないことをいう。 ◎ Scripting is disabled for an environment settings object when scripting is not enabled for it, i.e., when any of the above conditions are false.


所与の~node %~node 用の `~scriptingは可能化されて@ いるとは、 ~AND↓ が満たされることをいう:

  • %~node の`~node文書$が`属する閲覧~文脈$ ~NEQ ~NULL
  • %~node に`関連な設定群~obj$用の`~scriptingは可能化されて$sttいる
◎ Scripting is enabled for a node node if node's node document's browsing context is non-null, and scripting is enabled for node's relevant settings object.

所与の~node %~node 用の `~scriptingは不能化されて@ いるとは、 %~node 用の`~scriptingは可能化されて$いないことをいう。 ◎ Scripting is disabled for a node when scripting is not enabled, i.e., when its node document's browsing context is null or when scripting is disabled for its relevant settings object.

8.1.3.5. ~secureな文脈

所与の`環境$ %環境 は、 次の~algoが ~T を返すとき,そのときに限り, `~secureな文脈@enV ( `secure context^en )であるとされる: ◎ An environment environment is a secure context if the following algorithm returns true:

  1. ~IF[ %環境 は`環境~設定群~obj$である ]: ◎ If environment is an environment settings object, then:

    1. %大域~obj ~LET %環境 の`大域~obj$enV ◎ Let global be environment's global object.
    2. ~IF[ %大域~obj は `WorkerGlobalScope$I である ] ⇒ ~RET ~IS[ %大域~obj の`所有者~集合$[ 0 ] に`関連な設定群~obj$は`~secureな文脈$enVである ]

      注記: `所有者~集合$は、 最初の~item以外を検査する必要はない — それらすべてが一貫することが必要とされているので。

      ◎ If global is a WorkerGlobalScope, then: • If global's owner set[0]'s relevant settings object is a secure context, then return true. • We only need to check the 0th item since they will necessarily all be consistent. • Return false.
    3. ~IF[ %大域~obj は `WorkletGlobalScope$I である ] ⇒ ~RET ~T ◎ If global is a WorkletGlobalScope, then return true.

      注記: ~workletを作成できるのは、 ~secureな文脈~内に限られる。 ◎ Worklets can only be created in secure contexts.

  2. ~RET ~IS[ 次の結果 ~EQ `価し得る^i ] ⇒ `~URLは信用に価し得るか?$( %環境 の`~top-level作成時の~URL$enV ) ◎ If the result of Is url potentially trustworthy? given environment's top-level creation URL is "Potentially Trustworthy", then return true. ◎ Return false.

`~secureな文脈$enVでない`環境$は、 `~secureでない文脈@enV ( `non-secure context^en )であるとされる。 【この訳では、この用語は利用せず,単に “`~secureな文脈$enVでない” と記すことにする。】 ◎ An environment is a non-secure context if it is not a secure context.

【 `~secureな文脈$enVの意味論や具体例その他は、 `SECURE-CONTEXTS$r に見出せる。 】

8.1.4. ~script処理~model

8.1.4.1. ~script

`~script@ は、 2 種の`構造体$ — `古典~script$ / `~module~script$ — に大別される。 いずれにせよ、 各~scriptは次に挙げる`~item$sctを有する: ◎ A script is one of two possible structs (namely, a classic script or a module script). All scripts have:

【 これらの~itemのうち一部は、 明示的に設定されない場合もある (利用されない場合など) — その場合、 暗黙的に ~NULL に設定される。 】

`設定群~obj@sC ◎ A settings object
`環境~設定群~obj$ — 同じ文脈に属する他の~scriptと共有されるような,種々の設定を包含する。 ◎ An environment settings object, containing various settings that are shared with other scripts in the same context.
`~record@sC ◎ A record

次に挙げるいずれか: ◎ One of the following:

  • `~script~Record$ — `古典~script$用 ◎ a script record, for classic scripts;
  • `~source~text~module~Record$ — `~JS~module~script$用 ◎ a Source Text Module Record, for JavaScript module scripts;
  • `合成な~module~Record$ — [ `~CSS~module~script$/`~JSON~module~script$ ]用 ◎ a Synthetic Module Record, for CSS module scripts and JSON module scripts
  • `~WebAssembly~module~Record$ — `~WebAssembly~module~script$用 ◎ a WebAssembly Module Record, for WebAssembly module scripts; or
  • ~NULL — 構文解析に失敗したことを表現する ◎ null, representing a parsing failure.
`構文解析-~error@sC ◎ A parse error
~JS値。 意味があるのは、 `~record$sC ~EQ ~NULL の場合に限られ、 対応する~script~source~textを構文解析できなかったことを指示する。 ◎ A JavaScript value, which has meaning only if the record is null, indicating that the corresponding script source text could not be parsed.
注記: この値は、 `~scriptの作成-時@#creating-scripts$における即時な構文解析-~errorを内部的に追跡するために利用され, 直に利用されることはない。 この~scriptが “何か間違った” か決定するときには、 代わりに,`再投出-用~error$sCに諮ること。 ◎ This value is used for internal tracking of immediate parse errors when creating scripts, and is not to be used directly. Instead, consult the error to rethrow when determining "what went wrong" for this script.
`再投出-用~error@sC ◎ An error to rethrow
評価を成功させなくする~errorを表現している,~JS値。 `~scriptを走らす@#calling-scripts$よう試みられたときには、 これが投出し直されることになる。 ◎ A JavaScript value representing an error that will prevent evaluation from succeeding. It will be re-thrown by any attempts to run the script.
注記: これは,当の~scriptの`構文解析-~error$sCにもなり得るが、 `~module~script$の事例では,代わりに[ そのいずれかの依存物における`構文解析-~error$sC / `~module指定子を解決する$ときの~error ]にもなり得る。 ◎ This could be the script's parse error, but in the case of a module script it could instead be the parse error from one of its dependencies, or an error from resolve a module specifier.
注記: この例外~値は~JS仕様により供され,決して ~NULL にならないことはわかっているので、 ~errorは生じなかったことを通達するときには, ~NULL を利用することにする。 ◎ Since this exception value is provided by the JavaScript specification, we know that it is never null, so we use null to signal that no error has occurred.
`~fetch~option群@sC ◎ Fetch options
~NULL / `~script~fetch~option群$ ◎ Null or a script fetch options,\
~NULL でない場合、[ この~script, および それが~importする`~module~script$ ]を~fetchするときに関係する,様々な~optionを包含する。 ◎ containing various options related to fetching this script or module scripts that it imports.
`基底~URL@sC ◎ A base URL
~NULL / `~URL$ ◎ ↓
~NULL でない場合、 `~module指定子を解決する$ときに利用される基底~URLを与える ⇒# 外部~module~script用には,~scriptが得された~URLになる/ ~inline~script用には,それを包含している文書の`基底~URL$になる ◎ Null or a base URL used for resolving module specifiers. When non-null, this will either be the URL from which the script was obtained, for external scripts, or the document base URL of the containing document, for inline scripts.

`古典~script@ は、 `~script$の一種であり,次に挙げる`~item$sctも有する: ◎ A classic script is a type of script that has the following additional item:

`~errorを黙秘するか@sC ◎ A muted errors boolean
真偽値。 ~T ならば、 この~scriptにおける~errorに対しては,~error情報は供されなくなる。 ~private情報を漏洩し得る非同一-生成元~scriptに対し、 ~errorを黙秘するために利用される。 ◎ A boolean which, if true, means that error information will not be provided for errors in this script. This is used to mute errors for cross-origin scripts, since that can leak private information.

`~module~script@ も`~script$の一種であるが、 追加的な`~item$sctは無い。 ◎ A module script is another type of script. It has no additional items.

`~module~script$は、 その`~record$sCに応じて, 次に挙げる 4 種に大別される: ◎ Module scripts can be classified into four types:

  • `~JS~module~script@ ⇒ `~source~text~module~Record$であるもの。 ◎ A module script is a JavaScript module script if its record is a Source Text Module Record.
  • `~CSS~module~script@ ⇒ `合成な~module~Record$であって, それは`~CSS~module~scriptを作成する$~algoを介して作成されたもの。 ~CSS~module~scriptは、 構文解析-済みな~CSS~stylesheetを表現する。 ◎ A module script is a CSS module script if its record is a Synthetic Module Record, and it was created via the create a CSS module script algorithm. CSS module scripts represent a parsed CSS stylesheet.
  • `~JSON~module~script@ ⇒ `合成な~module~Record$であって, それは`~JSON~module~scriptを作成する$~algoを介して作成されたもの。 ~JSON~module~scriptは、 構文解析-済みな~JSON文書を表現する。 ◎ A module script is a JSON module script if its record is a Synthetic Module Record, and it was created via the create a JSON module script algorithm. JSON module scripts represent a parsed JSON document.
  • `~WebAssembly~module~script@ ⇒ `~WebAssembly~module~Record$であるもの。 ◎ A module script is a WebAssembly module script if its record is a WebAssembly Module Record.

注記: [ ~CSS~stylesheet/~JSON文書 ]は,[ 自身が依存する~moduleを~importしない 【前者は `import$at 規則も`許容されない@#_note-on-import-at$】 ]かつ[ 評価に対し例外を投出しない ]ので、[ `~CSS~module~script$/`~JSON~module~script$ ]の[ `~fetch~option群$sC, `基底~URL$sC ]は,常に ~NULL になる。 ◎ As CSS stylesheets and JSON documents do not import dependent modules, and do not throw exceptions on evaluation, the fetch options and base URL of CSS module scripts and JSON module scripts and are always null.

`作動中な~script@ は、 次の~algoにより決定される: ◎ The active script is determined by the following algorithm:

  1. %~record ~LET `GetActiveScriptOrModule$jA() ◎ Let record be GetActiveScriptOrModule().
  2. ~IF[ %~record ~EQ ~NULL ] ⇒ ~RET ~NULL ◎ If record is null, return null.
  3. ~RET %~record .`HostDefined^sl ◎ Return record.[[HostDefined]].

注記: `作動中な~script$の概念が利用されるのは、 `import()$m 特能が[ 相対~module指定子を解決するために,利用する`基底~URL$sCを決定するとき ]の他にない。 ◎ The active script concept is so far only used by the import() feature, to determine the base URL to use for resolving relative module specifiers.

8.1.4.2. ~scriptの~fetch法

この節では、 ~scriptを~fetchするための各種~algoを導入する。 それらは、 必要yな様々な入力から[ `古典~script$/`~module~script$ ]を得る。 ◎ This section introduces a number of algorithms for fetching scripts, taking various necessary inputs and resulting in classic or module scripts.


`~script~fetch~option群@ は、 次に挙げる`~item$sctからなる`構造体$である: ◎ Script fetch options is a struct with the following items:

`暗号用~nonce@sfO ◎ cryptographic nonce
`暗号用~nonce~metadata$rq — 次に利用される ⇒# 初期~fetch/ ~importした~moduleを~fetchするとき ◎ The cryptographic nonce metadata used for the initial fetch and for fetching any imported modules
`完全性~metadata@sfO ◎ integrity metadata
`完全性~metadata$rq — 初期~fetchに利用される。 ◎ The integrity metadata used for the initial fetch
`構文解析器~metadata@sfO ◎ parser metadata
`構文解析器~metadata$rq — 次に利用される ⇒# 初期~fetch/ ~importした~moduleを~fetchするとき ◎ The parser metadata used for the initial fetch and for fetching any imported modules
`資格証~mode@sfO ◎ credentials mode
`資格証~mode$rq — 次に利用される ⇒# 初期~fetch/ `~module~script$用に限り,~importした~moduleを~fetchするとき ◎ The credentials mode used for the initial fetch (for module scripts) and for fetching any imported modules (for both module scripts and classic scripts)
`~referrer施策@sfO ◎ referrer policy
`~referrer施策$rq — 次に利用される ⇒# 初期~fetch/ ~importした~moduleを~fetchするとき ◎ The referrer policy used for the initial fetch and for fetching any imported modules
注記: この施策は、 `~module~script$の`応答$を受信した後に, 当の応答から`構文解析され@~REFERRER-POLICY#parse-referrer-policy-from-header$た`~referrer施策$に変異し得る — それは、 ~module依存物を~fetchするときに利用される。 ◎ This policy can mutate after a module script's response is received, to be the referrer policy parsed from the response, and used when fetching any module dependencies.
`具現化を阻んでいるか@sfO ◎ render-blocking
真偽値 — 要請の`具現化を阻んでいるか$rq用の値を与え,次に利用される ⇒# 初期~fetch/ ~importされる~moduleを~fetchするとき ◎ The boolean value of render-blocking used for the initial fetch and for fetching any imported modules.\
他が言明されない限り, ~F をとるとする。 ◎ Unless otherwise stated, its value is false.
`~fetch優先度@sfO ◎ fetch priority
`優先度$rq — 初期~fetchに利用される。 ◎ The priority used for the initial fetch

注記: `古典~script$は、 `import()$m 特能を介して`~module~script$を~importできることに~~留意されたし。 ◎ Recall that via the import() feature, classic scripts can import module scripts.

`既定の~script~fetch~option群@ は、 次のように設定された`~script~fetch~option群$である ⇒# `暗号用~nonce$sfO ~SET 空~文字列, `完全性~metadata$sfO ~SET 空~文字列, `構文解析器~metadata$sfO ~SET `not-parser-inserted^l, `資格証~mode$sfO ~SET `same-origin^l, `~referrer施策$sfO ~SET 空~文字列, `~fetch優先度$sfO ~SET `auto^l ◎ The default classic script fetch options are a script fetch options whose cryptographic nonce is the empty string, integrity metadata is the empty string, parser metadata is "not-parser-inserted", credentials mode is "same-origin", referrer policy is the empty string, and fetch priority is "auto".

所与の ( `要請$ %要請, `~script~fetch~option群$ %~option群 ) に対し,次が定義される: ◎ Given a request request and a script fetch options options, we define:

  • `古典~script要請を設定しておく@ ときは、 次のように %要請 を設定する ⇒# `暗号用~nonce~metadata$rq ~SET %~option群 の`暗号用~nonce$sfO, `完全性~metadata$rq ~SET %~option群 の`完全性~metadata$sfO, `構文解析器~metadata$rq ~SET %~option群 の`構文解析器~metadata$sfO, `~referrer施策$rq ~SET %~option群 の`~referrer施策$sfO, `具現化を阻んでいるか$rq ~SET %~option群 の`具現化を阻んでいるか$sfO, `優先度$rq ~SET %~option群 の`~fetch優先度$sfO ◎ set up the classic script request • Set request's cryptographic nonce metadata to options's cryptographic nonce, its integrity metadata to options's integrity metadata, its parser metadata to options's parser metadata, its referrer policy to options's referrer policy, its render-blocking to options's render-blocking, and its priority to options's fetch priority.
  • `~module~script要請を設定しておく@ ときは、 次のように %要請 を設定する ⇒# `暗号用~nonce~metadata$rq ~SET %~option群 の`暗号用~nonce$sfO, `完全性~metadata$rq ~SET %~option群 の`完全性~metadata$sfO, `構文解析器~metadata$rq ~SET %~option群 の`構文解析器~metadata$sfO, `資格証~mode$rq ~SET %~option群 の`資格証~mode$sfO, `~referrer施策$rq ~SET %~option群 の`~referrer施策$sfO, `具現化を阻んでいるか$rq ~SET %~option群 の`具現化を阻んでいるか$sfO, `優先度$rq ~SET %~option群 の`~fetch優先度$sfO ◎ set up the module script request • Set request's cryptographic nonce metadata to options's cryptographic nonce, its integrity metadata to options's integrity metadata, its parser metadata to options's parser metadata, its credentials mode to options's credentials mode, its referrer policy to options's referrer policy, its render-blocking to options's render-blocking, and its priority to options's fetch priority.

`子孫~script~fetch~option群を取得する@ ときは、 所与の ⇒# `~script~fetch~option群$ %元の~option群, `~URL$ %~URL, `環境~設定群~obj$ %設定群~obj ◎終 に対し: ◎ To get the descendant script fetch options given a script fetch options originalOptions, a URL url, and an environment settings object settingsObject:

  1. %新たな~option群 ~LET %元の~option群 の複製 ◎ Let newOptions be a copy of originalOptions.
  2. %新たな~option群 の`完全性~metadata$sfO ~SET `~module完全性~metadataを解決する$( %~URL, %設定群~obj ) ◎ Let integrity be the result of resolving a module integrity metadata with url and settingsObject. ◎ Set newOptions's integrity metadata to integrity.
  3. %新たな~option群 の`~fetch優先度$sfO ~SET `auto^l ◎ Set newOptions's fetch priority to "auto".
  4. ~RET %新たな~option群 ◎ Return newOptions.

`~module完全性~metadataを解決する@ ときは、 所与の ( `~URL$ %~URL, `環境~設定群~obj$ %設定群~obj ) に対し: ◎ To resolve a module integrity metadata, given a URL url and an environment settings object settingsObject:

  1. %~map ~LET %設定群~obj の`大域~obj$enVの`~import~map$gL ◎ Let map be settingsObject's global object's import map.
  2. ~IF[ %~map の`完全性$iM[ %~URL ] ~NEQ ε ] ⇒ ~RET 空~文字列 ◎ If map's integrity[url] does not exist, then return the empty string.
  3. ~RET %~map の`完全性$iM[ %~URL ] ◎ Return map's integrity[url].

以下の~algoのうち いくつかは、 `~fetch~hookを遂行する~algo@ で~custom化できる(され得る) — それは、 次に挙げる引数をとる ⇒# `要請$, `~top-levelか$V, `~custom~fetch応答の処理n$V ◎ Several of the below algorithms can be customized with a perform the fetch hook algorithm, which takes a request, a boolean isTopLevel, and a processCustomFetchResponse algorithm.\

  • `~custom~fetch応答の処理n@i は、 この~hookが走らすことになる~algoであり, ( `応答$, [ ~NULL(失敗~時)/ 応答の本体を包含している`~byte列$ ] ) を引数にとる。 ◎ It runs processCustomFetchResponse with a response and either null (on failure) or a byte sequence containing the response body.\
  • `~top-levelか@i は、 真偽値をとる: ◎ isTopLevel will be\

    • 次に対しては ~T にされる:

      • `古典~script$に対する すべての~fetch
      • 次を行うときの初期~fetch ⇒# `外部~module~script~graphを~fetchする$ / `~module~worker~script~graphを~fetchする$
      ◎ true for all classic script fetches, and for the initial fetch when fetching an external module script graph or fetching a module worker script graph,\
    • 次による結果の~fetchに対しては ~F にされる ⇒# ~module~script~graphを通り抜ける間に遭遇した `import^c 文/ `import()^c 式 ◎ but false for the fetches resulting from import statements encountered throughout the graph or from import() expressions.

以下の各~algoは、[ `~fetch~hookを遂行する~algo$を給さない既定では, 単純に所与の`要請$を`~fetchする$ ]ことになるが,~algoに特有な[[ `要請$, および 結果の`応答$の検証 ]に対する~custom化 ]を伴う。 ◎ By default, not supplying a perform the fetch hook will cause the below algorithms to simply fetch the given request, with algorithm-specific customizations to the request and validations of the resulting response.

~algoに特有な~custom化の上層に,自前の~custom化を重ねたい仕様~策定者は、 次のような`~fetch~hookを遂行する~algo$を給すること ⇒ 所与の`要請$を改変して, それを`~fetch$して, 結果の`応答$に対する特有な検証を遂行する (検証に失敗したなら`~network~error$で完了する) ◎ To layer your own customizations on top of these algorithm-specific ones, supply a perform the fetch hook that modifies the given request, fetches it, and then performs specific validations of the resulting response (completing with a network error if the validations fail).

この~hookは、 もっと微妙な~custom化を遂行するためにも利用できる — `応答$を~cacheしておいて,`~fetch$をまったく遂行せずに済ませるためなど。 ◎ The hook can also be used to perform more subtle customizations, such as keeping a cache of responses and avoiding performing a fetch at all.

注記: `Service Workers^cite `SW$r は、 この~hookとして自前の~optionを与えて, これらの~algoを走らす仕様の例である。 ◎ Service Workers is an example of a specification that runs these algorithms with its own options for the hook. [SW]


各種~algo自体は、 ここから: ◎ Now for the algorithms themselves.

`古典~scriptを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %設定群~obj, `~script~fetch~option群$ %~option群, `~CORS設定群~属性$用の状態 %~CORS設定, `符号化法$ %符号化法, %完了-時の手続き, ◎終 に対し,次を走らす: ◎ To fetch a classic script given a URL url, an environment settings object settingsObject, a script fetch options options, a CORS settings attribute state corsSetting, an encoding encoding, and an algorithm onComplete, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`古典~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a classic script (on success).
  2. %要請 ~LET `~CORSになり得る要請を作成する$( %~URL, `script^l, %~CORS設定 ) ◎ Let request be the result of creating a potential-CORS request given url, "script", and corsSetting.
  3. %要請 の ⇒# `~client$rq ~SET %設定群~obj, `起動元~種別$rq ~SET `script^l ◎ Set request's client to settingsObject. ◎ Set request's initiator type to "script".
  4. `古典~script要請を設定しておく$( %要請, %~option群 ) ◎ Set up the classic script request given request and options.
  5. %要請 を`~fetchする$ — 次を与える下で ⇒ `応答の本体を消費する処理n$i ~SET 次に定義する手続き ◎ Fetch request with the following processResponseConsumeBody steps\

    手続きは、 所与の ( `応答$ %応答, [ ~NULL / `失敗^i / `~byte列$ ] %本体~byte列 ) に対し: ◎ given response response and null, failure, or a byte sequence bodyBytes:

    注記: %応答 は、[ `~CORS同一-生成元$, `~CORS非同一-生成元$ ]いずれにもなり得る。 これは、 ~error報告ngがどう起こるかにのみ影響する。 ◎ response can be either CORS-same-origin or CORS-cross-origin. This only affects how error reporting happens.

    1. %応答 ~SET %応答 の`安全でない応答$ ◎ Set response to response's unsafe response.
    2. ~IF[ %本体~byte列 ~IN { ~NULL, `失敗^i } ]~OR[ %応答 の`状態s$rs ~NIN { `~ok状態s$rs } ] ⇒# %完了-時の手続き( ~NULL ); ~RET ◎ If any of the following are true: • bodyBytes is null or failure; or • response's status is not an ok status, then run onComplete given null, and abort these steps.

      注記: この節における他の[ ~scriptを~fetchする~algo ]と違って、 歴史的な理由から,この~algoは~MIME型を検査しない。 ◎ For historical reasons, this algorithm does not include MIME type checking, unlike the other script-fetching algorithms in this section.

    3. %符号化法を与え得る~MIME型 ~LET `~header~listから~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ Let potentialMIMETypeForEncoding be the result of extracting a MIME type given response's header list.
    4. %符号化法 ~SET `旧来~用に符号化法を抽出する$( %符号化法を与え得る~MIME型, %符号化法 ) ◎ Set encoding to the result of legacy extracting an encoding given potentialMIMETypeForEncoding and encoding.

      注記: これは、 ~MIME型の`~essence$を意図的に無視する。 ◎ This intentionally ignores the MIME type essence.

    5. %~source~text ~LET `~Unicodeに復号する$( %本体~byte列, %符号化法 ) ◎ Let sourceText be the result of decoding bodyBytes to Unicode, using encoding as the fallback encoding.

      注記: ~fileに~BOMがある場合、 この復号する~algoは %符号化法 を上書きする。 ◎ The decode algorithm overrides encoding if the file contains a BOM.

    6. %~errorを黙秘するか ~LET ~IS[ %応答 は`~CORS非同一-生成元$である ] ◎ Let mutedErrors be true if response was CORS-cross-origin, and false otherwise.
    7. %~script ~LET `古典~scriptを作成する$( ↓ ) ⇒# %~source~text, %設定群~obj, %応答 の`~URL$rs, %~option群, %~errorを黙秘するか, %~URL ◎ Let script be the result of creating a classic script given sourceText, settingsObject, response's URL, options, mutedErrors, and url.
    8. %完了-時の手続き( %~script ) ◎ Run onComplete given script.

`~worker用~古典~scriptを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %~fetch~client, `行先$rq %行先, `環境~設定群~obj$ %設定群~obj, %完了-時の手続き, `~fetch~hookを遂行する~algo$ %~fetchを遂行する(省略時は ε ) ◎終 に対し,次を走らす: ◎ To fetch a classic worker script given a URL url, an environment settings object fetchClient, a destination destination, an environment settings object settingsObject, an algorithm onComplete, and an optional perform the fetch hook performFetch, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`古典~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a classic script (on success).
  2. %要請 ~LET 新たな`要請$ — その ⇒# `~URL$rq ~SET %~URL, `~client$rq ~SET %~fetch~client, `行先$rq ~SET %行先, `起動元~種別$rq ~SET `other^l, `~mode$rq ~SET `same-origin^l, `資格証~mode$rq ~SET `same-origin^l, `構文解析器~metadata$rq ~SET `not-parser-inserted^l【!not parser-inserted 】, `~URL資格証を利用するか$rq ~SET ~T ◎ Let request be a new request whose URL is url, client is fetchClient, destination is destination, initiator type is "other", mode is "same-origin", credentials mode is "same-origin", parser metadata is "not parser-inserted", and whose use-URL-credentials flag is set.
  3. ~IF[ %~fetchを遂行する ~NEQ ε ] ⇒ %~fetchを遂行する( %要請, ~T, %応答の本体を消費する処理n† ) ◎ If performFetch was given, run performFetch with request, true, and with processResponseConsumeBody as defined below.

    ~ELSE ⇒ %要請 を`~fetchする$ — 次を与える下で ⇒ `応答の本体を消費する処理n$i ~SET %応答の本体を消費する処理n† ◎ Otherwise, fetch request with processResponseConsumeBody set to processResponseConsumeBody as defined below.

    † %応答の本体を消費する処理n は、 所与の ( `応答$ %応答, [ ~NULL / `失敗^i / `~byte列$ ] %本体~byte列 ) に対し: ◎ In both cases, let processResponseConsumeBody given response response and null, failure, or a byte sequence bodyBytes be the following algorithm:

    1. %応答 ~SET %応答 の`安全でない応答$ ◎ Set response to response's unsafe response.
    2. ~IF[ %本体~byte列 ~IN { ~NULL, `失敗^i } ]~OR[ %応答 の`状態s$rs ~NIN { `~ok状態s$rs } ] ⇒# %完了-時の手続き( ~NULL ); ~RET ◎ If any of the following are true: • bodyBytes is null or failure; or • response's status is not an ok status, then run onComplete given null, and abort these steps.
    3. ~IF[ ~AND↓ ]… ◎ If all of the following are true:

      • %応答 の`~URL$rsの`~scheme$urlは`~HTTP_S~scheme$である ◎ response's URL's scheme is an HTTP(S) scheme; and
      • 次の結果は`~JS~MIME型$でない ⇒ `~header~listから~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ the result of extracting a MIME type from response's header list is not a JavaScript MIME type,

      …ならば ⇒# %完了-時の手続き( ~NULL ) ~RET ◎ then run onComplete given null, and abort these steps.

      注記: 他の`~fetch~scheme$に対しては、 歴史的な~web互換性の理由から,~MIME型の検査は免除されている。 これは、 将来には,整備-可能になるかもしれない — `課題 #3255@~HTMLissue/3255$ を見よ。 ◎ Other fetch schemes are exempted from MIME type checking for historical web-compatibility reasons. We might be able to tighten this in the future; see issue #3255.

    4. %~source~text ~LET `~UTF-8復号する$( %本体~byte列 ) ◎ Let sourceText be the result of UTF-8 decoding bodyBytes.
    5. %~script ~LET `古典~scriptを作成する$( ↓ ) ⇒# %~source~text, %設定群~obj, %応答 の`~URL$rs, `既定の~script~fetch~option群$ ◎ Let script be the result of creating a classic script using sourceText, settingsObject, response's URL, and the default script fetch options.
    6. %完了-時の手続き( %~script ) ◎ Run onComplete given script.

`~workerが~importした古典~scriptを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %設定群~obj, `~fetch~hookを遂行する~algo$ %~fetchを遂行する(省略時は ε ) ◎終 に対し,次を走らす — この~algoは、[ 成功~時には`古典~script$を返す/ 失敗~時には例外を投出する ]: ◎ To fetch a classic worker-imported script given a URL url, an environment settings object settingsObject, and an optional perform the fetch hook performFetch, run these steps. The algorithm will return a classic script on success, or throw an exception on failure.

  1. %応答 ~LET ~NULL ◎ Let response be null.
  2. %本体~byte列 ~LET ~NULL ◎ Let bodyBytes be null.
  3. %要請 ~LET 新たな`要請$ — その ⇒# `~URL$rq ~SET %~URL, `~client$rq ~SET %設定群~obj, `行先$rq ~SET `script^l, `起動元~種別$rq ~SET `other^l, `構文解析器~metadata$rq ~SET `not-parser-inserted^l, `~URL資格証を利用するか$rq ~SET ~T ◎ Let request be a new request whose URL is url, client is settingsObject, destination is "script", initiator type is "other", parser metadata is "not parser-inserted", and whose use-URL-credentials flag is set.
  4. ~IF[ %~fetchを遂行する ~NEQ ε ] ⇒ %~fetchを遂行する( %要請, %~top-levelか, %応答の本体を消費する処理n† ) ◎ If performFetch was given, run performFetch with request, isTopLevel, and with processResponseConsumeBody as defined below.

    ~ELSE ⇒ %要請 を`~fetchする$ — 次を与える下で ⇒ `応答の本体を消費する処理n$i ~SET %応答の本体を消費する処理n† ◎ Otherwise, fetch request with processResponseConsumeBody set to processResponseConsumeBody as defined below.

    † %応答の本体を消費する処理n は、 所与の ( `応答$ %ある応答, [ ~NULL / `失敗^i / `~byte列$ ] %ある本体~byte列 ) に対し: ◎ In both cases, let processResponseConsumeBody given response res and null, failure, or a byte sequence bb be the following algorithm:

    1. %本体~byte列 ~SET %ある本体~byte列 ◎ Set bodyBytes to bb.
    2. %応答 ~SET %ある応答 ◎ Set response to res.
  5. [ %応答 ~NEQ ~NULL ]になるまで`静止する$ ◎ Pause until response is not null.

    注記: この節の他の~algoと違って,ここでの~fetchingは同期的に行われる。 ◎ Unlike other algorithms in this section, the fetching process is synchronous here.

  6. %応答 ~SET %応答 の`安全でない応答$ ◎ Set response to response's unsafe response.
  7. ~IF[ ~OR↓ ]… ◎ If any of the following are true:

    • %本体~byte列 ~IN { ~NULL, `失敗^i } ◎ bodyBytes is null or failure;
    • %応答 の`状態s$rsは`~ok状態s$rsでない ◎ response's status is not an ok status; or
    • 次の結果は`~JS~MIME型$でない ⇒ `~header~listから~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ the result of extracting a MIME type from response's header list is not a JavaScript MIME type,

    …ならば ⇒ ~THROW `NetworkError$E ◎ then throw a "NetworkError" DOMException.

  8. %~source~text ~LET `~UTF-8復号する$( %本体~byte列 ) ◎ Let sourceText be the result of UTF-8 decoding bodyBytes.
  9. %~errorを黙秘するか ~LET ~IS[ %応答 は`~CORS非同一-生成元$である ] ◎ Let mutedErrors be true if response was CORS-cross-origin, and false otherwise.
  10. %~script ~LET `古典~scriptを作成する$( ↓ ) ⇒# %~source~text, %設定群~obj, %応答 の`~URL$rs, `既定の~script~fetch~option群$, %~errorを黙秘するか ◎ Let script be the result of creating a classic script given sourceText, settingsObject, response's URL, the default script fetch options, and mutedErrors.
  11. ~RET %~script ◎ Return script.

`外部~module~script~graphを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %設定群~obj, `~script~fetch~option群$ %~option群, %完了-時の手続き, ◎終 に対し,次を走らす: ◎ To fetch an external module script graph given a URL url, an environment settings object settingsObject, a script fetch options options, and an algorithm onComplete, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`~module~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a module script (on success).
  2. `単独の~module~scriptを~fetchする$( ↓ ) ⇒# %~URL, %設定群~obj, `script^l, %~option群, %設定群~obj, `client^l, ~T, 次に定義する手続き ◎ Fetch a single module script given url, settingsObject, "script", options, settingsObject, "client", true, and with\

    手続きは、 所与の ( %結果 ) に対し: ◎ the following steps given result:

    1. ~IF[ %結果 ~EQ ~NULL ] ⇒# %完了-時の手続き( ~NULL ); ~RET ◎ If result is null, run onComplete given null, and abort these steps.
    2. `~module~scriptの子孫を~fetchして~linkする$( ↓ ) ⇒# %結果, %設定群~obj, `script^l, %完了-時の手続き ◎ Fetch the descendants of and link result given settingsObject, "script", and onComplete.

`~modulepreload~script~graphを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `行先$rq %行先, `環境~設定群~obj$ %設定群~obj, `~script~fetch~option群$ %~option群, %完了-時の手続き, ◎終 に対し,次を走らす: ◎ To fetch a modulepreload module script graph given a URL url, a destination destination, an environment settings object settingsObject, a script fetch options options, and an algorithm onComplete, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`~module~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a module script (on success).
  2. `単独の~module~scriptを~fetchする$( ↓ ) ⇒# %~URL, %設定群~obj, %行先, %~option群, %設定群~obj, `client^l, ~T, 次に定義する手続き ◎ Fetch a single module script given url, settingsObject, destination, options, settingsObject, "client", true, and with\

    手続きは、 所与の ( %結果 ) に対し: ◎ the following steps given result:

    1. %完了-時の手続き( %結果 ) ◎ Run onComplete given result.
    2. ~Assert: %設定群~obj の`大域~obj$enVは `Window$I を実装する ◎ Assert: settingsObject's global object implements Window.
    3. ~IF[ %結果 ~EQ ~NULL ] ⇒ ~RET ◎ If result is not null,\
    4. 任意選択で ⇒ `~module~scriptの子孫を~fetchして~linkする$( ↓ ) ⇒# %結果, %設定群~obj, %行先, 何もしない~algo ◎ optionally fetch the descendants of and link result given settingsObject, destination, and an empty algorithm.

      注記: 一般に、 この段を遂行すれば,処理能にとって有益になる。 それは、 ~graph全体を~fetchする~algo — `外部~module~script~graphを~fetchする$など — を介して後で結局~要請される~moduleを,予め読込むことを許容するので。 しかしながら,~UAは、[ 帯域幅が拘束されている状況/関連な~fetchはすでに~~伝送中にある状況 ]においては,それを飛ばしたいと望むこともあろう。 ◎ Generally, performing this step will be beneficial for performance, as it allows pre-loading the modules that will invariably be requested later, via algorithms such as fetch an external module script graph that fetch the entire graph. However, user agents might wish to skip them in bandwidth-constrained situations, or situations where the relevant fetches are already in flight.

`~inline~module~script~graphを~fetchする@ ときは、 所与の ⇒# `文字列$ %~source~text, `~URL$ %基底~URL, `環境~設定群~obj$ %設定群~obj, `~script~fetch~option群$ %~option群, %完了-時の手続き, ◎終 に対し,次を走らす: ◎ To fetch an inline module script graph given a string sourceText, a URL baseURL, an environment settings object settingsObject, a script fetch options options, and an algorithm onComplete, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`~module~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a module script (on success).
  2. %~script ~LET `~JS~module~scriptを作成する$( ↓ ) ⇒# %~source~text, %設定群~obj, %基底~URL, %~option群 ◎ Let script be the result of creating a JavaScript module script using sourceText, settingsObject, baseURL, and options.
  3. `~module~scriptの子孫を~fetchして~linkする$( ↓ ) ⇒# %~script, %設定群~obj, `script^l, %完了-時の手続き ◎ Fetch the descendants of and link script, given settingsObject, "script", and onComplete.

`~module~worker~script~graphを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %~fetch~client, `行先$rq %行先, `資格証~mode$sfO %資格証~mode, `環境~設定群~obj$ %設定群~obj, %完了-時の手続き ◎終 に対し ⇒ `[~worklet/~module~worker]~script~graphを~fetchする$( ↓ ) ⇒# %~URL, %~fetch~client, %行先, %資格証~mode, %設定群~obj, %完了-時の手続き ◎ To fetch a module worker script graph given a URL url, an environment settings object fetchClient, a destination destination, a credentials mode credentialsMode, an environment settings object settingsObject, and an algorithm onComplete, fetch a worklet/module worker script graph given url, fetchClient, destination, credentialsMode, settingsObject, and onComplete.

`~worklet~script~graphを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %~fetch~client, `行先$rq %行先, `資格証~mode$sfO %資格証~mode, `環境~設定群~obj$ %設定群~obj, `~module応答~map$wL %~module応答~map, %完了-時の手続き ◎終 に対し ⇒ `[~worklet/~module~worker]~script~graphを~fetchする$( ↓ ) ⇒# %~URL, %~fetch~client, %行先, %資格証~mode, %設定群~obj, %完了-時の手続き, 次に定義する(`~fetch~hookを遂行する~algo$を成す)手続き ◎ To fetch a worklet script graph given a URL url, an environment settings object fetchClient, a destination destination, a credentials mode credentialsMode, an environment settings object settingsObject, a module responses map moduleResponsesMap, and an algorithm onComplete,\ fetch a worklet/module worker script graph given url, fetchClient, destination, credentialsMode, settingsObject, onComplete, and the following perform the fetch hook\

手続きは、 所与の ( %要請, 【`~top-levelか$V, 】`~custom~fetch応答の処理n$V ) に対し: ◎ given request and processCustomFetchResponse:

  1. %要請~URL ~LET %要請 の`~URL$rq ◎ Let requestURL be request's URL.
  2. ~IF[ %~module応答~map[ %要請~URL ] ~EQ `fetching^l ]:

    1. %~module応答~map[ %要請~URL ] の値が変化するまで`並列的$に待機する
    2. `~taskを~queueする$( `~network用~task~source$, この手続きの以降を続行する手続き )
    3. ~RET 【この段は、この訳による補完。】
    ◎ If moduleResponsesMap[requestURL] is "fetching", wait in parallel until that entry's value changes, then queue a task on the networking task source to proceed with running the following steps.
  3. ~IF[ %~module応答~map[ %要請~URL ] ~NEQ ε ]: ◎ If moduleResponsesMap[requestURL] exists, then:

    1. ( %ある応答, %ある本体~byte列 ) ~LET %~module応答~map[ %要請~URL ] ◎ Let cached be moduleResponsesMap[requestURL].
    2. %~custom~fetch応答の処理n( %ある応答, %ある本体~byte列 ); ◎ Run processCustomFetchResponse with cached[0] and cached[1].
    3. ~RET ◎ Return.
  4. %~module応答~map[ %要請~URL ] ~SET `fetching^l ◎ Set moduleResponsesMap[requestURL] to "fetching".
  5. %要請 を`~fetchする$ — 次を与える下で: ◎ Fetch request,\

    • `応答の本体を消費する処理n$i ~SET 所与の ( `応答$ %応答, [ ~NULL / `失敗^i / `~byte列$ ] %本体~byte列 ) に対し: ◎ with processResponseConsumeBody set to the following steps given response response and null, failure, or a byte sequence bodyBytes:

      1. %~module応答~map[ %要請~URL ] ~SET ( %応答, %本体~byte列 ) ◎ Set moduleResponsesMap[requestURL] to (response, bodyBytes).
      2. %~custom~fetch応答の処理n( %応答, %本体~byte列 ) ◎ Run processCustomFetchResponse with response and bodyBytes.

以下に与える各種~algoは、[ `外部~module~script~graphを~fetchする$,その他の上に与えた類似な概念 ]の一部を成すものとして,この仕様の内部~利用のみに意味されている。 他の仕様は、 これらを直に利用するべきではない。 ◎ The following algorithms are meant for internal use by this specification only as part of fetching an external module script graph or other similar concepts above, and should not be used directly by other specifications.

これらの~algoが[ 上に与えたものに, および互いに ]どう関係するかを,次の図式に示す:

  • 次に挙げる~algoが、 外部から直に利用され得る ⇒# (A) `外部~module~script~graphを~fetchする$/ (B) `~modulepreload~script~graphを~fetchする$/ (C) `~inline~module~script~graphを~fetchする$/ (D) `~module~worker~script~graphを~fetchする$/ (E) `~worklet~script~graphを~fetchする$
  • (D), (E) は、 次を呼出す ⇒ (F) `[~worklet/~module~worker]~script~graphを~fetchする$
  • (A), (B), (C), (F) は、 次を呼出す ⇒ `~module~scriptの子孫を~fetchして~linkする$

【 原文は~SVG画像による図式で示されているが、 日本語表示~上の都合により,単に~markupと~textで示す。 】

◎ This diagram illustrates how these algorithms relate to the ones above, as well as to each other: ◎ • fetch an external module script graph • fetch a modulepreload module script graph • fetch an inline module script graph • fetch a module worker script graph • fetch a worklet script graph ◎ • fetch a worklet/module worker script graph ◎ • fetch the descendants of and link a module script

`[~worklet/~module~worker]~script~graphを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %~fetch~client, `行先$rq %行先, `資格証~mode$sfO %資格証~mode, `環境~設定群~obj$ %設定群~obj, %完了-時の手続き, `~fetch~hookを遂行する~algo$ %~fetchを遂行する(省略時は ε ) ◎終 に対し,次を走らす: ◎ To fetch a worklet/module worker script graph given a URL url, an environment settings object fetchClient, a destination destination, a credentials mode credentialsMode, an environment settings object settingsObject, an algorithm onComplete, and an optional perform the fetch hook performFetch, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`~module~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a module script (on success).
  2. %~option群 ~LET 新たな`~script~fetch~option群$ — その ⇒# `暗号用~nonce$sfO ~SET 空~文字列, `完全性~metadata$sfO ~SET 空~文字列, `構文解析器~metadata$sfO ~SET `not-parser-inserted^l, `資格証~mode$sfO ~SET %資格証~mode, `~referrer施策$sfO ~SET 空~文字列, `~fetch優先度$sfO ~SET `auto^l ◎ Let options be a script fetch options whose cryptographic nonce is the empty string, integrity metadata is the empty string, parser metadata is "not-parser-inserted", credentials mode is credentialsMode, referrer policy is the empty string, and fetch priority is "auto".
  3. `単独の~module~scriptを~fetchする$( ↓ ) ⇒# %~URL, %~fetch~client, %行先, %~option群, %設定群~obj, `client^l, ~T, 次に定義する手続き, %~fetchを遂行する ◎ Fetch a single module script given url, fetchClient, destination, options, settingsObject, "client", true, and onSingleFetchComplete as defined below. If performFetch was given, pass it along as well.

    手続き【!onSingleFetchComplete】は、 所与の ( %結果 ) に対し: ◎ onSingleFetchComplete given result is the following algorithm:

    1. ~IF[ %結果 ~EQ ~NULL ] ⇒# %完了-時の手続き( ~NULL ); ~RET ◎ If result is null, run onComplete given null, and abort these steps.
    2. `~module~scriptの子孫を~fetchして~linkする$( ↓ ) ⇒# %結果, %~fetch~client, %行先, %完了-時の手続き, %~fetchを遂行する ◎ Fetch the descendants of and link result given fetchClient, destination, and onComplete. If performFetch was given, pass it along as well.

`~module~scriptの子孫を~fetchして~linkする@ ときは、 所与の ⇒# `~module~script$ %~module~script, `環境~設定群~obj$ %~fetch~client, `行先$rq %行先, %完了-時の手続き, `~fetch~hookを遂行する~algo$ %~fetchを遂行する(省略時は ε ) ◎終 に対し,次を走らす: ◎ To fetch the descendants of and link a module script moduleScript, given an environment settings object fetchClient, a destination destination, an algorithm onComplete, and an optional perform the fetch hook performFetch, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`~module~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a module script (on success).
  2. %~record ~LET %~module~script の`~record$sC ◎ Let record be moduleScript's record.
  3. ~IF[ %~record ~EQ ~NULL ]: ◎ If record is null, then:

    1. %~module~script の`再投出-用~error$sC ~SET %~module~script の`構文解析-~error$sC 【!誤:~HTMLparsing#parse-errors】 ◎ Set moduleScript's error to rethrow to moduleScript's parse error.
    2. %完了-時の手続き( %~module~script ) ◎ Run onComplete given moduleScript.
    3. ~RET ◎ Return.
  4. %状態 ~LET 新たな`~Record$ — その ⇒# `ParseError^sl ~SET ~NULL, `Destination^sl ~SET %行先, `PerformFetch^sl ~SET ~NULL, `FetchClient^sl ~SET %~fetch~client ◎ Let state be Record { [[ParseError]]: null, [[Destination]]: destination, [[PerformFetch]]: null, [[FetchClient]]: fetchClient }.
  5. ~IF[ %~fetchを遂行する ~NEQ ε ] ⇒ %状態 .`PerformFetch^sl ~SET %~fetchを遂行する ◎ If performFetch was given, set state.[[PerformFetch]] to performFetch.
  6. %読込ng~promise ~LET %~record .`LoadRequestedModules$jA( %状態 ) ◎ Let loadingPromise be record.LoadRequestedModules(state).

    注記: この段は、 当の~moduleの推移的な依存物~すべてを再帰的に読込むことになる。 ◎ This step will recursively load all the module transitive dependencies.

    • %読込ng~promise の`充足-時$には、 次の手続きを走らす: ◎ Upon fulfillment of loadingPromise, run the following steps:

      1. %~record .`Link$jA() ◎ Perform record.Link().

        注記: この段は、 当の~moduleの依存物のうち~linkされていないものすべてに対し, `Link$jA を再帰的に~callすることになる。 ◎ This step will recursively call Link on all of the module's unlinked dependencies.

        この段で例外 %E が投出されたときは、 ~catchして ⇒# %~module~script の`再投出-用~error$sC ~SET %E ◎ If this throws an exception, catch it, and set moduleScript's error to rethrow to that exception.

      2. %完了-時の手続き( %~module~script ) ◎ Run onComplete given moduleScript.
    • %読込ng~promise の`却下-時$には、 次の手続きを走らす: ◎ Upon rejection of loadingPromise, run the following steps:

      1. ~IF[ %状態 .`ParseError^sl ~NEQ ~NULL ] ⇒# %~module~script の`再投出-用~error$sC ~SET %状態 .`ParseError^sl; %完了-時の手続き( %~module~script ) ◎ If state.[[ParseError]] is not null, set moduleScript's error to rethrow to state.[[ParseError]] and run onComplete given moduleScript.
      2. ~ELSE ⇒ %完了-時の手続き( ~NULL ) ◎ Otherwise, run onComplete given null.

        注記: 読込ng~errorに因り %読込ng~promise が却下された場合、[ %状態 .`ParseError^sl ~EQ ~NULL ]になる。 ◎ state.[[ParseError]] is null when loadingPromise is rejected due to a loading error.

`単独の~module~scriptを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %~fetch~client, `行先$rq %行先, `~script~fetch~option群$ %~option群, `環境~設定群~obj$ %設定群~obj, `~referrer$rq %~referrer, `~module要請~Record$ %~module要請【!省略時は ε 】, 真偽値 `~top-levelか$V, %完了-時の手続き, `~fetch~hookを遂行する~algo$ %~fetchを遂行する(省略時は ε ) ◎終 に対し,次を走らす: ◎ To fetch a single module script, given a URL url, an environment settings object fetchClient, a destination destination, a script fetch options options, an environment settings object settingsObject, a referrer referrer, an optional ModuleRequest Record moduleRequest, a boolean isTopLevel, an algorithm onComplete, and an optional perform the fetch hook performFetch, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`~module~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a module script (on success).
  2. %~module種別 ~LET %~module要請 に応じて ⇒# ε ならば `javascript-or-wasm^l / ~ELSE_ `~module要請から~module種別を得る$( %~module要請 ) ◎ Let moduleType be "javascript-or-wasm". ◎ If moduleRequest was given, then set moduleType to the result of running the module type from module request steps given moduleRequest.
  3. ~Assert: `~module種別は許容されるか?$( %~module種別, %設定群~obj ) ~EQ ~T ◎ Assert: the result of running the module type allowed steps given moduleType and settingsObject is true.\

    さもなければ、 この地点に達することはない — それに先立って,[ `HostLoadImportedModule$A の`中で@#validate-requested-module-specifiers$ ]あるいは[ `単独の~importされた~module~scriptを~fetchする$とき ]に[ %~module要請 .`Attributes^sl を検分するとき ]に失敗に終わったはずなので。 ◎ Otherwise, we would not have reached this point because a failure would have been raised when inspecting moduleRequest.[[Attributes]] in HostLoadImportedModule or fetch a single imported module script.

  4. %~module~map ~LET %設定群~obj の`~module~map$enV ◎ Let moduleMap be settingsObject's module map.
  5. %~key ~LET ( %~URL, %~module種別 )
  6. ~IF[ %~module~map[ %~key ] ~EQ `fetching^l ]:

    1. %~module~map[ %~key ] の値が変化するまで,`並列的$に待機する
    2. `~taskを~queueする$( `~network用~task~source$, この手続きの以降を続行する手続き )
    3. ~RET 【この段は、この訳による補完。】
    ◎ If moduleMap[(url, moduleType)] is "fetching", wait in parallel until that entry's value changes, then queue a task on the networking task source to proceed with running the following steps.
  7. ~IF[ %~module~map[ %~key ] ~NEQ ε ] ⇒# %完了-時の手続き( %~module~map[ %~key ] ); ~RET ◎ If moduleMap[(url, moduleType)] exists, run onComplete given moduleMap[(url, moduleType)], and return.
  8. %~module~map[ %~key ] ~SET `fetching^l ◎ Set moduleMap[(url, moduleType)] to "fetching".
  9. %要請 ~LET 新たな`要請$ — その ⇒# `~URL$rq ~SET %~URL, `~mode$rq ~SET `cors^l, `~referrer$rq ~SET %~referrer, `~client$rq ~SET %~fetch~client, `行先$rq ~SET `~module種別から~fetch用の行先を得る$( %行先, %~module種別 ) ◎ Let request be a new request whose URL is url, mode is "cors", referrer is referrer, and client is fetchClient. ◎ Set request's destination to the result of running the fetch destination from module type steps given destination and moduleType.
  10. ~IF[ %行先 ~IN { `worker^l, `sharedworker^l, `serviceworker^l } ]~AND[ %~top-levelか ~EQ ~T ] ⇒ %要請 の`~mode$rq ~SET `same-origin^l ◎ If destination is "worker", "sharedworker", or "serviceworker", and isTopLevel is true, then set request's mode to "same-origin".
  11. %要請 の`起動元~種別$rq ~SET `script^l ◎ Set request's initiator type to "script".
  12. `~module~script要請を設定しておく$( %要請, %~option群 ) ◎ Set up the module script request given request and options.
  13. ~IF[ %~fetchを遂行する ~NEQ ε ] ⇒ %~fetchを遂行する( %要請, %~top-levelか, %応答の本体を消費する処理n† ) ◎ If performFetch was given, run performFetch with request, isTopLevel, and with processResponseConsumeBody as defined below.

    ~ELSE ⇒ %要請 を`~fetchする$ — 次を与える下で ⇒ `応答の本体を消費する処理n$i ~SET %応答の本体を消費する処理n† ◎ Otherwise, fetch request with processResponseConsumeBody set to processResponseConsumeBody as defined below.

    † %応答の本体を消費する処理n は、 所与の ( `応答$ %応答, [ ~NULL / `失敗^i / `~byte列$ ] %本体~byte列 ) に対し: ◎ In both cases, let processResponseConsumeBody given response response and null, failure, or a byte sequence bodyBytes be the following algorithm:

    注記: %応答 は、 常に`~CORS同一-生成元$になる。 ◎ response is always CORS-same-origin.

    1. ~IF[ %本体~byte列 ~IN { ~NULL, `失敗^i } ]~OR[ %応答 の`状態s$rsは`~ok状態s$rsでない ] ⇒# %~module~map[ %~key ] ~SET ~NULL; %完了-時の手続き( ~NULL ); ~RET ◎ If any of the following are true: • bodyBytes is null or failure; or • response's status is not an ok status, then set moduleMap[(url, moduleType)] to null, run onComplete given null, and abort these steps.
    2. %~MIME型 ~LET `~header~listから~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ Let mimeType be the result of extracting a MIME type from response's header list.
    3. %~module~script ~LET ~NULL ◎ Let moduleScript be null.
    4. %~referrer施策 ~LET `~referrer施策を構文解析する$( %応答 ) `REFERRERPOLICY$r ◎ Let referrerPolicy be the result of parsing the `Referrer-Policy` header given response. [REFERRERPOLICY]
    5. ~IF[ %~referrer施策 ~NEQ 空~文字列 ] ⇒ %~option群 の`~referrer施策$sfO ~SET %~referrer施策 ◎ If referrerPolicy is not the empty string, set options's referrer policy to referrerPolicy.
    6. ~IF[ %~MIME型 の`~essence$ ~EQ "`application/wasm$mt" ]~AND[ %~module種別 ~EQ `javascript-or-wasm^l ] ⇒ %~module~script ~SET `~WebAssembly~module~scriptを作成する$( ↓ ) ⇒# %本体~byte列, %設定群~obj, %応答 の`~URL$rs, %~option群 ◎ If mimeType's essence is "application/wasm" and moduleType is "javascript-or-wasm", then set moduleScript to the result of creating a WebAssembly module script given bodyBytes, settingsObject, response's URL, and options.
    7. ~ELSE: ◎ Otherwise:

      1. %~source~text ~LET `~UTF-8復号する$( %本体~byte列 ) ◎ Let sourceText be the result of UTF-8 decoding bodyBytes.
      2. ~IF[ %~MIME型 は`~JS~MIME型$である ]~AND[ %~module種別 ~EQ `javascript-or-wasm^l ] ⇒ %~module~script ~SET `~JS~module~scriptを作成する$( ↓ ) ⇒# %~source~text, %設定群~obj, %応答 の`~URL$rs, %~option群 ◎ If mimeType is a JavaScript MIME type and moduleType is "javascript-or-wasm", then set moduleScript to the result of creating a JavaScript module script given sourceText, settingsObject, response's URL, and options.
      3. ~IF[ %~MIME型 の`~essence$ ~EQ "`text/css$mt" ]~AND[ %~module種別 ~EQ `css^l ] ⇒ %~module~script ~SET `~CSS~module~scriptを作成する$( %~source~text, %設定群~obj ) ◎ If the MIME type essence of mimeType is "text/css" and moduleType is "css", then set moduleScript to the result of creating a CSS module script given sourceText and settingsObject.
      4. ~IF[ %~MIME型 は`~JSON~MIME型$である ]~AND[ %~module種別 ~EQ `json^l ] ⇒ %~module~script ~SET `~JSON~module~scriptを作成する$( %~source~text, %設定群~obj ) ◎ If mimeType is a JSON MIME type and moduleType is "json", then set moduleScript to the result of creating a JSON module script given sourceText and settingsObject.
    8. %~module~map[ %~key ] ~SET %~module~script ◎ Set moduleMap[(url, moduleType)] to moduleScript,\
    9. %完了-時の手続き( %~module~script ) ◎ and run onComplete given moduleScript.

      注記: `~module~map$は`要請~URL$rqを~keyに利用する一方で,`~module~script$の`基底~URL$sCは`応答~URL$rsに設定するのは、 意図的である。 前者は~fetchを重複させないために利用される一方で、 後者は~URL解決に利用される。 ◎ It is intentional that the module map is keyed by the request URL, whereas the base URL for the module script is set to the response URL. The former is used to deduplicate fetches, while the latter is used for URL resolution.

`単独の~importされた~module~scriptを~fetchする@ ときは、 所与の ⇒# `~URL$ %~URL, `環境~設定群~obj$ %~fetch~client, `行先$rq %行先, `~script~fetch~option群$ %~option群, `環境~設定群~obj$ %設定群~obj, `~referrer$rq %~referrer, `~module要請~Record$ %~module要請, %完了-時の手続き, `~fetch~hookを遂行する~algo$ %~fetchを遂行する(省略時は ε ) ◎終 に対し,次を走らす: ◎ To fetch a single imported module script, given a URL url, an environment settings object fetchClient, a destination destination, a script fetch options options, environment settings object settingsObject, a referrer referrer, a ModuleRequest Record moduleRequest, an algorithm onComplete, and an optional perform the fetch hook performFetch, run these steps.\

  1. ~Assert: %完了-時の手続き は、[ ~NULL (失敗~時)/`~module~script$(成功~時) ]を受容する~algoである。 ◎ onComplete must be an algorithm accepting null (on failure) or a module script (on success).
  2. ~Assert: どの`~Record$ %~entry ~IN %~module要請 .`Attributes^sl も[ %~entry .`Key^sl ~EQ `type^l ]を満たす — `HostGetSupportedImportAttributes$A にて, `type^l 属性を伴うものに限り依頼したので。 ◎ Assert: moduleRequest.[[Attributes]] does not contain any Record entry such that entry.[[Key]] is not "type", because we only asked for "type" attributes in HostGetSupportedImportAttributes.
  3. %~module種別 ~LET `~module要請から~module種別を得る$( %~module要請 ) ◎ Let moduleType be the result of running the module type from module request steps given moduleRequest.
  4. ~IF[ `~module種別は許容されるか?$( %~module種別, %設定群~obj ) ~EQ ~F ] ⇒# %完了-時の手続き( ~NULL ); ~RET ◎ If the result of running the module type allowed steps given moduleType and settingsObject is false, then run onComplete given null, and return.
  5. `単独の~module~scriptを~fetchする$( ↓ ) ⇒# %~URL, %~fetch~client, %行先, %~option群, %設定群~obj, %~referrer, %~module要請, ~F, %完了-時の手続き, %~fetchを遂行する ◎ Fetch a single module script given url, fetchClient, destination, options, settingsObject, referrer, moduleRequest, false, and onComplete. If performFetch was given, pass it along as well.
8.1.4.3. ~scriptの作成-法

`古典~scriptを作成する@ ときは、 所与の ⇒# `文字列$ %~source, `環境~設定群~obj$ %設定群, `~URL$ %基底~URL, `~script~fetch~option群$ %~option群, 真偽値 %~errorを黙秘するか(省略時は ~F ), [`~URL$/~NULL] %~window~script用の~source~URL(省略時は ~NULL ) ◎終 に対し,次を走らす: ◎ To create a classic script, given a string source, an environment settings object settings, a URL baseURL, a script fetch options options, an optional boolean mutedErrors (default false), and an optional URL-or-null sourceURLForWindowScripts (default null):

  1. ~IF[ %~errorを黙秘するか ~EQ ~T ] ⇒ %基底~URL ~SET `about:blank@~HTMLdep#about:blank$sc ◎ If mutedErrors is true, then set baseURL to about:blank.

    注記: %~errorを黙秘するか ~EQ ~T のとき、 %基底~URL は,当の~scriptの`~CORS非同一-生成元$な`応答$の`~URL$rsになる — それは,~JSには公開されないベキなので、 %基底~URL は,ここで無毒化される。 ◎ When mutedErrors is true, baseURL is the script's CORS-cross-origin response's url, which shouldn't be exposed to JavaScript. Therefore, baseURL is sanitized here.

  2. ~IF[ %設定群 用の`~scriptingは不能化されて$sttいる ] ⇒ %~source ~SET 空~文字列 ◎ If scripting is disabled for settings, then set source to the empty string.
  3. %~script ~LET 新たな`古典~script$ — その ⇒# `設定群~obj$sC ~SET %設定群, `基底~URL$sC ~SET %基底~URL, `~fetch~option群$sC ~SET %~option群 `~errorを黙秘するか$sC ~SET %~errorを黙秘するか, `構文解析-~error$sC ~SET ~NULL, `再投出-用~error$sC ~SET ~NULL ◎ Let script be a new classic script that this algorithm will subsequently initialize. ◎ Set script's settings object to settings. ◎ Set script's base URL to baseURL. ◎ Set script's fetch options to options. ◎ Set script's muted errors to mutedErrors. ◎ Set script's parse error and error to rethrow to null.
  4. `古典~scriptの作成~時刻を記録する$( %~script, %~window~script用の~source~URL ) ◎ Record classic script creation time given script and sourceURLForWindowScripts.
  5. %結果 ~LET `ParseScript$jA( %~source, %設定群 の`~realm$enV, %~script ) ◎ Let result be ParseScript(source, settings's realm, script).

    注記: ここで最後の~parameterに %~script を渡すことにより,[ %結果 .`HostDefined^sl ~EQ %~script ]になることが確保される。 ◎ Passing script as the last parameter here ensures result.[[HostDefined]] will be script.

  6. ~IF[ %結果 は ~errorたちが成す`~list$である ]: ◎ If result is a list of errors, then:

    1. %~script の ⇒# `構文解析-~error$sC ~SET %結果[0], `再投出-用~error$sC ~SET %結果[0] ◎ Set script's parse error and its error to rethrow to result[0].
    2. ~RET %~script ◎ Return script.
  7. %~script の`~record$sC ~SET %結果 ◎ Set script's record to result.
  8. ~RET %~script ◎ Return script.

`~JS~module~scriptを作成する@ ときは、 所与の ⇒# `文字列$ %~source, `環境~設定群~obj$ %設定群, `~URL$ %基底~URL, `~script~fetch~option群$ %~option群 ◎終 に対し,次を走らす: ◎ To create a JavaScript module script, given a string source, an environment settings object settings, a URL baseURL, and a script fetch options options:

  1. ~IF[ %設定群 用の`~scriptingは不能化されて$sttいる ] ⇒ %~source ~SET 空~文字列 ◎ If scripting is disabled for settings, then set source to the empty string.
  2. %~script ~LET 新たな`~module~script$ — その ⇒# `設定群~obj$sC ~SET %設定群, `基底~URL$sC ~SET %基底~URL, `~fetch~option群$sC ~SET %~option群 `構文解析-~error$sC ~SET ~NULL, `再投出-用~error$sC ~SET ~NULL ◎ Let script be a new module script that this algorithm will subsequently initialize. ◎ Set script's settings object to settings. ◎ Set script's base URL to baseURL. ◎ Set script's fetch options to options. ◎ Set script's parse error and error to rethrow to null.
  3. %結果 ~LET `ParseModule$jA( %~source, %設定群 の`~realm$enV, %~script ) ◎ Let result be ParseModule(source, settings's realm, script).

    注記: ここで最後の~parameterに %~script を渡すことにより,[ %結果 .`HostDefined^sl ~EQ %~script ]になることが確保される。 ◎ Passing script as the last parameter here ensures result.[[HostDefined]] will be script.

  4. ~IF[ %結果 は ~errorたちが成す`~list$である ]: ◎ If result is a list of errors, then:

    1. %~script の`構文解析-~error$sC ~SET %結果[0] ◎ Set script's parse error to result[0].
    2. ~RET %~script ◎ Return script.
  5. %~script の`~record$sC ~SET %結果 ◎ Set script's record to result.
  6. ~RET %~script ◎ Return script.

`~WebAssembly~module~scriptを作成する@ ときは、 所与の ⇒# `~byte列$ %本体~byte列, `環境~設定群~obj$ %設定群, `~URL~record$ %基底~URL, `~script~fetch~option群$ %~option群 ◎終 に対し: ◎ To create a WebAssembly module script, given a byte sequence bodyBytes, an environment settings object settings, a URL baseURL, and a script fetch options options:

  1. ~IF[ %設定群 用の`~scriptingは不能化されて$sttいる ] ⇒ %本体~byte列 ~SET ~byte列 0x00 0x61 0x73 0x6d 0x01 0x00 0x00 0x00 ◎ If scripting is disabled for settings, then set bodyBytes to the byte sequence 0x00 0x61 0x73 0x6d 0x01 0x00 0x00 0x00.

    注記: この~byte列は、[ ~magic~byte列, ~version番号 ]のみを供する空な~WebAssembly~moduleに対応する。 ◎ This byte sequence corresponds to an empty WebAssembly module with only the magic bytes and version number provided.

  2. %~script ~LET 新たな`~module~script$ — その ⇒# `設定群~obj$sC ~SET %設定群, `基底~URL$sC ~SET %基底~URL, `~fetch~option群$sC ~SET %~option群, `構文解析-~error$sC ~SET ~NULL, `再投出-用~error$sC ~SET ~NULL, ◎ Let script be a new module script that this algorithm will subsequently initialize. ◎ Set script's settings object to settings. ◎ Set script's base URL to baseURL. ◎ Set script's fetch options to options. ◎ Set script's parse error and error to rethrow to null.
  3. %結果 ~LET `~WebAssembly~moduleを構文解析する$( %本体~byte列, %設定群 の`~realm$enV, %~script ) ◎ Let result be the result of parsing a WebAssembly module given bodyBytes, settings's realm, and script.

    注記: ここで,最後の~parameterとして %~script を渡すことにより、 %結果. `HostDefined^sl が %~script になることを確保する。 ◎ Passing script as the last parameter here ensures result.[[HostDefined]] will be script.

    ~error %~error が投出されたときは、 ~catchして: ◎ If the previous step threw an error error, then:

    1. %~script の`構文解析-~error$sC ~SET %~error ◎ Set script's parse error to error.
    2. ~RET %~script ◎ Return script.
  4. %~script の`~record$sC ~SET %結果 ◎ Set script's record to result.
  5. ~RET %~script ◎ Return script.

注記: `WASMESM$r は、 ~WebAssemblyを `JAVASCRIPT$r ~module読込ngへ統合するための~hookを指定する。 これは、[ 直な依存関係~import( `direct dependency imports^en ), ~source段階~import( `source phase imports^en ) ]両者~用の~supportを含む — それは、[ ~virtual化( `virtualization^en ), 複-~instance化( `multi-instantiation^en ) ]を~supportする。 `WASMESM$r ◎ WebAssembly JavaScript Interface: ESM Integration specifies the hooks for the WebAssembly integration with ECMA-262 module loading. This includes support both for direct dependency imports, as well as for source phase imports, which support virtualization and multi-instantiation. [WASMESM]

`~CSS~module~scriptを作成する@ ときは、 所与の ( 文字列 %~source, `環境~設定群~obj$ %設定群 ) に対し: ◎ To create a CSS module script, given a string source and an environment settings object settings:

  1. %~script ~LET 新たな`~module~script$ — その ⇒# `設定群~obj$sC ~SET %設定群, `基底~URL$sC ~SET ~NULL, `構文解析-~error$sC ~SET ~NULL, `再投出-用~error$sC ~SET ~NULL ◎ Let script be a new module script that this algorithm will subsequently initialize. ◎ Set script's settings object to settings. ◎ Set script's base URL and fetch options to null. ◎ Set script's parse error and error to rethrow to null.
  2. %~stylesheet ~LET 新たな `CSSStyleSheet$I ~obj ◎ ↓
  3. %~stylesheet 上の `new CSSStyleSheet$m 構築子~手続き( 空な辞書 ) 【!構築-済みな~CSSStyleSheetを作成する】 ◎ Let sheet be the result of running the steps to create a constructed CSSStyleSheet with an empty dictionary as the argument.
  4. %~stylesheet 上の `replaceSync$m ~method手続き( %~source ) 【!~CSS規則~群を同期的に置換する】 ◎ Run the steps to synchronously replace the rules of a CSSStyleSheet on sheet given source.

    この段で例外 %E が投出されたときは、 ~catchして ⇒# %~script の`構文解析-~error$sC ~SET %E ; ~RET %~script ◎ If this throws an exception, catch it, and set script's parse error to that exception, and return script.

    注記: `replaceSync$m ~method手続きは、 %~source が `import$at 規則を包含する場合には,例外を投出することになる。 【と記されているが、実際の手続きは,そうなるかどうか明瞭でない。】 これは、 今の所は設計による — ~CSS~module~script用にこれらを取扱う方法に対し,まだ合意が無いので。 したがって総意に達するまでは,一律に阻止される。 ◎ The steps to synchronously replace the rules of a CSSStyleSheet will throw if source contains any @import rules. This is by-design for now because there is not yet an agreement on how to handle these for CSS module scripts; therefore they are blocked altogether until a consensus is reached.

  5. %~script の`~record$sC ~SET `CreateDefaultExportSyntheticModule$jA( %~stylesheet ) ◎ Set script's record to the result of CreateDefaultExportSyntheticModule(sheet).
  6. ~RET %~script ◎ Return script.

`~JSON~module~scriptを作成する@ ときは、 所与の ( 文字列 %~source, `環境~設定群~obj$ %設定群 ) に対し,次を走らす: ◎ To create a JSON module script, given a string source and an environment settings object settings:

  1. %~script ~LET 新たな`~module~script$ — その ⇒# `設定群~obj$sC ~SET %設定群, `基底~URL$sC ~SET ~NULL, `構文解析-~error$sC ~SET ~NULL, `再投出-用~error$sC ~SET ~NULL ◎ Let script be a new module script that this algorithm will subsequently initialize. ◎ Set script's settings object to settings. ◎ Set script's base URL and fetch options to null. ◎ Set script's parse error and error to rethrow to null.
  2. %結果 ~LET `ParseJSONModule$jA( %~source ) ◎ Let result be ParseJSONModule(source).

    この段で例外 %E が投出されたときは、 ~catchして ⇒# %~script の`構文解析-~error$sC ~SET %E; ~RET %~script ◎ If this throws an exception, catch it, and set script's parse error to that exception, and return script.

  3. %~script の`~record$sC ~SET %結果 ◎ Set script's record to result.
  4. ~RET %~script ◎ Return script.

`~module要請から~module種別を得る@ 手続きは、 所与の ( `~module要請~Record$ %~module要請 ) 対し,次に従う: ◎ The module type from module request steps, given a ModuleRequest Record moduleRequest, are as follows:

  1. %~module種別 ~LET `javascript-or-wasm^l ◎ Let moduleType be "javascript-or-wasm".
  2. ~IF[ %~module要請 .`Attributes^sl は、 `~Record$ %~entry として[ %~entry .`Key^sl ~EQ `type^l ]を満たすものを有する ]: ◎ If moduleRequest.[[Attributes]] has a Record entry such that entry.[[Key]] is "type", then:

    1. ~Assert: そのような`~Record$が複数個 在ることはない。 【この段は、この訳による補完。】
    2. ~IF[ %~entry .`Value^sl ~EQ `javascript-or-wasm^l ] ⇒ %~module種別 ~SET ~NULL ◎ If entry.[[Value]] is "javascript-or-wasm", then set moduleType to null.

      注記: この仕様は、[ `~JS~module~script$, `~WebAssembly~module~script$ ]用には,~module種別 `javascript-or-wasm^l を内部的に利用するので、 この段は,[ ~moduleが `javascript-or-wasm^l 種別~属性を利用して~importされる ]ことを防止するために必要になる ( %~module種別 ~NULL は、 `~module種別は許容されるか?$の検査を失敗させる)。 ◎ This specification uses the "javascript-or-wasm" module type internally for JavaScript module scripts or WebAssembly module scripts, so this step is needed to prevent modules from being imported using a "javascript-or-wasm" type attribute (a null moduleType will cause the module type allowed check to fail).

    3. ~ELSE ⇒ %~module種別 ~SET %~entry .`Value^sl ◎ Otherwise, set moduleType to entry.[[Value]].
  3. ~RET %~module種別 ◎ Return moduleType.

`~module種別は許容されるか?@ は、 所与の ( `文字列$ %~module種別, `環境~設定群~obj$ %設定群 ) に対し: ◎ The module type allowed steps, given a string moduleType and an environment settings object settings, are as follows:

  1. ~RET ~IS[ ~OR↓ ]:

    • %~module種別 ~IN { `javascript-or-wasm^l, `json^l }
    • [ %~module種別 ~EQ `css^l ]~AND[ `CSSStyleSheet$I ~interfaceは %設定群 の`~realm$enV 内に`公開されて$いる ]
    ◎ If moduleType is not "javascript-or-wasm", "css", or "json", then return false. ◎ If moduleType is "css" and the CSSStyleSheet interface is not exposed in settings's realm, then return false. ◎ Return true.

`~module種別から~fetch用の行先を得る@ ときは、 所与の ( `行先$rq %既定の行先, `文字列$ %~module種別 ) に対し ⇒ ~RET %~module種別 に応じて ⇒# `json^l ならば `json^l / `css^l ならば `style^l / ~ELSE_ %既定の行先 ◎ The fetch destination from module type steps, given a destination defaultDestination and a string moduleType, are as follows: • If moduleType is "json", then return "json". • If moduleType is "css", then return "style". • Return defaultDestination.

8.1.4.4. ~scriptの~call法

`古典~scriptを走らす@ ときは、 所与の ( `古典~script$ %~script, 真偽値 %~errorは再投出するか (省略時は ~F ) ) に対し: ◎ To run a classic script given a classic script script and an optional boolean rethrow errors (default false):

  1. %設定群 ~LET %~script の`設定群~obj$sC ◎ Let settings be the settings object of script.
  2. ~IF[ `~scriptは走れるかどうか検査する$( %設定群 ) ~EQ `走るな^i ] ⇒ ~RET `NormalCompletion$jA( `empty^i ) ◎ Check if we can run script with settings. If this returns "do not run" then return NormalCompletion(empty).
  3. `古典~scriptの実行~開始~時刻を記録する$( %~script ) ◎ Record classic script execution start time given script.
  4. `~scriptを走らすために準備する$( %設定群 ) ◎ Prepare to run script given settings.
  5. %評価~状態s ~LET ~NULL ◎ Let evaluationStatus be null.
  6. ~IF[ %~script の`再投出-用~error$sC ~NEQ ~NULL ] ⇒ %評価~状態s ~SET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET %~script の`再投出-用~error$sC, `Target^sl ~SET `empty^i ◎ If script's error to rethrow is not null, then set evaluationStatus to Completion { [[Type]]: throw, [[Value]]: script's error to rethrow, [[Target]]: empty }.
  7. ~ELSE:

    1. %評価~状態s ~SET `ScriptEvaluation$jA( %~script の`~record$sC )

      ~IF[ ~UAは`走っている~scriptを中止-$したため, `ScriptEvaluation$jA は完了しなかった ]:

      1. `走らせた~scriptを片付ける$( %設定群 )
      2. ~RET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET 新たな `QuotaExceededError$E 例外, `Target^sl ~SET `empty^i
    ◎ Otherwise, set evaluationStatus to ScriptEvaluation(script's record). ◎ If ScriptEvaluation does not complete because the user agent has aborted the running script, leave evaluationStatus as null. ◎ ↓↓
  8. ~IF[ %評価~状態s は`中途完了$である ]: ◎ If evaluationStatus is an abrupt completion, then:

    1. ~IF[ %~errorは再投出するか ~EQ ~T ]:

      1. `走らせた~scriptを片付ける$( %設定群 )
      2. ~THROW [ %~script の`~errorを黙秘するか$sC ]に応じて ⇒# ~T ならば `NetworkError$E / ~F ならば %評価~状態s .`Value^sl
      ◎ If rethrow errors is true and script's muted errors is false, then: • Clean up after running script with settings. • Rethrow evaluationStatus.[[Value]]. ◎ If rethrow errors is true and script's muted errors is true, then: • Clean up after running script with settings. • Throw a "NetworkError" DOMException.
    2. ~ELSE: ◎ Otherwise, rethrow errors is false. Perform the following steps:

      1. `例外を報告する$( %評価~状態s .`Value^sl, %~script の`設定群~obj$sCの`大域~obj$enV ) ◎ Report an exception given by evaluationStatus.[[Value]] for script's settings object's global object.
      2. `走らせた~scriptを片付ける$( %設定群 ) ◎ Clean up after running script with settings.
      3. ~RET %評価~状態s ◎ Return evaluationStatus.
  9. ~ELSE( %評価~状態s は正常完了である):

    1. `走らせた~scriptを片付ける$( %設定群 )
    2. ~RET %評価~状態s
    ◎ Clean up after running script with settings. ◎ If evaluationStatus is a normal completion, then return evaluationStatus. ◎ ↑↑If we've reached this point, evaluationStatus was left as null because the script was aborted prematurely during evaluation. Return Completion { [[Type]]: throw, [[Value]]: a new "QuotaExceededError" DOMException, [[Target]]: empty }.

`~module~scriptを走らす@ ときは、 所与の ( `~module~script$ %~script, 真偽値 %~error報告ngは防止するか (省略時は ~F ) ) に対し: ◎ To run a module script given a module script script and an optional boolean preventErrorReporting (default false):

  1. %設定群 ~LET %~script の`設定群~obj$sC ◎ Let settings be the settings object of script.
  2. ~IF[ `~scriptは走れるかどうか検査する$( %設定群 ) ~EQ `走るな^i ] ⇒ ~RET `却下される~promise$( `undefined^jv ) ◎ Check if we can run script with settings. If this returns "do not run", then return a promise resolved with undefined.
  3. `~module~scriptの実行~開始~時刻を記録する$( %~script ) ◎ Record module script execution start time given script.
  4. `~scriptを走らすために準備する$( %設定群 ) ◎ Prepare to run script given settings.
  5. %評価~promise ~LET ~NULL ◎ Let evaluationPromise be null.
  6. ~IF[ %~script の`再投出-用~error$sC ~NEQ ~NULL ] ⇒ %評価~promise ~SET `却下される~promise$( %~script の`再投出-用~error$sC ) ◎ If script's error to rethrow is not null, then set evaluationPromise to a promise rejected with script's error to rethrow.
  7. ~ELSE: ◎ Otherwise:

    1. %~record ~LET %~script の`~record$sC ◎ Let record be script's record.
    2. %評価~promise ~SET %~record .`Evaluate$jA() ◎ Set evaluationPromise to record.Evaluate().

      注記: この段は、 ~moduleの依存物すべてを再帰的に評価することになる。 ◎ This step will recursively evaluate all of the module's dependencies.

      ~IF[ ~UAが`走っている~scriptを中止-$したため, `Evaluate$jA は完了しなかった ] ⇒ %評価~promise ~SET `却下される~promise$( `QuotaExceededError$E 例外 ) ◎ If Evaluate fails to complete as a result of the user agent aborting the running script, then set evaluationPromise to a promise rejected with a new "QuotaExceededError" DOMException.

  8. ~IF[ %~error報告ngは防止するか ~EQ ~F ]: ◎ If preventErrorReporting is false, then\

    1. %評価~promise の`却下-時$には、 所与の ( 事由 %事由 ) に対し,次の手続きを走らす ⇒ `例外を報告する$( %事由, %~script の`設定群~obj$sCの`大域~obj$enV ) ◎ upon rejection of evaluationPromise with reason, report an exception given by reason for script's settings object's global object.
  9. `走らせた~scriptを片付ける$( %設定群 ) ◎ Clean up after running script with settings.
  10. ~RET %評価~promise ◎ Return evaluationPromise.

`~scriptは走れるかどうか検査する@ ときは、 所与の ( `環境~設定群~obj$ %設定群 ) に対し,次を走らす — これは、[ `走れ^i, `走るな^i ]のいずれかを返す: ◎ The steps to check if we can run script with an environment settings object settings are as follows. They return either "run" or "do not run".

  1. ~IF[ %設定群 の`大域~obj$enVは`~window$である ]~AND[ %設定群 の`文書$は`全部的に作動中$でない ] ⇒ ~RET `走るな^i ◎ If the global object specified by settings is a Window object whose Document object is not fully active, then return "do not run".
  2. ~IF[ %設定群 用の`~scriptingは不能化されて$sttいる ] ⇒ ~RET `走るな^i ◎ If scripting is disabled for settings, then return "do not run".
  3. ~RET `走れ^i ◎ Return "run".

`~scriptを走らすために準備する@ ときは、 所与の ( `環境~設定群~obj$ %設定群 ) に対し,次を走らす: ◎ The steps to prepare to run script with an environment settings object settings are as follows:

  1. `~JS実行~文脈~stack$に[ %設定群 の`~realm実行~文脈$enV ]を~pushする — この時点で、 それが`走っている~JS実行~文脈$になる。 ◎ Push settings's realm execution context onto the JavaScript execution context stack; it is now the running JavaScript execution context.
  2. `~surrounding~agent$の`~event~loop$aGの`現在~走っている~task$の`~script評価 環境~設定群~obj集合$tKに %設定群 を追加する ◎ Add settings to the surrounding agent's event loop's currently running task's script evaluation environment settings object set.

`走らせた~scriptを片付ける@ ときは、 所与の ( `環境~設定群~obj$ %設定群 ) に対し,次を走らす: ◎ The steps to clean up after running script with an environment settings object settings are as follows:

  1. ~Assert: %設定群 の`~realm実行~文脈$enVは、 `走っている~JS実行~文脈$である ◎ Assert: settings's realm execution context is the running JavaScript execution context.
  2. `~JS実行~文脈~stack$から, %設定群 の`~realm実行~文脈$enVを除去する ◎ Remove settings's realm execution context from the JavaScript execution context stack.
  3. ~IF[ `~JS実行~文脈~stack$は空になった ] ⇒ `小task~checkpointを遂行する$ (これが~scriptを走らす場合、 この~algoは,再入的に呼出されることになる。) ◎ If the JavaScript execution context stack is now empty, perform a microtask checkpoint. (If this runs scripts, these algorithms will be invoked reentrantly.)

注記: これらの~algoは、 ある~scriptが別の~scriptを直に~callして呼出されることはないが、 間接的な方式で再入的に呼出され得る — 例えば、 ~scriptが~eventを配送したとき,その~event用に~event~listenerが登録されている場合。 ◎ These algorithms are not invoked by one script directly calling another, but they can be invoked reentrantly in an indirect manner, e.g. if a script dispatches an event which has event listeners registered.

`走っている~script@ とは、 `走っている~JS実行~文脈$の~ScriptOrModule成分の `HostDefined^sl ~field内の`~script$である。 ◎ The running script is the script in the [[HostDefined]] field in the ScriptOrModule component of the running JavaScript execution context.

8.1.4.5. ~scriptの強制終了

`走っている~scriptを中止-@ する必要が生じることも,ときにはある — ~JS仕様はそのアリ性について織込んでいないが。 これは、[ `ScriptEvaluation$jA / `~source~text~module~Record$の `Evaluate$jA ]の呼出nがあれば即時に止めた上で, `finally^c ~blockの様な通常の仕組みを誘発することなく,`~JS実行~文脈~stack$を空にする。 `JAVASCRIPT$r ◎ Although the JavaScript specification does not account for this possibility, it's sometimes necessary to abort a running script. This causes any ScriptEvaluation or Source Text Module Record Evaluate invocations to cease immediately, emptying the JavaScript execution context stack without triggering any of the normal mechanisms like finally blocks. [JAVASCRIPT]

~UAは、 ~scriptに~~割り振る計算資源に制限を課してもヨイ — 例えば[ ~CPU~quota / ~memory / 実行~時間の総計 / 帯域幅 ]に対する制限など。 ~scriptがこれらの制限sを超過したときは、 ~UAは,次のいずれかを行ってもヨイ: ◎ User agents may impose resource limitations on scripts, for example CPU quotas, memory limits, total execution time limits, or bandwidth limitations. When a script exceeds a limit, the user agent may either\

  • `QuotaExceededError$E 例外を投出する
  • 例外を投出せずに~scriptを`中止-$する
  • 利用者に~promptする
  • ~script実行を絞る
◎ throw a "QuotaExceededError" DOMException, abort the script without an exception, prompt the user, or throttle script execution.

例えば、 次の~scriptは,決して終了しない。 ~UAは、 数~秒~待機した後に,利用者に[ ~scriptを終了するか,そのまま継続させるか ]を~promptすることもできる。 ◎ For example, the following script never terminates. A user agent could, after waiting for a few seconds, prompt the user to either terminate the script or let it continue.

<script>
 while (true) { /* loop */ }
</script>

~UAには、 次のときには,利用者が~scriptingを不能化できるようにすることが奨励される:

  • ~scriptが利用者に~promptしたとき (例えば `window.alert()$m ~APIを利用して)。
  • ~scriptの動作が何らかの制限-を超過したとき (例えば 時間~制限-)。
◎ User agents are encouraged to allow users to disable scripting whenever the user is prompted either by a script (e.g. using the window.alert() API) or because of a script's actions (e.g. because it has exceeded a time limit).

~scriptを実行している間に,~scriptingが不能化された場合、 ~scriptは即時に終了されるべきである。 ◎ If scripting is disabled while a script is executing, the script should be terminated immediately.

~UAは、 利用者が[ `閲覧~文脈$を何もさせずに閉じる目的で,特定的に~scriptを不能化する ]ことを許容してもヨイ。 ◎ User agents may allow users to specifically disable scripts just for the purposes of closing a browsing context.

例えば上の例で言及した~promptは、[ `unload$et ~event~handlerを走らすことなく,ただ~page全体を閉じる仕組み ]を利用者に提供することもできる。 ◎ For example, the prompt mentioned in the example above could also offer the user with a mechanism to just close the page entirely, without running any unload event handlers.

8.1.4.6. 稼働時の~script~error
%self .`reportError(e)$m
大域~objに向けて,所与の値 %e 用の `error$et ~eventを — 未取扱いな例外と同じ流儀で — 配送する。 ◎ Dispatches an error event at the global object for the given value e, in the same fashion as an unhandled exception.

`~error情報を抽出する@ ときは、 所与の ( ~JS値 %例外 ) に対し: ◎ To extract error information from a JavaScript value exception:

  1. %属性~群 ~LET 新たな`有順序~map$ — `ErrorEvent$I に定義される各~IDL属性を~keyに利用する。 ◎ Let attributes be an empty map keyed by IDL attributes.
  2. %属性~群[ `error$m ] ~SET %例外 ◎ Set attributes[error] to exception.
  3. ~EACH( %~key ~IN { `message$m, `filename$m, `lineno$m, `colno$m } ) に対し ⇒ %属性~群[ %~key ] ~SET %例外 から導出された`実装定義$な値 ◎ Set attributes[message], attributes[filename], attributes[lineno], and attributes[colno] to implementation-defined values derived from exception.

    注記: 各~browserは、[ ここ, および~JS仕様 ]においては指定されない,[ 【開発者に】役立つ値を集める挙動 ]を実装する — 通例的でない事例(例: `eval^c )を含めて。 将来においては、 これは,ずっと詳細に指定されるかもしれない。 ◎ Browsers implement behavior not specified here or in the JavaScript specification to gather values which are helpful, including in unusual cases (e.g., eval). In the future, this might be specified in greater detail.

  4. ~RET %属性~群 ◎ Return attributes.

`例外を報告する@ ときは、 所与の ⇒# ~JS値 %例外, `大域~obj$ %大域~obj, %~errorを省略するか ~IN { ε, `~errorを省略する^i } (省略時は ε ) ◎終 に対し: ◎ To report an exception exception which is a JavaScript value, for a particular global object global and optional boolean omitError (default false):

  1. %取扱われなかったか ~LET ~T ◎ Let notHandled be true.
  2. %~error報 ~LET `~error情報を抽出する$( %例外 ) ◎ Let errorInfo be the result of extracting error information from exception.
  3. %~script ~LET `実装定義$な仕方で見出された`~script$または ~NULL — これは、 通例的には,`走っている~script$になるベキである (とりわけ,`古典~scriptを走らす$間は)。 ◎ Let script be a script found in an implementation-defined way, or null. This should usually be the running script (most notably during run a classic script).

    注記: さほど共通でない事例において, どの~scriptを利用して~errorを黙秘するかどうか決定するかに関して、 各~実装は,まだ相互運用可能な挙動に決着してない。 ◎ Implementations have not yet settled on interoperable behavior for which script is used to determine whether errors are muted in less common cases.

  4. ~IF[ %~script は`古典~script$である ]~AND[ %~script の`~errorを黙秘するか$sC ~EQ ~T ] ⇒# %~error報[ `error$m ] ~SET ~NULL, %~error報[ `message$m ] ~SET `Script error.^l, %~error報[ `filename$m ] ~SET 空~文字列, %~error報[ `lineno$m ] ~SET 0, %~error報[ `colno$m ] ~SET 0 ◎ If script is a classic script and script's muted errors is true, then set errorInfo[error] to null, errorInfo[message] to "Script error.", errorInfo[filename] to the empty string, errorInfo[lineno] to 0, and errorInfo[colno] to 0.
  5. ~IF[ %~errorを省略するか ~EQ `~errorを省略する^i ] ⇒ %~error報[ `error$m ] ~SET ~NULL ◎ If omitError is true, then set errorInfo[error] to null.
  6. ~IF[ %大域~obj の`~error報告ng~modeか$gL ~EQ ~F ]: ◎ If global is not in error reporting mode, then:

    1. %大域~obj の`~error報告ng~modeか$gL ~SET ~T ◎ Set global's in error reporting mode to true.
    2. ~IF[ %大域~obj は `EventTarget$I を実装する ] ⇒ %取扱われなかったか ~SET `~eventを発火する$( %大域~obj, `error$et, `ErrorEvent$I ) — 次のように初期化して ⇒# `cancelable$m ~SET ~T, `ErrorEvent$I による追加的な各~属性を %~error報 に則って設定する ◎ If global implements EventTarget, then set notHandled to the result of firing an event named error at global, using ErrorEvent, with the cancelable attribute initialized to true, and additional attributes initialized according to errorInfo.

      注記: ~event~handlerが ~T を返した場合、 `~event~handler処理~algo$に従って, 当の~eventは取消されることになる。 ◎ Returning true in an event handler cancels the event per the event handler processing algorithm.

    3. %大域~obj の`~error報告ng~modeか$gL ~SET ~F ◎ Set global's in error reporting mode to false.
  7. ~IF[ %取扱われなかったか ~EQ ~T ]: ◎ If notHandled is true, then:

    1. %~error報[ `error$m ] ~SET ~NULL ◎ Set errorInfo[error] to null.
    2. ~IF[ %大域~obj は `DedicatedWorkerGlobalScope$I を実装する ] ⇒ `大域~taskを~queueする$( `~DOM操作~task~source$, %大域~obj に結付けられた `Worker$I ~objに`関連な大域~obj$, 次の手続き ) ◎ If global implements DedicatedWorkerGlobalScope, queue a global task on the DOM manipulation task source with the global's associated Worker's relevant global object to run these steps:

      手続きは:

      1. %~worker~obj ~LET %大域~obj に結付けられた `Worker$I ~obj ◎ Let workerObject be the Worker object associated with global.
      2. %取扱われなかったか ~SET `~eventを発火する$( %~worker~obj, `error$et, `ErrorEvent$I ) — 次のように初期化して ⇒# `cancelable$m 属性 ~SET ~T, `ErrorEvent$I による追加的な各~属性を %~error報 に則って設定する ◎ Set notHandled be the result of firing an event named error at workerObject, using ErrorEvent, with the cancelable attribute initialized to true, and additional attributes initialized according to errorInfo.
      3. ~IF[ %取扱われなかったか ~EQ ~T ] ⇒ `例外を報告する$( %例外, %~worker~obj に`関連な大域~obj$, `~errorを省略する^i ) ◎ If notHandled is true, then report exception for workerObject's relevant global object with omitError set to true.

        注記: 実際の %例外 値は,所有者~realm内では可用にならないが、 それでも,~UAは[ `message$m, `filename$m, その他の属性を設定する ]ため, および[ 場合によっては,開発者~consoleへ報告する ]ために十分な情報を成し遂げる。 ◎ The actual exception value will not be available in the owner realm, but the user agent still carries through enough information to set the message, filename, and other attributes, as well as potentially report to a developer console.

  8. ~ELSE ⇒ 任意選択で ⇒ %例外 を開発者~consoleへ報告する ◎ Otherwise, the user agent may report exception to a developer console.

`Worker$I ~objへ接続している`暗黙的な~port$への連絡が絶たれていた場合 (すなわち,当の~workerの親~workerが終了されていた場合)、 ~UAは[ 当の `Worker$I ~objには `error$et ~event~handlerは無かった ]かつ[ その~workerの `onerror@~WORKERS#handler-workerglobalscope-onerror$m 属性は ~NULLであった ]かのように動作するモノトスル。 他の場合は、 上で述べたとおり動作するモノトスル。 ◎ If the implicit port connecting a worker to its Worker object\ has been disentangled (i.e. if the parent worker has been terminated), then the user agent must act as if the Worker object had no error event handler and as if that worker's onerror attribute was null,\ but must otherwise act as described above.

注記: したがって,~error報告は、 専用~workerたちが成す連鎖を遡って,元の`文書$まで伝播する — この連鎖~沿いに在る いずれかの~workerが終了され,~garbage収集された場合でも。 ◎ Thus, error reports propagate up to the chain of dedicated workers up to the original Document, even if some of the workers along this chain have been terminated and garbage collected.

この仕様の以前の改訂は, `例外を報告する@#report-the-exception@ ( `report the exception^en ) ~algoを`課題 #958@~HTMLissue/958$ の一部として定義したが、 挙動も入力も異なる この~algo — `例外を報告する$( `report an exception^en ) — に取って代わられた。 この[ 仕様~levelの~ecosystem ]を更新することは、 `課題 #10516@~HTMLissue/10516$ にて追跡される。 ◎ Previous revisions of this standard defined an algorithm to report the exception. As part of issue #958, this has been superseded by report an exception which behaves differently and takes different inputs. Issue #10516 tracks updating the specification ecosystem.


`WindowOrWorkerGlobalScope$I の `reportError(e)@m ~method手続きは ⇒ `例外を報告する$( %e, コレ ) ◎ The reportError(e) method steps are to report the exception e.

ここで`~errorを黙秘するか$sCが適用-可能かどうかは、 不明瞭である — Chrome, Safari は黙秘する一方で, Firefox は黙秘しない。 `課題 #958@~HTMLissue/958$ も見よ。 ◎ It is unclear whether muting is applicable here. In Chrome and Safari it is muted, but in Firefox it is not. See also issue #958.


`ErrorEvent$I ~interfaceは、 次で定義される: ◎ The ErrorEvent interface is defined as follows:

[Exposed=*]
interface `ErrorEvent@I : `Event$I {
  `constructor$(DOMString %type, optional `ErrorEventInit$I %eventInitDict = {});

  readonly attribute DOMString `message$m;
  readonly attribute USVString `filename$m;
  readonly attribute unsigned long `lineno$m;
  readonly attribute unsigned long `colno$m;
  readonly attribute any `error$m;
};

dictionary `ErrorEventInit@I : `EventInit$I {
  DOMString %message = "";
  USVString %filename = "";
  unsigned long %lineno = 0;
  unsigned long %colno = 0;
  any %error;
};
`message@m 取得子~手続きは、 初期化-時の値を返す。 結果は、 ~error~messageを表現する。 ◎ The message attribute must return the value it was initialized to.\ It represents the error message.
`filename@m 取得子~手続きは、 初期化-時の値を返す。 結果は、 ~scriptにおいて~errorが元々生じた所の`~URL$を表現する。 ◎ The filename attribute must return the value it was initialized to.\ It represents the URL of the script in which the error originally occurred.
`lineno@m 取得子~手続きは、 初期化-時の値を返す。 結果は、 ~scriptにおいて~errorが元々生じた所の行l番号を表現する。 ◎ The lineno attribute must return the value it was initialized to.\ It represents the line number where the error occurred in the script.
`colno@m 取得子~手続きは、 初期化-時の値を返す。 結果は、 ~scriptにおいて~errorが元々生じた所の~col番号を表現する。 ◎ The colno attribute must return the value it was initialized to.\ ◎ It represents the column number where the error occurred in the script.
`error@m 取得子~手続きは、 初期化-時の値を返す。 初期~時には `undefined^jv に初期化するモノトスル。 結果は、 適切になる所では,~errorを表現している~objになる (例: 例外が~catchされなかった事例では、 例外~objになる)。 ◎ The error attribute must return the value it was initialized to.\ It must initially be initialized to undefined. Where appropriate, it is set to the object representing the error (e.g., the exception object in the case of an uncaught exception).
8.1.4.7. 未取扱いな~promise却下

同期的な`稼働時の~script~error$に加えて、 ~scriptは,非同期的な~promise却下に出くわすこともある — それは、[ `unhandledrejection$et, `rejectionhandled$et ]~eventを介して追跡される。 これらの却下の追跡は, `HostPromiseRejectionTracker@#the-hostpromiserejectiontracker-implementation$A 抽象-演算を介して行われるが、 それらの報告-法は,ここで定義される。 ◎ In addition to synchronous runtime script errors, scripts may experience asynchronous promise rejections, tracked via the unhandledrejection and rejectionhandled events. Tracking these rejections is done via the HostPromiseRejectionTracker abstract operation, but reporting them is defined here.

`却下-済み~promiseについて通知する@ ときは、 所与の ( `大域~obj$ %大域~obj ) に対し: ◎ To notify about rejected promises given a global object global:

  1. %~list ~LET %大域~obj の`通知待ちな却下-済み~promise~list$gLを`~cloneする$ ◎ Let list be a clone of global's about-to-be-notified rejected promises list.
  2. ~IF[ %~list は`空$である ] ⇒ ~RET ◎ If list is empty, then return.
  3. %大域~obj の`通知待ちな却下-済み~promise~list$gLを`空にする$ ◎ Empty global's about-to-be-notified rejected promises list.
  4. `大域~taskを~queueする$( `~DOM操作~task~source$, %大域~obj, 次の手続き ) ◎ Queue a global task on the DOM manipulation task source given global to\

    手続きは: ◎ run the following step:

    1. %~list を成す ~EACH( ~promise %p ) に対し: ◎ For each promise p of list:

      1. ~IF[ %p . `PromiseIsHandled^sl ~EQ ~T ] ⇒ ~CONTINUE ◎ If p.[[PromiseIsHandled]] is true, then continue.
      2. %取消されなかったか ~LET `~eventを発火する$( %大域~obj, `unhandledrejection$et, `PromiseRejectionEvent$I ) — 次のように初期化して ⇒# `cancelable$m ~SET ~T, `promise$m ~SET %p, `reason$m ~SET %p . `PromiseResult^sl ◎ Let notCanceled be the result of firing an event named unhandledrejection at global, using PromiseRejectionEvent, with the cancelable attribute initialized to true, the promise attribute initialized to p, and the reason attribute initialized to p.[[PromiseResult]].
      3. ~IF[ %取消されなかったか ~EQ ~T ] ⇒ 任意選択で ⇒ %p . `PromiseResult^sl を開発者~consoleへ報告する ◎ If notCanceled is true, then the user agent may report p.[[PromiseResult]] to a developer console.
      4. ~IF[ %p . `PromiseIsHandled^sl ~EQ ~F ] ⇒ %大域~obj の`未決な却下-済み~promiseへの弱い参照たちが成す集合$gLに %p を`付加する$set ◎ If p.[[PromiseIsHandled]] is false, then append p to global's outstanding rejected promises weak set.

`PromiseRejectionEvent$I ~interfaceは、 次で定義される: ◎ The PromiseRejectionEvent interface is defined as follows:

[Exposed=*]
interface `PromiseRejectionEvent@I : `Event$I {
  `constructor$(DOMString %type, `PromiseRejectionEventInit$I %eventInitDict);

  readonly attribute `object$ `promise$m;
  readonly attribute any `reason$m;
};

dictionary `PromiseRejectionEventInit@I : `EventInit$I {
  required `object$ promise;
  any reason;
};
`promise@m 取得子~手続きは、 初期化-時の値を返す。 結果は、 この通知が~~対象にしている~promiseを表現する。 ◎ The promise attribute must return the value it was initialized to.\ It represents the promise which this notification is about.

注記: ~Web~IDLにおける `Promise$<%T> 型~用の変換~規則は, 入力を常に新たな~promiseの中に包装するので、 `promise$m 属性の型は代わりに `object$ にする方が, 元の~promise~objへの不透明な~handleを表現するためには適切になる。 ◎ Because of how Web IDL conversion rules for Promise<T> types always wrap the input into a new promise, the promise attribute is of type object instead, which is more appropriate for representing an opaque handle to the original promise object.

`reason@m 取得子~手続きは、 初期化-時の値を返す。 結果は、 ~promiseの却下~事由を表現する。 ◎ The reason attribute must return the value it was initialized to.\ It represents the rejection reason for the promise.
8.1.4.8. ~import~map構文解析-結果

`~import~map構文解析-結果@ は、 `~script$に類似な`構造体$であり, `script$e 要素の`結果$scE内に格納されるが、 他の目的においては,`~script$として数えられない。 それは、 次に挙げる`~item$sctからなる: ◎ An import map parse result is a struct that is similar to a script, and also can be stored in a script element's result, but is not counted as a script for other purposes. It has the following items:

`~import~map@impR ◎ An import map
ある`~import~map$/ ~NULL ◎ An import map or null.
`再投出-用~error@impR ◎ An error to rethrow
~errorを表現している~JS値/~NULL — ~NULL でない場合、 この~import~mapを利用できなくする。 ◎ A JavaScript value representing an error that will prevent using this import map, when non-null.

`~import~map構文解析-結果を作成する@ ときは、 所与の ( `文字列$ %入力, `~URL$ %基底~URL ) に対し: ◎ To create an import map parse result given a string input and a URL baseURL:

  1. %結果 ~LET 新たな`~import~map構文解析-結果$ — その ⇒# `~import~map$impR ~SET ~NULL, `再投出-用~error$impR ~SET ~NULL ◎ Let result be an import map parse result whose import map is null and whose error to rethrow is null.
  2. %結果 の`~import~map$impR ~SET `~import~map文字列を構文解析する$( %入力, %基底~URL ) ◎ Parse an import map string given input and baseURL,\

    例外が投出されたときは、 ~catchして ⇒ %結果 の`再投出-用~error$impR ~SET その例外 ◎ catching any exceptions. If this threw an exception, then set result's error to rethrow to that exception. Otherwise, set result's import map to the return value.

  3. ~RET %結果 ◎ Return result.

`~import~mapを登録する@ ときは、 所与の ( `Window$I %大域~obj, `~import~map構文解析-結果$ %結果 ) に対し: ◎ To register an import map given a Window global and an import map parse result result:

  1. ~IF[ %結果 の`再投出-用~error$impR ~NEQ ~NULL ] ⇒# `例外を報告する$( %結果 の`再投出-用~error$impR, %大域~obj ); ~RET ◎ If result's error to rethrow is not null, then report an exception given by result's error to rethrow for global and return.
  2. `既存の~import~mapと新たな~import~mapを併合する$( %大域~obj, %結果 の`~import~map$impR ) ◎ Merge existing and new import maps, given global and result's import map.

8.1.5. ~module指定子の解決

8.1.5.1. 解決~algo

`~module指定子を解決する$~algoは、 ~module指定子~文字列を`~URL$へ変換するための首な入口点である。 それは、 孕まれる`~import~map$が無い場合には比較的~単直であり, `~URLの様な~module指定子を解決する$ことに抑制される。 ◎ The resolve a module specifier algorithm is the primary entry point for converting module specifier strings into URLs. When no import maps are involved, it is relatively straightforward, and reduces to resolving a URL-like module specifier.

空でない`~import~map$が在る場合、 ~algoの挙動は,より複階的になる。 それは、 適用-可能なすべての`~module指定子~map$から各~候補~entryを検査する — 各`~scope群$iMを最も特定度が高いものから順に (~top-levelの(~scopeされない)`~import群$iMに~fall-backする), および 各~接頭辞を最も特定度が高いものから順に。 各~候補には、 `~import群との合致-を解決する$~algoが適用される — それは、 次に挙げるいずれかの結果を与えることになる: ◎ When there is a non-empty import map present, the behavior is more complex. It checks candidate entries from all applicable module specifier maps, from most-specific to least-specific scopes (falling back to the top-level unscoped imports), and from most-specific to least-specific prefixes. For each candidate, the resolve an imports match algorithm will give on the following results:

  • 当の指定子は、 ある`~URL$に成功裡に解決される ⇒ `~module指定子を解決する$~algoは、 結果の~URLを返すことになる。 ◎ Successful resolution of the specifier to a URL. Then the resolve a module specifier algorithm will return that URL.
  • 例外を投出する ⇒ `~module指定子を解決する$~algoは、 更なる~fallbackを伴わずに,その例外を再投出することになる。 ◎ Throwing an exception. Then the resolve a module specifier algorithm will rethrow that exception, without any further fallbacks.
  • ~errorを伴わずに失敗する ⇒ この事例では、 `~module指定子を解決する$~algoは、 その次の候補へ移ることになる。 ◎ Failing to resolve, without an error. In this case the outer resolve a module specifier algorithm will move on to the next candidate.

`~module指定子を解決する$~algoは、 その終了までに[ どの候補`~module指定子~map$を介しても,成功裡な解決が見出されなかった ]場合には,例外を投出することになる。 したがって、 その結果は,常に[ `~URL$, 投出された例外 ]いずれかになる。 ◎ In the end, if no successful resolution is found via any of the candidate module specifier maps, resolve a module specifier will throw an exception. Thus the result is always either a URL or a thrown exception.

`~module指定子を解決する@ ときは、 所与の ( [ `~script$【!`script$e】/~NULL ] %参照rしている~script, `文字列$ %指定子 ) に対し: ◎ To resolve a module specifier given a script-or-null referringScript and a string specifier:

  1. %設定群~obj ~LET ~NULL ◎ ↓
  2. %基底~URL ~LET ~NULL ◎ Let settingsObject and baseURL be null.
  3. ~IF[ %参照rしている~script ~NEQ ~NULL ]: ◎ If referringScript is not null, then:

    1. %設定群~obj ~SET %参照rしている~script の`設定群~obj$sC ◎ Set settingsObject to referringScript's settings object.
    2. %基底~URL ~SET %参照rしている~script の`基底~URL$sC ◎ Set baseURL to referringScript's base URL.
  4. ~ELSE: ◎ Otherwise:

    1. ~Assert: `現在の設定群~obj$は在る。 【参考:`課題 #8410@~HTMLissue/8410$】 ◎ Assert: there is a current settings object.
    2. %設定群~obj ~SET `現在の設定群~obj$ ◎ Set settingsObject to the current settings object.
    3. %基底~URL ~SET %設定群~obj の`~API用~基底~URL$enV ◎ Set baseURL to settingsObject's API base URL.
  5. %~import~map ~LET `空な~import~map$ ◎ Let importMap be an empty import map.
  6. ~IF[ %設定群~obj の`大域~obj$enV は `Window$I を実装する ] ⇒ %~import~map ~SET %設定群~obj の`大域~obj$enVの`~import~map$gL ◎ If settingsObject's global object implements Window, then set importMap to settingsObject's global object's import map.
  7. %直列化-済み基底~URL ~LET `~URLを直列化する$( %基底~URL ) ◎ Let serializedBaseURL be baseURL, serialized.
  8. %~as~URL ~LET `~URLの様な~module指定子を解決する$( %指定子, %基底~URL ) ◎ Let asURL be the result of resolving a URL-like module specifier given specifier and baseURL.
  9. %正規化-済み指定子 ~LET %~as~URL に応じて ⇒# ~NULL ならば ~NULL / ~ELSE_ `~URLを直列化する$( %~as~URL ) ◎ Let normalizedSpecifier be the serialization of asURL, if asURL is non-null; otherwise, specifier.
  10. %結果 ~LET ~NULL【!a URL-or-null, initially null】 ◎ Let result be a URL-or-null, initially null. ◎ ↓
  11. %~import~map の`~scope群$iMを成す ~EACH( %~scope接頭辞 → %~scope~import群 ) に対し: ◎ For each scopePrefix → scopeImports of importMap's scopes:

    1. ~IF[ %~scope接頭辞 ~EQ %直列化-済み基底~URL ]~OR[[ %~scope接頭辞 は `/^l `で終端して$いる ]~AND[ %~scope接頭辞 は %直列化-済み基底~URL の`符号単位~接頭辞$である ]]: ◎ If scopePrefix is serializedBaseURL, or if scopePrefix ends with U+002F (/) and scopePrefix is a code unit prefix of serializedBaseURL, then:

      1. %~scope~import群との合致- ~LET `~import群との合致-を解決する$( %正規化-済み指定子, %~as~URL, %~scope~import群 ) ◎ Let scopeImportsMatch be the result of resolving an imports match given normalizedSpecifier, asURL, and scopeImports.
      2. ~IF[ %~scope~import群との合致- ~NEQ ~NULL ] ⇒# %結果 ~SET %~scope~import群との合致-; ~BREAK ◎ If scopeImportsMatch is not null, then set result to scopeImportsMatch, and break.
  12. ~IF[ %結果 ~EQ ~NULL ] ⇒ %結果 ~SET `~import群との合致-を解決する$( %正規化-済み指定子, %~as~URL, %~import~map の`~import群$iM ) ◎ If result is null, set result be the result of resolving an imports match given normalizedSpecifier, asURL, and importMap's imports.
  13. 注記: この時点では、[ %結果 ~EQ ~NULL ]ならば, %指定子 は %~import~map により何かへ対応付-直されなかったが、 ~URLに転じることは可能かもしれない。 ◎ At this point, if result is null, specifier wasn't remapped to anything by importMap, but it might have been able to be turned into a URL.

    ~IF[ %結果 ~EQ ~NULL ] ⇒ %結果 ~SET %~as~URL ◎ If result is null, set it to asURL.

  14. ~IF[ %結果 ~NEQ ~NULL ]: ◎ If result is not null, then:

    1. ~Assert: %結果 は`~URL$である。 ◎ ↑
    2. `解決-済み~module集合に~moduleを追加する$( ↓ ) ⇒# %設定群~obj, %直列化-済み基底~URL, %正規化-済み指定子, %~as~URL ◎ Add module to resolved module set given settingsObject, serializedBaseURL, normalizedSpecifier, and asURL.
    3. ~RET %結果 ◎ Return result.
  15. ~THROW `TypeError$jc — これは、 次を指示する ⇒ %指定子 は裸な指定子であったが, %~import~map により何かへ対応付-直されなかった。 ◎ Throw a TypeError indicating that specifier was a bare specifier, but was not remapped to anything by importMap.

`~import群との合致-を解決する@ ときは、 所与の ( `文字列$ %正規化-済み指定子, [ `~URL$/~NULL ] %~as~URL, `~module指定子~map$ %指定子~map ) に対し: ◎ To resolve an imports match, given a string normalizedSpecifier, a URL-or-null asURL, and a module specifier map specifierMap:

  1. %指定子~map を成す ~EACH( %指定子~key → %解決~結果 ) に対し: ◎ For each specifierKey → resolutionResult of specifierMap:

    1. ~IF[ %指定子~key ~EQ %正規化-済み指定子 ]: ◎ If specifierKey is normalizedSpecifier, then:

      1. ~IF[ %解決~結果 ~EQ ~NULL ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ %指定子~key の解決は、 ある ~NULL ~entryにより阻まれた。 ◎ If resolutionResult is null, then throw a TypeError indicating that resolution of specifierKey was blocked by a null entry.

        注記: これは、 `~module指定子を解決する$~algo全体を — 更なる~fallbackを伴うことなく — 終了させることになる。 ◎ This will terminate the entire resolve a module specifier algorithm, without any further fallbacks.

      2. ~Assert: %解決~結果 は`~URL$である ◎ Assert: resolutionResult is a URL.
      3. ~RET %解決~結果 ◎ Return resolutionResult.
    2. ~IF[ ~AND↓ ]… ◎ If all of the following are true:

      • %指定子~key は `/^l `で終端して$いる ◎ specifierKey ends with U+002F (/);
      • %指定子~key は、 %正規化-済み指定子 の`符号単位~接頭辞$である ◎ specifierKey is a code unit prefix of normalizedSpecifier; and
      • [ %~as~URL ~EQ ~NULL ]~OR[ %~as~URL は`特別$urlである ] ◎ either asURL is null, or asURL is special,

      …ならば: ◎ then:

      1. ~IF[ %解決~結果 ~EQ ~NULL ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ %指定子~key の解決は,ある ~NULL ~entryにより阻まれた。 ◎ If resolutionResult is null, then throw a TypeError indicating that the resolution of specifierKey was blocked by a null entry.

        注記: これは、 `~module指定子を解決する$~algo全体を — 更なる~fallbackを伴うことなく — 終了させることになる。 ◎ This will terminate the entire resolve a module specifier algorithm, without any further fallbacks.

      2. ~Assert: %解決~結果 は`~URL$である。 ◎ Assert: resolutionResult is a URL.
      3. %接頭辞より後 ~LET %正規化-済み指定子 の中の[ %指定子~key の`長さ$ ]から`終端までを成す符号単位~部分文字列$ ◎ Let afterPrefix be the portion of normalizedSpecifier after the initial specifierKey prefix.
      4. ~Assert: [ `~URLを直列化する$( %解決~結果 ) の結果 ]は、 `/^l `で終端して$いる — `~import~map文字列を構文解析する$ときに,そうなるよう施行されたので。 ◎ Assert: resolutionResult, serialized, ends with U+002F (/), as enforced during parsing.
      5. %~URL ~LET `~URL構文解析する$( %接頭辞より後, %解決~結果 ) ◎ Let url be the result of URL parsing afterPrefix with resolutionResult.
      6. ~IF[ %~URL ~EQ `失敗^i ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ %正規化-済み指定子 の解決は阻まれた — %接頭辞より後 を成す部位は[ %指定子~key 接頭辞により対応付けられた %解決~結果 ]に相対的に~URL構文解析できなかったので。 ◎ If url is failure, then throw a TypeError indicating that resolution of normalizedSpecifier was blocked since the afterPrefix portion could not be URL-parsed relative to the resolutionResult mapped to by the specifierKey prefix.

        注記: これは、 `~module指定子を解決する$~algo全体を — 更なる~fallbackを伴うことなく — 終了させることになる。 ◎ This will terminate the entire resolve a module specifier algorithm, without any further fallbacks.

      7. ~Assert: %~URL は`~URL$である。 ◎ Assert: url is a URL.
      8. ~IF[[ `~URLを直列化する$( %解決~結果 ) の結果 ]は[ `~URLを直列化する$( %~URL ) の結果 ]の`符号単位~接頭辞$でない ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ %正規化-済み指定子 の解決は、[ その接頭辞 %指定子~key の上へ引き~~返している( `backtracking above^en ) ]ことに因り阻まれた ◎ If the serialization of resolutionResult is not a code unit prefix of the serialization of url, then throw a TypeError indicating that the resolution of normalizedSpecifier was blocked due to it backtracking above its prefix specifierKey.

        注記: これは、 `~module指定子を解決する$~algo全体を — 更なる~fallbackを伴うことなく — 終了させることになる。 ◎ This will terminate the entire resolve a module specifier algorithm, without any further fallbacks.

      9. ~RET %~URL ◎ Return url.
  2. ~RET ~NULL ◎ Return null.

    注記: `~module指定子を解決する$~algoは、 より特定度が低い~scope — あるいは,アリな場合は `imports^l — へ~fall-backすることになる。 ◎ The resolve a module specifier algorithm will fall back to a less-specific scope, or to "imports", if possible.

`~URLの様な~module指定子を解決する@ ときは、 所与の ( `文字列$ %指定子, `~URL$ %基底~URL ) に対し: ◎ To resolve a URL-like module specifier, given a string specifier and a URL baseURL:

  1. ~IF[ %指定子 は 次に挙げるいずれか`から開始して$いる ]… ⇒# `/^l, `./^l, `../^l ◎終 …ならば: ◎ If specifier starts with "/", "./", or "../", then:

    1. %~URL ~LET `~URL構文解析する$( %指定子, %基底~URL ) ◎ Let url be the result of URL parsing specifier with baseURL.
    2. ~IF[ %~URL ~EQ `失敗^i ] ⇒ ~RET ~NULL ◎ If url is failure, then return null.

      これは、 例えば,次が満たされる場合に起こり得る ⇒ [ %指定子 ~EQ `../foo^l ]~AND[ %基底~URL の`~scheme$url ~EQ "`data@~RFCx/rfc2397#section-2$sc" ] ◎ One way this could happen is if specifier is "../foo" and baseURL is a data: URL.

    3. ~RET %~URL ◎ Return url.

    注記: これは、 %指定子 が `//^l `から開始して$いる事例 — すなわち,~schemeに相対的な~URLである事例 — を含む。 したがって、 %~URL の`~host$urlは, %基底~URL のそれと同じになるとは限らない。 ◎ This includes cases where specifier starts with "//", i.e., scheme-relative URLs. Thus, url might end up with a different host than baseURL.

  2. %~URL ~LET `~URL構文解析する$( %指定子 ) — (基底~URLは与えない) ◎ Let url be the result of URL parsing specifier (with no base URL).
  3. ~IF[ %~URL ~EQ `失敗^i ] ⇒ ~RET ~NULL ◎ If url is failure, then return null.
  4. ~RET %~URL ◎ Return url.
8.1.5.2. ~import~map

`~import~map$は、 ~module指定子の解決に対する制御を許容する。 ~import~mapは、 ~inlineな `script$e 要素のうち[ ~AND↓ を満たすもの ]を介して送達される: ◎ An import map allows control over module specifier resolution. Import maps are delivered via inline script elements\

  • その `type$a 属性は `importmap^l に設定されている ◎ with their type attribute set to "importmap",\
  • その`子~text内容$は、 当の~import~mapの~JSON表現を包含している ◎ and with their child text content containing a JSON representation of the import map.

各`文書$においては、 複数の~import~mapが処理され得る。 それは、 どの~moduleに対しても,それが~importされる前にも後にも起こり得る — 例:[ `import()$m 式/ `type$a 属性が `module^l に設定された `script$e 要素 ]を介して。 `既存の~import~mapと新たな~import~mapを併合する$~algoは、 次を確保する ⇒ 新たな~import~mapは、 すでに[ 過去の~import~mapにより定義された~module/ 解決された~module ]用には,~module解決を定義し得ない。 ◎ A Document can have multiple import maps processed, which can happen either before or after any modules have been imported, e.g., via import() expressions or script elements with their type attribute set to "module". The merge existing and new import maps algorithm ensures that new import maps cannot define the module resolution for modules that were already defined by past import maps, or for ones that were already resolved.

最も単純な~import~mapの利用は、 裸な~module指定子を大域的に対応付-直すことである: ◎ The simplest use of import maps is to globally remap a bare module specifier:

{
  "imports": {
    "moment": "/node_modules/moment/src/moment.js"
  }
}

これは、 `import moment from "moment";^c の様な文が[ ~URL `/node_modules/moment/src/moment.js^c にある~JS~moduleを~fetchして評価する ]ように働くことを可能化する。 ◎ This enables statements like import moment from "moment"; to work, fetching and evaluating the JavaScript module at the /node_modules/moment/src/moment.js URL.

~import~mapは、 末尾に~slashを利用することにより, ある~classの~module指定子を ある~classの~URLに対応付-直せる — 次の様に: ◎ An import map can remap a class of module specifiers into a class of URLs by using trailing slashes, like so:

{
  "imports": {
    "moment/": "/node_modules/moment/src/"
  }
}

これは、 `import localeData from "moment/locale/zh-cn.js";^c の様な文が[ ~URL `/node_modules/moment/src/locale/zh-cn.js^c にある~JS~moduleを~fetchして評価する ]よう働くことを可能化する。 そのような末尾の~slashによる対応付けは、 裸な指定子による対応付けと組合されることが多い — 例: ◎ This enables statements like import localeData from "moment/locale/zh-cn.js"; to work, fetching and evaluating the JavaScript module at the /node_modules/moment/src/locale/zh-cn.js URL. Such trailing-slash mappings are often combined with bare-specifier mappings, e.g.

{
  "imports": {
    "moment": "/node_modules/moment/src/moment.js",
    "moment/": "/node_modules/moment/src/"
  }
}

— 次のどちらも可用になるよう ⇒# `moment^l により 指定される “~main~module”, `moment/locale/zh-cn.js^l など,~pathにより指定される “下位-~module” ◎ so that both the "main module" specified by "moment" and the "submodules" specified by paths such as "moment/locale/zh-cn.js" are available.

~import~mapが対応付-直せる~module指定子は、 裸な指定子に限られない。 “~URLの様な” 指定子 — すなわち,次に挙げるもの: ◎ Bare specifiers are not the only type of module specifiers which import maps can remap. "URL-like" specifiers, i.e.,\

  • 絶対~URLとして構文解析-可能な文字列 ◎ those that are either parseable as absolute URLs or\ ◎ start with "/", "./", or "../",\
  • 次に挙げるいずれかから開始している文字列 ⇒# `/^l, `./^l, `../^l

も,対応付-直せる: ◎ can be remapped as well:

{
  "imports": {
    "https://cdn.example.com/vue/dist/vue.runtime.esm.js": "/node_modules/vue/dist/vue.runtime.esm.js",
    "/js/app.mjs": "/js/app-8e0d62a03.mjs",
    "../helpers/": "https://cdn.example/helpers/"
  }
}

[ 対応付-直される~URL, 対応付けられている~URL ]どちらも, 絶対~URLとして, あるいは[[ `/^l, `./^l, `../^l ]いずれかから開始している相対~URL ]として指定できる様子に注意 (相対~URLが,これらの文字列から開始する必要があるのは、 裸な~module指定子と判別し易くするためである)。 `末尾の~slashによる対応付け@#example-import-map-trailing-slashes$が, この文脈においてどう働くかにも注意。 ◎ Note how the URL to be remapped, as well as the URL being mapped to, can be specified either as absolute URLs, or as relative URLs starting with "/", "./", or "../". (They cannot be specified as relative URLs without those starting sigils, as those help distinguish from bare module specifiers.) Also note how the trailing slash mapping works in this context as well.

そのような対応付-直しは、 正準-化した後における~URLに対し演算する — [ ~import~mapの~keyとして給された,そのままの文字列 ]と[ ~importされる~module指定子 ]が合致することは要求されない。 なので、 例えば,この~import~mapが `https://example.com/app.html^c 上に含まれる場合、 `import "/js/app.mjs"^c のみならず, `import "./js/app.mjs"^c も `import "./foo/../js/app.mjs"^c も 対応付-直されることになる。 ◎ Such remappings operate on the post-canonicalization URL, and do not require a match between the literal strings supplied in the import map key and the imported module specifier. So for example, if this import map was included on https://example.com/app.html, then not only would import "/js/app.mjs" be remapped, but so would import "./js/app.mjs" and import "./foo/../js/app.mjs".

これまでの例は、 どれも,[ 当の~import~map内の~top-levelの~key `imports^l ]を利用して[ 大域的に対応付-直される~module指定子 ]を与えていた。 ~top-levelの~key `scopes^l を利用することで、 局所-化された対応付-直しを供せる — それは、[ 参照rしている~moduleが特定の~URL接頭辞に合致するとき ]に限り,適用される。 例えば: ◎ All previous examples have globally remapped module specifiers, by using the top-level "imports" key in the import map. The top-level "scopes" key can be used to provide localized remappings, which only apply when the referring module matches a specific URL prefix. For example:

{
  "scopes": {
    "/a/" : {
      "moment": "/node_modules/moment/src/moment.js"
    },
    "/b/" : {
      "moment": "https://cdn.example.com/moment/src/moment.js"
    }
  }
}

この~import~mapの下では、 文 `import "moment"^c の意味は,[ どの参照元~scriptが,この文を包含するか ]に依存して異なることになる: ◎ With this import map, the statement import "moment" will have different meanings depending on which referrer script contains the statement:

  • `/a/^c の下に所在する~scriptの内側では、 これは, `/node_modules/moment/src/moment.js^c を~importすることになる。 ◎ Inside scripts located under /a/, this will import /node_modules/moment/src/moment.js.
  • `/b/^c の下に所在する~scriptの内側では、 これは, `https://cdn.example.com/moment/src/moment.js^c を~importすることになる。 ◎ Inside scripts located under /b/, this will import https://cdn.example.com/moment/src/moment.js.
  • `/c/^c の下に所在する~scriptの内側では、 これは,解決に失敗して例外を投出することになる。 ◎ Inside scripts located under /c/, this will fail to resolve and thus throw an exception.

~scopeの代表的な用法は、[ ~web~app内に “同じ” ~moduleを成す複数の~versionが存在する ]ことを許容することにある — ~module~graphを成す ある部分は,ある~versionを~importして、 他の部分は別の~versionを~importするよう。 ◎ A typical usage of scopes is to allow multiple versions of the "same" module to exist in a web application, with some parts of the module graph importing one version, and other parts importing another version.

~scopeは[ 互いに/大域的な `imports^l 指定子~mapと ]重なり合い得る。 解決の際には、 ~scopeは,最も特定度が高いものから順に諮られる — この特定度は、[ ~LT`符号単位$sub 演算を利用して,~scopeたちを~sortする ]ことにより測定される。 なので、 例えば ⇒# `/scope2/scope3/^l は, `/scope2/^l より特定度が高いものと扱われる/ `/scope2/^l は,~top-levelの(~scopeされない)対応付けより特定度が高いものと扱われる ◎ Scopes can overlap each other, and overlap the global "imports" specifier map. At resolution time, scopes are consulted in order of most- to least-specific, where specificity is measured by sorting the scopes using the code unit less than operation. So, for example, "/scope2/scope3/" is treated as more specific than "/scope2/", which is treated as more specific than the top-level (unscoped) mappings.

このことを,次の~import~mapで例示する: ◎ The following import map illustrates this:

{
  "imports": {
    "a": "/a-1.mjs",
    "b": "/b-1.mjs",
    "c": "/c-1.mjs"
  },
  "scopes": {
    "/scope2/": {
      "a": "/a-2.mjs"
    },
    "/scope2/scope3/": {
      "b": "/b-3.mjs"
    }
  }
}

解決した結果は、 次のようになる (~~簡潔にするため,相対~URLを利用する): ◎ This results in the following resolutions (using relative URLs for brevity):

指定子
`a^l `b^l `c^l
参照元 `/scope1/r.mjs^c `/a-1.mjs^c `/b-1.mjs^c `/c-1.mjs^c
`/scope2/r.mjs^c `/a-2.mjs^c `/b-1.mjs^c `/c-1.mjs^c
`/scope2/scope3/r.mjs^c `/a-2.mjs^c `/b-3.mjs^c `/c-1.mjs^c

~import~mapは、 完全性~metadata — `下位資源の完全性^cite `SRI$r による各種~検査に利用されることになるそれ — を伴う~moduleを供するためにも利用できる。 ◎ Import maps can also be used to provide modules with integrity metadata to be used in Subresource Integrity checks. [SRI]

このことを,次の~import~mapで例示する: ◎ The following import map illustrates this:

{
  "imports": {
    "a": "/a-1.mjs",
    "b": "/b-1.mjs",
    "c": "/c-1.mjs"
  },
  "integrity": {
    "/a-1.mjs": "sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7",
    "/d-1.mjs": "sha384-MBO5IDfYaE6c6Aao94oZrIOiC6CGiSN2n4QUbHNPhzk5Xhm0djZLQqTpL0HzTUxk"
  }
}

上の例は、 ~module `/a-1.mjs^c, `/d-1.mjs^c に対し施行されることになる完全性~metadataを供する — 後者は~map内には~importとして定義されていないが,それでも。 ◎ The above example provides integrity metadata to be enforced on the modules /a-1.mjs and /d-1.mjs, even if the latter is not defined as an import in the map.


`~import~map$を表現している[ `script$e 要素の`子~text内容$ ]は、 ~AND↓ を満たさなければナラナイ — これらは、 `~import~map著作~要件@ と称される: ◎ The child text content of a script element representing an import map must match the following import map authoring requirements:

  • 妥当な~JSONである `JSON$r ◎ It must be valid JSON. [JSON]
  • 当の~JSONは、 ~JSON `object^jc を表現している ◎ The JSON must represent a JSON object,\
  • 次に挙げるもの以外の~keyを伴わない ⇒# `imports^l, `scopes^l, `integrity^l ◎ with at most the three keys "imports", "scopes", and "integrity". ◎ ↓↓ The values corresponding to the "imports", "scopes", and "integrity" keys, if present, must themselves be JSON objects.
  • ~key `imports^l が在る場合、 対応している値は,`妥当な~module指定子~map$である ◎ The value corresponding to the "imports" key, if present, must be a valid module specifier map.
  • ~key `scopes^l が在る場合、 対応している値は, ~AND↓ を満たす:

    • ~JSON `object^jc である
    • どの~keyも`妥当な~URL文字列$である
    • どの値も`妥当な~module指定子~map$である
    ◎ The value corresponding to the "scopes" key, if present, must be a JSON object, whose keys are valid URL strings and whose values are valid module specifier maps.
  • ~key `integrity^l が在る場合、 対応している値は, ~AND↓ を満たす:

    ◎ The value corresponding to the "integrity" key, if present, must be a JSON object, whose keys are valid URL strings and whose values fit the requirements of the integrity attribute.

`妥当な~module指定子~map@ は、 ~JSON `object^jc であり, ~AND↓ を満たさなければナラナイ: ◎ A valid module specifier map is a JSON object that meets the following requirements:

  • どの~keyも空でない ◎ All of its keys must be nonempty.
  • どの値も ~AND↓ を満たす:

    • `string^jc である
    • `妥当な~URL文字列$である
    • ~OR↓:

      • `絶対~URL$である
      • 次に挙げるいずれか`から開始して$いる ⇒# `/^l, `./^l, `../^l
    ◎ All of its values must be strings. ◎ Each value must be either a valid absolute URL or a valid URL string that starts with "/", "./", or "../".
  • 所与の~keyが `/^l `で終端して$いるならば、 対応している値も そうなっている。 ◎ If a given key ends with "/", then the corresponding value must also.
8.1.5.3. ~import~mapの処理~model

`~import~map@ は、 正式には,次に挙げる`~item$sctを伴う`構造体$である: ◎ Formally, an import map is a struct with three items:

  • `~import群@iM ⇒ `~module指定子~map$ ◎ imports, a module specifier map;
  • `~scope群@iM ⇒ `有順序~map$ { `~URL$ → `~module指定子~map$ }† ◎ scopes, an ordered map of URLs to module specifier maps; and
  • `完全性@iM ⇒ `~module完全性~map$ ◎ integrity, a module integrity map.

`~module指定子~map@ は、 `有順序~map$ { `文字列$ → [ `~URL$/~NULL ] } である。 ◎ A module specifier map is an ordered map whose keys are strings and whose values are either URLs or nulls.

`~module完全性~map@ は、 `有順序~map$ { `~URL$ → `完全性~metadata$rqとして利用されることになる`文字列$ } である†。 ◎ A module integrity map is an ordered map whose keys are URLs and whose values are strings that will be used as integrity metadata.

【† ~keyどうしの同等性は、 必然的に,`同等な~URL$に基づくことになる。 】

`空な~import~map@ は、[ `~import群$iM, `~scope群$iM 【, `完全性$iM ?】 ]いずれも空な`~import~map$を返す。 ◎ An empty import map is an import map with its imports and scopes both being empty maps.

`指定子~解決~record@ は、 次に挙げる`~item$sctを有する`構造体$である: ◎ A specifier resolution record is a struct. It has the following items:

  • `直列化された基底~URL@ssR ⇒ ~NULL/ある`文字列$

    当の指定子の基底~URLが存在するときは、 それを表現する。

    ◎ A serialized base URL • A string-or-null that represents the base URL of the specifier, when one exists.
  • `指定子@ssR ⇒ ある`文字列$

    当の指定子を表現する。

    ◎ A specifier • A string representing the specifier.
  • `~URLとしての指定子@ssR ⇒ ~NULL/ある`~URL$

    ~URLの様な~module指定子の事例において、 当の~URLを表現する。

    ◎ A specifier as a URL • A URL-or-null that represents the URL in case of a URL-like module specifier.

注記: 実装は、 `~URLとしての指定子$ssRを[ 当の指定子が[ 裸な指定子, `特別$urlな~URLの様な指定子 ]どちらであるかを指示する真偽値 ]で置換できる。 ◎ Implementations can replace specifier as a URL with a boolean that indicates that the specifier is either bare or URL-like that is special.

`解決-済み~module集合に~moduleを追加する@ ときは、 所与の ⇒# `環境~設定群~obj$ %設定群~obj, `文字列$ %直列化-済み基底~URL, `文字列$ %正規化-済み指定子, [ ~NULL / `~URL$ ] %~as~URL ◎終 に対し: ◎ To add module to resolved module set given an environment settings object settingsObject, a string serializedBaseURL, a string normalizedSpecifier, and a URL-or-null asURL:

  1. %大域~obj ~LET %設定群~obj の`大域~obj$enV ◎ Let global be settingsObject's global object.
  2. ~IF[ %大域~obj は `Window$I を実装しない ] ⇒ ~RET ◎ If global does not implement Window, then return.
  3. %~record ~LET 新たな`指定子~解決~record$ — その ⇒# `直列化された基底~URL$ssR ~SET %直列化-済み基底~URL, `指定子$ssR ~SET %正規化-済み指定子, `~URLとしての指定子$ssR ~SET %~as~URL ◎ Let record be a new specifier resolution record, with serialized base URL set to serializedBaseURL, specifier set to normalizedSpecifier, and specifier as a URL set to asURL.
  4. %大域~obj の`解決-済み~module集合$gLに %~record を`付加する$set ◎ Append record to global's resolved module set.

`~import~map文字列を構文解析する@ ときは、 所与の ( `文字列$ %入力, `~URL$ %基底~URL ) に対し: ◎ To parse an import map string, given a string input and a URL baseURL:

  1. %構文解析した結果 ~LET `~JSON文字列を~Infra値に構文解析する$( %入力 ) ◎ Let parsed be the result of parsing a JSON string to an Infra value given input.
  2. ~IF[ %構文解析した結果 は`有順序~map$でない ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ ~top-levelの値は、 ~JSON `object^jc にする必要がある ◎ If parsed is not an ordered map, then throw a TypeError indicating that the top-level value needs to be a JSON object.
  3. %~sortして正規化した~import群 ~LET 新たな`有順序~map$ ◎ Let sortedAndNormalizedImports be an empty ordered map.
  4. %~import群 ~LET %構文解析した結果[ `imports^l ] ◎ ↓
  5. ~IF[ %~import群 ~NEQ ε ]: ◎ If parsed["imports"] exists, then:

    1. ~IF[ %~import群 は`有順序~map$でない ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ ~top-levelの~key `imports^l 用の値は、 ~JSON `object^jc にする必要がある ◎ If parsed["imports"] is not an ordered map, then throw a TypeError indicating that the value for the "imports" top-level key needs to be a JSON object.
    2. %~sortして正規化した~import群 ~SET `~module指定子~mapを~sortして正規化する$( %~import群, %基底~URL ) ◎ Set sortedAndNormalizedImports to the result of sorting and normalizing a module specifier map given parsed["imports"] and baseURL.
  6. %~sortして正規化した~scope群 ~LET 新たな`有順序~map$ ◎ Let sortedAndNormalizedScopes be an empty ordered map.
  7. %~scope群 ~LET %構文解析した結果[ `scopes^l ] ◎ ↓
  8. ~IF[ %~scope群 ~NEQ ε ]: ◎ If parsed["scopes"] exists, then:

    1. ~IF[ %~scope群 は`有順序~map$でない ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ ~top-levelの~key `scopes^l 用の値は、 ~JSON `object^jc にする必要がある ◎ If parsed["scopes"] is not an ordered map, then throw a TypeError indicating that the value for the "scopes" top-level key needs to be a JSON object.
    2. %~sortして正規化した~scope群 ~SET `~scope群を~sortして正規化する$( %~scope群, %基底~URL ) ◎ Set sortedAndNormalizedScopes to the result of sorting and normalizing scopes given parsed["scopes"] and baseURL.
  9. %正規化-済み完全性 ~LET 新たな`有順序~map$ ◎ Let normalizedIntegrity be an empty ordered map.
  10. ~IF[ %構文解析した結果[ `integrity^l ] ~NEQ ε ]: ◎ If parsed["integrity"] exists, then:

    1. ~IF[ %構文解析した結果[ `integrity^l ] は`有順序~map$でない ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ ~top-levelの~key `integrity^l 用の値は、 ~JSON `object^jc にする必要がある ◎ If parsed["integrity"] is not an ordered map, then throw a TypeError indicating that the value for the "integrity" top-level key needs to be a JSON object.
    2. %正規化-済み完全性 ~SET `~module完全性~mapを正規化する$( %構文解析した結果[ `integrity^l ], %基底~URL ) ◎ Set normalizedIntegrity to the result of normalizing a module integrity map given parsed["integrity"] and baseURL.
  11. %構文解析した結果 の`~key群$mapを成す ~EACH( %~key ) に対し:

    1. ~IF[ %~key ~IN { `imports^l, `scopes^l, `integrity^l } ] ⇒ ~CONTINUE
    2. ~UAは、 次を指示するよう,`~consoleに警告を報告-$するベキである ⇒ 当の~import~map内に妥当でない~top-levelの~keyが在った
    3. ~BREAK
    ◎ If parsed's keys contains any items besides "imports", "scopes", or "integrity", then the user agent should report a warning to the console indicating that an invalid top-level key was present in the import map.

    注記: これは、 誤記を検出し易くするものであり,~errorではない — さもなければ、 将来に拡張を後方-互換に追加できなくなるので。 ◎ This can help detect typos. It is not an error, because that would prevent any future extensions from being added backward-compatibly.

  12. ~RET 新たな`~import~map$ — その ⇒# `~import群$iM ~SET %~sortして正規化した~import群, `~scope群$iM ~SET %~sortして正規化した~scope群, `完全性$iM ~SET %正規化-済み完全性 ◎ Return an import map whose imports are sortedAndNormalizedImports, whose scopes are sortedAndNormalizedScopes, and whose integrity are normalizedIntegrity.

この構文解析~algoから得られる`~import~map$は、 ~~高度に正規化される。 例えば,基底~URL `https://example.com/base/page.html^c が与えられた下では、 次の入力: ◎ The import map that results from this parsing algorithm is highly normalized. For example, given a base URL of https://example.com/base/page.html, the input

{
  "imports": {
    "/app/helper": "node_modules/helper/index.mjs",
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}

から生成される`~import~map$は、[ 次に挙げる`~entry$たちが成す`~import群$iM ]を伴うことになる:

  • `https://example.com/app/helper^l → `https://example.com/base/node_modules/helper/index.mjs^l,
  • `lodash^l → `https://example.com/node_modules/lodash-es/lodash.js^l
◎ will generate an import map with imports of «[ "https://example.com/app/helper" → https://example.com/base/node_modules/helper/index.mjs "lodash" → https://example.com/node_modules/lodash-es/lodash.js ]»

加えて,`~scope群$iMは、 (入力~文字列には何も無いにもかかわらず,) 空な`有順序~map$になる。 ◎ and (despite nothing being present in the input string) an empty ordered map for its scopes.


`新旧~module指定子~mapを併合する@ ときは、 所与の ( `~module指定子~map$ %新-~map, `~module指定子~map$ %旧-~map ) に対し: ◎ To merge module specifier maps, given a module specifier map newMap and a module specifier map oldMap:

  1. %併合-済み~map ~LET %旧-~map の深い複製 ◎ Let mergedMap be a deep copy of oldMap.
  2. %新-~map を成す ~EACH( %指定子 → %~URL ) に対し: ◎ For each specifier → url of newMap:

    1. ~IF[ %旧-~map[ %指定子 ] ~NEQ ε ]: ◎ If specifier exists in oldMap, then:

      1. ~UAは、 無視された規則を指示するよう,`~consoleに警告を報告-$してもヨイ — 当の規則が既存のいずれかの規則と一致する場合、 そうしないことを選んでもヨイ。 ◎ The user agent may report a warning to the console indicating the ignored rule. They may choose to avoid reporting if the rule is identical to an existing one.
      2. ~CONTINUE ◎ Continue.
    2. %併合-済み~map[ %指定子 ] ~SET %~URL ◎ Set mergedMap[specifier] to url.
  3. ~RET %併合-済み~map ◎ Return mergedMap.

`既存の~import~mapと新たな~import~mapを併合する@ ときは、 所与の ( `大域~obj$enV %大域~obj, `~import~map$ %新-~import~map ) に対し: ◎ To merge existing and new import maps, given a global object global and an import map newImportMap:

  1. %新-~import~map~scope群 ~LET %新-~import~map の`~scope群$iMの深い複製 ◎ Let newImportMapScopes be a deep copy of newImportMap's scopes.

    注記: この複製は、 以下において変異する — それが~scopeに特有な規則を無視するために利用されたとき, そこから~entry【!~item】を除去することにより。 次の段の複製も同様【!This is true for…】。 ◎ We're mutating these copies and removing items from them when they are used to ignore scope-specific rules. This is true for newImportMapScopes, as well as to newImportMapImports below.

  2. %新-~import~map~import群 ~LET %新-~import~map の`~import群$iMの深い複製 ◎ Let newImportMapImports be a deep copy of newImportMap's imports.
  3. %新-~import~map~scope群 を成す ~EACH( %~scope接頭辞 → %~scope~import群 ) に対し: ◎ For each scopePrefix → scopeImports of newImportMapScopes:

    1. %大域~obj の`解決-済み~module集合$gLを成す ~EACH( %~record ) に対し: ◎ For each record of global's resolved module set:

      1. ~IF[ ~OR↓ ]…

        • %~scope接頭辞 ~EQ %~record の`直列化された基底~URL$ssR
        • ~AND↓:

          • %~scope接頭辞 は `/^l `で終端して$いる
          • %~scope接頭辞 は %~record の`直列化された基底~URL$ssRの`符号単位~接頭辞$である

        …ならば:

        ◎ If scopePrefix is record's serialized base URL,\ or if scopePrefix ends with U+002F (/) and scopePrefix is a code unit prefix of record's serialized base URL, then:
        1. %~scope~import群 を成す ~EACH( %指定子~key → %解決~結果 ) に対し: ◎ For each specifierKey → resolutionResult of scopeImports:

          1. ~IF[ %指定子~key ~EQ %~record の`指定子$ssR ]~OR[ ~AND↓ ]… ◎ If specifierKey is record's specifier, or if all of the following conditions are true:

            • %指定子~key は `/^l `で終端して$いる ◎ specifierKey ends with U+002F (/);
            • %指定子~key は %~record の`指定子$ssRを成す`符号単位~接頭辞$である ◎ specifierKey is a code unit prefix of record's specifier;
            • ~OR↓:

              • %~record の`~URLとしての指定子$ssR ~EQ ~NULL
              • %~record の`~URLとしての指定子$ssRは`特別$urlである
              ◎ either record's specifier as a URL is null or is special,

            …ならば: ◎ then:

            1. ~UAは、 無視された規則を指示するよう,`~consoleに警告を報告-$してもヨイ — 当の規則が既存のいずれかの規則と一致する場合、 そうしないことを選んでもヨイ。 ◎ The user agent may report a warning to the console indicating the ignored rule. They may choose to avoid reporting if the rule is identical to an existing one.
            2. %~scope~import群[ %指定子~key【!%指定子】 ] ~SET ε ◎ Remove scopeImports[specifier].

      注記: 実装者には、 `解決-済み~module集合$gLで作業するときには, もっと効率的な照合~algoを実装することが奨励される。 指導として、 巨大な~app内で[ 解決される/対応付けられる ]~moduleの個数は,数千にもなり得る。 ◎ Implementers are encouraged to implement a more efficient matching algorithm when working with the resolved module set. As guidance, the number of resolved/mapped modules in a large application can be on the order of thousands.

    2. %旧-~scope群 ~LET %旧-~import~map の`~scope群$iM ◎ ↓
    3. ~IF[ %旧-~scope群[ %~scope接頭辞 ] ~NEQ ε ] ⇒ %旧-~scope群[ %~scope接頭辞 ] ~SET `新旧~module指定子~mapを併合する$( %~scope~import群, %旧-~scope群[ %~scope接頭辞 ] ) ◎ If scopePrefix exists in oldImportMap's scopes, then set oldImportMap's scopes[scopePrefix] to the result of merging module specifier maps, given scopeImports and oldImportMap's scopes[scopePrefix].
    4. ~ELSE ⇒ %旧-~scope群[ %~scope接頭辞 ] ~SET %~scope~import群 ◎ Otherwise, set oldImportMap's scopes[scopePrefix] to scopeImports.
  4. %新-~import~map の`完全性$iMを成す ~EACH( %~URL → %完全性 ) に対し: ◎ For each url → integrity of newImportMap's integrity:

    1. ~IF[ %旧-~import~map の`完全性$iM[ %~URL ] ~NEQ ε ]: ◎ If url exists in oldImportMap's integrity, then:

      1. ~UAは、 無視された規則を指示するよう,`~consoleに警告を報告-$してもヨイ — 当の規則が既存のいずれかの規則と一致する場合、 そうしないことを選んでもヨイ。 ◎ The user agent may report a warning to the console indicating the ignored rule. They may choose to avoid reporting if the rule is identical to an existing one.
      2. ~CONTINUE ◎ Continue.
    2. %旧-~import~map の`完全性$iM[ %~URL ] ~SET %完全性 ◎ Set oldImportMap's integrity[url] to integrity.
  5. %大域~obj の`解決-済み~module集合$gLを成す ~EACH( %~record ) に対し: ◎ For each record of global's resolved module set:

    1. %新-~import~map~import群 を成す ~EACH( %指定子 → %~URL ) に対し: ◎ For each specifier → url of newImportMapImports:

      1. ~IF[ %指定子 は %~record の`指定子$ssR`から開始して$いる ]: ◎ If specifier starts with record's specifier, then:

        1. ~UAは、 無視された規則を指示するよう,`~consoleに警告を報告-$してもヨイ — 当の規則が既存のいずれかの規則と一致する場合、 そうしないことを選んでもヨイ。 ◎ The user agent may report a warning to the console indicating the ignored rule. They may choose to avoid reporting if the rule is identical to an existing one.
        2. %新-~import~map~import群[ %指定子 ] ~SET ε ◎ Remove newImportMapImports[specifier].
  6. %旧-~import~map の`~import群$iM ~SET `新旧~module指定子~mapを併合する$( %新-~import~map~import群, %旧-~import~map の`~import群$iM ) ◎ Set oldImportMap's imports to the result of merge module specifier maps, given newImportMapImports and oldImportMap's imports.

上の~algoは、[ `環境~設定群~obj$の`大域~obj$の`~import~map$ ]が与えられた下で,新たな~import~mapを その中へ併合する。 以下では、 それを少数の例で,それについて精査する: ◎ The above algorithm merges a new import map into the given environment settings object's global object's import map. Let's examine a few examples:

新たな~import~mapを成す規則が既存の規則たちと併合されないようになる事例には、 次に挙げる 2 種がある: ◎ There are two cases when rules of the new import map don't get merged into the existing one.

  • 新たな~import~map規則は、 既存の~import~map内の規則と正確に同じ[ ~scope, 指定子 ]を有する場合。 以下では、 “競合している規則” と称される。 ◎ The new import map rule has the exact same scope and specifier as a rule in the existing import map. We'll call that "conflicting rule".
  • 新たな~import~map規則は、 すでに解決された~module【~module指定子】の解決に【当の規則が併合されたとするとき】影響iし得る場合。 “影響iされる解決-済みな~module” と称される。 ◎ The new import map rule may impact the resolution of an already resolved module. We'll call that "impacted already resolved module".

[ 新たな~import~mapは競合している規則を有さない ]かつ[ 影響iされる解決-済みな~moduleは無い ]ときは、 結果の~mapは、[ 新たな~map, 既存の~map ]が成す組合nになろう。 類似な~module(例: `/app/^l と `/app/helper^l )に個別に影響iするが, 正確には合致しない規則は、 競合している規則にはならず, 併合した結果の~mapへ行く。 ◎ When the new import map has no conflicting rules, and there are no impacted resolved modules, the resulting map would be a combination of the new and existing maps. Rules that would have individually impacted similar modules (e.g. "/app/" and "/app/helper") but are not an exact match are not conflicting, and all make it to the merged map.

なので、 次の[ 既存の~import~map, 新たな~import~map ](同順)は: ◎ So, the following existing and new import maps:

{
   "imports": {
    "/app/": "./original-app/",
  }
}
{
  "imports": {
    "/app/helper": "./helper/index.mjs"
  },
  "scopes": {
    "/js": {
      "/app/": "./js-app/"
    }
  }
}

次の単独の~import~mapと等価になろう: ◎ Would be equivalent to the following single import map:

{
  "imports": {
    "/app/": "./original-app/",
    "/app/helper": "./helper/index.mjs"
  },
  "scopes": {
    "/js": {
      "/app/": "./js-app/"
    }
  }
}

新たな~import~mapに解決-済みな~moduleに影響iする規則が在るときは、 当の規則は,当の~import~mapから落とされるようになる。 ◎ When the new import map impacts an already resolved module, that rule gets dropped from the import map.

`解決-済み~module集合$gLが,すでに `/app/helper^l を包含していた場合、 次の新たな~import~mapは: ◎ So, if the resolved module set already contains the "/app/helper", the following new import map:

{
   "imports": {
    "/app/helper": "./helper/index.mjs",
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}

次と等価になろう: ◎ Would be equivalent to the following one:

{
  "imports": {
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}

同じことは、 特定の~scope内に定義された解決-済みな~moduleに影響iする規則にも該当する。 【指定子】 `/app/helper^l が【参照元】 `/app/main.mjs^l からは解決-済みであった場合、 次の新たな~import~mapは: ◎ The same is true for rules that impact already resolved modules defined in specific scopes. If we already resolved "/app/helper" from "/app/main.mjs" the following new import map:

{
  "scopes": {
    "/app/": {
      "/app/helper": "./helper/index.mjs"
    }
  },
   "imports": {
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}

類似に,次と等価になろう: ◎ Would similarly be equivalent to:

{
  "imports": {
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}

単独の解決-済みな~module指定子が,複数の規則 — 参照している~scriptに依存して,解決した結果を違えるようなそれら — を有する事例もあり得る。 そのような事例では、 関連な規則に限り,当の~mapへ追加されなくなろう。 ◎ We could also have cases where a single already-resolved module specifier has multiple rules for its resolution, depending on the referring script. In such cases, only the relevant rules would not be added to the map.

例えば,`/app/helper^l が `/app/vendor/main.mjs^l からは解決-済みであった場合、 次の新たな~import~mapは: ◎ For example, if we already resolved "/app/helper" from "/app/vendor/main.mjs", the following new import map:

{
  "scopes": {
    "/app/": {
      "/app/helper": "./helper/index.mjs"
    },
    "/app/vendor/": {
      "/app/": "./vendor_helper/"
    },
    "/vendor/": {
      "/app/helper": "./helper/vendor_index.mjs"
    }
  },
   "imports": {
    "lodash": "/node_modules/lodash-es/lodash.js"
    "/app/": "./general_app_path/"
    "/app/helper": "./other_path/helper/index.mjs"
  }
}

次と等価になろう: ◎ Would be equivalent to:

{
  "scopes": {
    "/vendor/": {
      "/app/helper": "./helper/vendor_index.mjs"
    }
  },
  "imports": {
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}

このことは、 併合-~algoが次を行う事実により達成される ⇒ 解決-済みな各~moduleを追跡して, それらに影響している各~規則に対し — それが既存のものの中へ併合される前に — 新たな~import~mapから除去する。 ◎ This is achieved by the fact that the merge algorithm tracks already resolved modules and removes rules affecting them from new import maps before they are merged into the existing one.

新たな~import~mapが既存の~import~mapと競合している規則を有していて, 影響iされる解決-済みな~moduleは無いときは、 既存の~import~map規則は持続する。 ◎ When the new import map has conflicting rules to the existing import map, with no impacted already resolved modules, the existing import map rules persist.

例えば,次の[ 既存の~import~map, 新たな~import~map ](同順)は: ◎ For example, the following existing and new import maps:

{
   "imports": {
    "/app/helper": "./helper/index.mjs",
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}
{
  "imports": {
    "/app/helper": "./main/helper/index.mjs"
  }
}

次の単独の~import~mapと等価になろう: ◎ Would be equivalent to the following single import map:

{
  "imports": {
    "/app/helper": "./helper/index.mjs",
    "lodash": "/node_modules/lodash-es/lodash.js",
  }
}

`~module指定子~mapを~sortして正規化する@ ときは、 所与の ( `有順序~map$ %元の~map, `~URL$ %基底~URL ) に対し: ◎ To sort and normalize a module specifier map, given an ordered map originalMap and a URL baseURL:

  1. %正規化した結果 ~LET 新たな`有順序~map$ ◎ Let normalized be an empty ordered map.
  2. %元の~map を成す ~EACH( %指定子~key → %値 ) に対し: ◎ For each specifierKey → value of originalMap:

    1. %正規化-済み指定子~key ~LET `指定子~keyを正規化する$( %指定子~key, %基底~URL ) ◎ Let normalizedSpecifierKey be the result of normalizing a specifier key given specifierKey and baseURL.
    2. ~IF[ %正規化-済み指定子~key ~EQ ~NULL ] ⇒ ~CONTINUE ◎ If normalizedSpecifierKey is null, then continue.
    3. ~IF[ %値 は`文字列$でない ]: ◎ If value is not a string, then:

      1. ~UAは、 次を指示するよう,`~consoleに警告を報告-$してもヨイ ⇒ ~addressは文字列にする必要がある ◎ The user agent may report a warning to the console indicating that addresses need to be strings.
      2. %正規化した結果[ %正規化-済み指定子~key ] ~SET ~NULL ◎ Set normalized[normalizedSpecifierKey] to null.
      3. ~CONTINUE ◎ Continue.
    4. %~address~URL ~LET `~URLの様な~module指定子を解決する$( %値, %基底~URL ) ◎ Let addressURL be the result of resolving a URL-like module specifier given value and baseURL.
    5. ~IF[ %~address~URL ~EQ ~NULL ]: ◎ If addressURL is null, then:

      1. ~UAは、 次を指示するよう,`~consoleに警告を報告-$してもヨイ ⇒ 当の~addressは妥当でなかった。 ◎ The user agent may report a warning to the console indicating that the address was invalid.
      2. %正規化した結果[ %正規化-済み指定子~key ] ~SET ~NULL ◎ Set normalized[normalizedSpecifierKey] to null.
      3. ~CONTINUE ◎ Continue.
    6. ~IF[ %指定子~key は `/^l `で終端して$いる ]~AND[ `~URLを直列化する$( %~address~URL ) の結果は `/^l `で終端して$いない ]: ◎ If specifierKey ends with U+002F (/), and the serialization of addressURL does not end with U+002F (/), then:

      1. ~UAは、 次を指示するよう,`~consoleに警告を報告-$してもヨイ ⇒ %指定子~key に妥当でない~addressが与えられた — %指定子~key は~slashで終端しているので、 ~addressもそうなる必要がある。 ◎ The user agent may report a warning to the console indicating that an invalid address was given for the specifier key specifierKey; since specifierKey ends with a slash, the address needs to as well.
      2. %正規化した結果[ %正規化-済み指定子~key ] ~SET ~NULL ◎ Set normalized[normalizedSpecifierKey] to null.
      3. ~CONTINUE ◎ Continue.
    7. %正規化した結果[ %正規化-済み指定子~key ] ~SET %~address~URL ◎ Set normalized[normalizedSpecifierKey] to addressURL.
  3. ~RET `降順に~sortする$map( %正規化した結果, ~LT`符号単位$sub ) ◎ Return the result of sorting in descending order normalized, with an entry a being less than an entry b if a's key is code unit less than b's key.

`~scope群を~sortして正規化する@ ときは、 所与の ( `有順序~map$ %元の~map, `~URL$ %基底~URL ) に対し: ◎ To sort and normalize scopes, given an ordered map originalMap and a URL baseURL:

  1. %正規化した結果 ~LET 新たな`有順序~map$ ◎ Let normalized be an empty ordered map.
  2. %元の~map を成す ~EACH( %~scope接頭辞 → %指定子~mapになり得るもの ) に対し: ◎ For each scopePrefix → potentialSpecifierMap of originalMap:

    1. ~IF[ %指定子~mapになり得るもの は`有順序~map$でない ] ⇒ ~THROW `TypeError$jc — これは、 次を指示する ⇒ 接頭辞に %~scope接頭辞 を伴う~scopeの値は、 ~JSON `object^jc にする必要がある ◎ If potentialSpecifierMap is not an ordered map, then throw a TypeError indicating that the value of the scope with prefix scopePrefix needs to be a JSON object.
    2. %~scope接頭辞~URL ~LET `~URL構文解析する$( %~scope接頭辞, %基底~URL ) ◎ Let scopePrefixURL be the result of URL parsing scopePrefix with baseURL.
    3. ~IF[ %~scope接頭辞~URL ~EQ `失敗^i ]: ◎ If scopePrefixURL is failure, then:

      1. ~UAは、 次を指示するよう,`~consoleに警告を報告-$してもヨイ ⇒ 当の~scope接頭辞~URLは構文解析-可能でなかった ◎ The user agent may report a warning to the console that the scope prefix URL was not parseable.
      2. ~CONTINUE ◎ Continue.
    4. %正規化-済み~scope接頭辞 ~LET `~URLを直列化する$( %~scope接頭辞~URL ) ◎ Let normalizedScopePrefix be the serialization of scopePrefixURL.
    5. %正規化した結果[ %正規化-済み~scope接頭辞 ] ~SET `~module指定子~mapを~sortして正規化する$( %指定子~mapになり得るもの, %基底~URL ) ◎ Set normalized[normalizedScopePrefix] to the result of sorting and normalizing a module specifier map given potentialSpecifierMap and baseURL.
  3. ~RET `降順に~sortする$map( %正規化した結果, ~LT`符号単位$sub ) ◎ Return the result of sorting in descending order normalized, with an entry a being less than an entry b if a's key is code unit less than b's key.

注記: 上の 2 つの~algoは、 ~keyと~scopeを降順に~sortするので, `foo/bar/^l は `foo/^l より前に来る — すなわち、 `~module指定子を解決する$間は, `foo/^l より `foo/bar/^l に高い優先度を与える。 ◎ In the above two algorithms, sorting keys and scopes in descending order has the effect of putting "foo/bar/" before "foo/". This in turn gives "foo/bar/" a higher priority than "foo/" during module specifier resolution.

`~module完全性~mapを正規化する@ ときは、 所与の ( `有順序~map$ %元の~map ) に対し: ◎ To normalize a module integrity map, given an ordered map originalMap:

  1. %正規化した結果 ~LET 新たな`有順序~map$ ◎ Let normalized be an empty ordered map.
  2. %元の~map を成す ~EACH( %~key → %値 ) に対し: ◎ For each key → value of originalMap:

    1. %解決-済み~URL ~LET `~URLの様な~module指定子を解決する$( %~key, %基底~URL ) ◎ Let resolvedURL be the result of resolving a URL-like module specifier given key and baseURL.

      `imports^l と違って、 完全性~mapを成す~keyは,~module指定子ではなく~URLとして扱われる。 しかしながら、 `foo^c の様な[ ~module指定子~用であると~~誤認され易い “裸な” 相対~URL ]を禁制するため, `~URLの様な~module指定子を解決する$~algoを利用する。 ◎ Unlike "imports", keys of the integrity map are treated as URLs, not module specifiers. However, we use the resolve a URL-like module specifier algorithm to prohibit "bare" relative URLs like foo, which could be mistaken for module specifiers.

    2. ~IF[ %解決-済み~URL ~EQ ~NULL ]: ◎ If resolvedURL is null, then:

      1. ~UAは、 次を指示するよう,`~consoleに警告を報告-$してもヨイ ⇒ ~keyを解決するのに失敗した ◎ The user agent may report a warning to the console indicating that the key failed to resolve.
      2. ~CONTINUE ◎ Continue.
    3. ~IF[ %値 は`文字列$でない ]: ◎ If value is not a string, then:

      1. ~UAは、 次を指示するよう,`~consoleに警告を報告-$してもヨイ ⇒ `完全性~metadata$rq用の値は`文字列$にする必要がある ◎ The user agent may report a warning to the console indicating that integrity metadata values need to be strings.
      2. ~CONTINUE ◎ Continue.
    4. %正規化した結果[ %解決-済み~URL ] ~SET %値 ◎ Set normalized[resolvedURL] to value.
  3. ~RET %正規化した結果 ◎ Return normalized.

`指定子~keyを正規化する@ ときは、 所与の ( `文字列$ %指定子~key, `~URL$ %基底~URL ) に対し: ◎ To normalize a specifier key, given a string specifierKey and a URL baseURL:

  1. ~IF[ %指定子~key ~EQ 空~文字列 ]: ◎ If specifierKey is the empty string, then:

    1. ~UAは、 次を指示するよう,`~consoleに警告を報告-$してもヨイ ⇒ 指定子~keyは、 空~文字列~以外にする必要がある。 ◎ The user agent may report a warning to the console indicating that specifier keys may not be the empty string.
    2. ~RET ~NULL ◎ Return null.
  2. %~URL ~LET `~URLの様な~module指定子を解決する$( %指定子~key, %基底~URL ) ◎ Let url be the result of resolving a URL-like module specifier, given specifierKey and baseURL.
  3. ~IF[ %~URL ~NEQ ~NULL ] ⇒ ~RET `~URLを直列化する$( %~URL ) ◎ If url is not null, then return the serialization of url.
  4. ~RET %指定子~key ◎ Return specifierKey.

8.1.6. ~JS仕様~host~hook

~JS仕様には,いくつかの`実装定義$な抽象-演算があり、 ~host環境に依存して変わる。 この節では、 ~UA~host用のそれらを定義する。 ◎ The JavaScript specification contains a number of implementation-defined abstract operations, that vary depending on the host environment. This section defines them for user agent hosts.

8.1.6.1. `HostEnsureCanAddPrivateElement^A( %O )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostEnsureCanAddPrivateElement$jA を`実装定義$としている。 ◎ JavaScript contains an implementation-defined HostEnsureCanAddPrivateElement(O) abstract operation.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. ~IF[ %O は `WindowProxy$I ~objである ]~OR[ %O は `Location$I を`実装-$する ] ⇒ ~RET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET 新たな `TypeError$jc ◎ If O is a WindowProxy object, or implements Location, then return Completion { [[Type]]: throw, [[Value]]: a new TypeError }.
  2. ~RET `NormalCompletion$jA( `unused^i ) ◎ Return NormalCompletion(unused).

注記: ~JS~private~fieldは、 任意な~objに適用され得る。 このことは, 特に【!particularly-?】~exoticな~host~obj用の実装を劇的に複雑化させるので、 ~JS言語~仕様は,この~hookを[ ~host定義な判定基準を満たしている~obj上では,~private~fieldを却下する ]ことを~hostに許容するために供する。 ~HTMLの事例では、[ `WindowProxy$I, `Location$I ]に複雑な意味論があり, ~private~field意味論の実装を — 特に,~naviと~security周りで — 難題にする。 なので、 ここでの実装は,単純に それらの~objを却下する。 ◎ JavaScript private fields can be applied to arbitrary objects. Since this can dramatically complicate implementation for particularly-exotic host objects, the JavaScript language specification provides this hook to allow hosts to reject private fields on objects meeting a host-defined criteria. In the case of HTML, WindowProxy and Location have complicated semantics — particularly around navigation and security — that make implementation of private field semantics challenging, so our implementation simply rejects those objects.

8.1.6.2. `HostEnsureCanCompileStrings^A( %~realm, %~parameter文字列~群, %本体~文字列, %~code文字列, %~compilation種別, %~parameter引数~群, %本体~引数 )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostEnsureCanCompileStrings$jA を`実装定義$としている — それは、 `Dynamic Code Brand Checks^cite 提案 `JSDYNAMICCODEBRANDCHECKS$r により定義し直された。 ◎ JavaScript contains an implementation-defined HostEnsureCanCompileStrings abstract operation, redefined by the Dynamic Code Brand Checks proposal.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT] [JSDYNAMICCODEBRANDCHECKS]

  1. ~ABRUPT `EnsureCSPDoesNotBlockStringCompilation$jA( %~realm, %~parameter文字列~群, %本体~文字列, %~code文字列, %~compilation種別, %~parameter引数~群, %本体~引数 ) `CSP$r ◎ Perform ? EnsureCSPDoesNotBlockStringCompilation(realm, parameterStrings, bodyString, codeString, compilationType, parameterArgs, bodyArg). [CSP]
8.1.6.3. `HostGetCodeForEval^A( %引数 )

`Dynamic Code Brand Checks^cite 提案 `JSDYNAMICCODEBRANDCHECKS$r は、 その `HostGetCodeForEval$jA 抽象-演算を`実装定義$としている。 ◎ The Dynamic Code Brand Checks proposal contains an implementation-defined HostGetCodeForEval(argument) abstract operation.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JSDYNAMICCODEBRANDCHECKS]

  1. ~IF[ %引数 は `TrustedScript$I ~objである ] ⇒ ~RET %引数 の`~data@~TRUSTED-TYPES#trustedscript-data$ ◎ If argument is a TrustedScript object, then return argument's data.
  2. ~RET `no-code^i ◎ Otherwise, return no-code.
8.1.6.4. `HostPromiseRejectionTracker^A( %promise, %演算 )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostPromiseRejectionTracker$jA を`実装定義$としている。 ◎ JavaScript contains an implementation-defined HostPromiseRejectionTracker(promise, operation) abstract operation.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %~script ~LET `走っている~script$ ◎ Let script be the running script.
  2. ~IF[ %~script は`古典~script$である ]~AND[ %~script の`~errorを黙秘するか$sC ~EQ ~T ] ⇒ ~RET ◎ If script is a classic script and script's muted errors is true, then return.
  3. %設定群~obj ~LET `現在の設定群~obj$ ◎ Let settingsObject be the current settings object.
  4. ~IF[ %~script ~NEQ ~NULL ] ⇒ %設定群~obj ~SET %~script の`設定群~obj$sC ◎ If script is not null, then set settingsObject to script's settings object.
  5. %大域~obj ~LET %設定群~obj の`大域~obj$enV ◎ Let global be settingsObject's global object.
  6. %却下-済み~list ~LET %大域~obj の`通知待ちな却下-済み~promise~list$gL ◎ ↓
  7. ~IF[ %演算 ~EQ `reject^l ] ⇒ %却下-済み~list に %promise を`付加する$ ◎ If operation is "reject", then: • Append promise to global's about-to-be-notified rejected promises list.
  8. ~ELIF[ %演算 ~EQ `handle^l ]: ◎ If operation is "handle", then:

    1. ~IF[ %promise ~IN %却下-済み~list ] ⇒# %却下-済み~list から %promise を`除去する$; ~RET ◎ If global's about-to-be-notified rejected promises list contains promise, then remove promise from that list and return.
    2. %弱い参照たちが成す集合 ~LET %大域~obj の`未決な却下-済み~promiseへの弱い参照たちが成す集合$gL ◎ ↓
    3. ~IF[ %promise ~NIN %弱い参照たちが成す集合 ] ⇒ ~RET ◎ If global's outstanding rejected promises weak set does not contain promise, then return.
    4. %弱い参照たちが成す集合 から %promise を`除去する$ ◎ Remove promise from global's outstanding rejected promises weak set.
    5. `大域~taskを~queueする$( `~DOM操作~task~source$, %大域~obj, 次の手続き ) ◎ Queue a global task on the DOM manipulation task source given global to\

      手続きは ⇒ `~eventを発火する$( %大域~obj, `rejectionhandled$et, `PromiseRejectionEvent$I ) — 次のように初期化して ⇒# `promise$m ~SET %promise, `reason$m ~SET %promise .`PromiseResult^sl ◎ fire an event named rejectionhandled at global, using PromiseRejectionEvent, with the promise attribute initialized to promise, and the reason attribute initialized to promise.[[PromiseResult]].
8.1.6.5. `HostSystemUTCEpochNanoseconds^A( %大域~obj )

`Temporal^cite 提案 `JSTEMPORAL$r は、 その抽象-演算 `HostSystemUTCEpochNanoseconds$jA を`実装定義$としている。 ◎ The Temporal proposal contains an implementation-defined HostSystemUTCEpochNanoseconds abstract operation.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JSTEMPORAL]

  1. %設定群~obj ~LET %大域~obj に`関連な設定群~obj$ ◎ Let settingsObject be global's relevant settings object.
  2. %時刻 ~LET `現在の壁~時計~時刻$enV( %設定群~obj ) ◎ Let time be settingsObject's current wall time.
  3. %ns ~LET [ `~Unix~epoch$から %時刻 まで ]を成す~nano秒数を最も近い整数に丸めた結果 ◎ Let ns be the number of nanoseconds from the Unix epoch to time, rounded to the nearest integer.
  4. ~RET %ns を `nsMinInstant@https://tc39.es/proposal-temporal/#eqn-nsMinInstant$jv 以上, `nsMaxInstant@https://tc39.es/proposal-temporal/#eqn-nsMaxInstant$jv 以下 に`切詰める@https://tc39.es/ecma262/#clamping$ ◎ Return the result of clamping ns between nsMinInstant and nsMaxInstant.
8.1.6.6. ~jobに関係する~host用の~hook

~JS仕様は、 ~job( `Job^en )を定義する — それは、 後で~hostが走らすよう~scheduleされる。 また,`~JobCallback~Record$を定義する — それは、 ~job( `job^en )の一部として~callされる~JS関数を~capsule化する。 ~JS仕様には、[ 各~jobがどう~scheduleされるか, 各~JobCallbackがどう取扱われるか ]を定義することを~hostに任せるための,`実装定義$な抽象-演算がいくつかある。 ~HTMLは、 これらの抽象-演算を利用して,`作動中な~script$用の[ `現任な設定群~obj$, `~JS実行~文脈$ ]を~JobCallback内で[ 保存する/復旧する ]ことにより、 `現任な設定群~obj$を[ ~promise/ `FinalizationRegistry$jc ~callback ](順不同)内で追跡する。 この節は、 ~UA~host用にそれらを定義する。 ◎ The JavaScript specification defines Jobs to be scheduled and run later by the host, as well as JobCallback Records which encapsulate JavaScript functions that are called as part of jobs. The JavaScript specification contains a number of implementation-defined abstract operations that lets the host define how jobs are scheduled and how JobCallbacks are handled. HTML uses these abstract operations to track the incumbent settings object in promises and FinalizationRegistry callbacks by saving and restoring the incumbent settings object and a JavaScript execution context for the active script in JobCallbacks. This section defines them for user agent hosts.

8.1.6.6.1. `HostCallJobCallback^A( %~callback, %V, %引数~list )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostCallJobCallback$jA を`実装定義$としている — それは、 ~taskの内側から~JS~callbackを呼出すとき, 状態を復旧することを~hostに任せるためにある。 ~HTMLは、[ `現任な設定群~obj$, `作動中な~script$ ]を復旧する。 ◎ JavaScript contains an implementation-defined HostCallJobCallback(callback, V, argumentsList) abstract operation to let hosts restore state when invoking JavaScript callbacks from inside tasks.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %現任な設定群 ~LET %~callback .`HostDefined^sl.`IncumbentSettings^sl ◎ Let incumbent settings be callback.[[HostDefined]].[[IncumbentSettings]].
  2. %~script実行~文脈 ~LET %~callback .`HostDefined^sl.`ActiveScriptContext^sl ◎ Let script execution context be callback.[[HostDefined]].[[ActiveScriptContext]].
  3. `~callbackを走らすために準備する$( %現任な設定群 ) ◎ Prepare to run a callback with incumbent settings.

    注記: これは、 当の~callbackが走っている間,`現任な某$の概念に影響する。 ◎ This affects the incumbent concept while the callback runs.

  4. ~IF[ %~script実行~文脈 ~NEQ ~NULL ] ⇒ `~JS実行~文脈~stack$に %~script実行~文脈 を`~push$する ◎ If script execution context is not null, then push script execution context onto the JavaScript execution context stack.

    注記: これは、 当の~callbackが走っている間,`作動中な~script$に影響する。 ◎ This affects the active script while the callback runs.

  5. %結果 ~LET `Call$jA( %~callback .`Callback^sl, %V, %引数~list ) ◎ Let result be Call(callback.[[Callback]], V, argumentsList).
  6. ~IF[ %~script実行~文脈 ~NEQ ~NULL ] ⇒ `~JS実行~文脈~stack$から %~script実行~文脈 を`~pop$する ◎ If script execution context is not null, then pop script execution context from the JavaScript execution context stack.
  7. `走らせた~callbackを片付ける$( %現任な設定群 ) ◎ Clean up after running a callback with incumbent settings.
  8. ~RET %結果 ◎ Return result.
8.1.6.6.2. `HostEnqueueFinalizationRegistryCleanupJob^A( %完結~registry )

~JSには、[ ~objが~garbage収集されたことが見出されたとき,片付け動作を~scheduleする ]ためとして,当の~objを `FinalizationRegistry$jc ~objで登録する能がある。 ~JS仕様 `JAVASCRIPT$r は、 片付け動作を~scheduleする抽象-演算 `HostEnqueueFinalizationRegistryCleanupJob$jA を`実装定義$としている。 ◎ JavaScript has the ability to register objects with FinalizationRegistry objects, in order to schedule a cleanup action if they are found to be garbage collected. The JavaScript specification contains an implementation-defined HostEnqueueFinalizationRegistryCleanupJob(finalizationRegistry) abstract operation to schedule the cleanup action.

注記: 片付け作業の時機や~~頻度は、 ~JS仕様においては`実装定義$とされている。 ある~objが,いつ~garbage収集されるか(されないか)は、 ~UAごとに相違するかもしれない — それは、[ `WeakRef.prototype.deref()$m ~methodの返り値が `undefined^jv になるかどうか ], および[ `FinalizationRegistry$jc 【の構築子に渡した】片付け~callbackが生じるかどうか ]に影響する。 普及している~web~browserには,~objが~JSから~access可能でなくなる周知な事例があるが、 ~garbage収集器は,それらを不定期に~~保ち続ける。 ~HTMLは、 生きたまま保たれた `WeakRef$jc ~objを`小task~checkpointを遂行する$~algo内で~clearする。 作者にとっての最上策は、 実装における~garbage収集の時機の詳細~に依存しないことである。 ◎ The timing and occurrence of cleanup work is implementation-defined in the JavaScript specification. User agents might differ in when and whether an object is garbage collected, affecting both whether the return value of the WeakRef.prototype.deref() method is undefined, and whether FinalizationRegistry cleanup callbacks occur. There are well-known cases in popular web browsers where objects are not accessible to JavaScript, but they remain retained by the garbage collector indefinitely. HTML clears kept-alive WeakRef objects in the perform a microtask checkpoint algorithm. Authors would be best off not depending on the timing details of garbage collection implementations.

片付け動作は、 同期的な~JS実行の途中に挟まれることはないが,~queueされた`~task$内で起こる。 ◎ Cleanup actions do not take place interspersed with synchronous JavaScript execution, but rather happen in queued tasks.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %大域~obj ~LET %完結~registry .`Realm^sl の`大域~obj$ ◎ Let global be finalizationRegistry.[[Realm]]'s global object.
  2. `大域~taskを~queueする$( `~JS~engine~task~source@ , %大域~obj, 次の手続き ) ◎ Queue a global task on the JavaScript engine task source given global to perform the following steps:

    手続きは: ◎ ↑

    1. %~entry ~LET %完結~registry .`CleanupCallback^sl.`Callback^sl.`Realm^sl の`設定群~obj$rM ◎ Let entry be finalizationRegistry.[[CleanupCallback]].[[Callback]].[[Realm]]'s environment settings object.
    2. ~IF[ `~scriptは走れるかどうか検査する$( %~entry ) ~EQ `走るな^i ] ⇒ ~RET ◎ Check if we can run script with entry. If this returns "do not run", then return.
    3. `~scriptを走らすために準備する$( %~entry ) ◎ Prepare to run script with entry.

      注記: これは、 当の片付け~callback【 `CleanupCallback^sl 】が走っている間,`入口~某$の概念に影響する。 ◎ This affects the entry concept while the cleanup callback runs.

    4. %結果 ~LET `CleanupFinalizationRegistry$jA( %完結~registry ) ◎ Let result be the result of performing CleanupFinalizationRegistry(finalizationRegistry).
    5. `走らせた~scriptを片付ける$( %~entry ) ◎ Clean up after running script with entry.
    6. ~IF[ %結果 は`中途完了$である ] ⇒ `例外を報告する$( %結果 .`Value^sl, %大域~obj ) ◎ If result is an abrupt completion, then report an exception given by result.[[Value]] for global.
8.1.6.6.3. `HostEnqueueGenericJob^A( %~job, %~realm )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostEnqueueGenericJob$jA を`実装定義$としている — それは、 特定0の~realm内で汎用な~job (例: `Atomics.waitAsync@~TC39#sec-atomics.waitasync$c による結果の~promiseを解決する) を遂行するためにある。 ◎ JavaScript contains an implementation-defined HostEnqueueGenericJob(job, realm) abstract operation to perform generic jobs in a particular realm (e.g., resolve promises resulting from Atomics.waitAsync).\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %大域~obj ~LET %~realm の`大域~obj$rM ◎ Let global be realm's global object.
  2. `大域~taskを~queueする$( `~JS~engine~task~source$, %大域~obj, %~job ) ◎ Queue a global task on the JavaScript engine task source given global to perform job().
8.1.6.6.4. `HostEnqueuePromiseJob^A( %~job, %~realm )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostEnqueuePromiseJob$jA を`実装定義$としている — それは、 `Promise^jc に関係する演算を~scheduleするためにある。 ~HTMLは、 そのような演算を`小task~queue$において~scheduleする。 ◎ JavaScript contains an implementation-defined HostEnqueuePromiseJob(job, realm) abstract operation to schedule Promise-related operations. HTML schedules these operations in the microtask queue.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %~job設定群 ~LET %~realm に応じて ⇒# ~NULL ならば ~NULL / ~ELSE_ %~realm 用の`設定群~obj$rM ◎ If realm is not null, then let job settings be the settings object for realm. Otherwise, let job settings be null.

    注記: %~realm ~NEQ ~NULL の場合、 %~realm は走らすことになる作者~codeが属する`~realm$になる — それは, %~job が[ `NewPromiseReactionJob$jA から返されたなら,当の~promiseの~handler関数 / `NewPromiseResolveThenableJob$jA から返されたなら,当の~promiseの `then^c 関数 ]が属する~realmになる。 ◎ If realm is not null, it is the realm of the author code that will run. When job is returned by NewPromiseReactionJob, it is the realm of the promise's handler function. When job is returned by NewPromiseResolveThenableJob, it is the realm of the then function.

    %~realm ~EQ ~NULL 場合、 走らす作者~codeは無いか, 作者~codeは投出することが保証される。 前者は、 作者が走らすものを~code内で渡さなかったからであろう — `promise.then(null, null)^c など。 後者は、 廃止された `Proxy^jc が渡されたからである。 どちらの事例でも、 以下において %~job設定群 を利用する段は,すべて飛ばされることになる。 ◎ If realm is null, either no author code will run or author code is guaranteed to throw. For the former, the author may not have passed in code to run, such as in promise.then(null, null). For the latter, it is because a revoked Proxy was passed. In both cases, all the steps below that would otherwise use job settings get skipped.

    [ `NewPromiseResolveThenableJob$jA, `NewPromiseReactionJob$jA ]は、 どちらも,廃止された `Proxy^jc の事例では ~NULL でない~realm(`現在の~realm$【!the current Realm Record】)を供するものと見受けられる。 前段落【!The previous text】は、 そのことを反映するよう更新され得る。 ◎ NewPromiseResolveThenableJob and NewPromiseReactionJob both seem to provide non-null realms (the current Realm Record) in the case of a revoked proxy. The previous text could be updated to reflect that.

  2. `小taskを~queueする$( 次の手続き ) ◎ Queue a microtask to perform the following steps:

    手続きは: ◎ ↑

    1. ~IF[ %~job設定群 ~NEQ ~NULL ]: ◎ ↓

      1. ~IF[ `~scriptは走れるかどうか検査する$( %~job設定群 ) ~EQ `走るな^i ] ⇒ ~RET ◎ If job settings is not null, then check if we can run script with job settings. If this returns "do not run" then return.
      2. `~scriptを走らすために準備する$( %~job設定群 ) ◎ If job settings is not null, then prepare to run script with job settings.

        注記: これは、 当の~jobが走っている間,`入口~某$の概念に影響する。 ◎ This affects the entry concept while the job runs.

    2. %結果 ~LET %~job() ◎ Let result be job().

      注記: %~job は[ `NewPromiseReactionJob$jA / `NewPromiseResolveThenableJob$jA ]から返された`抽象-~closure$である。 [ 前者/後者 ]から返されたときの,当の~promiseの[ ~handler関数 / `then^c 関数 ]は、 `~JobCallback~Record$内に包装される。 ~HTMLは、 `HostMakeJobCallback$A において`作動中な~script$用に[ `現任な設定群~obj$, `~JS実行~文脈$ ]を保存した上で, `HostCallJobCallback$A において それらを復旧する。 ◎ job is an abstract closure returned by NewPromiseReactionJob or NewPromiseResolveThenableJob. The promise's handler function when job is returned by NewPromiseReactionJob, and the then function when job is returned by NewPromiseResolveThenableJob, are wrapped in JobCallback Records. HTML saves the incumbent settings object and a JavaScript execution context for to the active script in HostMakeJobCallback and restores them in HostCallJobCallback.

    3. ~IF[ %~job設定群 ~NEQ ~NULL ] ⇒ `走らせた~scriptを片付ける$( %~job設定群 ) ◎ If job settings is not null, then clean up after running script with job settings.
    4. ~IF[ %結果 は`中途完了$である ] ⇒ `例外を報告する$( %結果 .`Value^sl, %~realm の`大域~obj$rM ) ◎ If result is an abrupt completion, then report an exception given by result.[[Value]] for realm's global object.

      [ %~realm には ~NULL が渡されつつ (例: `Promise.prototype.then^c が ~NULL ~handlerを伴って~callされたことにより), %結果 は (当の~promise能力の[ 解決-~handler/却下-~handler ]が例外を投出したことにより†) 中途完了になる ]ような,~~厄介な事例がある († それは、 これ【~promise能力?】が `Promise^jc の ある下位classであって, 【解決-~handler/却下-~handler用に?】 給された関数たちを[ 上位classである `Promise^jc の構築子へ渡された関数 ]へ渡す前に[ 投出している関数たち内に包装するもの ]であることにより生じる場合がある)。 次に,どの大域~objが利用されるか? — 現在の~realmは、[ 別の~realmに属する[ `Promise^jc 構築子 / `Promise.prototype.then^c ]を利用することにより[ その手続きを成す各~段で異なることもある ]ことを考慮して。 `課題 #10516@~HTMLissue/10526$ を見よ。 ◎ There is a very gnarly case where HostEnqueuePromiseJob is called with a null realm (e.g., because Promise.prototype.then was called with null handlers) but also the job returns abruptly (because the promise capability's resolve or reject handler threw, possibly because this is a subclass of Promise that takes the supplied functions and wraps them in throwing functions before passing them on to the function passed to the Promise superclass constructor. Which global is to be used then, considering that the current realm could be different at each of those steps, by using a Promise constructor or Promise.prototype.then from another realm? See issue #10526.

8.1.6.6.5. `HostEnqueueTimeoutJob^A( %~job, %~realm, %~milli秒数 )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostEnqueueTimeoutJob$jA を`実装定義$としている — それは、 演算を~timeout後に遂行されるよう~scheduleするためにある。 ~HTMLは、 `手続きを~timeout後に走らす$を利用して,そのような演算を~scheduleする。 ◎ JavaScript contains an implementation-defined HostEnqueueTimeoutJob(job, milliseconds) abstract operation to schedule an operation to be performed after a timeout. HTML schedules these operations using run steps after a timeout.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %大域~obj ~LET %~realm の`大域~obj$rM ◎ Let global be realm's global object.
  2. %~timeout手続き ~LET 次を走らす手続き ⇒ `大域~taskを~queueする$( `~JS~engine~task~source$, %大域~obj, %~job ) ◎ Let timeoutStep be an algorithm step which queues a global task on the JavaScript engine task source given global to perform job().
  3. `手続きを~timeout後に走らす$( %大域~obj, `JavaScript^l, %~milli秒数, %~timeout手続き ) ◎ Run steps after a timeout given global, "JavaScript", milliseconds, and timeoutStep.
8.1.6.6.6. `HostMakeJobCallback^A( %~callable )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostMakeJobCallback$jA を`実装定義$としている — それは、[ `~task$の内側から~callされた~JS~callbackに,状態を伴わせる ]ことを~hostに任せるためにある。 ◎ JavaScript contains an implementation-defined HostMakeJobCallback(callable) abstract operation to let hosts attach state to JavaScript callbacks that are called from inside tasks.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %現任な設定群 ~LET `現任な設定群~obj$ ◎ Let incumbent settings be the incumbent settings object.
  2. %作動中な~script ~LET `作動中な~script$ ◎ Let active script be the active script.
  3. %~script実行~文脈 ~LET ~NULL ◎ Let script execution context be null.
  4. ~IF[ %作動中な~script ~NEQ ~NULL ] ⇒ %~script実行~文脈 ~SET 新たな`~JS実行~文脈$ — その ⇒# ~Function~field ~SET ~NULL, ~Realm~field ~SET %作動中な~script の`設定群~obj$sCの`~realm$enV, ~ScriptOrModule成分 ~SET %作動中な~script の`~record$sC ◎ If active script is not null, set script execution context to a new JavaScript execution context, with its Function field set to null, its Realm field set to active script's settings object's realm, and its ScriptOrModule set to active script's record.

    注記: 下に見られるとおり、 これは,現在の`作動中な~script$を — 後で当の~job~callback【 %~callable 】が呼出される時点まで — 伝播するために利用される。 ◎ As seen below, this is used in order to propagate the current active script forward to the time when the job callback is invoked.

    %作動中な~script ~NEQ ~NULL のときに,それを この仕方で保存することは、 次の事例で有用になる: ◎ A case where active script is non-null, and saving it in this way is useful, is the following:

    Promise.resolve('import(``^./example.mjs``^)').then(eval);
    

    この段 (および, `HostCallJobCallback$A 内でそれを利用する手続き) を経ない限り、 `import()$m 式を評価するときに,`作動中な~script$は無いことになる — `eval()$m は、 特定0の`~script$を出自にしない組込みの関数なので。 ◎ Without this step (and the steps that use it in HostCallJobCallback), there would be no active script when the import() expression is evaluated, since eval() is a built-in function that does not originate from any particular script.

    この段を経ることで, %作動中な~script は 上の~codeから~jobの中へ伝播され、 `import()$m は,元の~scriptの`基底~URL$sCを適切に利用できるようになる。 ◎ With this step in place, the active script is propagated from the above code into the job, allowing import() to use the original script's base URL appropriately.

    %作動中な~script は、 利用者が次のような~buttonを~clickした場合には, ~NULL になり得る: ◎ active script can be null if the user clicks on the following button:

    <button onclick="Promise.resolve('import(``^./example.mjs``^)').then(eval)">Click me</button>
    

    この事例では、 `~event~handler$用の~JS関数は,`~event~handlerの現在の値を取得する$~algoにより作成され、 それは[ `ScriptOrModule^sl が ~NULL 値にされた関数 ]を作成することになる。 したがって、 ~promise機構が `HostMakeJobCallback$A を~callするときも,渡される`作動中な~script$は無いことになる。 ◎ In this case, the JavaScript function for the event handler will be created by the get the current value of the event handler algorithm, which creates a function with null [[ScriptOrModule]] value. Thus, when the promise machinery calls HostMakeJobCallback, there will be no active script to pass along.

    その帰結として、 このことは,[ `import()$m 式が評価される時点でも,`作動中な~script$は依然として無い ]ことを意味する。 幸いにも、 それは,この仕様による `HostLoadImportedModule$A の実装により取扱われる — `現在の設定群~obj$の`~API用~基底~URL$enVを利用するよう~fall-backすることにより。 ◎ As a consequence, this means that when the import() expression is evaluated, there will still be no active script. Fortunately that is handled by our implementation of HostLoadImportedModule by falling back to using the current settings object's API base URL.

  5. ~RET 新たな`~JobCallback~Record$ — その:

    • `Callback^sl ~SET %~callable
    • `HostDefined^sl ~SET 新たな`~Record$ — その ⇒# `IncumbentSettings^sl ~SET %現任な設定群, `ActiveScriptContext^sl ~SET %~script実行~文脈
    ◎ Return the JobCallback Record { [[Callback]]: callable, [[HostDefined]]: { [[IncumbentSettings]]: incumbent settings, [[ActiveScriptContext]]: script execution context } }.
8.1.6.7. ~moduleに関係する~host~hook

~JS仕様は、 ~module用の構文, および その処理~modelにおける ~hostに不問な部分を定義する。 この仕様は、 その処理~modelの残りの部分 — ~module~systemが[ `type$a 属性が `module^l に設定された `script$e 要素 ]を介して~bootstrapされる方法,および ~moduleが[ ~fetchされ, 解決され, 実行される ]方法 — を定義する。 `JAVASCRIPT$r ◎ The JavaScript specification defines a syntax for modules, as well as some host-agnostic parts of their processing model. This specification defines the rest of their processing model: how the module system is bootstrapped, via the script element with type attribute set to "module", and how modules are fetched, resolved, and executed. [JAVASCRIPT]

注記: ~JS仕様は,[ “script” vs. “module” ]の用語で記されているが、 この仕様は,一般に[ `古典~script$ vs. `~module~script$ ]の用語で記される — 両者とも `script$e 要素を利用するので。 ◎ Although the JavaScript specification speaks in terms of "scripts" versus "modules", in general this specification speaks in terms of classic scripts versus module scripts, since both of them use the script element.

%modulePromise = `import(specifier)$m
%specifier により識別される`~module~script$用の~module名前空間~obj用の~promiseを返す。 この~module~scriptの稼働時における動的な~import法を許容する — `import^c 文の形を利用して,静的に~importする代わりに。 指定子 %specifier は、 `作動中な~script$に相対的に`解決される@#resolve-a-module-specifier$ことになる。 ◎ Returns a promise for the module namespace object for the module script identified by specifier. This allows dynamic importing of module scripts at runtime, instead of statically using the import statement form. The specifier will be resolved relative to the active script.
返される~promiseは、 次の場合には,却下される ⇒ 所与の指定子は妥当でない/ 結果の~module~graphを[ `~fetchして@#hostloadimportedmodule$いる間/評価している間 ]に失敗に遭遇した ◎ The returned promise will be rejected if an invalid specifier is given, or if a failure is encountered while fetching or evaluating the resulting module graph.
この構文は、[ `古典~script$, `~module~script$ ]どちらの内側でも利用できる。 したがって、 古典~scriptの世界から~module~scriptの世界への橋渡しを供する。 ◎ This syntax can be used inside both classic and module scripts. It thus provides a bridge into the module-script world, from the classic-script world.
%url = `import.meta$c.`url$m
`作動中な~script$の`基底~URL$sCを返す。 ◎ Returns the active module script's base URL.
この構文は、 `~module~script$の内側に限り利用できる。 ◎ This syntax can only be used inside module scripts.
%url = `import.meta$c.`resolve(specifier)$m
%specifier を`作動中な~script$に相対的に`解決-@#resolve-a-module-specifier$した結果を返す。 すなわち,これは、 `import(specifier)$m を利用して~importされることになる~URLを返す。 ◎ Returns specifier, resolved relative to the active script. That is, this returns the URL that would be imported by using import(specifier).
所与の指定子が妥当でない場合、 `TypeError$jc 例外を投出する。 ◎ Throws a TypeError exception if an invalid specifier is given.
この構文は、 `~module~script$の内側に限り利用できる。 ◎ This syntax can only be used inside module scripts.

`~module~map@ は、 `~map$である — それを成す各`~entry$の: ◎ A module map is a map\

  • `~key$mapは、 ( `~URL~record$, `文字列$ ) が成す`~tuple$である ⇒# `~URL~record$は、当の~moduleを~fetchした`~URL$rqを与える。 `文字列$は、当の~moduleの種別(例: `javascript-or-wasm^l )を指示する。

    【 ~keyどうしの同等性は、 必然的に,成分ごとの比較に基づくことになる。 ~URL成分の同等性は、 必然的に,`同等な~URL$に基づくことになる。 】

    ◎ keyed by tuples consisting of a URL record and a string. The URL record is the request URL at which the module was fetched, and the string indicates the type of the module (e.g. "javascript-or-wasm").
  • `値$mapは、 次のいずれかになる ⇒# `~module~script$ / ~NULL(失敗した~fetchを表現するために利用される)/ `fetching^l (仮入力~値†)

    【† すなわち、 `fetching^l は,~fetch後には他の値に確定される。 】

    ◎ The module map's values are either a module script, null (used to represent failed fetches), or a placeholder value "fetching".\

`~module~map$は、 次を確保するために利用される ⇒ ~importされた~module~scriptが[ ~fetchされ, 構文解析され, 評価される ]のは、 各[ `文書$/`~worker$ ]ごとに一度に限られる。 ◎ Module maps are used to ensure that imported module scripts are only fetched, parsed, and evaluated once per Document or worker.

`~module~map$は ( ~URL, ~module種別 ) を~keyに利用するので、 次の~codeは,`~module~map$内に 3 個の別々な~entryを作成させることになる — それらの結果は、 3 個の異なる~tuple ( ~URL, ~module種別 ) になるので (どれも,同じ種別 `javascript-or-wasm^l を伴うが): ◎ Since module maps are keyed by (URL, module type), the following code will create three separate entries in the module map, since it results in three different (URL, module type) tuples (all with "javascript-or-wasm" type):

import "https://example.com/module.mjs";
import "https://example.com/module.mjs#map-buster";
import "https://example.com/module.mjs?debug=true";

すなわち、 ~URLの[ `~query$url, `素片$url ]の違いは無視されず,`~module~map$内に別個な~entryを作成させる。 したがって、 3 回の別々な~fetch, 3 回の別々な~module評価 が遂行されることになる。 ◎ That is, URL queries and fragments can be varied to create distinct entries in the module map; they are not ignored. Thus, three separate fetches and three separate module evaluations will be performed.

対照的に、 次の~codeにより`~module~map$内に作成される~entryは 1 個だけになる — これらの入力を`~URL構文解析-$した結果の`~URL$は、 互いに等しくなるので: ◎ In contrast, the following code would only create a single entry in the module map, since after applying the URL parser to these inputs, the resulting URL records are equal:

import "https://example.com/module2.mjs";
import "https:example.com/module2.mjs";
import "https://///example.com\\module2.mjs";
import "https://example.com/foo/../module2.mjs";

よって、 この~codeにより生じる~fetch, および~module評価は 1 回だけになる。 ◎ So in this second example, only one fetch and one module evaluation will occur.

この挙動は、 `共用~worker$が構文解析された`構築子~URL$を~keyに利用するときと同じであることに注意。 ◎ Note that this behavior is the same as how shared workers are keyed by their parsed constructor url.

~module種別も`~module~map$用の~keyの一部を成すので、 次の~codeは, `~module~map$内に 2 個の別々な~entry (順に、種別 `javascript-or-wasm^l, 種別 `css^l ) を作成することになる: ◎ Since module type is also part of the module map key, the following code will create two separate entries in the module map (the type is "javascript-or-wasm" for the first, and "css" for the second):

<script type=module>
  import "https://example.com/module";
</script>
<script type=module>
  import "https://example.com/module" with { type: "css" };
</script>

その結果、[ 2 つの別々な~fetch, 2 つの別々な~module評価 ]が遂行され得る。 ◎ This can result in two separate fetches and two separate module evaluations being performed.

実施においては — [ WebKit / Blink ]に基づく~browserにおいては — まだ仕様~化されてない~memory~cache ( `課題 #6110@~HTMLissue/6110$を見よ) に因り、 当の資源が~fetchされ得るのは,一度限りになる。 加えて,すべての~module種別が互いに排他的である限り、 `単独の~module~scriptを~fetchする$ における~module種別~検査は[ ~importたちのうち少なくとも 1 つ ]に対し失敗することになるので, ~module評価は 1 回までしか生じない。 【背後にどのような論理があるのかよくわからない。】 ◎ In practice, due to the as-yet-unspecified memory cache (see issue #6110) the resource may only be fetched once in WebKit and Blink-based browsers. Additionally, as long as all module types are mutually exclusive, the module type check in fetch a single module script will fail for at least one of the imports, so at most one module evaluation will occur.

`~module~map$の~keyに種別を含めている目的は、 間違った種別【 `type^c 】属性を伴う~importが,異なる~import — 同じ指定子を伴うが,正しい種別を伴うそれ — が成功することまでは防止しないことにある。 ◎ The purpose of including the type in the module map key is so that an import with the wrong type attribute does not prevent a different import of the same specifier but with the correct type from succeeding.

~JS~module~scriptは、 別の~JS~moduleから~importするときの既定の~import種別である。 すなわち、 `import^c 文が `type^c ~import属性を欠如するとき, ~importされた~module~scriptの種別は~JSになる。 [ `type^c ~import属性を伴う `import^c 文 ]を利用して~JS資源を~importする試みは、 失敗することになる: ◎ JavaScript module scripts are the default import type when importing from another JavaScript module; that is, when an import statement lacks a type import attribute the imported module script's type will be JavaScript. Attempting to import a JavaScript resource using an import statement with a type import attribute will fail:

<script type="module">
    /* 
次に挙げるものは、
どれも失敗することになる
— ~importされる .mjs ~fileは、
~JS~MIME型を伴って~serveされると見做すならば。
~JS~module~scriptは既定であり、
どの~import種別~属性( `with { type: … }^c )でも,~importし得ない。
◎
All of the following will fail, assuming that the imported .mjs files are served with a JavaScript MIME type. JavaScript module scripts are the default and cannot be imported with any import type attribute.
 */
    import foo from "./foo.mjs" with { type: "javascript" };
    import foo2 from "./foo2.mjs" with { type: "js" };
    import foo3 from "./foo3.mjs" with { type: "" };
    await import("./foo4.mjs", { with: { type: null } });
    await import("./foo5.mjs", { with: { type: undefined } });
</script>
8.1.6.7.1. `HostGetImportMetaProperties^A( %~module~record )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostGetImportMetaProperties$jA を`実装定義$としている。 ◎ JavaScript contains an implementation-defined HostGetImportMetaProperties abstract operation.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %~module~script ~LET %~module~record .`HostDefined^sl ◎ Let moduleScript be moduleRecord.[[HostDefined]].
  2. ~Assert: %~module~script の`基底~URL$sC ~NEQ ~NULL — %~module~script は`~JS~module~script$なので。 ◎ Assert: moduleScript's base URL is not null, as moduleScript is a JavaScript module script.
  3. %~URL文字列 ~LET `~URLを直列化する$( %~module~script の`基底~URL$sC ) ◎ Let urlString be moduleScript's base URL, serialized.
  4. %手続き ~LET 所与の ( %指定子 ) に対し,次を走らす手続き: ◎ Let steps be the following steps, given the argument specifier:

    1. %指定子 ~SET ~ABRUPT `ToString$jA( %指定子 ) ◎ Set specifier to ? ToString(specifier).
    2. %~URL ~LET `~module指定子を解決する$( %~module~script, %指定子 ) ◎ Let url be the result of resolving a module specifier given moduleScript and specifier.
    3. ~RET `~URLを直列化する$( %~URL ) ◎ Return the serialization of url.
  5. %解決-関数 ~LET ~NOABRUPT `CreateBuiltinFunction$jA( %手続き, 1, `resolve^l, « » ) ◎ Let resolveFunction be ! CreateBuiltinFunction(steps, 1, "resolve", « »).
  6. ~RET « 次に挙げる~itemたち »

    1. 新たな`~Record$ — その ⇒# `Key^sl ~SET "`url@m", `Value^sl ~SET %~URL文字列
    2. 新たな`~Record$ — その ⇒# `Key^sl ~SET "`resolve@m", `Value^sl ~SET %解決-関数
    ◎ Return « Record { [[Key]]: "url", [[Value]]: urlString }, Record { [[Key]]: "resolve", [[Value]]: resolveFunction } ».
8.1.6.7.2. `HostGetSupportedImportAttributes^A()

`~import属性^cite ( `Import Attributes^en )提案 `JSIMPORTATTRIBUTES$r は、 その抽象-演算 `HostGetSupportedImportAttributes$jA を`実装定義$としている。 ◎ The Import Attributes proposal contains an implementation-defined HostGetSupportedImportAttributes abstract operation.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JSIMPORTATTRIBUTES]

  1. ~RET « `type^l » ◎ Return « "type" ».
8.1.6.7.3. `HostLoadImportedModule^A( %参照元, %~module要請, %読込n状態, %~payload )

~JS `JAVASCRIPT$r は、 その抽象-演算 `HostLoadImportedModule$jA を`実装定義$としている。 ◎ JavaScript contains an implementation-defined HostLoadImportedModule abstract operation.\

~UAは、 次の実装を利用するモノトスル: ◎ User agents must use the following implementation: [JAVASCRIPT]

  1. %設定群~obj ~LET `現在の設定群~obj$ ◎ Let settingsObject be the current settings object.
  2. ~IF[ %設定群~obj の`大域~obj$enVは[ `WorkletGlobalScope$I / `ServiceWorkerGlobalScope$I ]を実装する ]~AND[ %読込n状態 ~EQ `undefined^jv ]: ◎ If settingsObject's global object implements WorkletGlobalScope or ServiceWorkerGlobalScope and loadState is undefined, then:

    注記: %読込n状態 は、 次のときには `undefined^jv になる ⇒ 現在の~fetchingが,次により起動された ⇒ 次のいずれかにより `import()$m が動的に~callされた ⇒# 直に/ 動的に~importされた~moduleの推移的な依存物を読込むとき ◎ loadState is undefined when the current fetching process has been initiated by a dynamic import() call, either directly or when loading the transitive dependencies of the dynamically imported module.

    1. %完了~record ~LET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET 新たな `TypeError$jc, `Target^sl ~SET `empty^i ◎ Let completion be Completion Record { [[Type]]: throw, [[Value]]: a new TypeError, [[Target]]: empty }.
    2. `FinishLoadingImportedModule$jA( %参照元, %~module要請, %~payload, %完了~record ) ◎ Perform FinishLoadingImportedModule(referrer, moduleRequest, payload, completion).
    3. ~RET ◎ Return.
  3. %参照ng~script ~LET ~NULL ◎ Let referencingScript be null.
  4. %元の~fetch~option群 ~LET `既定の~script~fetch~option群$ ◎ Let originalFetchOptions be the default script fetch options.
  5. %~fetch~referrer ~LET `client^l ◎ Let fetchReferrer be "client".
  6. ~IF[ %参照元 は[ `~script~Record$/`循環な~module~Record$ ]である ]: ◎ If referrer is a Script Record or a Cyclic Module Record, then:

    1. %参照ng~script ~SET %参照元 .`HostDefined^sl ◎ Set referencingScript to referrer.[[HostDefined]].
    2. %設定群~obj ~SET %参照ng~script の`設定群~obj$sC ◎ Set settingsObject to referencingScript's settings object.
    3. %~fetch~referrer ~SET %参照ng~script の`基底~URL$sC ◎ Set fetchReferrer to referencingScript's base URL.
    4. %元の~fetch~option群 ~SET %参照ng~script の`~fetch~option群$sC ◎ Set originalFetchOptions to referencingScript's fetch options.

    %参照元 は,通例的には[ `~script~Record$/`循環な~module~Record$ ]になるが、 `~event~handlerの現在の値を取得する$~algoにより,~event~handler用にはそうならない。 例えば,次が与えられた下で: ◎ referrer is usually a Script Record or a Cyclic Module Record, but it will not be so for event handlers per the get the current value of the event handler algorithm. For example, given:

    <button onclick="import('./foo.mjs')">Click me</button>
    

    `click$et ~eventが生じた場合、[ `import()$m 式が走る時点で, `GetActiveScriptOrModule$jA は ~NULL を返す ]ことになり,[ この演算は、 %参照元 用の~fallbackとして`現在の~realm$を受取る ]ことになる。 ◎ If a click event occurs, then at the time the import() expression runs, GetActiveScriptOrModule will return null, and this operation will receive the current realm as a fallback referrer.

  7. ~IF[ %参照元 は`循環な~module~Record$である ]~AND[ %~module要請 ~EQ %参照元 .`RequestedModules^sl[ 0 ] ]: ◎ If referrer is a Cyclic Module Record and moduleRequest is equal to the first element of referrer.[[RequestedModules]], then:

    1. %参照元 .`RequestedModules^sl を成す ~EACH( `~module要請~Record$ %~module要請【!誤記:requested】 ) に対し: ◎ For each ModuleRequest record requested of referrer.[[RequestedModules]]:

      1. %~module要請 .`Attributes^sl を成す ~EACH( `~Record$ %~entry ) に対し: ◎ If moduleRequest.[[Attributes]] contains a Record entry\

        1. ~IF[ %~entry .`Key^sl ~EQ `type^l ] ⇒ ~CONTINUE ◎ such that entry.[[Key]] is not "type", then:
        2. %完了~record ~LET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET 新たな `TypeError$jc, `Target^sl ~SET `empty^i ◎ Let completion be Completion Record { [[Type]]: throw, [[Value]]: a new SyntaxError exception, [[Target]]: empty }.
        3. `FinishLoadingImportedModule$jA( %参照元, %~module要請, %~payload, %完了~record ) ◎ Perform FinishLoadingImportedModule(referrer, moduleRequest, payload, completion).
        4. ~RET ◎ Return.

        注記: ~JS仕様は[ %~script の依存物を読込むときに,この検証を遂行し直す ]が、 ここに重複されたのは,[ 検証に失敗した依存物を不必要に読込むことを避ける ]ためである。 ◎ The JavaScript specification re-performs this validation but it is duplicated here to avoid unnecessarily loading any of the dependencies on validation failure.

      2. `~module指定子を解決する$( %参照ng~script, %~module要請 .`Specifier^sl ) ◎ Resolve a module specifier given referencingScript and moduleRequest.[[Specifier]],\

        例外 %解決~error が投出されたときは、 ~catchして: ◎ catching any exceptions. If they throw an exception, let resolutionError be the thrown exception. ◎ If the previous step threw an exception, then:

        1. %完了~record ~LET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET %解決~error, `Target^sl ~SET `empty^i ◎ Let completion be Completion Record { [[Type]]: throw, [[Value]]: resolutionError, [[Target]]: empty }.
        2. `FinishLoadingImportedModule$jA( %参照元, %~module要請, %~payload, %完了~record ) ◎ Perform FinishLoadingImportedModule(referrer, moduleRequest, payload, completion).
        3. ~RET ◎ Return.
      3. %~module種別 ~LET `~module要請から~module種別を得る$( %~module要請 ) ◎ Let moduleType be the result of running the module type from module request steps given moduleRequest.
      4. ~IF[ `~module種別は許容されるか?$( %~module種別, %設定群~obj ) ~EQ ~F ]: ◎ If the result of running the module type allowed steps given moduleType and settingsObject is false, then:

        1. %完了~record ~LET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET 新たな `TypeError$jc, `Target^sl ~SET `empty^i ◎ Let completion be Completion Record { [[Type]]: throw, [[Value]]: a new TypeError exception, [[Target]]: empty }.
        2. `FinishLoadingImportedModule$jA( %参照元, %~module要請, %~payload, %完了~record ) ◎ Perform FinishLoadingImportedModule(referrer, moduleRequest, payload, completion).
        3. ~RET ◎ Return.

      注記: この段は、[ 静的~module依存関係~list用に `HostLoadImportedModule$A の~callが最初に為された ]ときに,本質的に[ 要請された[ ~module指定子, 種別~属性 ]すべて ]を検証する — ある依存物に静的な~errorがある事例において,更なる読込ng演算を避けるため。 [ 解決-不能な~module指定子/~supportされない種別~属性 ]は、 構文解析できなかったときと同じに扱う — 後で~moduleを~linkするような考えは排される。 ◎ This step is essentially validating all of the requested module specifiers and type attributes when the first call to HostLoadImportedModule for a static module dependency list is made, to avoid further loading operations in the case any one of the dependencies has a static error. We treat a module with unresolvable module specifiers or unsupported type attributes the same as one that cannot be parsed; in both cases, a syntactic issue makes it impossible to ever contemplate linking the module later.

  8. %~URL ~LET `~module指定子を解決する$( %参照ng~script, %~module要請 .`Specifier^sl ) ◎ Let url be the result of resolving a module specifier given referencingScript and moduleRequest.[[Specifier]], catching any exceptions.\

    この段で例外 %解決~error が投出されたときは、 ~catchして: ◎ If they throw an exception,\ let resolutionError be the thrown exception. ◎ If the previous step threw an exception, then:

    1. %完了~record ~LET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET %解決~error, `Target^sl ~SET `empty^i ◎ Let completion be Completion Record { [[Type]]: throw, [[Value]]: resolutionError, [[Target]]: empty }.
    2. `FinishLoadingImportedModule$jA( %参照元, %~module要請, %~payload, %完了~record ) ◎ Perform FinishLoadingImportedModule(referrer, moduleRequest, payload, completion).
    3. ~RET ◎ Return.
  9. %~fetch~option群 ~LET `子孫~script~fetch~option群を取得する$( %元の~fetch~option群, %~URL, %設定群~obj ) ◎ Let fetchOptions be the result of getting the descendant script fetch options given originalFetchOptions, url, and settingsObject.
  10. %行先 ~LET `script^l ◎ Let destination be "script".
  11. %~fetch~client ~LET %設定群~obj ◎ Let fetchClient be settingsObject.
  12. ~IF[ %読込n状態 ~NEQ `undefined^jv ]: ◎ If loadState is not undefined, then:

    1. %行先 ~SET %読込n状態 .`Destination^sl ◎ Set destination to loadState.[[Destination]].
    2. %~fetch~client ~SET %読込n状態 .`FetchClient^sl ◎ Set fetchClient to loadState.[[FetchClient]].
  13. %~fetchを遂行する ~LET ε ◎ ↓
  14. ~IF[ %読込n状態 ~NEQ `undefined^jv ]~AND[ %読込n状態 .`PerformFetch^sl ~NEQ ~NULL ] ⇒ %~fetchを遂行する ~SET %読込n状態 .`PerformFetch^sl ◎ ↓
  15. `単独の~importされた~module~scriptを~fetchする$( ↓ ) ⇒# %~URL, %~fetch~client, %行先, %~fetch~option群, %設定群~obj, %~fetch~referrer, %~module要請, 次に定義する手続き, %~fetchを遂行する ◎ Fetch a single imported module script given url, fetchClient, destination, fetchOptions, settingsObject, fetchReferrer, moduleRequest, and onSingleFetchComplete as defined below. If loadState is not undefined and loadState.[[PerformFetch]] is not null, pass loadState.[[PerformFetch]] along as well.

    手続き【!onSingleFetchComplete】は、 所与の ( %~module~script ) に対し: ◎ onSingleFetchComplete given moduleScript is the following algorithm:

    1. %完了~record ~LET ~NULL ◎ Let completion be null.
    2. ~IF[ %~module~script ~EQ ~NULL ] ⇒ %完了~record ~SET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET 新たな `TypeError$jc, `Target^sl ~SET `empty^i ◎ If moduleScript is null, then set completion to Completion Record { [[Type]]: throw, [[Value]]: a new TypeError, [[Target]]: empty }.
    3. ~ELIF[ %~module~script の`構文解析-~error$sC ~NEQ ~NULL ]: ◎ Otherwise, if moduleScript's parse error is not null, then:

      1. %構文解析-~error ~LET %~module~script の`構文解析-~error$sC ◎ Let parseError be moduleScript's parse error.
      2. %完了~record ~SET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `throw^i, `Value^sl ~SET %構文解析-~error, `Target^sl ~SET `empty^i ◎ Set completion to Completion Record { [[Type]]: throw, [[Value]]: parseError, [[Target]]: empty }.
      3. ~IF[ %読込n状態 ~NEQ `undefined^jv ]~AND[ %読込n状態 .`ParseError^sl ~EQ ~NULL ] ⇒ %読込n状態 .`ParseError^sl ~SET %構文解析-~error ◎ If loadState is not undefined and loadState.[[ParseError]] is null, set loadState.[[ParseError]] to parseError.
    4. ~ELSE ⇒ %完了~record ~SET 新たな`完了~Record$ — その ⇒# `Type^sl ~SET `normal^i, `Value^sl ~SET %~module~script の`~record$sC, `Target^sl ~SET `empty^i ◎ Otherwise, set completion to Completion Record { [[Type]]: normal, [[Value]]: moduleScript's record, [[Target]]: empty }.
    5. `FinishLoadingImportedModule$jA( %参照元, %~module要請, %~payload, %完了~record ) ◎ Perform FinishLoadingImportedModule(referrer, moduleRequest, payload, completion).

8.1.7. ~event~loop

8.1.7.1. 各種~定義

~UAは、 この節に述べる `~event~loop@ を利用して,[ ~event, 利用者-ヤリトリ, ~script, 描画, ~networking, 等々 ]を互いに協調させるモノトスル。 ◎ To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as described in this section.\

各`~agent$には、 `~event~loop@aG が,その~agentに一意な`~event~loop$として結付けられる: ◎ Each agent has an associated event loop, which is unique to that agent.

  • `生成元が類似な~window~agent$の`~event~loop$aGは、 `~window~event~loop@ と称される。 ◎ The event loop of a similar-origin window agent is known as a window event loop.\
  • [ `専用~worker~agent$/`共用~worker~agent$/`~sw~agent$ ]の`~event~loop$aGは、 `~worker~event~loop@ と総称される。 ◎ The event loop of a dedicated worker agent, shared worker agent, or service worker agent is known as a worker event loop.\
  • `~worklet~agent$の`~event~loop$aGは、 `~worklet~event~loop@ と称される。 ◎ And the event loop of a worklet agent is known as a worklet event loop.

注記: `~event~loop$は、 実装の~threadに対応するとは限らない。 例えば、 複数の`~window~event~loop$が,単独の~thread内で協力的に~scheduleされることもある。 ◎ Event loops do not necessarily correspond to implementation threads. For example, multiple window event loops could be cooperatively scheduled in a single thread.

しかしながら,各種~worker`~agent$のうち, `CanBlock^sl を ~T に設定して割振られたものに対しては、 ~JS仕様は `前方-進捗@~TC39#sec-forward-progress$に関する要件を設置している — その要件は,実質的に、 そのような事例においては,~agentごとに専用な~threadを要求することに相当する。 ◎ However, for the various worker agents that are allocated with [[CanBlock]] set to true, the JavaScript specification does place requirements on them regarding forward progress, which effectively amount to requiring dedicated per-agent threads in those cases.


各`~event~loop$には、 1 個以上の `~task~queue@ がある。 各`~task~queue$は、 `~task$たちが成す`有順序~集合$である。 ◎ An event loop has one or more task queues. A task queue is a set of tasks.

注記: `~task~queue$は`有順序~集合$であり,`~queue$ではない。 ~event~loop処理~modelは、 `選ばれた~queue@#step1$から — 最初の~taskを`~dequeueする$ことに代えて — 最初の`可走な~task$を取り出すので。 【`~queue$に対しては、そのような演算は許容されないことが前提にある。】 ◎ Task queues are sets, not queues, because the event loop processing model grabs the first runnable task from the chosen queue, instead of dequeuing the first task.

注記: `小task~queue$は`~task~queue$ではない。 ◎ The microtask queue is not a task queue.

各~taskは、 次に挙げるような作業を担当する~algoを~capsule化する: ◎ Tasks encapsulate algorithms that are responsible for such work as:

~event ◎ Events
特定0の `EventTarget$I ~objに向けて~eventを`配送-$するときは、 専用の~taskで行われることが多い。 ◎ Dispatching an Event object at a particular EventTarget object is often done by a dedicated task.
注記: すべての~eventが`~task~queue$を利用して配送されるわけではない。 他の~taskの中で配送されるものも多々ある。 ◎ Not all events are dispatched using the task queue; many are dispatched during other tasks.
構文解析 ◎ Parsing
`~HTML構文解析器$が,~byte列を~token化して結果の~token列を処理することは、 概して~taskになる。 ◎ The HTML parser tokenizing one or more bytes, and then processing any resulting tokens, is typically a task.
~callback ◎ Callbacks
~callbackを~callすることは、 専用の~taskで行われることが多い。 ◎ Calling a callback is often done by a dedicated task.
資源を利用するとき ◎ Using a resource
~algoが ある資源を`~fetchする$とき,その~fetchingが他を阻まずに行われる場合、[ 資源の一部または~~全部が可用になったときの処理 ]は,何らかの~taskにより遂行される。 ◎ When an algorithm fetches a resource, if the fetching occurs in a non-blocking fashion then the processing of the resource once some or all of the resource is available is performed by a task.
~DOM操作に反応するとき ◎ Reacting to DOM manipulation
一部の要素には、 要素が`文書の中へ挿入された$ときなど,~DOM操作に呼応して誘発されるような~taskがある。 ◎ Some elements have tasks that trigger in response to DOM manipulation, e.g. when that element is inserted into the document.

`~task@ とは、 正式には,次に挙げるものからなる`構造体$である: ◎ Formally, a task is a struct which has:

`手続き@tK ◎ Steps
この~taskが行うことになる作業を指定している一連の段。 ◎ A series of steps specifying the work to be done by the task.
`~source@tK ◎ A source
この~taskが属するとされる,いずれかの`~task~source$。 互いに関係する~taskを~group化して直列化する【順序どおりに走らす】ために利用される。 ◎ One of the task sources, used to group and serialize related tasks.
`文書@tK ◎ A document
この~taskに結付けられる`文書$, または、 `~window~event~loop$に属さない~task用には ~NULL 。 ◎ A Document associated with the task, or null for tasks that are not in a window event loop.
`~script評価 環境~設定群~obj集合@tK ◎ A script evaluation environment settings object set
`環境~設定群~obj$たちが成す`有順序~集合$ — この~taskを走らす間に~script評価を追跡するために利用される。 ◎ A set of environment settings objects used for tracking script evaluation during the task.

`~task$のうち、 その`文書$tKは[ ~NULL または`全部的に作動中$ ]であるものを, `可走な~task@ という。 ◎ A task is runnable if its document is either null or fully active.

どの`~task$も,その`~source$tKが指す特定の `~task~source@ から来るものとして定義される。 各`~event~loop$においては、 `~task~source$ごとに,特定の`~task~queue$が結付けられるモノトスル†。 ◎ Per its source field, each task is defined as coming from a specific task source. For each event loop, every task source must be associated with a specific task queue.

【† 言い換えれば、 所与の~task~sourceには,各~event~loopごとに対応する~task~queueが 1 個だけある — または無い (その~task~sourceからの~taskは決して~queueされない~event~loopの場合)。 】

注記: `~task~source$は、 本質的には,[ ~UAが判別したいと望むであろう,相異なる型の~taskどうし ]を各種~標準の中で論理的に分離するために利用される。 `~task~queue$は、 所与の`~event~loop$の中で~task~sourceたちを合体するために,~UAにより利用される。 ◎ Essentially, task sources are used within standards to separate logically-different types of tasks, which a user agent might wish to distinguish between. Task queues are used by user agents to coalesce task sources within a given event loop.

例えば~UAは、[ ~mouse/~UIkey ]等の~UI~event用には,ある一つの(`利用者~対話~task~source$が結付けられた)`~task~queue$をあてがい、 他のすべてには,別の(他の`~task~source$が結付けられた)それをあてがうこともできる。 その上で,`~event~loop処理~model$の最初の段に是認される自由度を利用して、 ~UI~event用に 他すべての~taskの 3 倍程度の時間をあてがうこともできる — ~UIを即応可能に保ちながら,他の~task~queueも放置しないよう。 この設定下においても、 この処理~modelにより,~UAは[ どの`~task~source$に対しても,それに属する各~eventは必ず順序通りに処理する ]ことを施行することに注意。 ◎ For example, a user agent could have one task queue for mouse and key events (to which the user interaction task source is associated), and another to which all other task sources are associated. Then, using the freedom granted in the initial step of the event loop processing model, it could give keyboard and mouse events preference over other tasks three-quarters of the time, keeping the interface responsive but not starving other task queues. Note that in this setup, the processing model still enforces that the user agent would never process events from any one task source out of order.


各`~event~loop$には、 次に挙げるものが結付けられる: ◎ ↓

`現在~走っている~task@ ◎ Each event loop has a currently running task,\
`~task$または~NULL — 初期~時には~NULLとする。 ◎ which is either a task or null. Initially, this is null.\
これは、 再入性を取扱うために利用される。 ◎ It is used to handle reentrancy.
`小task~queue@ ◎ Each event loop has a microtask queue,\
`小task$たちが成す`~queue$ — 初期~時は空とする。 ◎ which is a queue of microtasks, initially empty.\
`小task@ は、[ `小taskを~queueする$~algoを介して作成された`~task$ ]を指す,平易な呼称である。 ◎ A microtask is a colloquial way of referring to a task that was created via the queue a microtask algorithm.
`小task~checkpoint遂行-中か@ ◎ Each event loop has a performing a microtask checkpoint\
真偽値 — 初期~時は ~F とする。 ◎ boolean, which is initially false.\
これは、[ `小task~checkpointを遂行する$~algoが再入的に呼出される ]のを防止するために利用される。 ◎ It is used to prevent reentrant invocation of the perform a microtask checkpoint algorithm.

各`~window~event~loop$には、 次に挙げるものが結付けられる: ◎ ↓

  • `最後の描画-機会~時刻@ ⇒ `DOMHighResTimeStamp$I 値 — 初期~時は 0 とする。 ◎ Each window event loop has a DOMHighResTimeStamp last render opportunity time, initially set to zero.
  • `最後の遊休期間~開始-時刻@ ⇒ `DOMHighResTimeStamp$I 値 — 初期~時は 0 とする。 ◎ Each window event loop has a DOMHighResTimeStamp last idle period start time, initially set to zero.

`~window~event~loop$ %~loop 用の `同じ~loop内の~window群@ を取得するときは ⇒ ~RET 次を満たす すべての`~window$ ⇒ `関連な~agent$の`~event~loop$aG ~EQ %~loop ◎ To get the same-loop windows for a window event loop loop, return all Window objects whose relevant agent's event loop is loop.

8.1.7.2. ~taskの~queue法

`~taskを~queueする@ ときは、 所与の ( %~task~source, %手続き, %~event~loop, %文書 ) に対し…:

  • %~task~source は`~task~source$である
  • %手続き は何かを遂行する一連の段からなる
  • %~event~loop は`~event~loop$であり、 省略時は`暗黙な~event~loop$とする
  • %文書 は`文書$または ~NULL であり、 省略時は`暗黙な文書$とする
◎ To queue a task on a task source source, which performs a series of steps steps, optionally given an event loop event loop and a document document: • If event loop was not given, set event loop to the implied event loop. • If document was not given, set document to the implied document.
  1. %~queue ~LET %~event~loop に属する`~task~queue$のうち, %~task~source に結付けられたもの ◎ ↓
  2. %~task ~LET 新たな`~task$ — その ⇒# `手続き$tK ~SET %手続き, `~source$tK ~SET %~task~source, `文書$tK ~SET %文書, `~script評価 環境~設定群~obj集合$tK ~SET 新たな`有順序~集合$, ◎ Let task be a new task. • Set task's steps to steps. • Set task's source to source. • Set task's document to the document. • Set task's script evaluation environment settings object set to an empty set. ◎ Let queue be the task queue to which source is associated on event loop.
  3. %~queue に %~task を`付加する$ ◎ Append task to queue.
  4. ~RET %~task

    【 原文は何も返していないが、 ときには,この~algoを利用している文脈から~queueした~taskを~~参照する必要もあり、 (その表記上の都合により)この訳では %~task を返すことにしている。 以下の[ “`大域~taskを~queueする$” / “`要素~taskを~queueする$” ]も同様。 】

`~taskを~queueする$ときに[ ~event~loop, 文書 ]を渡し損なうことは、 多義的で拙く指定された[ `暗黙な~event~loop$, `暗黙な文書$ ]の概念に依拠することを意味する。 仕様~策定者は、 これらの値を常に渡すか,この~algoを包装する[ `大域~taskを~queueする$/`要素~taskを~queueする$ ]~algo(こちらの方が推奨される)を利用すること。 ◎ Failing to pass an event loop and document to queue a task means relying on the ambiguous and poorly-specified implied event loop and implied document concepts. Specification authors should either always pass these values, or use the wrapper algorithms queue a global task or queue an element task instead. Using the wrapper algorithms is recommended.

`大域~taskを~queueする@ ときは、 所与の ( `~task~source$ %~task~source, `大域~obj$ %大域~obj, 何かを遂行する一連の段 %手続き ) に対し: ◎ To queue a global task on a task source source, with a global object global and a series of steps steps:

  1. %~event~loop ~LET %大域~obj に`関連な~agent$ の`~event~loop$aG ◎ Let event loop be global's relevant agent's event loop.
  2. %文書 ~LET [ %大域~obj は`~window$であるならば それに`結付けられた文書$ / ~ELSE_ ~NULL ] ◎ Let document be global's associated Document, if global is a Window object; otherwise null.
  3. ~RET `~taskを~queueする$( %~task~source, %~event~loop, %文書, %手続き ) ◎ Queue a task given source, event loop, document, and steps.

`要素~taskを~queueする@ ときは、 所与の ( `~task~source$ %~task~source, 要素 %要素, 何かを遂行する一連の段 %手続き ) に対し: ◎ To queue an element task on a task source source, with an element element and a series of steps steps:

  1. %大域~obj ~LET %要素 に`関連な大域~obj$ ◎ Let global be element's relevant global object.
  2. ~RET `大域~taskを~queueする$( %~task~source, %大域~obj, %手続き ) ◎ Queue a global task given source, global, and steps.

`小taskを~queueする@ ときは、 所与の ( 何かを遂行する一連の段からなる %手続き, `文書$ %文書 (省略時は ε ) ) に対し…: ◎ To queue a microtask which performs a series of steps steps, optionally given a document document:

  1. ~Assert: `~surrounding~agent$は在る — すなわち、 この~algoは,`並列的$な手続きから~callされてはいない。 ◎ Assert: there is a surrounding agent. I.e., this algorithm is not called while in parallel.
  2. %~event~loop ~LET `~surrounding~agent$の`~event~loop$aG ◎ Let eventLoop be the surrounding agent's event loop.
  3. ~IF[ %文書 ~EQ ε ] ⇒ %文書 ~SET `暗黙な文書$ ◎ If document was not given, set document to the implied document.
  4. %小task ~LET 新たな`~task$ — その ⇒# `手続き$tK ~SET %手続き, `~source$tK ~SET `小task~task~source@, `文書$tK ~SET %文書, `~script評価 環境~設定群~obj集合$tK ~SET 新たな`有順序~集合$ ◎ Let microtask be a new task. • Set microtask's steps to steps. • Set microtask's source to the microtask task source. • Set microtask's document to document. • Set microtask's script evaluation environment settings object set to an empty set.
  5. %~event~loop の`小task~queue$に %小task を`~enqueueする$ ◎ Enqueue microtask on eventLoop's microtask queue.

注記: `小task$は、 定例の`~task~queue$に移動されることもある — その初期~実行の間に,それが`~event~loopを回す$場合には。 当の小taskの[ `~source$tK, `文書$tK, `~script評価 環境~設定群~obj集合$tK ]が諮られるのは、 これが唯一の事例である — これらは、 `小task~checkpointを遂行する$~algoからは無視される。 ◎ It is possible for a microtask to be moved to a regular task queue, if, during its initial execution, it spins the event loop. This is the only case in which the source, document, and script evaluation environment settings object set of the microtask are consulted; they are ignored by the perform a microtask checkpoint algorithm.

`~taskを~queueする$ときの `暗黙な~event~loop@ は、 ~callしている~algoの文脈から演繹できる それである。 これは、 一般に一義的になる — ほとんどの仕様の~algoは、 単独の`~agent$(したがって単独の`~event~loop$)しか孕まないので。 例外は、 ~agent間をまたがる通信を[ 指定する/孕む ]~algoである (例:~windowと~workerの間) — そのような事例では、 各~仕様は、 `~taskを~queueする$ときには — `暗黙な~event~loop$の概念に依拠することなく — 明示的に`~event~loop$を供さなければナラナイ。 ◎ The implied event loop when queuing a task is the one that can deduced from the context of the calling algorithm. This is generally unambiguous, as most specification algorithms only ever involve a single agent (and thus a single event loop). The exception is algorithms involving or specifying cross-agent communication (e.g., between a window and a worker); for those cases, the implied event loop concept must not be relied upon and specifications must explicitly provide an event loop when queuing a task.

`~event~loop$ %~event~loop に~task %~task を~queueするときの `暗黙な文書@ は、 次に従って決定される: ◎ The implied document when queuing a task on an event loop event loop is determined as follows:

  1. ~IF[ %~event~loop は`~window~event~loop$でない ] ⇒ ~RET ~NULL ◎ If event loop is not a window event loop, then return null.
  2. ~IF[ %~task はある要素の文脈にて~queueされている ] ⇒ ~RET 要素の`~node文書$ ◎ If the task is being queued in the context of an element, then return the element's node document.
  3. ~IF[ %~task はある`閲覧~文脈$の文脈にて~queueされている ] ⇒ ~RET その`閲覧~文脈$にて`作動中な文書$ ◎ If the task is being queued in the context of a browsing context, then return the browsing context's active document.
  4. ~IF[ %~task は`~script$[ により/用に ]~queueされている ] ⇒ ~RET その~scriptの`設定群~obj$sCの`大域~obj$enVに`結付けられた文書$ ◎ If the task is being queued by or for a script, then return the script's settings object's global object's associated Document.
  5. ~Assert: この段に達することは決してない — ここまでの条件いずれかが満たされるので。 本当か? ◎ Assert: this step is never reached, because one of the previous conditions is true. Really?

[ `暗黙な~event~loop$/`暗黙な文書$ ]は、 漠然と定義されていたため,たくさんの `action-at-a-distance^en がある 【遠くの動作が挙動に影響する —“バタフライ~~効果” の様に:`参考@https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)$】 。 これらは — とりわけ`暗黙な文書$は — 除去することが希望される。 `課題 #4980@~HTMLissue/4980$ を見よ。 ◎ Both implied event loop and implied document are vaguely-defined and have a lot of action-at-a-distance. The hope is to remove these, especially implied document. See issue #4980.

8.1.7.3. 処理~model

`~event~loop$ %~event~loop は、 存在する限り,次の手続きを断続的に(反復的に)走らせ続けるモノトスル: ◎ An event loop must continually run through the following steps for as long as it exists:

  1. %~task ~LET ~NULL ◎ Let oldestTask and\
  2. %~task開始~時刻 ~LET ~NULL ◎ taskStartTime be null.
  3. %~task~queue群 ~LET [ %~event~loop に属する`~task~queue$のうち,`可走な~task$を包含するもの ]たちが成す集合 ◎ ↓
  4. ~IF[ %~task~queue群 は空でない ]: ◎ If the event loop has a task queue with at least one runnable task, then:

    1. %~task~queue ~LET %~task~queue群 を成す`~task~queue$のうち,`実装定義$な方式で選ばれるいずれか ◎ Let taskQueue be one such task queue, chosen in an implementation-defined manner.

      注記: `小task~queue$は`~task~queue$ではないので、 この段で選ばれることはない。 しかしながら、 `小task~task~source$が結付けられた`~task~queue$が,この段で選ばれることはある。 その事例では,下の段で選ばれる`~task$( %~task )は、 元々は`小task$であったが,`~event~loopを回す$一部として移動されたものになる。 ◎ Remember that the microtask queue is not a task queue, so it will not be chosen in this step. However, a task queue to which the microtask task source is associated might be chosen in this step. In that case, the task chosen in the next step was originally a microtask, but it got moved as part of spinning the event loop.

    2. %~task開始~時刻 ~SET `安全でない共有される現在の時刻$ ◎ Set taskStartTime to the unsafe shared current time.
    3. %~task ~SET %~task~queue を成す`可走な~task$のうち最初のもの ◎ Set oldestTask to the first runnable task in taskQueue,\
    4. %~task~queue から %~task を`除去する$ ◎ and remove it from taskQueue.
    5. ~IF[ %~task の`文書$tK ~NEQ ~NULL ] ⇒ `~task開始~時刻を記録する$( %~task開始~時刻, %~task の`文書$tK ) ◎ If oldestTask's document is not null, then record task start time given taskStartTime and oldestTask's document.
    6. %~event~loop の`現在~走っている~task$ ~SET %~task ◎ Set the event loop's currently running task to oldestTask.
    7. %~task の`手続き$tKを走らす ◎ Perform oldestTask's steps.
    8. %~event~loop の`現在~走っている~task$ ~SET ~NULL ◎ Set the event loop's currently running task back to null.
    9. `小task~checkpointを遂行する$ ◎ Perform a microtask checkpoint.
  5. %~task終了~時刻 ~LET `安全でない共有される現在の時刻$ `HRT$r ◎ Let taskEndTime be the unsafe shared current time. [HRT]
  6. ~IF[ %~task ~NEQ ~NULL ]: ◎ If oldestTask is not null, then:

    1. %~top-level閲覧~文脈~群 ~LET 新たな`有順序~集合$ ◎ Let top-level browsing contexts be an empty set.
    2. %~task の`~script評価 環境~設定群~obj集合$tKを成す ~EACH( `環境~設定群~obj$ %設定群 ) に対し: ◎ For each environment settings object settings of oldestTask's script evaluation environment settings object set:

      1. %大域~obj ~LET %設定群 の`大域~obj$enV ◎ Let global be settings's global object.
      2. ~IF[ %大域~obj は `Window$I ~objでない ] ⇒ ~CONTINUE ◎ If global is not a Window object, then continue.
      3. %閲覧~文脈 ~LET %大域~obj に`対応する閲覧~文脈$ ◎ ↓
      4. ~IF[ %閲覧~文脈 ~EQ ~NULL ] ⇒ ~CONTINUE ◎ If global's browsing context is null, then continue.
      5. %~top-level閲覧~文脈 ~LET %閲覧~文脈 の`~top-level閲覧~文脈$bc ◎ Let tlbc be global's browsing context's top-level browsing context.
      6. ~IF[ %~top-level閲覧~文脈 ~NEQ ~NULL ] ⇒ %~top-level閲覧~文脈~群 に %~top-level閲覧~文脈 を`付加する$set ◎ If tlbc is not null, then append it to top-level browsing contexts.
    3. `長い~taskを報告する$( ↓ ) ⇒# %~task開始~時刻, %~task終了~時刻, %~top-level閲覧~文脈~群, %~task ◎ Report long tasks, passing in taskStartTime, taskEndTime, top-level browsing contexts, and oldestTask.
    4. ~IF[ %~task の`文書$tK ~NEQ ~NULL ] ⇒ `~task終了~時刻を記録する$( %~task終了~時刻, %~task の`文書$tK ) ◎ If oldestTask's document is not null, then record task end time given taskEndTime and oldestTask's document.
  7. ~IF[ %~event~loop は`~window~event~loop$である ]~AND[ %~event~loop の`~task~queue$内に`可走な~task$は無い ]: ◎ If this is a window event loop that has no runnable task in this event loop's task queues, then:

    1. %~event~loop の`最後の遊休期間~開始-時刻$ ~SET `安全でない共有される現在の時刻$ ◎ Set this event loop's last idle period start time to the unsafe shared current time.
    2. %刻限を算出する手続き ~LET 次を走らす手続き: ◎ Let computeDeadline be the following steps:

      1. %刻限 ~LET %~event~loop の`最後の遊休期間~開始-時刻$ ~PLUS 50 ◎ Let deadline be this event loop's last idle period start time plus 50.

        注記: 50ms 後の未来までにしているのは、 新たな利用者~入力に対し,ヒトから知覚される閾値~内に~~収まる応答性を確保するためである。 ◎ The cap of 50ms in the future is to ensure responsiveness to new user input within the threshold of human perception.

      2. %処理待ち描画-はあるか ~LET ~F ◎ Let hasPendingRenders be false.
      3. %~window群 ~LET %~event~loop 用の`同じ~loop内の~window群$() ◎ ↓
      4. %~window群 を成す ~EACH( %~window ) に対し: ◎ For each windowInSameLoop of the same-loop windows for this event loop:

        1. ~IF[ %~window の`~animation~frame~callback~map$は`空$mapでない ]~OR[ ~UAは[ %~window には、 処理待ち描画~更新があり得る ]と予見する ] ⇒ %処理待ち描画-はあるか ~SET ~T ◎ If windowInSameLoop's map of animation frame callbacks is not empty, or if the user agent believes that the windowInSameLoop might have pending rendering updates, set hasPendingRenders to true.
        2. %~timer~callback見積もり群 ~LET %~window の`作動中な~timer群が成す~map$の`値~群$map ◎ Let timerCallbackEstimates be the result of getting the values of windowInSameLoop's map of active timers.
        3. %~timer~callback見積もり群 を成す ~EACH( %~timeout刻限 ) に対し ⇒ ~IF[ %~timeout刻限 ~LT %刻限 ] ⇒ %刻限 ~SET %~timeout刻限 ◎ For each timeoutDeadline of timerCallbackEstimates, if timeoutDeadline is less than deadline, set deadline to timeoutDeadline.
      5. ~IF[ %処理待ち描画-はあるか ~EQ ~T ]: ◎ If hasPendingRenders is true, then:

        1. %次回の描画-刻限 ~LET %~event~loop の`最後の描画-機会~時刻$ ~PLUS ( 1000 ~DIV 現在の更新率 ) ◎ Let nextRenderDeadline be this event loop's last render opportunity time plus (1000 divided by the current refresh rate).

          注記: 更新率は、 ~hardwareや実装に特有になり得る。 更新率が 60Hz なら、 %次回の描画-刻限 は `最後の描画-機会~時刻$より約 16.67ms 後になろう。 ◎ The refresh rate can be hardware- or implementation-specific. For a refresh rate of 60Hz, the nextRenderDeadline would be about 16.67ms after the last render opportunity time.

        2. ~IF[ %次回の描画-刻限 ~LT %刻限 ] ⇒ ~RET %次回の描画-刻限 ◎ If nextRenderDeadline is less than deadline, then return nextRenderDeadline.
      6. ~RET %刻限 ◎ Return deadline.
    3. %~window群 ~LET %~event~loop 用の`同じ~loop内の~window群$() ◎ ↓
    4. %~window群 を成す ~EACH( %~window ) に対し:

      1. %手続き ~LET 次を走らす手続き:

        1. %刻限 ~LET %刻限を算出する手続き()
        2. %隔離されるか ~LET %~window に`関連な設定群~obj$の`非同一-生成元~能力は隔離されるか?$enV
        3. ~RET `時刻を粗化する$( %刻限, %隔離されるか )
      2. `遊休期間を開始する$( %~window, %手続き ) `REQUESTIDLECALLBACK$r
      ◎ For each win of the same-loop windows for this event loop, perform the start an idle period algorithm for win with the following step: return the result of calling computeDeadline, coarsened given win's relevant settings object's cross-origin isolated capability. [REQUESTIDLECALLBACK]
  8. ~IF[ %~event~loop は`~worker~event~loop$である ]: ◎ If this is a worker event loop, then:

    1. %~worker ~LET [ %~event~loop の`~agent$を成す単独の`~realm$ ]の`大域~obj$rM ◎ ↓
    2. ~Assert: %~worker は `WorkerGlobalScope$I ~objである。 【この段は、この訳による補完。】
    3. ~IF[ %~worker は `DedicatedWorkerGlobalScope$I である ]~AND[ %~worker は`~supportされている@~HTMLGAPI#concept-animationframeprovider-supported$ ]~AND[ ~UAは、 この時点で描画を更新することに益があるものと予見している ]: ◎ If this event loop's agent's single realm's global object is a supported DedicatedWorkerGlobalScope and the user agent believes that it would benefit from having its rendering updated at this time, then:

      1. %now ~LET `現在の高分解能~時刻$( %~worker【!the DedicatedWorkerGlobalScope】 ) `HRT$r ◎ Let now be the current high resolution time given the DedicatedWorkerGlobalScope. [HRT]
      2. %~worker 用に `各~animation~frame~callbackを走らす$( %now ) ◎ Run the animation frame callbacks for that DedicatedWorkerGlobalScope, passing in now as the timestamp.
      3. %~worker の描画を[ 現在の状態を反映する ]よう更新する ◎ Update the rendering of that dedicated worker to reflect the current state.

      注記: `~window~event~loop$における`描画を更新する$ときの注記と同様に、 ~UAは,専用~workerにおける描画の更新率を決定できる。 ◎ Similar to the notes for updating the rendering in a window event loop, a user agent can determine the rate of rendering in the dedicated worker.

    4. ~IF[ %~event~loop 内のどの`~task~queue$も空である ]~AND[ %~worker【!the WorkerGlobalScope object】 の`~close中か$wG ~EQ ~T ]:

      1. この手続きは中止した上で, %~event~loop を破壊する
      2. `§ ~Web~worker@~WORKERS#workers$ に述べられる`~workerを走らす$手続きを再開する
      ◎ If there are no tasks in the event loop's task queues and the WorkerGlobalScope object's closing flag is true, then destroy the event loop, aborting these steps, resuming the run a worker steps described in the Web workers section below.

`~window~event~loop$ %~event~loop は、 存在する限り,次も`並列的$に走らすモノトスル: ◎ A window event loop eventLoop must also run the following in parallel, as long as it exists:

  1. 次を満たす`~navigable$のうち 1 つ以上が,`描画~機会$を有し得るようになるまで待機する ⇒ それにて`作動中な文書$navに`関連な~agent$の`~event~loop$aG ~EQ %~event~loop ◎ Wait until at least one navigable whose active document's relevant agent's event loop is eventLoop might have a rendering opportunity.
  2. %~event~loop の`最後の描画-機会~時刻$ ~SET `安全でない共有される現在の時刻$ ◎ Set eventLoop's last render opportunity time to the unsafe shared current time.
  3. ~EACH( `描画~機会$を有する`~navigable$ %~navigable ) に対し ⇒ `大域~taskを~queueする$( `描画~task~source$, %~navigable にて`作動中な~window$nav, `描画を更新する$ ) ◎ For each navigable that has a rendering opportunity, queue a global task on the rendering task source given navigable's active window to update the rendering:

    注記: これは、 `描画を更新する$手続きを冗長に~callするかもしれないが、 そのような~callによる効果は,観測-可能にならない — `不必要な描画^i 段により、 必要yな描画は無いので。 実装は、 更なる最適化を導入できる — この~taskを~task~queue内に無いときに限り~queueするなど。 しかしながら、 この~taskの`文書$tKは,~taskが処理される前に作動中でなくなることもあることに注意。 ◎ This might cause redundant calls to update the rendering. However, these calls would have no observable effect because there will be no rendering necessary, as per the Unnecessary rendering step. Implementations can introduce further optimizations such as only queuing this task when it is not already queued. However, note that the document associated with the task might become inactive before the task is processed.

    `描画を更新する@ 手続きは:

    1. %~frame時刻印 ~LET %~event~loop の`最後の描画-機会~時刻$ ◎ Let frameTimestamp be eventLoop's last render opportunity time.
    2. %文書~群 ~LET `全部的に作動中$な`文書$のうち[ それに`関連な~agent$の`~event~loop$aG ~EQ %~event~loop ]を満たすものたちが成す~list — ~list内の どの 2 つの`文書$ %A, %B に対しても, それらの順序は、 %B の`容器~文書$docを %B1 とするとき, 次に挙げる条件を満たすモノトスル(条件~以外は任意): ◎ Let docs be all fully active Document objects whose relevant agent's event loop is eventLoop, sorted arbitrarily except that the following conditions must be met:

      • [ %A ~EQ %B1 ]ならば、 %B は %A より後になる。 ◎ Any Document B whose container document is A must be listed after A in the list.
      • [ %A の`容器~文書$doc ~EQ %B1 ]ならば、 %A, %B の順序は,[ %B1 の`~node~tree$における`~shadowも含めた~tree順序$ ]による[ %A の`~navigable容器$, %B の`~navigable容器$ ]の順序に合致する。 ◎ If there are two documents A and B that both have the same non-null container document C, then the order of A and B in the list must match the shadow-including tree order of their respective navigable containers in C's node tree.

      以下において %文書~群 を成す ~EACH( %文書 ) にわたって反復する各~段においては、 この順序で処理するモノトスル。 ◎ In the steps below that iterate over docs, each Document must be processed in the order it is found in the list.

    3. `描画-可能でない文書を~filterする^i ⇒ %文書~群 から ~OR↓ を満たす`文書$を除去する ◎ Filter non-renderable documents: Remove from docs any Document object doc for which any of the following are true:

      • その`具現化は阻まれて$いる ◎ doc is render-blocked;
      • その`可視性~状態$doc ~EQ `hidden^l ◎ doc's visibility state is "hidden";
      • その描画は`~view遷移~用の具現化は抑止されて@~CSSVT#document-rendering-suppression-for-view-transitions$いる ◎ doc's rendering is suppressed for view transitions; or
      • その`~node~navigable$には,現在は`描画~機会$を有さない ◎ doc's node navigable doesn't currently have a rendering opportunity.

      注記: `並列的$な手続き内で検査した描画~機会の有無は、 ここでも検査する必要がある — %文書~群 【!that share the same event loop】を成す一部の文書は、 この時点では`描画~機会$を有さないかもしれないので。 ◎ We have to check for rendering opportunities here, in addition to checking that in the in parallel steps, as some documents that share the same event loop might not have a rendering opportunity at the same time.

    4. `不必要な描画^i ⇒ %文書~群 から ~AND↓ を満たす`文書$ %文書 をすべて除去する: ◎ Unnecessary rendering: Remove from docs any Document object doc for which all of the following are true:

      • ~UAは、 %文書 の`~node~navigable$の描画を更新しても,可視な効果はないものと予見している ◎ the user agent believes that updating the rendering of doc's node navigable would have no visible effect; and
      • %文書 の`~animation~frame~callback~map$は空である ◎ doc's map of animation frame callbacks is empty.
    5. %文書~群 から次に該当する`文書$をすべて除去する ⇒ ~UAは、 その他の理由により,文書の描画を更新するのは飛ばした方が好ましいと予見している ◎ Remove from docs all Document objects for which the user agent believes that it's preferable to skip updating the rendering for other reasons.

      `描画-可能でない文書を~filterする^i 段は、 新たな内容を利用者に呈示-不能なときに,~UAが描画を更新するのを防止する。 ◎ The step labeled Filter non-renderable documents prevents the user agent from updating the rendering when it is unable to present new content to the user.

      `不必要な描画^i 段は、 新たに描く内容が無いときに,~UAが描画を更新するのを防止する。 ◎ The step labeled Unnecessary rendering prevents the user agent from updating the rendering when there's no new content to draw.

      この段は、~UAが[ 他の理由でも,以下の手続きを走らすのを防止する ]ことを可能化する — 例えば、 ある種の`~task$たちを[ ~~間断なく順に実行して、 間に差挟まれるのは,`小task~checkpointを遂行する$ことに限る ]ことを確保するなど (例えば,`各~animation~frame~callbackを走らす$ことなく)。 具体的には、 ~UAは,例えば[ 複数の~timer~callbackを,描画~更新を挟まずに合体したい ]と望むかもしれない。 ◎ This step enables the user agent to prevent the steps below from running for other reasons, for example, to ensure certain tasks are executed immediately after each other, with only microtask checkpoints interleaved (and without, e.g., animation frame callbacks interleaved). Concretely, a user agent might wish to coalesce timer callbacks together, with no intermediate rendering updates.

    6. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `文書を露呈する$( %文書 ) ◎ For each doc of docs, reveal doc.
    7. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ ~IF[ %文書 の`~node~navigable$は`~top-level辿可能$である ] ⇒ `自動focus候補~群を洗出す$( %文書 ) ◎ For each doc of docs, flush autofocus candidates for doc if its node navigable is a top-level traversable.
    8. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `文書の~resize手続き$( %文書 ) `CSSOMVIEW$r ◎ For each doc of docs, run the resize steps for doc. [CSSOMVIEW]
    9. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `文書の~scroll手続き$( %文書 ) `CSSOMVIEW$r ◎ For each doc of docs, run the scroll steps for doc. [CSSOMVIEW]
    10. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `文書~用の媒体~queryを評価して変化を報告する$( %文書 ) `CSSOMVIEW$r ◎ For each doc of docs, evaluate media queries and report changes for doc. [CSSOMVIEW]
    11. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `~animationを更新して~eventを送信する$( %文書, `相対的な高分解能~時刻$( %~frame時刻印, %文書 に`関連な大域~obj$ ) ) `WEBANIMATIONS$r ◎ For each doc of docs, update animations and send events for doc, passing in relative high resolution time given frameTimestamp and doc's relevant global object as the timestamp [WEBANIMATIONS]
    12. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `全screen化~手続き$( %文書 ) `FULLSCREEN$r ◎ For each doc of docs, run the fullscreen steps for doc. [FULLSCREEN]
    13. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ ~IF[ ~UAは,ある[ `CanvasRenderingContext2D$I / `OffscreenCanvasRenderingContext2D$I ]文脈に結付けられた裏~storageを喪失したことを検出した ] ⇒ そのような ~EACH( 文脈 %文脈 ) に対し ⇒ `文脈~喪失d時の手続き$を走らす ◎ For each doc of docs, if the user agent detects that the backing storage associated with a CanvasRenderingContext2D or an OffscreenCanvasRenderingContext2D, context, has been lost, then it must run the context lost steps for each such context:

      `文脈~喪失d時の手続き@ は: ◎ ↑

      1. %~canvas ~LET %文脈 に応じて ⇒# `CanvasRenderingContext2D$I であるならば %文脈 の `canvas$m 属性の値 / `OffscreenCanvasRenderingContext2D$I であるならば %文脈 の`~OffscreenCanvas~obj$o2D ◎ Let canvas be the value of context's canvas attribute, if context is a CanvasRenderingContext2D, or the associated OffscreenCanvas object for context otherwise.
      2. %文脈 の`文脈~喪失dか$ ~SET ~T ◎ Set context's context lost to true.
      3. `描画~文脈を既定の状態に設定し直す$( %文脈 ) ◎ Reset the rendering context to its default state given context.
      4. %復旧するべきか ~LET `~eventを発火する$( %~canvas, `contextlost$et ) — 次のように初期化して ⇒ `cancelable$m 属性 ~SET ~T ◎ Let shouldRestore be the result of firing an event named contextlost at canvas, with the cancelable attribute initialized to true.
      5. ~IF[ %復旧するべきか ~EQ ~F ] ⇒ ~RET ◎ If shouldRestore is false, then abort these steps.
      6. %文脈 を復旧するよう試みる — %文脈 の属性~群を利用して裏~storageを作成して, %文脈 にそれを結付けることにより ◎ Attempt to restore context by creating a backing storage using context's attributes and associating them with context.\
      7. ~IF[ 前~段に失敗した ] ⇒ ~RET ◎ If this fails, then abort these steps.
      8. %文脈 の`文脈~喪失dか$ ~SET ~F ◎ Set context's context lost to false.
      9. `~eventを発火する$( %~canvas, `contextrestored$et ) ◎ Fire an event named contextrestored at canvas.
    14. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `各~animation~frame~callbackを走らす$( %文書, `相対的な高分解能~時刻$( %~frame時刻印, %文書 に`関連な大域~obj$ ) ) ◎ For each doc of docs, run the animation frame callbacks for doc, passing in the relative high resolution time given frameTimestamp and doc's relevant global object as the timestamp.
    15. %~styleと~layoutの安全でない開始~時刻 ~LET `安全でない共有される現在の時刻$ ◎ Let unsafeStyleAndLayoutStartTime be the unsafe shared current time.
    16. %文書~群 を成す ~EACH( %文書 ) に対し: ◎ For each doc of docs:

      1. %~resize観測器の深さ ~LET 0 ◎ Let resizeObserverDepth be 0.
      2. ~WHILE 無条件 ◎ While true:

        1. %文書 の~styleを計算し直して,その~layoutを更新する ◎ Recalculate styles and update layout for doc.
        2. %内容~可視性に関する初期~決定を経たか ~LET ~F ◎ Let hadInitialVisibleContentVisibilityDetermination be false.
        3. 【%文書 内の】[ `content-visibility$p の使用~値 ~EQ `auto^v ]を満たす ~EACH( 要素 %要素 ) に対し: ◎ For each element element with 'auto' used value of 'content-visibility':

          1. %初期~決定~用に検査するか ~LET ~IS[ %要素 の`表示域への近接度$ ~EQ `未決定$i ]~AND[ ~NOT %要素 は`利用者に関連する$ ] ◎ Let checkForInitialDetermination be true if element's proximity to the viewport is not determined and it is not relevant to the user. Otherwise, let checkForInitialDetermination be false.
          2. %要素 の`表示域への近接度を決定する$ ◎ Determine proximity to the viewport for element.
          3. ~IF[ %初期~決定~用に検査するか ~EQ ~T ]~AND[ %要素 は`利用者に関連する$ ] ⇒ %内容~可視性に関する初期~決定を経たか ~SET ~T ◎ If checkForInitialDetermination is true and element is now relevant to the user, then set hadInitialVisibleContentVisibilityDetermination to true.
        4. ~IF[ %内容~可視性に関する初期~決定を経たか ~EQ ~T ] ⇒ ~CONTINUE ◎ If hadInitialVisibleContentVisibilityDetermination is true, then continue.

          注記: この段の意図は、[ 表示域への近接度に対する初期~決定 ]が即時に効果を発揮するよう,この~loopを成す始めの段で遂げられた[ ~styleと~layoutの計算 ]に反映させることにある。 近接度に対する初期~以外の決定は、 次回の`描画~機会$にて効果を発揮する。 `CSSCONTAIN$r ◎ The intent of this step is for the initial viewport proximity determination, which takes effect immediately, to be reflected in the style and layout calculation which is carried out in a previous step of this loop. Proximity determinations other than the initial one take effect at the next rendering opportunity. [CSSCONTAIN]

        5. `ある深さ以上で作動中な~resize観測nを集める$( %文書, %~resize観測器の深さ ) ◎ Gather active resize observations at depth resizeObserverDepth for doc.
        6. ~IF[ `作動中な~resize観測nはあるか?$( %文書 ) ~EQ ~T ]: ◎ If doc has active resize observations:

          1. %~resize観測器の深さ ~SET `作動中な~resize観測nを~broadcastする$( %文書 ) ◎ Set resizeObserverDepth to the result of broadcasting active resize observations given doc.
          2. ~CONTINUE ◎ Continue.
        7. ~ELSE ⇒ ~BREAK ◎ Otherwise, break.
      3. ~IF[ `飛ばした~resize観測nはあるか?$( %文書 ) ~EQ ~T ] ⇒ `~resize~loop~errorを送達する$( %文書 ) ◎ If doc has skipped resize observations, then deliver resize loop error given doc.
    17. %文書~群 を成す ~EACH( %文書 ) に対し:

      1. ~IF[ %文書 が`指名する被focus区画$docは`~focus可能な区画$である ] ⇒ ~CONTINUE
      2. `~objを~focusする$( %文書 の`表示域$ )
      3. %文書 に`関連な大域~obj$の`~navi~API$の`進行中な~naviの間に~focusは変化したか$ ~SET ~F
      ◎ For each doc of docs, if the focused area of doc is not a focusable area, then run the focusing steps for doc's viewport, and set doc's relevant global object's navigation API's focus changed during ongoing navigation to false.

      これは,例えば、 要素に `hidden$a 属性が追加され,`具現化されなく@~HTMLrendering#being-rendered$なったときに起こり得る。 また、 `input$e 要素においては,それが`不能化され@~HTMLforms#concept-fe-disabled$たときにも起こり得る。 ◎ For example, this might happen because an element has the hidden attribute added, causing it to stop being rendered. It might also happen to an input element when the element gets disabled.

      注記: これは、 `通例的@~HTMLinteraction#note-sometimes-no-blur-event$には `blur$et ~eventを発火することになり, 場合によっては `change$et ~eventも発火することになる。 ◎ This will usually fire blur events, and possibly change events.

      注記: `指名する被focus区画$docが %文書 から除去された場合、 この非同期的な~focusの修復に加えて, `同期的な修復@~HTMLINFRA#node-remove-focus-fixup$もある。 そこでは、[ `blur$et / `change$et ]~eventは`発火されない^em。 ◎ In addition to this asynchronous fixup, if the focused area of the document is removed, there is a synchronous fixup. That one will not fire blur or change events.

    18. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `処理待ち遷移~演算を遂行する@~CSSVT#perform-pending-transition-operations$( %文書 ) `CSSVIEWTRANSITIONS$r ◎ For each doc of docs, perform pending transition operations for doc. [CSSVIEWTRANSITIONS]
    19. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `交差~観測nを更新する$( %文書, `相対的な高分解能~時刻$( %~frame時刻印【!%now】, %文書 に`関連な大域~obj$ ) ) `INTERSECTIONOBSERVER$r ◎ For each doc of docs, run the update intersection observations steps for doc, passing in the relative high resolution time given now and doc's relevant global object as the timestamp. [INTERSECTIONOBSERVER]
    20. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `描画~時刻を記録する$( %文書, %~styleと~layoutの安全でない開始~時刻 ) ◎ For each doc of docs, record rendering time for doc given unsafeStyleAndLayoutStartTime.
    21. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `塗り計時を刻む$( %文書 ) `PAINTTIMING$r ◎ For each doc of docs, mark paint timing for doc.
    22. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ [ %文書, および その`~node~navigable$ ]の描画や~UIを,現在の状態を反映するように更新する ◎ For each doc of docs, update the rendering or user interface of doc and its node navigable to reflect the current state.
    23. %文書~群 を成す ~EACH( %文書 ) に対し ⇒ `上端~層からの除去を処理する$( %文書 ) ◎ For each doc of docs, process top layer removals given doc.

`~navigable$は、 次に該当するとき, `描画~機会@ を有するとされる ⇒ ~UAは、 現在[ ~hardware更新率による拘束 / 処理能の理由による~UAによる減速 ]を織り込む下で,利用者に当の~navigableを成す内容を【一部でも】呈示-可能である — 表示域の外側に呈示-可能な内容も考慮して。 ◎ A navigable has a rendering opportunity if the user agent is currently able to present the contents of the navigable to the user, accounting for hardware refresh rate constraints and user agent throttling for performance reasons, but considering content presentable even if it's outside the viewport.

`~navigable$の`描画~機会$は、 ~hardwareによる拘束 (~display更新率など), その他の要因 (~pageの処理能, ~pageにて`作動中な文書$navの`可視性~状態$doc【!is "visible"】など) に基づいて決定される。 描画~機会は、 概して,定常間隔で生じる。 ◎ A navigable's rendering opportunities are determined based on hardware constraints such as display refresh rates and other factors such as page performance or whether its active document's visibility state is "visible". Rendering opportunities typically occur at regular intervals.

注記: この仕様は、 描画~機会の選定-法として,特定0の~modelを何ら義務付けない。 例えば,~browserが更新率 60Hz を達成するよう試みている場合、 描画~機会が生じるのは,最大でも毎秒 60 回( およそ 16.7ms ごと)になる。 ~browserは、 ある`~navigable$に対し この更新率を維持-不能と見出した場合には,当の~navigable用には — ~frameを時々落とすのではなく — 描画~機会を より維持-可能な毎秒 30 回に落とすこともある。 同様に,`~navigable$は可視でない場合、 ~UAは,当の~pageの描画~機会をずっと低速な毎秒 4 回に — あるいは,それ未満にすら — 落とすものと裁定することもある。 ◎ This specification does not mandate any particular model for selecting rendering opportunities. But for example, if the browser is attempting to achieve a 60Hz refresh rate, then rendering opportunities occur at a maximum of every 60th of a second (about 16.7ms). If the browser finds that a navigable is not able to sustain this rate, it might drop to a more sustainable 30 rendering opportunities per second for that navigable, rather than occasionally dropping frames. Similarly, if a navigable is not visible, the user agent might decide to drop that page to a much slower 4 rendering opportunities per second, or even less.


`小task~checkpointを遂行する@ ときは,次を走らすモノトスル: ◎ When a user agent is to perform a microtask checkpoint:

  1. %~event~loop ~LET 当の`~event~loop$ ◎ ↓
  2. ~IF[ %~event~loop の`小task~checkpoint遂行-中か$ ~EQ ~T ] ⇒ ~RET ◎ If the event loop's performing a microtask checkpoint is true, then return.
  3. %~event~loop の`小task~checkpoint遂行-中か$ ~SET ~T ◎ Set the event loop's performing a microtask checkpoint to true.
  4. ~WHILE[ %~event~loop の`小task~queue$は空でない ]: ◎ While the event loop's microtask queue is not empty:

    1. %小task ~LET %~event~loop の`小task~queue$から`~dequeueする$ ◎ Let oldestMicrotask be the result of dequeuing from the event loop's microtask queue.
    2. %~event~loop の`現在~走っている~task$ ~SET %小task ◎ Set the event loop's currently running task to oldestMicrotask.
    3. %小task を走らす ◎ Run oldestMicrotask.

      注記: これは、 ~scriptによる~callbackの呼出ngを孕むかもしれず, 最終的に `走らせた~scriptを片付ける$手続きを~callする結果、 この~algoが再度~callされることになる。 `小task~checkpoint遂行-中か$を利用しているのは、 その再入性を避けるためである。 ◎ This might involve invoking scripted callbacks, which eventually calls the clean up after running script steps, which call this perform a microtask checkpoint algorithm again, which is why we use the performing a microtask checkpoint flag to avoid reentrancy.

    4. %~event~loop の`現在~走っている~task$ ~SET ~NULL ◎ Set the event loop's currently running task back to null.
  5. ~EACH( `環境~設定群~obj$ %設定群~obj ) に対し ⇒ ~IF[ %設定群~obj の`担当の~event~loop$enV ~EQ %~event~loop ] ⇒ `却下-済み~promiseについて通知する$( %設定群~obj の`大域~obj$enV ) ◎ For each environment settings object settingsObject whose responsible event loop is this event loop, notify about rejected promises given settingsObject's global object.
  6. `Indexed Database ~transactionを片付ける@~INDEXEDDB#cleanup-indexed-database-transactions$ ◎ Cleanup Indexed Database transactions.
  7. `ClearKeptObjects$jA() ◎ Perform ClearKeptObjects().

    注記: `WeakRef.prototype.deref()$m が~objを返すとき、 その~objは,次回の `ClearKeptObjects$jA() の呼出nまで生きたまま保たれ、 その後に再び~garbage収集の~subjectになる。 ◎ When WeakRef.prototype.deref() returns an object, that object is kept alive until the next invocation of ClearKeptObjects(), after which it is again subject to garbage collection.

  8. %~event~loop の`小task~checkpoint遂行-中か$ ~SET ~F ◎ Set the event loop's performing a microtask checkpoint to false.
  9. `小task~checkpoint用に計時~報を記録する$() ◎ Record timing info for microtask checkpoint.

~UAは、 `並列的$に走っている %~algo において, `安定~状態を待受ける@ ときは、 %~algo 自身の実行を いったん停止すると同時に,次を遂行するモノトスル ⇒ `小taskを~queueする$( 次の手続き ) ◎ When an algorithm running in parallel is to await a stable state, the user agent must queue a microtask that runs the following steps, and must then stop executing (execution of the algorithm resumes when the microtask is run, as described in the following steps):

手続きは: ◎ ↑

  1. %~algo 内の `同期区間@ を走らす ◎ Run the algorithm's synchronous section.
  2. %~algo の記述にしたがって,適切になるなら、 %~algo の`並列的$な実行を再開する ◎ Resumes execution of the algorithm in parallel, if appropriate, as described in the algorithm's steps.

注記: %~algo 内の`同期区間$は、 ~~記号 ⌛ が付与される段として与えられる。 【が,この訳では、その~~記号に代えて,明示的な句の下で下位~blockに~group化して与えることもある。】 ◎ Steps in synchronous sections are marked with ⌛.


~algoにて,所与の条件 %目標 が満たされるまで `~event~loopを回す@ と記される箇所は、 次の手続きが成す~algoで代用することに等価とする: ◎ Algorithm steps that say to spin the event loop until a condition goal is met are equivalent to substituting in the following algorithm steps:

  1. %~task ~LET 当の`~event~loop$の`現在~走っている~task$ ◎ Let task be the event loop's currently running task.

    注記: %~task は`小task$の場合もある。 ◎ task could be a microtask.

  2. %~task~source ~LET %~task の`~source$tK ◎ Let task source be task's source.
  3. %旧~stack ~LET `~JS実行~文脈~stack$の複製 ◎ Let old stack be a copy of the JavaScript execution context stack.
  4. `~JS実行~文脈~stack$を空にする ◎ Empty the JavaScript execution context stack.
  5. `小task~checkpointを遂行する$ ◎ Perform a microtask checkpoint.

    注記: %~task が`小task$である場合、[ `小task~checkpoint遂行-中か$ ~EQ ~T ]に因り,この段は何もしない。 ◎ If task is a microtask this step will be a no-op due to performing a microtask checkpoint being true.

  6. この段は`並列的$に走らす: ◎ In parallel:

    1. %目標 が満たされるまで待機する ◎ Wait until the condition goal is met.
    2. `~taskを~queueする$( %~task~source, 次の手続き ) ◎ Queue a task on task source to:

      手続きは: ◎ ↑

      1. `~JS実行~文脈~stack$を %旧~stack に置換する ◎ Replace the JavaScript execution context stack with old stack.
      2. 元の~algo内の[ この`~event~loopを回す$と記された箇所の後に現れる手続き ]があれば それを遂行する ◎ Perform any steps that appear after this spin the event loop instance in the original algorithm.

        注記: これは %~task を再開する ◎ This resumes task.

  7. %~task を停止して,それを呼出した~algoを何であれ再開できるようにする ◎ Stop task, allowing whatever algorithm that invoked it to resume.

    注記: これは、 次のいずれかの~algoを継続させる ⇒# `~event~loop$の~main手続き【`~event~loop処理~model$】, `小task~checkpointを遂行する$ ◎ This causes the event loop's main set of steps or the perform a microtask checkpoint algorithm to continue.

注記: この仕様や他の仕様における他の~algoの挙動は,~programming言語の関数~callに類似するが、`~event~loopを回す$は,それと違って もっと~macroに~~近く、 ~~利用された箇所にて一連の[ 段/演算 ]に展開することにより~~字数と~~字下げを節約する。 ◎ Unlike other algorithms in this and other specifications, which behave similar to programming-language function calls, spin the event loop is more like a macro, which saves typing and indentation at the usage site by expanding into a series of steps and operations.

次の手続きが成す~algoは: ◎ An algorithm whose steps are:

  1. ~~動作 1 を行う ◎ Do something.
  2. スゴイことが起きるまで`~event~loopを回す$ ◎ Spin the event loop until awesomeness happens.
  3. ~~動作 2 を行う ◎ Do something else.

“~macro展開” の後は 次のようになる,略記である: ◎ is a shorthand which, after "macro expansion", becomes

  1. ~~動作 1 を行う ◎ Do something.
  2. %旧~stack ~LET `~JS実行~文脈~stack$の複製 ◎ Let old stack be a copy of the JavaScript execution context stack.
  3. `~JS実行~文脈~stack$を空にする ◎ Empty the JavaScript execution context stack.
  4. `小task~checkpointを遂行する$ ◎ Perform a microtask checkpoint.
  5. この段は`並列的$に走らす: ◎ In parallel:

    1. スゴイことが起きるまで待機する ◎ Wait until awesomeness happens.
    2. `~taskを~queueする$( “~~動作 1 を行う” を行わせた~task~source, 次の手続き ): ◎ Queue a task on the task source in which "do something" was done to:

      手続きは: ◎ ↑

      1. `~JS実行~文脈~stack$を %旧~stack に置換する ◎ Replace the JavaScript execution context stack with old stack.
      2. ~~動作 2 を行う ◎ Do something else.

代用を成す もっと全部的な例を与える。 ここでは、 ~event~loopは[ 並列的な作業~内から~queueされた,ある~taskの内側 ]から回される。 まず、 `~event~loopを回す$を利用する~version: ◎ Here is a more full example of the substitution, where the event loop is spun from inside a task that is queued from work in parallel. The version using spin the event loop:

  1. この段は`並列的$に走らす: ◎ In parallel:

    1. 並列的~~動作 1 を行う ◎ Do parallel thing 1.
    2. `~taskを~queueする$( `~DOM操作~task~source$, 次の手続き ) ◎ Queue a task on the DOM manipulation task source to:

      手続きは: ◎ ↑

      1. ~task~~動作 1 を行う ◎ Do task thing 1.
      2. スゴイことが起きるまで`~event~loopを回す$ ◎ Spin the event loop until awesomeness happens.
      3. ~task~~動作 2 を行う ◎ Do task thing 2.
    3. 並列的~~動作 2 を行う ◎ Do parallel thing 2.

次に、 全部的に展開された~version: ◎ The fully expanded version:

  1. この段は`並列的$に走らす: ◎ In parallel:

    1. 並列的~~動作 1 を行う ◎ Do parallel thing 1.
    2. %旧~stack ~LET ~NULL ◎ Let old stack be null.
    3. `~taskを~queueする$( `~DOM操作~task~source$, 次の手続き ) ◎ Queue a task on the DOM manipulation task source to:

      手続きは: ◎ ↑

      1. ~task~~動作 1 を行う ◎ Do task thing 1.
      2. %旧~stack ~SET `~JS実行~文脈~stack$の複製 ◎ Set old stack to a copy of the JavaScript execution context stack.
      3. `~JS実行~文脈~stack$を空にする ◎ Empty the JavaScript execution context stack.
      4. `小task~checkpointを遂行する$ ◎ Perform a microtask checkpoint.
    4. スゴイことが起きるまで待機する ◎ Wait until awesomeness happens.
    5. `~taskを~queueする$( `~DOM操作~task~source$, 次の手続き ): ◎ Queue a task on the DOM manipulation task source to:

      手続きは: ◎ ↑

      1. `~JS実行~文脈~stack$を %旧~stack に置換する ◎ Replace the JavaScript execution context stack with old stack.
      2. ~task~~動作 2 を行う ◎ Do task thing 2.
    6. 並列的~~動作 2 を行う ◎ Do parallel thing 2.

歴史的な理由から、 この仕様における一部の~algoは,~UAに対し[ ある`~task$ %~task が走っている間、 所与の %目標 が満たされるまで `静止する@ ]よう要求する。 これは、 次の手続きを走らすことを意味する: ◎ Some of the algorithms in this specification, for historical reasons, require the user agent to pause while running a task until a condition goal is met. This means running the following steps:

  1. %大域~obj ~LET `現在の大域~obj$ ◎ Let global be the current global object.
  2. %静止-前の時刻 ~LET `現在の高分解能~時刻$( %大域~obj ) ◎ Let timeBeforePause be the current high resolution time given global.
  3. 必要yなら、[ `文書$や`~navigable$ ]の[ 描画や~UI ]を[ 現在の状態を反映する ]よう更新する ◎ If necessary, update the rendering or user interface of any Document or navigable to reflect the current state.
  4. %目標 が満たされるまで待機する — %~task を`静止-$している間は、 ~UAは:

    • %~task が属している`~event~loop$は、 他の`~task$を走らせないモノトスル。
    • `現在~走っている~task$における~script実行は、 阻むモノトスル。
    • 利用者~入力に対しては、 即応可能であり続けるべきである — しかしながら、 `~event~loop$は何もしなくなるので,~~能力は抑制されることになる。
    ◎ Wait until the condition goal is met. While a user agent has a paused task, the corresponding event loop must not run further tasks, and any script in the currently running task must block. User agents should remain responsive to user input while paused, however, albeit in a reduced capacity since the event loop will not be doing anything.
  5. `静止-所要時間を記録する$( `所要時間を得る$( %静止-前の時刻, `現在の高分解能~時刻$( %大域~obj ) ) ◎ Record pause duration given the duration from timeBeforePause to the current high resolution time given global.

`静止する$ことは — とりわけ,複数の文書が単独の`~event~loop$を共有している局面では — 利用者~体験をひどく~~害する。 ~UAには、 既存の内容との互換性を保全しつつアリなら,`静止-$の代替 — `~event~loopを回す$, あるいは単純に あらゆる種類の実行を休止させずに,続行するなど — を試験することが奨励される。 もっと~~円滑で~web互換な代替が発見されたなら、 この仕様は,積極的にそれを取り入れることになる。 ◎ Pausing is highly detrimental to the user experience, especially in scenarios where a single event loop is shared among multiple documents. User agents are encouraged to experiment with alternatives to pausing, such as spinning the event loop or even simply proceeding without any kind of suspended execution at all, insofar as it is possible to do so while preserving compatibility with existing content. This specification will happily change if a less-drastic alternative is discovered to be web-compatible.

実装者は、 ~UAが試験し得る様々な代替が,`~event~loop$の挙動の微妙な側面 — `~task$や`小task$の時機も含め — を変更し得ることを,当分の間は自覚しておくべきである。 実装は、 そうすることが`静止-$する演算に含意される正確な意味論に違反するとしても,試験し続けるべきである。 ◎ In the interim, implementers should be aware that the variety of alternatives that user agents might experiment with can change subtle aspects of event loop behavior, including task and microtask timing. Implementations should continue experimenting even if doing so causes them to violate the exact semantics implied by the pause operation.

8.1.7.4. 汎用な~task~source

次に挙げる`~task~source$は、 いくつもの特能 — [ この仕様/他の仕様 ]における,互いにほぼ無関係なそれら — から利用される: ◎ The following task sources are used by a number of mostly unrelated features in this and other specifications.

`~DOM操作~task~source@ ◎ The DOM manipulation task source
この`~task~source$は、 ~DOM操作に反応する特能~用に利用される — 要素が`文書の中へ挿入された$ときに,他を阻まずに起きるものなど。 ◎ This task source is used for features that react to DOM manipulations, such as things that happen in a non-blocking fashion when an element is inserted into the document.
`利用者~対話~task~source@ ◎ The user interaction task source
この`~task~source$は、 利用者-ヤリトリに反応する特能~用に利用される — 例えば[ ~keyboard/~mouse ]入力。 ◎ This task source is used for features that react to user interaction, for example keyboard or mouse input.
利用者~入力に呼応して送信される~event (例: `click$et ~event `UIEVENTS$r ) は、 `利用者~対話~task~source$により`~queueされ$る`~task$を利用して発火するモノトスル。 ◎ Events sent in response to user input (e.g. click events) must be fired using tasks queued with the user interaction task source. [UIEVENTS]
`~network用~task~source@ ◎ The networking task source
この`~task~source$は、 ~network活動に呼応して誘発される特能~用に利用される。 ◎ This task source is used for features that trigger in response to network activity.
`~naviと辿り~task~source@ ◎ The navigation and traversal task source
この`~task~source$は、 `~navi$や`履歴の辿り@~HTMLnav#apply-the-traverse-history-step$に孕まれる~taskを~queueするために利用される。 ◎ This task source is used to queue tasks involved in navigation and history traversal.
`描画~task~source@ ◎ The rendering task source
この`~task~source$は、 もっぱら,`描画を更新する$ために利用される。 ◎ This task source is used solely to update the rendering.
8.1.7.5. 他の仕様における~event~loopの~~扱い方

`~event~loop$と正しくヤリトリするように仕様を書くことは、 込み入ったものにもなり得る。 これは、 この仕様による,同時並行性~modelに依存しない用語体系 — “~main~thread” / “~background~thread上で” の様な,その種の~modelに特有な馴染みな用語に代えて, “`~event~loop$”, “`並列的$” などの語 — の用-法により構成される。 ◎ Writing specifications that correctly interact with the event loop can be tricky. This is compounded by how this specification uses concurrency-model-independent terminology, so we say things like "event loop" and "in parallel" instead of using more familiar model-specific terms like "main thread" or "on a background thread".

既定では、 仕様~textは,一般に`~event~loop$上で走る。 これは、 正式な`~event~loop処理~model$から外へ出る — すなわち,ほとんどの~algoは、 跡を~~辿れば,最終的には そこへ`~queueされ$る`~task$に戻る。 【!*】 ◎ By default, specification text generally runs on the event loop. This falls out from the formal event loop processing model, in that you can eventually trace most algorithms back to a task queued there.

どの~JS~methodも、 その~algoを成す手続きは,作者~codeがその~methodを~callすることにより呼出される。 また、 作者~codeが走れるのは,~queueされた~taskを介してのみであり、 通例的に, `script^e 要素の`処理~model@~HEscripting#script-processing-model$内のどこかを出自にしている。 ◎ The algorithm steps for any JavaScript method will be invoked by author code calling that method. And author code can only be run via queued tasks, usually originating somewhere in the script processing model.

この出発点から上書きするときの指針は: 仕様が遂行する必要がある作業のうち[ `並列的$に遂行しなければ`~event~loop$を阻むことになる ]ものは、 何であれ そのように遂行されなければナラナイ。 これには、 少なくとも次が含まれる: ◎ From this starting point, the overriding guideline is that any work a specification needs to perform that would otherwise block the event loop must instead be performed in parallel with it. This includes (but is not limited to):

  • 重い計算を遂行するとき。 ◎ performing heavy computation;
  • 利用者に~promptを表示するとき。 ◎ displaying a user-facing prompt;
  • 外側の~systemも孕み得る(すなわち, “~UA処理nの外へ出る” )ような演算を遂行するとき。 ◎ performing operations which could require involving outside systems (i.e. "going out of process").

次に挙がる複雑化は,~algoの`並列的$な区間であり、 そこでは,特定の[ `~realm$ / `大域~obj$ / `環境~設定群~obj$ ]に結付けられた~objを作成したり, 操作してはナラナイ (馴染みな用語で言明するなら、 ~main~threadによる遺物に,~background~threadから直に~accessしないモノトスル)。 そうすると,~JS~codeから観測-可能な~data競争が生じることになる — ~algoのそれ以降の手続きは、 ~JS~codeと`並列的$に走っているので。 ◎ The next complication is that, in algorithm sections that are in parallel, you must not create or manipulate objects associated to a specific realm, global, or environment settings object. (Stated in more familiar terms, you must not directly access main-thread artifacts from a background thread.) Doing so would create data races observable to JavaScript code, since after all, your algorithm steps are running in parallel to the JavaScript code.

しかしながら,仕様~levelの~data構造 — `Infra^cite `INFRA$r にて定義されるものなど — は、 操作できる。 それらは~realmに不問なので、 ~JSに直に公開されることは決してなく,特定の変換 (~Web~IDLによる`変換-$xを介するものが多い)がそこを占めることはないので。 `WEBIDL$r ◎ You can, however, manipulate specification-level data structures and values from Infra, as those are realm-agnostic. They are never directly exposed to JavaScript without a specific conversion taking place (often via Web IDL). [INFRA] [WEBIDL]

次に,観測-可能な~JS~objの世界に影響させるためには、 次に従わなければナラナイ: ◎ To affect the world of observable JavaScript objects, then, you must\

  • そのような操作は、 `大域~taskを~queueする$ことを介して遂行すること。 これは、 当の手続きが,`~event~loop$にて起こる他の~taskの合間に適正に差挟まれることを確保する。 ◎ queue a global task to perform any such manipulations. This ensures your steps are properly interleaved with respect to other things happening on the event loop.\
  • 加えて、 `大域~taskを~queueする$ときは,`~task~source$も選ぶこと。 これは、 自他の手続きの相対的な遂行-順序を統治する。 どの`~task~source$を利用するか定かでない場合は、 `汎用な~task~source@#generic-task-sources$から,最も適用-可能と思しきものを~~選ぶこと。 ◎ Furthermore, you must choose a task source when queuing a global task; this governs the relative order of your steps versus others. If you are unsure which task source to use, pick one of the generic task sources that sounds most applicable.\
  • ~~最後に、 どの`大域~obj$が,~queueした~taskに結付けられるか指示すること。 これは、 その大域~objが作動中でない間は,当の~taskは走らないことを確保する。 ◎ Finally, you must indicate which global object your queued task is associated with; this ensures that if that global object is inactive, the task does not run.

注記: `~taskを~queueする$~algoが,その上に`大域~taskを~queueする$~algoが築かれる基底~primitiveを成す。 一般に,`大域~taskを~queueする$方が良い。 それは、 的確な`~event~loop$を — および,適切な所では`文書$tKも — 自動的に~~選ぶので。 より旧い仕様は、 `~taskを~queueする$を[ `暗黙な~event~loop$, `暗黙な文書$ ]の概念と組合せて利用することが多いが、 これは忌避される。 ◎ The base primitive, on which queue a global task builds, is the queue a task algorithm. In general, queue a global task is better because it automatically picks the right event loop and, where appropriate, document. Older specifications often use queue a task combined with the implied event loop and implied document concepts, but this is discouraged.

以上をまとめれば、 非同期に作業する必要がある~algo用の代表的な雛形は,次のようになる: ◎ Putting this all together, we can provide a template for a typical algorithm that needs to do work asynchronously:

  1. 同期的に設定しておく作業があれば、 まずそれを行う — 依然として`~event~loop$上にある間に。 これは、 `~realm$に特有な~JS値を,~realmに不問な仕様~levelの値に 変換することも含み得る。 ◎ Do any synchronous setup work, while still on the event loop. This may include converting realm-specific JavaScript values into realm-agnostic specification-level values.
  2. 高価にもなり得る[ 次を行うための一連の段 ]を`並列的$に遂行する ⇒ ~realmにまったく不問な値に演算して,~realmに不問な結果を生産する ◎ Perform a set of potentially-expensive steps in parallel, operating entirely on realm-agnostic values, and producing a realm-agnostic result.
  3. `大域~taskを~queueする$( 指定された`~task~source$, 適切な`大域~obj$, 次の手続き ) ◎ Queue a global task, on a specified task source and given an appropriate global object, to\

    手続きは ⇒ ~realmに不問な結果を変換して,`~event~loop$上の[ ~JS~objたちが成す観測-可能な世界 ]における観測-可能な効果へ戻す ◎ convert the realm-agnostic result back into observable effects on the observable world of JavaScript objects on the event loop.

渡された[ `~scalar値~文字列$たちが成す`~list$ ] %入力 を,~URLとして構文解析してから “暗号化する” ~algoの例: ◎ The following is an algorithm that "encrypts" a passed-in list of scalar value strings input, after parsing them as URLs:

  1. %~URL~list ~LET 新たな`~list$ ◎ Let urls be an empty list.
  2. %入力 を成す ~EACH( %文字列 ) に対し: ◎ For each string of input:

    1. %構文解析-済み~URL ~LET `~URLを符号化法の下で相対的に構文解析する$( %文字列, `現在の設定群~obj$ ) ◎ Let parsed be the result of encoding-parsing a URL given string, relative to the current settings object.
    2. IF[ %構文解析-済み~URL ~EQ `失敗^i ] ⇒ ~RET `却下される~promise$( `SyntaxError$E 例外 ) ◎ If parsed is failure, then return a promise rejected with a "SyntaxError" DOMException.
    3. %直列形 ~LET `~URLを直列化する$( %構文解析-済み~URL ) ◎ Let serialized be the result of applying the URL serializer to parsed.
    4. %~URL~list に %直列形 を`付加する$ ◎ Append serialized to urls.
  3. %~realm ~LET `現在の~realm$ ◎ Let realm be the current realm.
  4. %~promise ~LET 新たな~promise ◎ Let p be a new promise.
  5. この段は`並列的$に走らす: ◎ Run the following steps in parallel:

    1. %暗号形~URL~list ~LET 新たな`~list$ ◎ Let encryptedURLs be an empty list.
    2. %~URL~list を成す ~EACH( %~URL ) に対し: ◎ For each url of urls:

      1. 100 ~milli秒間~待機する — 暗号化の重い計算は、 その間に行うとする。 ◎ Wait 100 milliseconds, so that people think we're doing heavy-duty encryption.
      2. %暗号形 ~LET 前~段の間に %~URL から導出された新たな`文字列$ 【! whose nth code unit is equal to url's nth code unit plus 13】 ◎ Let encrypted be a new string derived from url, whose nth code unit is equal to url's nth code unit plus 13.
      3. %暗号形~URL~list に %暗号形 を`付加する$ ◎ Append encrypted to encryptedURLs.
    3. `大域~taskを~queueする$( `~network用~task~source$, %~realm の`大域~obj$rM , 次の手続き ) ◎ Queue a global task on the networking task source, given realm's global object, to perform the following\

      手続きは: ◎ steps:

      1. %配列 ~LET %暗号形~URL~list を %~realm 内の~JS配列に`変換-$xした結果 ◎ Let array be the result of converting encryptedURLs to a JavaScript array, in realm.
      2. %配列 で %~promise を解決する ◎ Resolve p with array.
  6. ~RET %~promise ◎ Return p.

この~algoには、 注目すべき点がいくつかある: ◎ Here are several things to notice about this algorithm:

  • 前もって,`~event~loop$上で~URLの構文解析を行っている — `並列的$な手続きに入る前に。 これが必要yなのは、 構文解析が依存している`現在の設定群~obj$は, `並列的$に行った後における`現在の設定群~obj$ではなくなるためである。 ◎ It does its URL parsing up front, on the event loop, before going to the in parallel steps. This is necessary, since parsing depends on the current settings object, which would no longer be current after going in parallel.
  • 代替として、 `現在の設定群~obj$の`~API用~基底~URL$enVへの参照を保存してから,`並列的$な手続きの間にそれを利用しても等価になる。 しかしながら,上の例が行なっているように、 前もってアリな限り多くの作業を行うことが推奨される。 正しい値を保存するよう試みるのは、 誤りを導き易くなりがちなので — 例えば、 `~API用~基底~URL$enVに代えて,単に`現在の設定群~obj$を保存した場合、 競争が生じ得ることになる。 ◎ Alternately, it could have saved a reference to the current settings object's API base URL and used it during the in parallel steps; that would have been equivalent. However, we recommend instead doing as much work as possible up front, as this example does. Attempting to save the correct values can be error prone; for example, if we'd saved just the current settings object, instead of its API base URL, there would have been a potential race.
  • `文字列$たちが成す`~list$を、 初期~手続きから`並列的$な手続きに暗黙的に渡している。 `~list$, `文字列$とも,`~realm$には不問なので、 そうしても差し支えない。 ◎ It implicitly passes a list of strings from the initial steps to the in parallel steps. This is OK, as both lists and strings are realm-agnostic.
  • “高価な計算” は、 `並列的$な手続きの間に遂行している (入力~URLごとに 100~milli秒間~待機して) — したがって~main`~event~loop$は阻んでいない。 ◎ It performs "expensive computation" (waiting for 100 milliseconds per input URL) during the in parallel steps, thus not blocking the main event loop.
  • `並列的$な手続きの間は、 決して,観測-可能な~JS~objとしての~promiseを[ 作成-/操作- ]していない。 %~promise は,その手続きに入る前に作成され、 当の目的で特定的に`~queueされ@#queue-a-global-task$た`~task$の中で操作されている。 ◎ Promises, as observable JavaScript objects, are never created and manipulated during the in parallel steps. p is created before entering those steps, and then is manipulated during a task that is queued specifically for that purpose.
  • ~JS配列~objの作成は,~queueされた~taskの中でも起こり、 当の配列を どの~realm内に作成するか指定することにも気を付けている — ~realmはもはや、 文脈からは明白でないので。 ◎ The creation of a JavaScript array object also happens during the queued task, and is careful to specify which realm it creates the array in since that is no longer obvious from context.

(最後の 2 点については、 `whatwg/webidl 課題 #135@https://github.com/whatwg/webidl/issues/135$, `whatwg/webidl 課題 #371@https://github.com/whatwg/webidl/issues/371$ も見よ — 上述した~promiseの解決~patternの細部については、 依然として思案中にある) ◎ (On these last two points, see also whatwg/webidl issue #135 and whatwg/webidl issue #371, where we are still mulling over the subtleties of the above promise-resolution pattern.)

上とは別に、 この~algoが,~Web~IDLにより指定される演算として[ ~IDL sequence<`USVString$> 型の値を入力にとるもの ]から~callされたときには、 作者から入力として供された[ `~realm$に特有な~JS~obj ]から[ ~realmに不問な sequence<`USVString$> 型 ]への自動的な変換もあることに注意。 それは、 入力を[ `~scalar値~文字列$たちが成す`~list$ ]として扱うことになる。 なので、 当の仕様の構造に依存して,[ `並列的$に走らすに準備済みにする処理nの一部を担う ]ような[ ~main`~event~loop$上で起こる暗黙的な他の手続き ]もあり得る。 ◎ Another thing to note is that, in the event this algorithm was called from a Web IDL-specified operation taking a sequence<USVString>, there was an automatic conversion from realm-specific JavaScript objects provided by the author as input, into the realm-agnostic sequence<USVString> Web IDL type, which we then treat as a list of scalar value strings. So depending on how your specification is structured, there may be other implicit steps happening on the main event loop that play a part in this whole process of getting you ready to go in parallel.

8.1.8. ~event

8.1.8.1. ~event~handler

多くの~objには、 何個かの `~event~handler@ を指定できる。 これらは、 指定された~obj用の非~capture`~event~listener$として動作する。 `DOM$r ◎ Many objects can have event handlers specified. These act as non-capture event listeners for the object on which they are specified. [DOM]

`~event~handler$は、 次に挙げる`~item$sctからなる`構造体$である: ◎ An event handler is a struct with two items:

`値@eH ◎ a value,\
~NULL / ~callback~obj /`内部的な生の未compileな~handler$ ◎ which is either null, a callback object, or an internal raw uncompiled handler.\
`EventHandler$I ~callback関数~型は、 これが~scriptに どう公開されるかを述べる。 ◎ The EventHandler callback function type describes how this is exposed to scripts.\
初期~時は、 ~NULL になるモノトスル。 ◎ Initially, an event handler's value must be set to null.
`~listener@eH ◎ a listener,\
~NULL / `~event~listener$ ◎ which is either null or an event listener\
~event~listenerは、 `~event~handler処理~algo$を走らすのを担当する。 ◎ responsible for running the event handler processing algorithm.\
初期~時は、 ~NULL になるモノトスル。 ◎ Initially, an event handler's listener must be set to null.

各~event~handlerは、 2 通りの仕方で公開される: ◎ Event handlers are exposed in two ways.

  • `~event~handler~IDL属性$として ⇒ この仕方は、 すべての~event~handlerに共通する。 ◎ The first way, common to all event handlers, is as an event handler IDL attribute.
  • `~event~handler内容~属性$として ⇒ [ `~HTML要素$ / `~window$ ]上の~event~handlerのうち一部は、 この仕方でも公開される。 ◎ The second way is as an event handler content attribute. Event handlers on HTML elements and some of the event handlers on Window objects are exposed in this way.

どちらの仕方でも,`~event~handler$は、 `名前@eH を通して公開される — それは、 常に `on^l から開始され,~handlerに意図される~event名が後続する文字列である。 ◎ For both of these two ways, the event handler is exposed through a name, which is a string that always starts with "on" and is followed by the name of the event for which the handler is intended.


[ `~event~handler$を公開する~obj, 対応する`~event~listener$が追加される~obj ]は、 ほとんどにおいては同じになる。 しかしながら,[ `body$e / `frameset$e ]要素は、 その【`~node文書$を結付けている】`~window$が存在するならば, それ上で動作する いくつかの`~event~handler$を公開する。 いずれにせよ、 `~event~handler$は,自身の `~target@eH 【すなわち、次の手続きで決定される後者の~obj】 上で動作するという。 ◎ Most of the time, the object that exposes an event handler is the same as the object on which the corresponding event listener is added. However, the body and frameset elements expose several event handlers that act upon the element's Window object, if one exists. In either case, we call the object an event handler acts upon the target of that event handler.

`~event~handlerの~targetを決定する@ ときは、 所与の ( %~event~target, %名前 ) に対し,次の手続きを走らす: ◎ To determine the target of an event handler, given an EventTarget object eventTarget on which the event handler is exposed, and an event handler name name, the following steps are taken:

  1. ~Assert ⇒# %~event~target は ある`~event~handler$を公開する `EventTarget$I ~objである / %名前 は ある`~event~handler$の`名前$eHを与える文字列である ◎ ↑
  2. ~IF[ %~event~target は[ `body$e / `frameset$e ]要素でない ] ⇒ ~RET %~event~target ◎ If eventTarget is not a body element or a frameset element, then return eventTarget.
  3. ~IF[ %名前 は `WindowEventHandlers$I ~interface~mixinの属性~memberの名前でない ]~AND[ %名前 ~NIN `~windowを反映する~body要素~event~handler集合$ ] ⇒ ~RET %~event~target ◎ If name is not the name of an attribute member of the WindowEventHandlers interface mixin and the Window-reflecting body element event handler set does not contain name, then return eventTarget.
  4. ~IF[ %~event~target の`~node文書$は`作動中な文書$でない ] ⇒ ~RET ~NULL ◎ If eventTarget's node document is not an active document, then return null.

    注記: これは例えば、 %~event~target が[ 対応する`~window$が無い `body$e 要素 ]である場合に起こり得る。 ◎ This could happen if this object is a body element without a corresponding Window object, for example.

    注記: [ `body$e / `frameset$e ]要素が自身の`~node文書$の`~body要素$でない場合、 この段で終えるとは限らない。 特に、 `作動中な文書$内で (たぶん, `document.createElement()$c を用いて) 作成された `body$e 要素であるが,`接続されて$いないものにも、 要素を通して公開される いくつかの`~event~handler$の`~target$eHになるような,対応する`~window$がある。 ◎ This check does not necessarily prevent body and frameset elements that are not the body element of their node document from reaching the next step. In particular, a body element created in an active document (perhaps with document.createElement()) but not connected will also have its corresponding Window object as the target of several event handlers exposed through it.

  5. ~RET %~event~target の`~node文書$に`関連な大域~obj$ ◎ Return eventTarget's node document's relevant global object.

各 `EventTarget$I ~objには、 `~event~handler~map@ が結付けられる† — それは、 `~event~handler$の`名前$eHを表現する文字列を`~event~handler$に対応付ける`~map$である。 ◎ Each EventTarget object that has one or more event handlers specified has an associated event handler map, which is a map of strings representing names of event handlers to event handlers.

`EventTarget$I ~objの作成-時には、 その`~event~handler~map$は,各[ ~obj上に指定された`~event~handler$のうち,~objを`~target$eHとするもの ]用の`~entry$を包含するように初期化するモノトスル — その`~event~handler$の各`~item$sctをそれぞれの初期~値に設定して。 ◎ When an EventTarget object that has one or more event handlers specified is created, its event handler map must be initialized such that it contains an entry for each event handler that has that object as target, with items in those event handlers set to their initial values.

【† 原文では, “`EventTarget^I ~objのうち,[ 1 個~以上の~event~handlerが指定されたもの ]に結付けられる” と記されているが、 この~mapが[ 空であること, 結付けられないこと ]に[ 論理的/観測-可能 ]な差異はないので,この訳では どの `EventTarget^I にも結付けられるものと見なす。 】

注記: `~event~handler~map$を成す`~entry$たちの順序は、 任意に~~選べる — その~map上で演算する どの~algoからも観測-可能にならないので。 ◎ The order of the entries of event handler map could be arbitrary. It is not observable through any algorithms that operate on the map.

注記: [ ~obj上に公開されるだけで,`~target$eHは他の~objになる`~event~handler$ ]用の`~entry$は、 ~objの`~event~handler~map$内には作成されない。 ◎ Entries are not created in the event handler map of an object for event handlers that are merely exposed on that object, but have some other object as their targets.


`~event~handler~IDL属性@ は、 特定の`~event~handler$用の~IDL属性である。 ~IDL属性の名前は、 `~event~handler$の`名前$eHと同じである。 ◎ An event handler IDL attribute is an IDL attribute for a specific event handler. The name of the IDL attribute is the same as the name of the event handler.

名前 %名前 の`~event~handler~IDL属性$の取得子~手続きは: ◎ The getter of an event handler IDL attribute with name name, when called, must run these steps:

  1. %~event~target ~LET `~event~handlerの~targetを決定する$( コレ, %名前 ) ◎ Let eventTarget be the result of determining the target of an event handler given this object and name.
  2. ~IF[ %~event~target ~EQ ~NULL ] ⇒ ~RET ~NULL ◎ If eventTarget is null, then return null.
  3. ~RET `~event~handlerの現在の値を取得する$( %~event~target, %名前 ) ◎ Return the result of getting the current value of the event handler given eventTarget and name.

名前 %名前 の`~event~handler~IDL属性$の設定子~手続きは: ◎ The setter of an event handler IDL attribute with name name, when called, must run these steps:

  1. %~event~target ~LET `~event~handlerの~targetを決定する$( コレ, %名前 ) ◎ Let eventTarget be the result of determining the target of an event handler given this object and name.
  2. ~IF[ %~event~target ~EQ ~NULL ] ⇒ ~RET ◎ If eventTarget is null, then return.
  3. ~IF[ 所与の値 ~EQ ~NULL ] ⇒ `~event~handlerを非作動化する$( %~event~target, %名前 ) ◎ If the given value is null, then deactivate an event handler given eventTarget and name.
  4. ~ELSE: ◎ Otherwise:

    1. %~event~handler ~LET %~event~target の`~event~handler~map$[ %名前 ] ◎ Let handlerMap be eventTarget's event handler map. ◎ Let eventHandler be handlerMap[name].
    2. %~event~handler の`値$eH ~SET 所与の値 ◎ Set eventHandler's value to the given value.
    3. `~event~handlerを作動化する$( %~event~target, %名前 ) ◎ Activate an event handler given eventTarget and name.

注記: ある種の`~event~handler~IDL属性$ — 特に `MessagePort$I ~objの `onmessage$m 属性 — には、 追加的な要件がある。 ◎ Certain event handler IDL attributes have additional requirements, in particular the onmessage attribute of MessagePort objects.


`~event~handler内容~属性@ は、 ~obj上の特定の`~event~handler$に対応する,同じ~obj上の内容~属性である。 その名前は、 `~event~handler$の名前と同じである。 ◎ An event handler content attribute is a content attribute for a specific event handler. The name of the content attribute is the same as the name of the event handler.

`~event~handler内容~属性$に指定する値は、[ `自動的~semicolon挿入$後に, `FunctionBody$P 生成規則に合致するように構文解析される ]ような,妥当な~JS~codeを包含していなければナラナイ。 ◎ Event handler content attributes, when specified, must contain valid JavaScript code which, when parsed, would match the FunctionBody production after automatic semicolon insertion.

`~event~handler内容~属性$と`~event~handler$とを同期するため、 `属性~変更-時の手続き$ `DOM$r が利用される — それは、 所与の ( %局所~名, %旧-値, %値, %名前空間 ) に対し,次を走らす: ◎ The following attribute change steps are used to synchronize between event handler content attributes and event handlers: [DOM]

  1. ~IF[ %名前空間 ~NEQ ~NULL ]~OR[ %局所~名 ~NEQ %要素 上の`~event~handler内容~属性$の名前 ] ⇒ ~RET ◎ If namespace is not null, or localName is not the name of an event handler content attribute on element, then return.
  2. %~event~target ~LET `~event~handlerの~targetを決定する$( %要素, %局所~名 ) ◎ Let eventTarget be the result of determining the target of an event handler given element and localName.
  3. ~IF[ %~event~target ~EQ ~NULL ] ⇒ ~RET ◎ If eventTarget is null, then return.
  4. ~IF[ %値 ~EQ ~NULL ] ⇒ `~event~handlerを非作動化する$( %~event~target, %局所~名 ) ◎ If value is null, then deactivate an event handler given eventTarget and localName.
  5. ~ELSE: ◎ Otherwise:

    1. ~IF[ `要素における~inline型の挙動は~CSPにより阻止されるべきか?$( %要素, `script attribute^l, %値 ) ~EQ `阻止される^i `CSP$r ] ⇒ ~RET ◎ If the Should element's inline behavior be blocked by Content Security Policy? algorithm returns "Blocked" when executed upon element, "script attribute", and value, then return. [CSP]
    2. %~event~handler ~LET %~event~target の`~event~handler~map$[ %局所~名 ] ◎ Let handlerMap be eventTarget's event handler map. ◎ Let eventHandler be handlerMap[localName].
    3. %所在 ~LET この手続きの実行を誘発した~scriptの所在 ◎ Let location be the script location that triggered the execution of these steps.
    4. %~event~handler の`値$eH ~SET ( %値, %所在 ) 組からなる,`内部的な生の未compileな~handler$ ◎ Set eventHandler's value to the internal raw uncompiled handler value/location.
    5. `~event~handlerを作動化する$( %~event~target, %局所~名 ) ◎ Activate an event handler given eventTarget and localName.

注記: `DOM$r 標準により,この手続きは: %旧-値, %値 が一致する場合(属性をその現在の値に設定したとき)でも走るが、 両~値とも ~NULL の場合(現在~存在しない属性を除去したとき)には`走らない^em。 ◎ Per the DOM Standard, these steps are run even if oldValue and value are identical (setting an attribute to its current value), but not if oldValue and value are both null (removing an attribute that doesn't currently exist). [DOM]


`~event~handlerを非作動化する@ ときは、 所与の ( %~event~target, %名前 ) に対し,次の手続きを走らす: ◎ To deactivate an event handler given an EventTarget object eventTarget and a string name that is the name of an event handler, run these steps:

  1. ~Assert ⇒# %~event~target は `EventTarget$I ~objである / %名前 は ある`~event~handler$の`名前$eHを与える文字列である ◎ ↑
  2. %~event~handler ~LET %~event~target の`~event~handler~map$[ %名前 ] ◎ Let handlerMap be eventTarget's event handler map. ◎ Let eventHandler be handlerMap[name].
  3. %~event~handler の`値$eH ~SET ~NULL ◎ Set eventHandler's value to null.
  4. %~listener ~LET %~event~handler の`~listener$eH ◎ Let listener be eventHandler's listener.
  5. ~IF[ %~listener ~NEQ ~NULL ] ⇒ `~event~listenerを除去する$( %~event~target, %~listener ) ◎ If listener is not null, then remove an event listener with eventTarget and listener.
  6. %~event~handler の`~listener$eH ~SET ~NULL ◎ Set eventHandler's listener to null.

`すべての~event~listener/~event~handlerを消去する@ ときは、 所与の ( `EventTarget$I ~obj %~event~target ) に対し,次の手続きを走らす: ◎ To erase all event listeners and handlers given an EventTarget object eventTarget, run these steps:

  1. %~event~target の`~event~handler~map$を成す ~EACH( %名前 → %~event~handler ) に対し ⇒ `~event~handlerを非作動化する$( %~event~target, %名前 ) ◎ If eventTarget has an associated event handler map, then for each name → eventHandler of eventTarget's associated event handler map, deactivate an event handler given eventTarget and name.
  2. `~event~listenerをすべて除去する$( %~event~target ) ◎ Remove all event listeners given eventTarget.

この~algoは `document.open()$c を定義するために利用される。 ◎ This algorithm is used to define document.open().

`~event~handlerを作動化する@ ときは、 所与の ( %~event~target, %名前 ) に対し,次の手続きを走らす: ◎ To activate an event handler given an EventTarget object eventTarget and a string name that is the name of an event handler, run these steps:

  1. ~Assert ⇒# %~event~target は `EventTarget$I ~objである / %名前 は ある`~event~handler$の`名前$eHを与える文字列である ◎ ↑
  2. %~event~handler ~LET %~event~target の`~event~handler~map$[ %名前 ] ◎ Let handlerMap be eventTarget's event handler map. ◎ Let eventHandler be handlerMap[name].
  3. ~IF[ %~event~handler の`~listener$eH ~NEQ ~NULL ] ⇒ ~RET ◎ If eventHandler's listener is not null, then return.
  4. %callback ~LET [ 1 個の引数 %引数 をとり,次を実行する関数 ]への参照を表現している,~Web~IDL `EventListener$I ~instanceを作成した結果 ⇒ `~event~handler処理~algo$( %~event~target, %名前, %引数 ) ◎ Let callback be the result of creating a Web IDL EventListener instance representing a reference to a function of one argument that executes the steps of the event handler processing algorithm, given eventTarget, name, and its argument.

    `EventListener$I の`~callback文脈$は、 任意なものをとれる — それは、 `~event~handler処理~algo$には影響iしない。 `DOM$r ◎ The EventListener's callback context can be arbitrary; it does not impact the steps of the event handler processing algorithm. [DOM]

    注記: `callback^i は、 `~event~handler$そのもの`ではない^emことに注意。 どの`~event~handler$も、 同じ `~callback^i — すなわち,下に定義する~algo — を登録する結果になる。 その~algoが、[ 的確な~codeを呼出して,その~codeから返される値を処理する ]ことを受け持つ。 ◎ The callback is emphatically not the event handler itself. Every event handler ends up registering the same callback, the algorithm defined below, which takes care of invoking the right code, and processing the code's return value.

  5. %~listener ~LET 新たな`~event~listener$ — その ⇒# `型$evL ~SET %~event~handler に対応する `~event~handler~event型@ `~callback$evL ~SET %~callback ◎ Let listener be a new event listener whose type is the event handler event type corresponding to eventHandler and callback is callback.

    注記: `~event~listener$は `EventListener$I とは異なることに注意。 ◎ To be clear, an event listener is different from an EventListener.

  6. `~event~listenerを追加する$( %~event~target, %~listener ) ◎ Add an event listener with eventTarget and listener.
  7. %~event~handler の`~listener$eH ~SET %~listener ◎ Set eventHandler's listener to listener.

注記: ~event~listener登録が起こるのは、 当の`~event~handler$ %~event~handler が,作動化-済みでない下で その`値$eHが非 ~NULL に設定されるときに限られる。 ~listenerは登録-順に~callされるので、 非作動化は生じていないと見做すならば,特定0の~event型~用の~event~listenerたちは,常に次の順序で~callされる: ◎ The event listener registration happens only if the event handler's value is being set to non-null, and the event handler is not already activated. Since listeners are called in the order they were registered, assuming no deactivation occurred, the order of event listeners for a particular event type will always be:

  1. %~event~handler の`値$eHが最初に非 ~NULL に設定される前に, `addEventListener()$m で登録された~event~listenerたち ◎ the event listeners registered with addEventListener() before the first time the event handler's value was set to non-null
  2. 現在, %~event~handler に設定されている~callbackが在れば,その~listener ◎ then the callback to which it is currently set, if any
  3. %~event~handler の`値$eHが最初に非 ~NULL に設定された`後に^em, `addEventListener()$m で登録された~event~listenerたち ◎ and finally the event listeners registered with addEventListener() after the first time the event handler's value was set to non-null.

この例は、 ~event~listenerが呼出される順序をデモる。 利用者がこの例の~buttonを~clickしたとき、 ~pageは,順に~text[ `一^l, `二^l, `三^l, `四^l ]を伴う 4 回の~alertを示すことになる。 ◎ This example demonstrates the order in which event listeners are invoked. If the button in this example is clicked by the user, the page will show four alerts, with the text "ONE", "TWO", "THREE", and "FOUR" respectively.

<button id="test">Start Demo</button>
<script>
  var %button = document.getElementById('test');
  %button.addEventListener(
    'click', function(){ alert('一') }, false
  );
  %button.setAttribute(
    'onclick', "alert('この~alertは呼ばれない')"
  ); /* 
~event~handler~listenerはこの時点で登録される。
◎
event handler listener is registered here
 */

  %button.addEventListener(
    'click', function(){ alert('三') }, false
  );
  %button.onclick = function(){ alert('二'); };
  %button.addEventListener(
    'click', function(){ alert('四') }, false
  );
</script>

しかしながら,次の例では、 ~event~handlerは,初回に作動化された後 (および,その~event~listenerが除去された後)に非作動化され, その後に作動化し直されるので、 ~pageは,順に~text[ `一^l, `二^l, `三^l, `四^l, `五^l ]を伴う 5 回の~alertを示すことになる。 ◎ However, in the following example, the event handler is deactivated after its initial activation (and its event listener is removed), before being reactivated at a later time. The page will show five alerts with "ONE", "TWO", "THREE", "FOUR", and "FIVE" respectively, in order.

<%button id="test">Start Demo</%button>
<script>
  var %button = document.getElementById('test');
  %button.addEventListener(
    'click', function () { alert('一') }, false
  );
  %button.setAttribute(
    'onclick', "alert('この~alertは呼ばれない')"
  ); /* 
~event~handlerは、
ここで作動化される
◎
event handler is activated here
 */
  %button.addEventListener(
    'click', function () { alert('二') }, false
  );
  %button.onclick = null;  /* 
が、
ここで非作動化される
◎
but deactivated here
 */
  %button.addEventListener(
    'click', function () { alert('三') }, false
  );
  %button.onclick = function () {
    alert('四');
  }; /* 
ここで作動化し直される
◎
and re-activated here
 */
  %button.addEventListener(
    'click', function () { alert('五') }, false
  );
</script>

注記: ~event~objが実装する~interfaceは、 `~event~handler$が誘発されるかどうかには波及しない。 ◎ The interfaces implemented by the event object do not influence whether an event handler is triggered or not.

`~event~handler処理~algo@ は、 所与の ( %~event~target, %名前, %~event ) に対し,次を走らす: ◎ The event handler processing algorithm for an EventTarget object eventTarget, a string name representing the name of an event handler, and an Event object event is as follows:

  1. ~Assert ⇒# %~event~target は `EventTarget$I ~objである / %名前 は ある`~event~handler$の`名前$eHを与える文字列である / %~event は `Event$I ~objである ◎ ↑
  2. %~callback ~LET `~event~handlerの現在の値を取得する$( %~event~target, %名前 ) ◎ Let callback be the result of getting the current value of the event handler given eventTarget and name.
  3. ~IF[ %~callback ~EQ ~NULL ] ⇒ ~RET ◎ If callback is null, then return.
  4. %特別な~error~event取扱いか ~LET ~IS[ %~event は `ErrorEvent$I ~objである ]~AND[ %~event の `type$m ~EQ "`error$et" ]~AND[ %~event の `currentTarget$m 値は `WindowOrWorkerGlobalScope$I ~mixinを実装する ] ◎ Let special error event handling be true if event is an ErrorEvent object, event's type is "error", and event's currentTarget implements the WindowOrWorkerGlobalScope mixin. Otherwise, let special error event handling be false.
  5. %引数~群 ~LET %特別な~error~event取扱いか に応じて:

    • ~F ⇒ « %~event »
    • ~T ⇒ %~event の次に挙げる属性の値たちが成す同順の`~list$ ⇒ `message$m, `filename$m, `lineno$m, `colno$m, `error$m
    ◎ ↓
  6. %返り値 ~LET `~callback関数を呼出す$( %~callback, %引数~list, `投出し直す^i, %~event の `currentTarget$m 属性の値 ) ◎ Process the Event object event as follows: • If special error event handling is true •• Let return value be the result of invoking callback with « event's message, event's filename, event's lineno, event's colno, event's error », "rethrow", and with callback this value set to event's currentTarget. • Otherwise •• Let return value be the result of invoking callback with « event », "rethrow", and with callback this value set to event's currentTarget.

    注記: %~callback から例外が投出された場合、 投出し直され,この手続きを終えることになる (当の例外は、 `~DOM~event配送-~logic@~DOM4#concept-event-listener-invoke$へ伝播して, そこで`報告される@#report-an-exception$ことになる)。 ◎ If an exception gets thrown by the callback, it will be rethrown, ending these steps. The exception will propagate to the DOM event dispatch logic, which will then report it.

  7. ~IF[ %~event は `BeforeUnloadEvent$I ~objである ]~AND[ %~event の `type$m ~EQ "`beforeunload$et" ]: ◎ Process return value as follows: • If event is a BeforeUnloadEvent object and event's type is "beforeunload"

    注記: この事例では、 `~event~handler~IDL属性$の型は `OnBeforeUnloadEventHandler$I 型になるので、 %返り値 は[ ~NULL または `DOMString^I ]型に型強制されることになる。 ◎ • In this case, the event handler IDL attribute's type will be OnBeforeUnloadEventHandler, so return value will have been coerced into either null or a DOMString.

    1. ~IF[ %返り値 ~EQ ~NULL ] ⇒ ~RET ◎ If return value is not null, then:
    2. %~event の`取消されたか$ev ~SET ~T ◎ Set event's canceled flag.
    3. ~IF[ %~event の `returnValue$m 属性の値 ~EQ 空~文字列 ] ⇒ %~event の `returnValue$m 属性の値 ~SET %返り値 ◎ If event's returnValue attribute's value is the empty string, then set event's returnValue attribute's value to return value.
  8. ~ELIF[ %特別な~error~event取扱いか ~EQ ~T ] ⇒ ~IF[ %返り値 ~EQ ~T ] ⇒ %~event の`取消されたか$ev ~SET ~T ◎ • If special error event handling is true •• If return value is true, then set event's canceled flag.
  9. ~ELIF[ %返り値 ~EQ ~F ] ⇒ %~event の`取消されたか$ev ~SET ~T ◎ • Otherwise •• If return value is false, then set event's canceled flag.

    注記: [ %~event の `type$m ~EQ "`beforeunload$et" ]だが[ %~event は `BeforeUnloadEvent$I ~objでない ]がため,この段に達した場合、 %返り値 は決して ~F にならない — すでに[ ~NULL または `DOMString^I ]型に型強制されているので。 ◎ • If we've gotten to this "Otherwise" clause because event's type is "beforeunload" but event is not a BeforeUnloadEvent object, then return value will never be false, since in such cases return value will have been coerced into either null or a DOMString.


`EventHandler$I ~callback関数~型は、 ~event~handlerに利用される~callbackを表現する。 それは、 次の~Web~IDLで表現される: ◎ The EventHandler callback function type represents a callback used for event handlers. It is represented in Web IDL as follows:

[`LegacyTreatNonObjectAsNull$]
callback `EventHandlerNonNull@I = any (`Event$I event);
typedef `EventHandlerNonNull$I? `EventHandler@I;

注記: ~JSにおいては、 どの `Function$I ~objもこの~interfaceを実装する。 ◎ In JavaScript, any Function object implements this interface.

例えば、 次の文書~片で: ◎ For example, the following document fragment:

<body onload="alert(this)" onclick="alert(this)">

文書が読込まれたときは `[object Window]^l が~alertされ、 利用者が~page内のどこかを~clickしたなら `[object HTMLBodyElement]^l が~alertされる。 ◎ ...leads to an alert saying "[object Window]" when the document is loaded, and an alert saying "[object HTMLBodyElement]" whenever the user clicks something in the page.

注記: 関数の返り値は,~eventが取消されるかどうかに影響する — 上で述べたように、 返り値 ~EQ ~F の場合,~eventは取消される。 ◎ The return value of the function affects whether the event is canceled or not: as described above, if the return value is false, the event is canceled.

歴史的な理由から、 ~platformには 2 つの例外がある ◎ There are two exceptions in the platform, for historical reasons:

  • 大域~obj上の `onerror$hd ~handlerは、 `true^jv を返した場合に~eventを取消すことになる。 ◎ The onerror handlers on global objects, where returning true cancels the event.
  • `onbeforeunload$hd ~handlerは、 `null^jv でも `undefined^jv でもない値を返した場合に~eventを取消すことになる。 ◎ The onbeforeunload handler, where returning any non-null and non-undefined value will cancel the event.

歴史的な理由から、 `onerror$hd ~handlerは,異なる引数をとる: ◎ For historical reasons, the onerror handler has different arguments:

[`LegacyTreatNonObjectAsNull$]
callback `OnErrorEventHandlerNonNull@I = any (
    (`Event$I or DOMString) %event,
    optional DOMString %source,
    optional unsigned long %lineno,
    optional unsigned long %colno,
    optional any %error
);
typedef `OnErrorEventHandlerNonNull$I? `OnErrorEventHandler@I;
window.onerror = (message, source, lineno, colno, error) => { … };

同様に、 `onbeforeunload$hd ~handlerは,異なる値を返す: ◎ Similarly, the onbeforeunload handler has a different return value:

[`LegacyTreatNonObjectAsNull$]
callback `OnBeforeUnloadEventHandlerNonNull@I = DOMString? (`Event$I %event);
typedef `OnBeforeUnloadEventHandlerNonNull$I? `OnBeforeUnloadEventHandler@I;

`内部的な生の未compileな~handler@ は、 次に挙げる情報からなる~tupleである: ◎ An internal raw uncompiled handler is a tuple with the following information:

  • 未compileな~script本体 ◎ An uncompiled script body
  • ~script本体が出自にしている所在 — ~errorを報告する必要がある場合に限り。 ◎ A location where the script body originated, in case an error needs to be reported

~UAは `~event~handlerの現在の値を取得する@ ときは、 所与の ( %~event~target, %名前 ) に対し,次を走らすモノトスル: ◎ When the user agent is to get the current value of the event handler given an EventTarget object eventTarget and a string name that is the name of an event handler, it must run these steps:

  1. ~Assert ⇒# %~event~target は `EventTarget$I ~objである / %名前 は ある`~event~handler$の`名前$eHを与える文字列である ◎ ↑
  2. %~event~handler ~LET %~event~target の`~event~handler~map$[ %名前 ] ◎ Let handlerMap be eventTarget's event handler map. ◎ Let eventHandler be handlerMap[name].
  3. ~IF[ %~event~handler の`値$eHは、 `内部的な生の未compileな~handler$でない ] ⇒ ~RET %~event~handler の`値$eH ◎ If eventHandler's value is an internal raw uncompiled handler, then:
  4. ( %要素, %文書 ) ~LET %~event~target に応じて:

    • ある要素 %E である ⇒ ( %E, %E の`~node文書$ )
    • ある`~window$ %W である ⇒ ( ~NULL, %W に`結付けられた文書$ )
    ◎ If eventTarget is an element, then let element be eventTarget, and document be element's node document. Otherwise, eventTarget is a Window object, let element be null, and document be eventTarget's associated Document.
  5. ~IF[ %文書 用の`~scriptingは不能化されて$いる ] ⇒ ~RET ~NULL ◎ If scripting is disabled for document, then return null.
  6. %本体 ~LET %~event~handler の`値$eHを成す未compileな~script本体 ◎ Let body be the uncompiled script body in eventHandler's value.
  7. %所在 ~LET %本体 が出自にしている所在 ◎ Let location be the location where the script body originated, as given by eventHandler's value.
  8. %~form所有者 ~LET ~NULL ◎ ↓
  9. ~IF[ %要素 ~NEQ ~NULL ]~AND[ %要素 には`~form所有者$ %F がある ] ⇒ %~form所有者 ~LET %F ◎ If element is not null and element has a form owner, let form owner be that form owner. Otherwise, let form owner be null.
  10. %設定群~obj ~LET %文書 に`関連な設定群~obj$ ◎ Let settings object be the relevant settings object of document.
  11. ~IF[ %本体 は `FunctionBody$P として構文解析-可能でない ]~OR[ 構文解析-時に`早期~error$が検出された ]: ◎ If body is not parsable as FunctionBody or if parsing detects an early error, then follow these substeps:

    1. %~event~handler の`値$eH ~SET ~NULL ◎ Set eventHandler's value to null.

      注記: これは、 `~event~handlerを非作動化する$ことはない — それは、 ~event~handlerの`~listener$eHが在れば, それも`除去する@~DOM4#remove-an-event-listener$。 ◎ This does not deactivate the event handler, which additionally removes the event handler's listener (if present).

    2. %構文~error ~LET %設定群~obj の`~realm$enV に属する新たな `SyntaxError$E 例外 — これは、 検出された~errorを述べるものであり, 【その`~message@~WEBIDL#domexception-message$は】 %所在 に基づくベキである。 ◎ Let syntaxError be a new SyntaxError exception associated with settings object's realm which describes the error while parsing. It should be based on location, where the script body originated.
    3. `例外を報告する$( %構文~error, %設定群~obj の`大域~obj$enV ) ◎ Report an exception with syntaxError for settings object's global object.
    4. ~RET ~NULL ◎ Return null.
  12. `~JS実行~文脈~stack$に[ %設定群~obj の`~realm実行~文脈$enV ]を~pushする — それが,現在 `走っている~JS実行~文脈$になる ◎ Push settings object's realm execution context onto the JavaScript execution context stack; it is now the running JavaScript execution context.

    注記: これは、 後の `OrdinaryFunctionCreate$jA の呼出nが正しい`~realm$に属するようにするため,必要yである。 ◎ This is necessary so the subsequent invocation of OrdinaryFunctionCreate takes place in the correct realm.

  13. %onerror用か ~LET ~IS[ %名前 ~EQ `onerror$hd ]~AND[ %~event~target は`~window$である ] ◎ ↓
  14. %関数 ~LET 次を引数に `OrdinaryFunctionCreate$jA を~callした結果: ◎ Let function be the result of calling OrdinaryFunctionCreate, with arguments:

    %functionPrototype
    `Function.prototype$jI
    %sourceText

    次を順に連結して形成される文字列 ⇒# `function ^l, %名前, 下に与える %S, ` {^l, `000A^U `LF^cn, %本体, `000A^U `LF^cn, `}^l

    上の %S は、 %onerror用か に応じて ⇒# ~T ならば `(event, source, lineno, colno, error)^l / ~F ならば `(event)^l

    ◎ If name is onerror and eventTarget is a Window object • The string formed by concatenating "function ", name, "(event, source, lineno, colno, error) {", U+000A LF, body, U+000A LF, and "}". ◎ Otherwise • The string formed by concatenating "function ", name, "(event) {", U+000A LF, body, U+000A LF, and "}".
    %ParameterList
    %関数 は %onerror用か に応じて,次に与える名前の引数をとる ⇒# ~T ならば 5 個の引数 ( `event^c, `source^c, `lineno^c, `colno^c, `error^c ) / ~F ならば 1 個の引数 ( `event^c ) ◎ If name is onerror and eventTarget is a Window object • Let the function have five arguments, named event, source, lineno, colno, and error. ◎ Otherwise • Let the function have a single argument called event.
    %body
    %本体 を構文解析した結果 ◎ The result of parsing body above.
    %thisMode
    `non-lexical-this^i
    %scope

    次の手続きを走らせた結果: ◎ —

    1. %~realm ~LET %設定群~obj の`~realm$enV ◎ Let realm be settings object's realm.
    2. %視野 ~LET %~realm .`GlobalEnv^sl ◎ Let scope be realm.[[GlobalEnv]].
    3. ~IF[ %~event~handler は要素の`~event~handler$である ] ⇒ %視野 ~SET `NewObjectEnvironment$jA( %文書, ~T, %視野 ) ◎ If eventHandler is an element's event handler, then set scope to NewObjectEnvironment(document, true, scope).
    4. ~ELSE ⇒ ~Assert: %~event~handler は`~window$の`~event~handler$である ◎ (Otherwise, eventHandler is a Window object's event handler.)
    5. ~IF[ %~form所有者 ~NEQ ~NULL ] ⇒ %視野 ~SET `NewObjectEnvironment$jA( %~form所有者, ~T, %視野 ) ◎ If form owner is not null, then set scope to NewObjectEnvironment(form owner, true, scope).
    6. ~IF[ %要素 ~NEQ ~NULL ] ⇒ %視野 ~SET `NewObjectEnvironment$jA( %要素, ~T, %視野 ) ◎ If element is not null, then set scope to NewObjectEnvironment(element, true, scope).
    7. ~RET %視野 ◎ Return scope.
  15. %設定群~obj の`~realm実行~文脈$enVを,`~JS実行~文脈~stack$から除去する ◎ Remove settings object's realm execution context from the JavaScript execution context stack.
  16. %関数 .`ScriptOrModule^sl ~SET ~NULL ◎ Set function.[[ScriptOrModule]] to null.

    注記: これを行うわけは、[ 作成した %関数 を当の~stack上で最も近い`~script$に結付けるとする,既定の挙動 ]では,~pathに依存する結果を導き得るからである: 例えば、 ~event~handlerが利用者-ヤリトリにより最初に呼出された場合, `ScriptOrModule^sl は ~NULL になる (その時点では`作動中な~script$は ~NULL であり,この~algoは、 そのとき最初に呼出されるので) 一方で、 ~scriptから~eventを配送することにより最初に呼出された場合, `ScriptOrModule^sl は その~scriptに設定されることになる。 ◎ This is done because the default behavior, of associating the created function with the nearest script on the stack, can lead to path-dependent results. For example, an event handler which is first invoked by user interaction would end up with null [[ScriptOrModule]] (since then this algorithm would be first invoked when the active script is null), whereas one that is first invoked by dispatching an event from script would have its [[ScriptOrModule]] set to that script.

    ここでは代わりに、 `ScriptOrModule^sl は常に ~NULL に設定することにする。 こうすれば、 もっと直感的になる — [ 最初に~eventを配送した~scriptが、 どうにかして,当の~event~handler~codeを担当する ]とする案では、 不確かになる。 ◎ Instead, we just always set [[ScriptOrModule]] to null. This is more intuitive anyway; the idea that the first script which dispatches an event is somehow responsible for the event handler code is dubious.

    これは,実施においては、 `import()$m を介する相対~URLの解決に限り影響する — それは、 結付けられた~scriptの`基底~URL$sCを諮る。 `ScriptOrModule^sl を ~NULL 化することは、[ `HostLoadImportedModule$jA は、 `現在の設定群~obj$の`~API用~基底~URL$enVに~fall-backする ]ことを意味する。 ◎ In practice, this only affects the resolution of relative URLs via import(), which consult the base URL of the associated script. Nulling out [[ScriptOrModule]] means that HostLoadImportedModule will fall back to the current settings object's API base URL.

  17. %~event~handler の値 ~SET 新たな~Web~IDL `EventHandler$I ~callback関数 — その ⇒# その~obj参照 ~SET %関数, その`~callback文脈$ ~SET %設定群~obj ◎ Set eventHandler's value to the result of creating a Web IDL EventHandler callback function object whose object reference is function and whose callback context is settings object.
  18. ~RET %~event~handler の値 ◎ Return eventHandler's value.
8.1.8.2. [ 要素 / 文書 / ~window ]上の各種~event~handler

以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • `~HTML要素$においては、[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]の両者として,~supportするモノトスル。
  • [ `文書$ / `~window$ ]においては、 `~event~handler~IDL属性$として,~supportするモノトスル。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements, as both event handler content attributes and event handler IDL attributes; and that must be supported by all Document and Window objects, as event handler IDL attributes:
`~event~handler$ `~event~handler~event型$
`onabort@hd `abort^et†
`onauxclick@hd `auxclick$et
`onbeforeinput@hd `beforeinput$et
`onbeforematch@hd `beforematch$et
`onbeforetoggle@hd `beforetoggle$et
`oncancel@hd `cancel$et
`oncanplay@hd `canplay$et
`oncanplaythrough@hd `canplaythrough$et
`onchange@hd `change$et
`onclick@hd `click$et
`onclose@hd `close$et
`oncontextlost@hd `contextlost$et
`oncontextmenu@hd `contextmenu$et
`oncontextrestored@hd `contextrestored$et
`oncopy@hd `copy$et
`oncuechange@hd `cuechange$et
`oncut@hd `cut$et
`ondblclick@hd `dblclick$et
`ondrag@hd `drag$et
`ondragend@hd `dragend$et
`ondragenter@hd `dragenter$et
`ondragleave@hd `dragleave$et
`ondragover@hd `dragover$et
`ondragstart@hd `dragstart$et
`ondrop@hd `drop$et
`ondurationchange@hd `durationchange$et
`onemptied@hd `emptied$et
`onended@hd `ended$et
`onformdata@hd `formdata$et
`oninput@hd `input$et
`oninvalid@hd `invalid$et
`onkeydown@hd `keydown$et
`onkeypress@hd `keypress$et
`onkeyup@hd `keyup$et
`onloadeddata@hd `loadeddata$et
`onloadedmetadata@hd `loadedmetadata$et
`onloadstart@hd `loadstart$et
`onmousedown@hd `mousedown$et
`onmouseenter@hd `mouseenter$et
`onmouseleave@hd `mouseleave$et
`onmousemove@hd `mousemove$et
`onmouseout@hd `mouseout$et
`onmouseover@hd `mouseover$et
`onmouseup@hd `mouseup$et
`onpaste@hd `paste$et
`onpause@hd `pause$et
`onplay@hd `play$et
`onplaying@hd `playing$et
`onprogress@hd `progress$et
`onratechange@hd `ratechange$et
`onreset@hd `reset$et
`onscrollend@hd `scrollend$et
`onsecuritypolicyviolation@hd `securitypolicyviolation$et
`onseeked@hd `seeked$et
`onseeking@hd `seeking$et
`onselect@hd `select$et
`onslotchange@hd `slotchange$et
`onstalled@hd `stalled$et
`onsubmit@hd `submit$et
`onsuspend@hd `suspend$et
`ontimeupdate@hd `timeupdate$et
`ontoggle@hd `toggle$et
`onvolumechange@hd `volumechange$et
`onwaiting@hd `waiting$et
`onwebkitanimationend@hd `webkitAnimationEnd^et
`onwebkitanimationiteration@hd `webkitAnimationIteration^et
`onwebkitanimationstart@hd `webkitAnimationStart^et
`onwebkittransitionend@hd `webkitTransitionEnd^et
`onwheel@hd `wheel$et

【† `abort^et ~eventは、 実装されていないため,仕様から除去された (`課題 #3525@~HTMLissue/3525$)。 】


以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • [ `body$e, `frameset$e ]要素を除く `~HTML要素$においては、[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]の両者として,~supportするモノトスル。
  • `文書$においては、 `~event~handler~IDL属性$として,~supportするモノトスル。
  • `~window$においては、 `~event~handler~IDL属性$として,~supportするモノトスル。 加えて、 当の`~window$に`結付けられた文書$が所有する[ `body$e / `frameset$e ]要素においても,対応する[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]を公開するモノトスル。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements other than body and frameset elements, as both event handler content attributes and event handler IDL attributes; that must be supported by all Document objects, as event handler IDL attributes; and that must be supported by all Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's associated Document:
`~event~handler$ `~event~handler~event型$
`onblur@hd `blur$et
`onerror@hd `error$et
`onfocus@hd `focus$et
`onload@hd `load$et
`onresize@hd `resize$et
`onscroll@hd `scroll$et

上の 1 列目に挙げた`~event~handler$の`名前$eHが成す`有順序~集合$を指して, `~windowを反映する~body要素~event~handler集合@ と呼ぶ。 ◎ We call the set of the names of the event handlers listed in the first column of this table the Window-reflecting body element event handler set.


以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • `~window$においては,`~event~handler~IDL属性$として,~supportするモノトスル。
  • 前項に対応する[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]は、 当の`~window$に`結付けられた文書$が所有する[ `body$e / `frameset$e ]要素において公開するモノトスル。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported by Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's associated Document:
`~event~handler$ `~event~handler~event型$
`onafterprint@hd `afterprint$et
`onbeforeprint@hd `beforeprint$et
`onbeforeunload@hd `beforeunload$et
`onhashchange@hd `hashchange$et
`onlanguagechange@hd `languagechange$et
`onmessage@hd `message$et
`onmessageerror@hd `messageerror$et
`onoffline@hd `offline$et
`ononline@hd `online$et
`onpageswap@hd `pageswap$et
`onpagehide@hd `pagehide$et
`onpagereveal@hd `pagereveal$et
`onpageshow@hd `pageshow$et
`onpopstate@hd `popstate$et
`onrejectionhandled@hd `rejectionhandled$et
`onstorage@hd `storage$et
`onunhandledrejection@hd `unhandledrejection$et
`onunload@hd `unload$et

上に挙げた`~event~handler$は、 `WindowEventHandlers$I ~interface~mixinを通して,`~event~handler~IDL属性$として具象化される。 ◎ This list of event handlers is reified as event handler IDL attributes through the WindowEventHandlers interface mixin.


以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • `文書$においては、 `~event~handler~IDL属性$として,~supportするモノトスル。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported on Document objects as event handler IDL attributes:
`~event~handler$ `~event~handler~event型$
`onreadystatechange@hd `readystatechange$et
`onvisibilitychange@hd `visibilitychange$et
8.1.8.2.1. ~IDL定義
【!#handler-xxx】
interface mixin `GlobalEventHandlers@I {
  attribute EventHandler `onabort$hd;
  attribute EventHandler `onauxclick$hd;
  attribute EventHandler `onbeforeinput$hd;
  attribute EventHandler `onbeforematch$hd;
  attribute EventHandler `onbeforetoggle$hd;
  attribute EventHandler `onblur$hd;
  attribute EventHandler `oncancel$hd;
  attribute EventHandler `oncanplay$hd;
  attribute EventHandler `oncanplaythrough$hd;
  attribute EventHandler `onchange$hd;
  attribute EventHandler `onclick$hd;
  attribute EventHandler `onclose$hd;
  attribute EventHandler `oncontextlost$hd;
  attribute EventHandler `oncontextmenu$hd;
  attribute EventHandler `oncontextrestored$hd;
  attribute EventHandler `oncopy$hd;
  attribute EventHandler `oncuechange$hd;
  attribute EventHandler `oncut$hd;
  attribute EventHandler `ondblclick$hd;
  attribute EventHandler `ondrag$hd;
  attribute EventHandler `ondragend$hd;
  attribute EventHandler `ondragenter$hd;
  attribute EventHandler `ondragleave$hd;
  attribute EventHandler `ondragover$hd;
  attribute EventHandler `ondragstart$hd;
  attribute EventHandler `ondrop$hd;
  attribute EventHandler `ondurationchange$hd;
  attribute EventHandler `onemptied$hd;
  attribute EventHandler `onended$hd;
  attribute `OnErrorEventHandler$I `onerror$hd;
  attribute EventHandler `onfocus$hd;
  attribute EventHandler `onformdata$hd;
  attribute EventHandler `oninput$hd;
  attribute EventHandler `oninvalid$hd;
  attribute EventHandler `onkeydown$hd;
  attribute EventHandler `onkeypress$hd;
  attribute EventHandler `onkeyup$hd;
  attribute EventHandler `onload$hd;
  attribute EventHandler `onloadeddata$hd;
  attribute EventHandler `onloadedmetadata$hd;
  attribute EventHandler `onloadstart$hd;
  attribute EventHandler `onmousedown$hd;
  [`LegacyLenientThis$] attribute EventHandler `onmouseenter$hd;
  [`LegacyLenientThis$] attribute EventHandler `onmouseleave$hd;
  attribute EventHandler `onmousemove$hd;
  attribute EventHandler `onmouseout$hd;
  attribute EventHandler `onmouseover$hd;
  attribute EventHandler `onmouseup$hd;
  attribute EventHandler `onpaste$hd;
  attribute EventHandler `onpause$hd;
  attribute EventHandler `onplay$hd;
  attribute EventHandler `onplaying$hd;
  attribute EventHandler `onprogress$hd;
  attribute EventHandler `onratechange$hd;
  attribute EventHandler `onreset$hd;
  attribute EventHandler `onresize$hd;
  attribute EventHandler `onscroll$hd;
  attribute EventHandler `onscrollend$hd;
  attribute EventHandler `onsecuritypolicyviolation$hd;
  attribute EventHandler `onseeked$hd;
  attribute EventHandler `onseeking$hd;
  attribute EventHandler `onselect$hd;
  attribute EventHandler `onslotchange$hd;
  attribute EventHandler `onstalled$hd;
  attribute EventHandler `onsubmit$hd;
  attribute EventHandler `onsuspend$hd;
  attribute EventHandler `ontimeupdate$hd;
  attribute EventHandler `ontoggle$hd;
  attribute EventHandler `onvolumechange$hd;
  attribute EventHandler `onwaiting$hd;
  attribute EventHandler `onwebkitanimationend$hd;
  attribute EventHandler `onwebkitanimationiteration$hd;
  attribute EventHandler `onwebkitanimationstart$hd;
  attribute EventHandler `onwebkittransitionend$hd;
  attribute EventHandler `onwheel$hd;
};
【! #handler-window-xxxx】
interface mixin `WindowEventHandlers@I {
  attribute EventHandler `onafterprint$hd;
  attribute EventHandler `onbeforeprint$hd;
  attribute `OnBeforeUnloadEventHandler$I `onbeforeunload$hd;
  attribute EventHandler `onhashchange$hd;
  attribute EventHandler `onlanguagechange$hd;
  attribute EventHandler `onmessage$hd;
  attribute EventHandler `onmessageerror$hd;
  attribute EventHandler `onoffline$hd;
  attribute EventHandler `ononline$hd;
  attribute EventHandler `onpagehide$hd;
  attribute EventHandler `onpagereveal$hd;
  attribute EventHandler `onpageshow$hd;
  attribute EventHandler `onpageswap$hd;
  attribute EventHandler `onpopstate$hd;
  attribute EventHandler `onrejectionhandled$hd;
  attribute EventHandler `onstorage$hd;
  attribute EventHandler `onunhandledrejection$hd;
  attribute EventHandler `onunload$hd;
};
8.1.8.3. ~eventの発火-法

ある種の演算や~methodは、 要素に向けて~eventを発火するものと定義される。 例えば, `HTMLElement$I 上の `click()$m ~methodは、 要素に向けて `click$et ~eventを発火するものと定義される。 `UIEVENTS$r ◎ Certain operations and methods are defined as firing events on elements. For example, the click() method on the HTMLElement interface is defined as firing a click event on the element. [UIEVENTS]

`合成な~pointer~eventを発火する@ ときは、 所与の ( %~target(~eventの配送-先), %e(~event名), %~trustされないか ~IN { `~trustされない^i, ε } (省略時は ε ) ) に対し,次の手続きを走らす: ◎ Firing a synthetic pointer event named e at target, with an optional not trusted flag, means running these steps:

  1. %~event ~LET `~eventを作成する$( `PointerEvent$I ) ◎ Let event be the result of creating an event using PointerEvent.
  2. 以下に従って, %~event を初期化する: ◎ ↓

    1. `type$m ~SET %e ◎ Initialize event's type attribute to e.
    2. `bubbles$m ~SET ~T ◎ ↓
    3. `cancelable$m ~SET ~T ◎ Initialize event's bubbles and cancelable attributes to true.
    4. `~composedか$ev ~SET ~T ◎ Set event's composed flag.
    5. ~IF[ %~trustされないか ~EQ `~trustされない^i ] ⇒ `isTrusted$m ~SET ~F ◎ If the not trusted flag is set, initialize event's isTrusted attribute to false.
    6. [ `ctrlKey^m, `shiftKey^m, `altKey^m, `metaKey^m ]は、 ~UIkey入力~装置の現在の状態に則って初期化する (可用でない~UIkeyに対しては ~F にする) ◎ Initialize event's ctrlKey, shiftKey, altKey, and metaKey attributes according to the current state of the key input device, if any (false for any keys that are not available).
    7. `view$m ~SET %~target の`~node文書$の`~window$が[ あれば それ/ なければ ~NULL ] ◎ Initialize event's view attribute to target's node document's Window object, if any, and null otherwise.
    8. `getModifierState()^m ~methodは、 ~UIkey入力~装置の現在の状態を適切に述べる値を返すようにする ◎ event's getModifierState() method is to return values appropriately describing the current state of the key input device.
  3. ~RET `~eventを配送する$( %~target, %~event ) ◎ Return the result of dispatching event at target.

%~target に向けて `~click~eventを発火する@ とは、 次を走らすことを意味する ⇒ `合成な~pointer~eventを発火する$( %~target, `click^et ) ◎ Firing a click event at target means firing a synthetic pointer event named click at target.