スクリプト処理 — Scripting

8.1.3.1. 各種~定義

`~script@ は、 2 種の`構造体$に分けられる。 いずれにせよ、各~scriptは次の~itemを有する： ◎ A script is one of two possible structs. All scripts have:

`設定群~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

~NULL, または［ `~classic~script$に対しては `Script Record$js ／ `~module~script$に対しては `Source Text Module Record$js ］。 ~NULL でない場合、構文解析-済みの~scriptを表現する。 ~NULL は、構文解析に失敗したことを表現する。 ◎ Either a Script Record, for classic scripts; a Source Text Module Record, for module scripts; or null. In the former two cases, it represents a parsed script; null represents a failure parsing.

`構文解析-~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.

`再投出-用~error@sC ◎ An error to rethrow

評価を成功させなくする~errorを表現している，~JS値。 ~scriptを走らすよう試みられたときには、これが再~投出されることになる。 ◎ A JavaScript value representing an error that will prevent evaluation from succeeding. It will be re-thrown by any attempts to run the script.

注記： この例外~値は~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~options@sC ◎ Fetch options

`~script~fetch~options$ — ［ この~script, および それが~importする`~module~script$ ］を~fetchするときに関係する，様々な~optionを包含する。 ◎ A script fetch options, containing various options related to fetching this script or module scripts that it imports.

`基底~URL@sC ◎ A base URL

`~module指定子を解決する$ときに利用される基底~URL。 これは、外部~module~scriptに対しては，~scriptが得られた~URLになり、~inline~scriptに対しては，それを包含している文書の`基底~URL$になる。 ◎ A base URL used for resolving module specifiers. 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.

`~classic~script@ は、`~script$の一種であり，次の`~item$も有する： ◎ 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は有さない。 ◎ A module script is another type of script. It has no additional items.

`作動中の~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]].

`環境@ とは、［ 現在の実行~環境，または そうなり得るもの ］の設定群を識別する~objである。 各 `環境$ %環境 は、次のものを有する： ◎ An environment is an object that identifies the settings of a current or potential execution environment. An environment has the following fields:

`~id@enV ◎ An id

%環境 を一意に識別する，不透明な文字列。 ◎ An opaque string that uniquely identifies the environment.

`作成時の~URL@enV ◎ A creation URL

%環境 が結付けられている資源の所在を表現している，`~URL~record$。 ◎ A URL record that represents the location of the resource with which the environment is associated.

注記： `環境~設定群~obj$の事例では、この~URLは `history.pushState$m などの仕組みに因り，`担当の文書$enVの`~URL$docとは別個のものにもなり得ることに注意。 ◎ In the case of an environment settings object, this URL might be distinct from the environment settings object's responsible document's URL, due to mechanisms such as history.pushState().

`~target閲覧文脈@enV ◎ A target browsing context

~NULL, または `~navi要請$の~target`閲覧文脈$。 ◎ Null or a target browsing context for a navigation request.

`作動中の~service-worker@enV ◎ An active service worker

~NULL, または %環境 を`制御-$xしている`~service-worker$。 ◎ Null or a service worker that controls the environment.

`実行~準備済み~flag@enV ◎ An execution ready flag

~flag値 — ~ON ならば、 %環境 はすでに設定しておかれたことを指示する。 初期~時は ~OFF 。 ◎ A flag that indicates whether the environment setup is done. It is initially unset.

各種~仕様は、環境~用に `環境を破棄する手続き@ を定義して~MAY。 この手続きは、入力として`環境$をとる。 ◎ 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.

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

`~realm実行~文脈@enV ◎ A realm execution context

%設定群 を利用するすべての `~script$x から共有される，`~JS実行~文脈$。 すなわち、これらの~scriptは，この`~JS~realm$内にある。 ［ `~classic~script$ ／ `~module~script$ ］を走らすときは、この実行~文脈が`~JS実行~文脈~stack$の一番上になり，その上に当の~scriptに特有の別の実行~文脈が~pushされる。 （こう設定しておけば、［ `ParseScript$jA ／ `Source Text Module Record$js の `Evaluate$jA ］は，どの~Realmを利用するかを知れるようになる。） ◎ A JavaScript execution context shared by all scripts that use this settings object, i.e. all scripts in a given JavaScript 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 ParseScript and Source Text Module Record's Evaluate know 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.

`担当の閲覧文脈@enV ◎ A responsible browsing context

［ %設定群 を利用する各~scriptがとる動作 ］を担当するものとされる，`閲覧文脈$。 ◎ A browsing context that is assigned responsibility for actions taken by the scripts that use this environment settings object.

例えば、~scriptが新たな`~top-level閲覧文脈$を作成して`~navigate$するとき、新たな`閲覧文脈$の`~window$の `opener$m 属性は，`担当の閲覧文脈$enVの `WindowProxy$I ~objに設定されることになる。 ◎ When a script creates and navigates a new top-level browsing context, the opener attribute of the new browsing context's Window object will be set to the responsible browsing context's WindowProxy object.

`担当の~event-loop@enV ◎ A responsible event loop

［ どの~event-loopを利用するか，すぐには はっきりしない ］ときに利用される，`~event-loop$。 ◎ An event loop that is used when it would not be immediately clear what event loop to use.

【 はっきりした時点で、特定0の~event-loopに振り分けられる（不定な~event-loopであって，他の処理に影響する前に何らかの~event-loopに確定される）ことを意味すると見られる。 】

`担当の文書@enV ◎ A responsible document

［ %設定群 を利用する各~scriptがとる動作 ］を担当するものとされる，`文書$。 ◎ A Document that is assigned responsibility for actions taken by the scripts that use this environment settings object.

例えば、`担当の文書$enVの`~URL$docは、`文書$の`~URL$docを設定するために利用される — それが `document.open(type, replace)$m を利用して再設定された後に。 ◎ For example, the URL of the responsible document is used to set the URL of the Document after it has been reset using document.open(type, replace).

`担当の~event-loop$enVが`閲覧文脈~event-loop$でない場合、 %設定群 は，`担当の文書$enVを持たない。 ◎ If the responsible event loop is not a browsing context event loop, then the environment settings object has no responsible document.

`~API用~URL文字~符号化法@enV ◎ An API URL character encoding

［［ %設定群 を利用している~script ］により~callされる~APIが，~URLを符号化する ］ときに利用する，文字~符号化法。 ◎ A character encoding used to encode URLs by APIs called by scripts that use this environment settings object.

`~API用~基底~URL@enV ◎ An API base URL

［［ %設定群 を利用している~script ］により~callされる~APIが，~URLを`相対的に構文解析-$する ］ときに利用する，`~URL$。 ◎ A URL used by APIs called by scripts that use this environment settings object to parse URLs.

`生成元@enV ◎ An origin

保安~検査に利用される`生成元$。 ◎ An origin used in security checks.

`~HTTPS状態@enV ◎ An HTTPS state

`~HTTPS状態~値$ — ［［ %設定群 が結付けられている資源 ］を送達するために利用されている~network-channel ］の，保安~上の特性を表現する。 ◎ An HTTPS state value representing the security properties of the network channel used to deliver the resource with which the environment settings object is associated.

`~referrer施策@enV ◎ A referrer policy

［ %設定群 を`要請~client$rqに利用して遂行される`~fetch$ ］用の，既定の`~referrer施策$。 `REFERRERPOLICY$r ◎ The default referrer policy for fetches performed using this environment settings object as a request client. [REFERRERPOLICY]

8.1.3.2. ~scriptの~fetch法

この節では、~scriptを~fetchするための各種~algoを導入する。 それらは、種々の必要な入力から［ `~classic~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~options@ は、次の`~item$を有する`構造体$である： ◎ Script fetch options is a struct with the following items:

`暗号用~nonce@sfO

初期~fetchに, および ~importした~moduleを~fetchするときに利用される，`暗号用~nonce~metadata$rq。 ◎ The cryptographic nonce metadata used for the initial fetch and for fetching any imported modules

`完全性~metadata@sfO

初期~fetchに利用される，`完全性~metadata$rq。 ◎ The integrity metadata used for the initial fetch

`構文解析器~metadata@sfO

初期~fetchに, および ~importした~moduleを~fetchするときに利用される，`構文解析器~metadata$rq。 ◎ The parser metadata used for the initial fetch and for fetching any imported modules

`資格証~mode@sfO

初期~fetchに, および — `~module~script$の場合に限り — ~importした~moduleを~fetchするときに利用される，`資格証~mode$rq。 ◎ 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

初期~fetch, および ~importされる~moduleの~fetchingに利用される，`~referrer施策$rq。 ◎ The referrer policy used for the initial fetch and for fetching any imported modules

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

`既定の~classic~script~fetch~options@ は、次のようにされた`~script~fetch~options$である ⇒＃ `暗号用~nonce$sfO ~SET 空~文字列, `完全性~metadata$sfO ~SET 空~文字列, `構文解析器~metadata$sfO ~SET `not-parser-inserted^l, `資格証~mode$sfO ~SET `omit^l, `~referrer施策$sfO ~SET 空~文字列 ◎ 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 "omit", and referrer policy is the empty string.

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

• `~classic~script要請を設定しておく@ ときは、次のように %要請 を設定する ⇒＃ `暗号用~nonce~metadata$rq ~SET %~options の`暗号用~nonce$sfO, `完全性~metadata$rq ~SET %~options の`完全性~metadata$sfO, `構文解析器~metadata$rq ~SET %~options の`構文解析器~metadata$sfO, `~referrer施策$rq ~SET %~options の`~referrer施策$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, and its referrer policy to options's referrer policy. , and .
• `~module~script要請を設定しておく@ ときは、次のように %要請 を設定する ⇒＃ `暗号用~nonce~metadata$rq ~SET %~options の`暗号用~nonce$sfO, `完全性~metadata$rq ~SET %~options の`完全性~metadata$sfO, `構文解析器~metadata$rq ~SET %~options の`構文解析器~metadata$sfO, `資格証~mode$rq ~SET %~options の`資格証~mode$sfO, `~referrer施策$rq ~SET %~options の`~referrer施策$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, and its referrer policy to options's referrer policy.

`子孫~script~fetch~options@ は、所与の ( `~script~fetch~options$ %~options ) に対し，次のようにされた新たな`~script~fetch~options$を返す ⇒＃ `完全性~metadata$sfO ~SET 空~文字列, 他のすべての`~item$は %~options と同じ値 ◎ For any given script fetch options options, the descendant script fetch options are a new script fetch options whose items all have the same values, except for the integrity metadata, which is instead the empty string.

これらの~algoを利用する仕様は、任意選択で `~fetchを遂行する@ ~custom~hookを給して，~algoを~custom化できる — この~custom~hookは： ◎ The algorithms below can be customized by optionally supplying a custom perform the fetch hook,＼

• ( `要請$, %~top-level内~flag ~IN { `~top-level内@i, ε } ) が入力に渡される。 ◎ which takes a request and an is top-level flag.＼
• `応答$を結果とし~MUST（`~network~error$も可）。 ◎ The algorithm must complete with a response (which may be a network error),＼
• `~workerが~importした~classic~scriptを~fetchする$ときは，結果を同期的に返し、他の場合は，`非同期に完了-$し~MUST。 ◎ either synchronously (when using fetch a classic worker-imported script) or asynchronously (otherwise).＼

• %~top-level内~flag は：

  • ［ `~classic~script$に対する すべての~fetch, および［ `~module~script~graphを~fetchする$ ／ `~worker用~module~script~graphを~fetchする$ ］ときの初期~fetch ］に対しては， `~top-level内$i にされる
  • ［ ~module~script~graphを通り抜ける間に遭遇した `import^c 文による結果の~fetch ］に対しては， ε にされる。
  ◎ The is top-level flag will be set for all classic script fetches, and for the initial fetch when fetching a module script graph or fetching a module worker script graph, but not for the fetches resulting from import statements encountered throughout the graph.

注記： Service Workers `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.

`~classic~scriptを~fetchする@ ときは、所与の ( %~url, %設定群~obj, %~options, %~CORS設定, %文字~符号化法 ) に対し，次を走らす — この~algoは、［ ~NULL （失敗~時） ／ 新たな`~classic~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To fetch a classic script given a url, a settings object, some options, a CORS setting, and a character encoding, run these steps. The algorithm will asynchronously complete with either null (on failure) or a new classic script (on success).

1. %要請 ~LET `~CORSになり得る要請を作成する$( %~url, `script^l, %~CORS設定 ) ◎ Let request be the result of creating a potential-CORS request given url, "script", and CORS setting.
2. %要請 の`~client$rq ~SET %設定群~obj ◎ Set request's client to settings object.
3. `~classic~script要請を設定しておく$( %要請, %~options ) ◎ Set up the classic script request given request and options.

4. ~IF［ この~algoの~call元にて，`~fetchを遂行する$ ~custom手続き %手続き が指定されている ］：

   1. %手続き を遂行する( %要請, `~top-level内$i )
   2. ~RET — ただし，以降の手続きは、 %手続き を完了した結果の`応答$ %応答 に対し走らす

   ◎ If the caller specified custom steps to perform the fetch, perform them on request, with the is top-level flag set. Return from this algorithm, and when the custom perform the fetch steps complete with response response, run the remaining steps.

   ~ELSE：

   1. %要請 を`~fetch$する
   2. ~RET — ただし，以降の手続きは、［ ~fetchした結果の`応答$ %応答 に対し`応答を処理する$ ］一部として走らす

   ◎ Otherwise, fetch request. Return from this algorithm, and run the remaining steps as part of the fetch's process response for the response response.

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

5. %応答 ~LET %応答 の`非安全~応答$ ◎ Let response be response's unsafe response.
6. ~IF［ %応答 の`種別$rs ~EQ `error^l ］~OR［ %応答 の`~status$rs ~NIN { `~ok~status$rs } ］ ⇒ ~NULL を結果として，`非同期に完了-$する ◎ If response's type is "error", or response's status is not an ok status, asynchronously complete this algorithm with null, and abort these steps.
7. ~IF［ %応答 には`Content Type ~metadata$があって，それは 文字~符号化法 %符号化法 を指定する ］~AND［ ~UAは %符号化法 を~supportする ］ ⇒ %文字~符号化法 ~SET %符号化法 （渡された %文字~符号化法 は無視する） ◎ If response's Content Type metadata, if any, specifies a character encoding, and the user agent supports that encoding, then set character encoding to that encoding (ignoring the passed-in value).

8. %~source~text ~LET　`~Unicodeに復号する$( %文字~符号化法, %応答 の`本体$rs ) ◎ Let source text be the result of decoding response's body to Unicode, using character encoding as the fallback encoding.

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

9. %~errorは黙秘する ~LET ［ %応答 は`~CORS非同一生成元$であるならば ~T ／ ~ELSE_ ~F ］ ◎ Let muted errors be true if response was CORS-cross-origin, and false otherwise.
10. %~script ~LET `~classic~scriptを作成する$( %~source~text, %応答 の`~url$rs, %~options, %~errorは黙秘する ) ◎ Let script be the result of creating a classic script given source text, settings object, response's url, options, and muted errors.
11. %~script を結果として，`非同期に完了-$する ◎ Asynchronously complete this algorithm with script.

`~worker用~classic~scriptを~fetchする@ ときは、所与の ⇒＃ %~url, %~fetch~client設定群~obj, %行先, %~script設定群~obj ◎終 に対し，次を走らす — この~algoは、［ ~NULL （失敗~時） ／ 新たな`~classic~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To fetch a classic worker script given a url, a fetch client settings object, a destination, and a script settings object, run these steps. The algorithm will asynchronously complete with either null (on failure) or a new classic script (on success).

1. %要請 ~LET 次のようにされた新たな`要請$ ⇒＃ `~url$rq ~SET %~url, `~client$rq ~SET %~fetch~client設定群~obj, `行先$rq ~SET %行先, `~mode$rq ~SET `same-origin^l, `資格証~mode$rq ~SET `same-origin^l, `構文解析器~metadata$rq ~SET `not-parser-inserted^l, `~URL資格証~利用~flag$rq ~SET ~ON ◎ Let request be a new request whose url is url, client is fetch client settings object, destination is destination, mode is "same-origin", credentials mode is "same-origin", parser metadata is "not parser-inserted", and whose use-URL-credentials flag is set.

2. ~IF［ この~algoの~call元にて，`~fetchを遂行する$ ~custom手続き %手続き が指定されている ］：

   1. %手続き を遂行する( %要請, `~top-level内$i )
   2. ~RET — ただし，以降の手続きは、 %手続き を完了した結果の`応答$ %応答 に対し走らす

   ◎ If the caller specified custom steps to perform the fetch, perform them on request, with the is top-level flag set. Return from this algorithm, and when the custom perform the fetch steps complete with response response, run the remaining steps.

   ~ELSE：

   1. %要請 を`~fetch$する
   2. ~RET — ただし，以降の手続きは、［ ~fetchした結果の`応答$ %応答 に対し`応答を処理する$ ］一部として走らす

   ◎ Otherwise, fetch request. Return from this algorithm, and run the remaining steps as part of the fetch's process response for the response response.
3. %応答 ~LET %応答 の`非安全~応答$ ◎ Let response be response's unsafe response.
4. ~IF［ %応答 の`種別$rs ~EQ `error^l ］~OR［ %応答 の`~status$rs ~NIN { `~ok~status$rs } ］ ⇒ ~NULL を結果として，`非同期に完了-$する ◎ If response's type is "error", or response's status is not an ok status, asynchronously complete this algorithm with null, and abort these steps.
5. %~source~text ~LET `~UTF-8復号する$( %応答 の`本体$rs ) ◎ Let source text be the result of UTF-8 decoding response's body.
6. %~script ~LET `~classic~scriptを作成する$( %~source~text, %~script設定群~obj, %応答 の`~url$rs, `既定の~classic~script~fetch~options$ ) ◎ Let script be the result of creating a classic script using source text, script settings object, response's url, and the default classic script fetch options.
7. %~script を結果として，`非同期に完了-$する ◎ Asynchronously complete this algorithm with script.

`~workerが~importした~classic~scriptを~fetchする@ ときは、所与の ( %~url, %設定群~obj ) に対し，次を走らす — この~algoは、同期的に完了し，例外を投出する（失敗~時）か, 新たな`~classic~script$を返す（成功~時）： ◎ To fetch a classic worker-imported script given a url and a settings object, run these steps. The algorithm will synchronously complete with a classic script on success, or throw an exception on failure.

1. %要請 ~LET 次のようにされた新たな`要請$ ⇒＃ `~url$rq ~SET %~url, `~client$rq ~SET %設定群~obj, `行先$rq ~SET `script^l, `構文解析器~metadata$rq ~SET `not-parser-inserted^l, `同期~flag$rq ~SET ~ON, `~URL資格証~利用~flag$rq ~SET ~ON ◎ Let request be a new request whose url is url, client is settings object, destination is "script", parser metadata is "not parser-inserted", synchronous flag is set, and whose use-URL-credentials flag is set.

2. ~IF［ この~algoの~call元にて，`~fetchを遂行する$ ~custom手続き %手続き が指定されている ］ ⇒ %応答 ~LET %手続き を遂行する( %要請, `~top-level内$i ) ◎ If the caller specified custom steps to perform the fetch, perform them on request, with the is top-level flag set. Let response be the result.

   ~ELSE ⇒ %応答 ~LET %要請 を`~fetch$した結果 ◎ Otherwise, fetch request, and let response be the result.

   注記： この節の他の~algoと違って，ここでの~fetchingは同期的に行われる。 したがって、ここで`~fetchを遂行する$どの手続きも，その仕事を同期的に終えることになる。 ◎ Unlike other algorithms in this section, the fetching process is synchronous here. Thus any perform the fetch steps will also finish their work synchronously.

3. %応答 ~LET %応答 の`非安全~応答$ ◎ Let response be response's unsafe response.
4. ~IF［ %応答 の`種別$rs ~EQ `error^l ］~OR［ %応答 の`~status$rs ~NIN { `~ok~status$rs } ］ ⇒ ~THROW `NetworkError$E ◎ If response's type is "error", or response's status is not an ok status, throw a "NetworkError" DOMException.
5. %~source~text ~LET `~UTF-8復号する$( %応答 の`本体$rs ) ◎ Let source text be the result of UTF-8 decoding response's body.
6. %~errorは黙秘する ~LET ［ %応答 は`~CORS非同一生成元$であるならば ~T ／ ~ELSE_ ~F ］ ◎ Let muted errors be true if response was CORS-cross-origin, and false otherwise.
7. %~script ~LET `~classic~scriptを作成する$( %~source~text, %設定群~obj, %応答 の`~url$rs, `既定の~classic~script~fetch~options$, %~errorは黙秘する ) ◎ Let script be the result of creating a classic script given source text, settings object, response's url, the default classic script fetch options, and muted errors.
8. ~RET %~script ◎ Return script.

`~module~script~graphを~fetchする@ ときは、所与の ( %~url, %設定群~obj, %行先, %~options ) に対し，次を走らす — この~algoは、［ ~NULL （失敗~時） ／ `~module~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To fetch a module script graph given a url, a settings object, a destination, and some options, run these steps. The algorithm will asynchronously complete with either null (on failure) or a module script (on success).

1. %訪問-済み集合 ~LET « %~url » ◎ Let visited set be « url ».
2. 次を与える下で，`~module~script~graphを~fetchする内部手続き$を遂行する ⇒＃ %~url, %設定群~obj, %行先, %~options, %設定群~obj, %訪問-済み集合, `client^l, `~top-level~module~fetch^i ◎終 — この~algoの~call元にて`~fetchを遂行する$ ~custom手続きが指定されている場合、それも渡す。 ◎ Perform the internal module script graph fetching procedure given url, settings object, destination, options, settings object, visited set, "client", and with the top-level module fetch flag set. If the caller of this algorithm specified custom perform the fetch steps, pass those along as well.
3. `~module~script~graphを~fetchする内部手続き$が %結果 を結果として`非同期に完了-$した時点で，この~algoも %結果 を結果として`非同期に完了-$する ◎ When the internal module script graph fetching procedure asynchronously completes with result, asynchronously complete this algorithm with result.

`~worker用~module~script~graphを~fetchする@ ときは、所与の ⇒＃ %~url, %~fetch~client設定群~obj, %行先, %資格証~mode, %~module~map設定群~obj ◎終 に対し，次を走らす — この~algoは、［ ~NULL （失敗~時） ／ `~module~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To fetch a module worker script graph given a url, a fetch client settings object, a destination, a credentials mode, and a module map settings object, run these steps. The algorithm will asynchronously complete with either null (on failure) or a module script (on success).

1. %訪問-済み集合 ~LET « %~url » ◎ Let visited set be « url ».
2. %~options ~LET 次のようにされた`~script~fetch~options$ ⇒＃ `暗号用~nonce$sfO ~SET 空~文字列, `完全性~metadata$sfO ~SET 空~文字列, `構文解析器~metadata$sfO ~SET `not-parser-inserted^l, `資格証~mode$sfO ~SET %資格証~mode, `~referrer施策$sfO ~SET 空~文字列 ◎ 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 credentials mode, and referrer policy is the empty string.
3. 次を与える下で，`~module~script~graphを~fetchする内部手続き$を遂行する ⇒＃ %~url, %~fetch~client設定群~obj, %行先, %~options, %~module~map設定群~obj %訪問-済み集合, `client^l, `~top-level~module~fetch^i ◎終 — この~algoの~call元にて`~fetchを遂行する$ ~custom手続きが指定されている場合、それも渡す。 ◎ Perform the internal module script graph fetching procedure given url, fetch client settings object, destination, options, module map settings object, visited set, "client", and with the top-level module fetch flag set. If the caller of this algorithm specified custom perform the fetch steps, pass those along as well.
4. `~module~script~graphを~fetchする内部手続き$が %結果 を結果として`非同期に完了-$した時点で，この~algoも %結果 を結果として`非同期に完了-$する ◎ When the internal module script graph fetching procedure asynchronously completes with result, asynchronously complete this algorithm with result.

以下の各種~algoは、［ `~module~script~graphを~fetchする$／ `~scriptを準備-$する ］の一部を成すものとして，この仕様の内部~利用のみに~~意図されている。 他の仕様は、これらを直に利用するべきではない。 ◎ The following algorithms are meant for internal use by this specification only as part of fetching a module script graph or preparing a script, and should not be used directly by other specifications.

`~module~script~graphを~fetchする内部手続き@ を遂行するときは、所与の ⇒＃ %~url, %~fetch~client設定群~obj, %行先, %~options, %~module~map設定群~obj, %訪問-済み集合, %~referrer, %~top-level~module~fetch~flag ~IN { `~top-level~module~fetch^i, ε }（省略時は ε ） ◎終 に対し，次の手続きを遂行する。 この~algoは、［ ~NULL （失敗~時） ／ `~module~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To perform the internal module script graph fetching procedure given a url, a fetch client settings object, a destination, some options, a module map settings object, a visited set, a referrer, and a top-level module fetch flag, perform these steps. The algorithm will asynchronously complete with either null (on failure) or a module script (on success).

1. ~Assert： %~url ~IN %訪問-済み集合 ◎ Assert: visited set contains url.

2. 次を与える下で，`単独の~module~scriptを~fetchする$ ⇒＃ %~url, %~fetch~client設定群~obj, %行先, %~options, %~module~map設定群~obj, %~referrer, %~top-level~module~fetch~flag ◎終 — この~algoの~call元にて`~fetchを遂行する$ ~custom手続きが指定されている場合、それも渡す。 ◎ Fetch a single module script given url, fetch client settings object, destination, options, module map settings object, referrer, and the top-level module fetch flag. If the caller of this algorithm specified custom perform the fetch steps, pass those along while fetching a single module script.

3. ~RET — 前~段の~fetchが %結果 を結果として`非同期に完了-$したときは、以下を走らす： ◎ Return from this algorithm, and run the following steps when fetching a single module script asynchronously completes with result:

   1. ~IF［ %結果 ~EQ ~NULL ］ ⇒ ~NULL を結果として，`非同期に完了-$する ◎ If result is null, asynchronously complete this algorithm with null, and abort these steps.
   2. ~IF［ %~top-level~module~fetch~flag ~NEQ ε ］ ⇒ %結果 の`子孫を~fetchして~instance化する$( %~fetch~client設定群~obj, %行先, %訪問-済み集合 ) ◎ If the top-level module fetch flag is set, fetch the descendants of and instantiate result given fetch client settings object, destination, and visited set.＼
   3. ~ELSE ⇒ %結果 の`子孫を~fetchする$( %~fetch~client設定群~obj, %行先, %訪問-済み集合 ) ◎ Otherwise, fetch the descendants of result given the same arguments.
   4. ［ 前~段／前~前~段 ］の~algoが %最終~結果 を結果として，`非同期に完了-$したときは ⇒ %最終~結果 を結果として，`非同期に完了-$する ◎ When the appropriate algorithm asynchronously completes with final result, asynchronously complete this algorithm with final result.

`単独の~module~scriptを~fetchする@ ときは、所与の ⇒＃ %~url, %~fetch~client設定群~obj, %行先, %~options, %~module~map設定群~obj, %~referrer, %~top-level~module~fetch~flag ◎終 に対し，次を走らす — この~algoは、［ ~NULL （失敗~時） ／ `~module~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To fetch a single module script, given a url, a fetch client settings object, a destination, some options, a module map settings object, a referrer, and a top-level module fetch flag, run these steps. The algorithm will asynchronously complete with either null (on failure) or a module script (on success).

1. %~module~map ~LET %~module~map設定群~obj の`~module~map$enV ◎ Let moduleMap be module map settings object's module map.
2. ~IF［ %~module~map[ %~url ] ~EQ `fetching^l ］ ⇒ %~module~map[ %~url ] が変化するまで，この段で`並列的$に待機した上で、`~network用~task源$を用いて，この手続きの以降の部分を続行する`~taskを~queueする$ ◎ If moduleMap[url] 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 ε ］ ⇒ %~module~map[ %~url ] を結果として，`非同期に完了-$する ◎ If moduleMap[url] exists, asynchronously complete this algorithm with moduleMap[url], and abort these steps.
4. %~module~map[ %~url ] `~SET$ `fetching^l ◎ Set moduleMap[url] to "fetching".
5. %要請 ~LET 次のようにされた新たな`要請$ ⇒＃ `~url$rq ~SET %~url, `行先$rq ~SET %行先, `~mode$rq ~SET `cors^l, `~referrer$rq ~SET %~referrer, `~client$rq ~SET %~fetch~client設定群~obj ◎ Let request be a new request whose url is url, destination is destination, mode is "cors", referrer is referrer, and client is fetch client settings object.
6. `~module~script要請を設定しておく$( %要請, %~options ) ◎ Set up the module script request given request and options.

7. ~IF［ この~algoの~call元にて，`~fetchを遂行する$ ~custom手続き %手続き が指定されている ］：

   1. %~top-level内~flag ~LET %~top-level~module~fetch~flag に応じて ⇒ ε ならば ε ／ ~ELSE_ `~top-level内$i
   2. %手続き を遂行する( %要請, %~top-level内~flag )
   3. ~RET — ただし，以降の手続きは、 %手続き を完了した結果の`応答$ %応答 に対し走らす

   ◎ If the caller specified custom steps to perform the fetch, perform them on request, setting the is top-level flag if the top-level module fetch flag is set. Return from this algorithm, and when the custom perform the fetch steps complete with response response, run the remaining steps.

   ~ELSE：

   1. %要請 を`~fetch$する
   2. ~RET — ただし，以降の手続きは、［ ~fetchした結果の`応答$ %応答 に対し`応答を処理する$ ］一部として走らす

   ◎ Otherwise, fetch request. Return from this algorithm, and run the remaining steps as part of the fetch's process response for the response response.

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

8. ~IF［ 次のいずれかが満たされる ］…： ◎ If any of the following conditions are met, set moduleMap[url] to null, asynchronously complete this algorithm with null, and abort these steps:

   • %応答 の`種別$rs ~EQ `error^l ◎ response's type is "error"
   • %応答 の`~status$rsは`~ok~status$rsでない ◎ response's status is not an ok status
   • 次の結果は`~JS~MIME型$でない ⇒ `~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ The result of extracting a MIME type from response's header list is not a JavaScript MIME type

   …ならば ⇒＃ %~module~map[ %~url ] `~SET$ ~NULL； ~NULL を結果として，`非同期に完了-$する ◎ ↑

   注記： 歴史的~理由から、`~classic~scriptを~fetchする$ときは，~MIME型は検査されない。 対照的に，~module~scriptは、正しい~MIME型でなければ，読込みに失敗することになる。 ◎ For historical reasons, fetching a classic script does not include MIME type checking. In contrast, module scripts will fail to load if they are not of a correct MIME type.

9. %~source~text ~LET `~UTF-8復号する$( %応答 の`本体$rs ) ◎ Let source text be the result of UTF-8 decoding response's body.
10. %~module~script ~LET `~module~scriptを作成する$( %~source~text, %~module~map設定群~obj, %応答 の`~url$rs, %~options ) ◎ Let module script be the result of creating a module script given source text, module map settings object, response's url, and options.

11. %~module~map[ %~url ] `~SET$ %~module~script；
    %~module~script を結果として，`非同期に完了-$する ◎ Set moduleMap[url] to module script, and asynchronously complete this algorithm with module script.

    注記： `~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.

`~module~script$ %~module~script の `子孫を~fetchする@ ときは、所与の ( %~fetch~client設定群~obj, %行先, %訪問-済み集合 ) に対し，次を走らす — この~algoは、［ ~NULL （失敗~時） ／ `~module~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To fetch the descendants of a module script module script, given a fetch client settings object, a destination, and a visited set, run these steps. The algorithm will asynchronously complete with either null (on failure) or with module script (on success).

1. %~record ~LET %~module~script の`~record$sC ◎ ↓
2. ~IF［ %~record ~EQ ~NULL ］ ⇒ %~module~script を結果として，`非同期に完了-$する ◎ If module script's record is null, then asynchronously complete this algorithm with module script and abort these steps. ◎ Let record be module script's record.
3. ~IF［ %~record . `RequestedModules^sl は`空$である ］ ⇒ %~module~script を結果として，`非同期に完了-$する ◎ If record.[[RequestedModules]] is empty, asynchronously complete this algorithm with module script.
4. %~url~list ~LET 新たな空`~list$ ◎ Let urls be a new empty list.

5. %~record . `RequestedModules^sl 内の `~EACH$( 文字列 %要請された何か ) に対し： ◎ For each string requested of record.[[RequestedModules]],

   1. %~url ~LET `~module指定子を解決する$( %~module~script の`基底~URL$sC, %要請された何か ) ◎ Let url be the result of resolving a module specifier given module script's base URL and requested.
   2. ~Assert： %~url ~NEQ `失敗^i — 以前にも、同じ引数で，`~module指定子を解決する$のに成功している。 ◎ Assert: url is never failure, because resolving a module specifier must have been previously successful with these same two arguments.

   3. ~IF［ %~url ~NIN %訪問-済み集合 ］： ◎ If visited set does not contain url, then:

      1. %~url~list に %~url を`付加する$ ◎ Append url to urls.
      2. %訪問-済み集合 に %~url を`付加する$set ◎ Append url to visited set.
6. %~options ~LET `子孫~script~fetch~options$( %~module~script の`~fetch~options$sC ) ◎ Let options be the descendant script fetch options for module script's fetch options.

7. %~url~list 内の `~EACH$( %~url ) に対し ⇒ 次を与える下で，`~module~script~graphを~fetchする内部手続き$を遂行する ⇒＃ %~url, %~fetch~client設定群~obj, %行先, %~options, %~module~script の`設定群~obj$sC, %訪問-済み集合, %~module~script の`基底~URL$sC, ε ◎終 — この~algoの~call元にて`~fetchを遂行する$ ~custom手続きが指定されている場合、それも渡す。 ◎ For each url in urls, perform the internal module script graph fetching procedure given url, fetch client settings object, destination, options, module script's settings object, visited set, module script's base URL, and with the top-level module fetch flag unset. If the caller of this algorithm specified custom perform the fetch steps, pass those along while performing the internal module script graph fetching procedure.

   これらの`~module~script~graphを~fetchする内部手続き$の呼出は、互いに並列的に遂行されるべきである — そうするかどうかに関わらず： ◎ These invocations of the internal module script graph fetching procedure should be performed in parallel to each other.

   1. ~IF［ ある呼出が ~NULL を結果として`非同期に完了-$した ］ ⇒ ~NULL を結果として，`非同期に完了-$する ◎ If any of the invocations of the internal module script graph fetching procedure asynchronously complete with null, asynchronously complete this algorithm with null, aborting these steps.
   2. ~ELSE — したがって［ すべての呼出が `非同期に完了-$する ］まで待機した上で ⇒ %~module~script を結果として，`非同期に完了-$する ◎ Otherwise, wait until all of the internal module script graph fetching procedure invocations have asynchronously completed. Asynchronously complete this algorithm with module script.

`~module~script$ %~module~script の `子孫を~fetchして~instance化する@ ときは、所与の ( %~fetch~client設定群~obj, %行先, %訪問-済み集合 （省略時は空`集合$） ) に対し，次を走らす — この~algoは、［ ~NULL （失敗~時） ／ `~module~script$（成功~時） ］を結果として，`非同期に完了-$する： ◎ To fetch the descendants of and instantiate a module script module script, given a fetch client settings object, a destination, and an optional visited set, run these steps. The algorithm will asynchronously complete with either null (on failure) or with module script (on success). • If visited set was not given, let it be an empty set.

1. %~module~script の`子孫を~fetchする$( %~fetch~client設定群~obj, %行先, %訪問-済み集合 ) ◎ Fetch the descendants of module script, given fetch client settings object, destination, and visited set.
2. ~RET — ただし、［ 前~段の`子孫を~fetchする$ ］が， %結果 を結果として `非同期に完了-$したときには、以下を走らす： ◎ Return from this algorithm, and run the following steps when fetching the descendants of a module script asynchronously completes with result.

3. ~IF［ %結果 ~EQ ~NULL ］ ⇒ %結果 を結果として，`非同期に完了-$する ◎ If result is null, then asynchronously complete this algorithm with result.

   注記： この事例では， 1 個~以上の子孫において、~fetchingに~errorが生じている。 よって、~instance化しようとは試みない。 ◎ In this case, there was an error fetching one or more of the descendants. We will not attempt to instantiate.

4. %構文解析-~error ~LET `最初の~errorを見出す$( %結果 ) ◎ Let parse error be the result of finding the first parse error given result.

5. ~IF［ %構文解析-~error ~EQ ~NULL ］： ◎ If parse error is null, then:

   1. ( %結果 の`~record$sC ) . `Instantiate$jA() を遂行する ◎ Let record be result's record. ◎ Perform record.Instantiate().

      注記： この段は、当の~moduleの~instance化されていない依存物すべてに対し， `Instantiate$jA を再帰的に~callすることになる。 ◎ This step will recursively call Instantiate on all of the module's uninstantiated dependencies.

      この段で例外 %E が投出されたときは ⇒ %結果 の`再投出-用~error$sC ~SET %E ◎ If this throws an exception, set result's error to rethrow to that exception.

6. ~ELSE ⇒ %結果 の`再投出-用~error$sC ~SET %構文解析-~error ◎ Otherwise, set result's error to rethrow to parse error.
7. %結果 を結果として，`非同期に完了-$する ◎ Asynchronously complete this algorithm with result.

`最初の~errorを見出す@ ときは、所与の ( 根 %~module~script, %発見-済み集合 （省略時は新たな`集合$） ) に対し，次を走らす： ◎ To find the first parse error given a root moduleScript and an optional discoveredSet:

1. %~module~map ~LET %~module~script の`設定群~obj$sCの`~module~map$enV ◎ Let moduleMap be moduleScript's settings object's module map. ◎ If discoveredSet was not given, let it be an empty set.
2. %発見-済み集合 に %~module~script を`付加する$set ◎ Append moduleScript to discoveredSet.
3. ~IF［ %~module~script の`~record$sC ~EQ ~NULL ］ ⇒ ~RET %~module~script の`構文解析-~error$sC ◎ If moduleScript's record is null, then return moduleScript's parse error.
4. %子~指定子~list ~LET ( %~module~script の`~record$sC ) . `RequestedModules^sl ◎ Let childSpecifiers be the value of moduleScript's record's [[RequestedModules]] internal slot.
5. %子~URL~list ~LET 新たな`~list$ ◎ Let childURLs be the list＼

6. %子~指定子~list 内の~EACH( %~item ) に対し ⇒ %子~URL~list に次の結果を`付加する$ ⇒ `~module指定子を解決する$( %~module~script の`基底~URL$sC, %~item )

   注記： どの %~item に対しても，この結果が `失敗^i になることはない — さもなければ， %~module~script 自身が構文解析-~errorとされている筈なので。

   ◎ obtained by calling resolve a module specifier once for each item of childSpecifiers, given moduleScript's base URL and that item. (None of these will ever fail, as otherwise moduleScript would have been marked as itself having a parse error.)
7. %子~module~list ~LET 新たな`~list$ ◎ Let childModules be the list＼
8. %子~URL~list 内の~EACH( %~item ) に対し ⇒ %子~module~list に %~module~map[ %~item ] を`付加する$ ◎ obtained by getting each value in moduleMap whose key is given by an item of childURLs.

9. %子~module~list 内の`~EACH$( %子~module ) に対し： ◎ For each childModule of childModules:

   1. ~Assert： %子~module は`~module~script$である （すなわち、 %子~module ~NIN { `fetching^l, ~NULL } ） — この時点までに、［ ~graph内の， %~module~script を根とする すべての`~module~script$ ］に対する~fetchは，成功したことになる。 ◎ Assert: childModule is a module script (i.e., it is not "fetching" or null); by now all module scripts in the graph rooted at moduleScript will have successfully been fetched.
   2. ~IF［ %子~module ~IN %発見-済み集合 ］ ⇒ ~CONTINUE ◎ If discoveredSet already contains childModule, continue.
   3. %子~構文解析-~error ~LET `最初の~errorを見出す$( %子~module, %発見-済み集合 ) ◎ Let childParseError be the result of finding the first parse error given childModule and discoveredSet.
   4. ~IF［ %子~構文解析-~error ~NEQ ~NULL ］ ⇒ ~RET %子~構文解析-~error ◎ If childParseError is not null, return childParseError.
10. ~RET ~NULL ◎ Return null.

8.1.3.3. ~scriptの作成-法

`~classic~scriptを作成する@ ときは、所与の ⇒＃ `~JS文字列$ %~source, `環境~設定群~obj$ %設定群, `~URL$ %基底~URL, `~script~fetch~options$ %~options, 真偽値 %~errorは黙秘する （省略時は ~F ） ◎終 に対し，次を走らす： ◎ To create a classic script, given a JavaScript string source, an environment settings object settings, a URL baseURL, some script fetch options options, and an optional muted errors boolean: • If muted errors was not provided, let it be false.

1. ~IF［ %設定群 の`担当の閲覧文脈$enVにおいて `~scriptingは不能化されて$いる ］ ⇒ %~source ~SET 空~文字列 ◎ If scripting is disabled for settings's responsible browsing context, then set source to the empty string.
2. %~script ~LET 新たな`~classic~script$ ◎ Let script be a new classic script that this algorithm will subsequently initialize.
3. %~script の ⇒＃ `設定群~obj$sC ~SET %設定群, `基底~URL$sC ~SET %基底~URL, `~fetch~options$sC ~SET %~options `~errorは黙秘する$sC ~SET %~errorは黙秘する, `構文解析-~error$sC ~SET ~NULL, `再投出-用~error$sC ~SET ~NULL ◎ 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 muted errors. ◎ Set script's parse error and error to rethrow to null.

4. %結果 ~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.

5. ~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.
6. %~script の`~record$sC ~SET %結果 ◎ Set script's record to result.
7. ~RET %~script ◎ Return script.

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

1. ~IF［ %設定群 の`担当の閲覧文脈$enVにおいて `~scriptingは不能化されて$いる ］ ⇒ %~source ~SET 空~文字列 ◎ If scripting is disabled for settings's responsible browsing context, then set source to the empty string.
2. %~script ~LET 新たな`~module~script$ ◎ Let script be a new module script that this algorithm will subsequently initialize.
3. %~script の ⇒＃ `設定群~obj$sC ~SET %設定群, `基底~URL$sC ~SET %基底~URL, `~fetch~options$sC ~SET %~options `構文解析-~error$sC ~SET ~NULL, `再投出-用~error$sC ~SET ~NULL ◎ 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.

4. %結果 ~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.

5. ~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.

6. %結果 . `RequestedModules^sl 内の ~EACH( 文字列 %要請された何か ) に対し： ◎ For each string requested of result.[[RequestedModules]]:

   1. %~url ~LET `~module指定子を解決する$( %~script の`基底~URL$sC, %要請された何か ) ◎ Let url be the result of resolving a module specifier given script's base URL and requested.

   2. ~IF［ %~url ~EQ `失敗^i ］： ◎ If url is failure, then:

      1. %~error ~LET 新たな `TypeError$js 例外 ◎ Let error be a new TypeError exception.
      2. %~script の`構文解析-~error$sC ~SET %~error ◎ Set script's parse error to error.
      3. ~RET %~script ◎ Return script.

   注記： この段は、本質的に，要請された~module指定子すべてを検証する。 解決-不能な~module指定子は，構文解析できなかったのと同じに扱い、後で~moduleを~instance化するような考えは排される。 ◎ This step is essentially validating all of the requested module specifiers. We treat a module with unresolvable module specifiers the same as one that cannot be parsed; in both cases, a syntactic issue makes it impossible to ever contemplate instantiating the module later.

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

8.1.3.4. ~scriptの~call法

`~classic~scriptを走らす@ ときは、所与の ( `~classic~script$ %~script, 真偽値 %~errorは再投出する （省略時は ~F ） ) に対し，次を走らす： ◎ To run a classic script given a classic script script and an optional rethrow errors boolean: • If rethrow errors is not given, let it be false.

1. %設定群 ~LET %~script の`設定群~obj$sC ◎ Let settings be the settings object of script.
2. ~IF［ `~scriptは走れるかどうか検査する$( %設定群 ) ~EQ `走るな^i ］ ⇒ ~RET ◎ Check if we can run script with settings. If this returns "do not run" then return.
3. `~scriptを走らすために準備する$( %設定群 ) ◎ Prepare to run script given settings.
4. %評価~status ~LET ~NULL ◎ Let evaluationStatus be null.
5. ~IF［ %~script の`再投出-用~error$sC ~NEQ ~NULL ］ ⇒ %評価~status ~SET `Completion^js{ `Type^sl: `throw^js, `Value^sl: %~script の`再投出-用~error$sC, `Target^sl: `empty^js } ◎ If script's error to rethrow is not null, then set evaluationStatus to Completion { [[Type]]: throw, [[Value]]: script's error to rethrow, [[Target]]: empty }.

6. ~ELSE：

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

      ~IF［ ~UAは`走っている~scriptを中止-$したため， `ScriptEvaluation$jA は完了しなかった ］：

      1. `走らせた~scriptを片付ける$( %設定群 )
      2. ~RET `undefined^jv
   ◎ 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.

7. ~IF［ %評価~status は`中途完了$である ］： ◎ If evaluationStatus is an abrupt completion, then:

   1. ~IF［ %~errorは再投出する ~EQ ~T ］：

      1. `走らせた~scriptを片付ける$( %設定群 )
      2. ~THROW ［ %~script の`~errorは黙秘する$sC ］に応じて ⇒ ~T ならば `NetworkError$E ／ ~F ならば %評価~status . `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. `例外を報告する$( %~script, %評価~status . `Value^sl ) ◎ Report the exception given by evaluationStatus.[[Value]] for script.
      2. `走らせた~scriptを片付ける$( %設定群 ) ◎ Clean up after running script with settings.
      3. ~RET `undefined^jv ◎ Return undefined.

8. ~ELSE（ %評価~status は正常完了である）：

   1. `走らせた~scriptを片付ける$( %設定群 )
   2. ~RET %評価~status . `Value^sl

   注記： 返される値は、 `javascript$sc ~URL手続き以外からは利用されない。

   ◎ Clean up after running script with settings. ◎ If evaluationStatus is a normal completion, return evaluationStatus.[[Value]]. ◎ This value is only ever used by the javascript: URL steps. ◎ If we've reached this point, evaluationStatus was left as null because the script was aborted prematurely during evaluation. Return undefined.

`~module~scriptを走らす@ ときは、所与の ( `~module~script$ %~script, 真偽値 %~errorは再投出する （省略時は ~F ） ) に対し，次を走らす： ◎ To run a module script given a module script script, with an optional rethrow errors boolean: • If rethrow errors is not given, let it be false.

1. %設定群 ~LET %~script の`設定群~obj$sC ◎ Let settings be the settings object of script.
2. ~IF［ `~scriptは走れるかどうか検査する$( %設定群 ) ~EQ `走るな^i ］ ⇒ ~RET ◎ Check if we can run script with settings. If this returns "do not run" then return.
3. `~scriptを走らすために準備する$( %設定群 ) ◎ Prepare to run script given settings.
4. %評価~status ~LET ~NULL ◎ Let evaluationStatus be null.
5. ~IF［ %~script の`再投出-用~error$sC ~NEQ ~NULL ］ ⇒ %評価~status ~SET `Completion^js{ `Type^sl: `throw^js, `Value^sl: %~script の`再投出-用~error$sC, `Target^sl: `empty^js } ◎ If script's error to rethrow is not null, then set evaluationStatus to Completion { [[Type]]: throw, [[Value]]: script's error to rethrow, [[Target]]: empty }.

6. ~ELSE： ◎ Otherwise:

   1. %~record ~LET %~script の`~record$sC ◎ Let record be script's record.

   2. %評価~status ~SET %~record . `Evaluate$jA() ◎ Set evaluationStatus to record.Evaluate().

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

      ~IF［ ~UAが`走っている~scriptを中止-$したため， `Evaluate$jA は完了しなかった ］ ⇒ %評価~status ~SET `Completion^js{ `Type^sl: `throw^js, `Value^sl: 新たな `QuotaExceededError$E 例外, `Target^sl: `empty^js } ◎ If Evaluate fails to complete as a result of the user agent aborting the running script, then set evaluationStatus to Completion { [[Type]]: throw, [[Value]]: a new "QuotaExceededError" DOMException, [[Target]]: empty }.

7. ~IF［ %評価~status は`中途完了$である ］： ◎ If evaluationStatus is an abrupt completion, then:

   1. ~IF［ %~errorは再投出する ~EQ ~T ］ ⇒ ~THROW %評価~status . `Value^sl ◎ If rethrow errors is true, rethrow the exception given by evaluationStatus.[[Value]].
   2. ~ELSE ⇒ `例外を報告する$( %~script, %評価~status . `Value^sl ) ◎ Otherwise, report the exception given by evaluationStatus.[[Value]] for script.
8. `走らせた~scriptを片付ける$( %設定群 ) ◎ Clean up after running script with settings.

`~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［ %設定群 により指定される`担当の閲覧文脈$enVにおいて `~scriptingは不能化されて$いる ］ ⇒ ~RET `走るな^i ◎ If scripting is disabled for the responsible browsing context specified by 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.

`走らせた~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$e である。 ◎ The running script is the script in the [[HostDefined]] field in the ScriptOrModule component of the running JavaScript execution context.

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

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

注記： この仕様では、すべての`~JS~realm$は，［［ `Window$I, `WorkerGlobalScope$I ］いずれかの~objである`大域~obj$ ］で＊`作成-$rMされる。 ◎ In this specification, all JavaScript realms are created with global objects that are either Window or WorkerGlobalScope objects.

［ `~JS~realm$ %~Realm, `大域~obj$ %G, `環境~設定群~obj$ %設定群 ］は、常に，互いに 1:1:1 に対応する： ◎ There is always a 1-to-1-to-1 mapping between JavaScript realms, global objects, and environment settings objects:

• %~Realm 視点からは：

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

• %G 視点からは：

  • %G は， %~Realm が＊`作成-$rMされる間に作成される。 %~Realm を指して %G の `~Realm@gL という。
  • %G は， %設定群 と並行して作成される。 %設定群 は %G に`関連する設定群~obj$と呼ばれる。
  ◎ Each global object in this specification is created during the creation of a corresponding JavaScript 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.

• %設定群 視点からは：

  • %設定群 の`~realm実行~文脈$enVの~Realm成分が， %~Realm を与える — %~Realm を指して %設定群 の `~Realm@enV という。
  • 対応する %G （すなわち， %設定群 の`~Realm$enVの `GlobalObject^sl ~field）を指して %設定群 の `大域~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.

`新たな~JS~realmを作成する@ ときは、次の手続きに従う： ◎ To create a new JavaScript realm, optionally with instructions to create a global object or a global this binding (or both), the following steps are taken:

1. この手続きには、次に挙げる指示書きも，それぞれ任意選択で供される ⇒＃ 大域~objを作成する ／ 利用する大域 `this^jv 束縛 ◎ ↑

   この指示書きにより~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. ~RET %~realm実行~文脈 ◎ Return realm execution context.

この仕様~全体を通して、~algoの手続きを定義するときに，どの`~JS~realm$が利用されるか — あるいは，同じことだが、どの`大域~obj$／`環境~設定群~obj$が利用されるか — を指示することが重要になることは、よくある。 一般に、少なくとも次の 4 種いずれかで指示される： ◎ When defining algorithm steps throughout this specification, it is often important to indicate what JavaScript 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 某）

これは、現在~走っている~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 某）

これは、作者による［ 関数／~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 某）

これは、現在~走っている関数~objに対応する。 これには、~JSとして実装されていないかもしれないような，~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 JavaScript realm.)

`某に関連する@ （ 某に relevant な）

どの`~platform~obj$にも`関連する~Realm$がある — それは概ね，その~objの作成-元である`~JS~realm$である。 ~algoを書くときに，［ `関連する~Realm$が重要になり得るような`~platform~obj$ ］として，真っ先に挙がるのは、現在~走っている関数~objの `this^jv 値になる。 一部の事例では、引数のそれなど，`関連する~Realm$が重要になるものが他にもあり得る。 ◎ Every platform object has a relevant Realm, which is roughly the JavaScript 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$に適用され~MUSTことに注意。 ◎ Note how the entry, incumbent, and current concepts are usable without qualification, whereas the relevant concept must be applied to a particular platform object.

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

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

<!--b.html -->
<!DOCTYPE html>
<html lang="ja">
<title>現任の頁</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>

`現任の某$, `入口~某$ の概念は、あまりに複雑で直感的でないので，新たな仕様には利用されるべきでない。 既存の利用は，~platformからほぼ除去すべく~~策定が進められている。 `現任の某$ については， issue #1430 を、`入口~某$ については， issue #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 構築子が属する`~JS~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 JavaScript 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.

構築子においては、 `this^jv 値がまだないので，`現在の某$ の概念が適切な既定になることに注意。 ◎ Note that in constructors, where there is no this value yet, the current concept is the appropriate default.

<!-- outer.html -->
<!DOCTYPE html>
<html lang="ja">
<title>関連する~Realmの例証： outer 頁</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 頁</title>
<script>
  function hello() {
    const %promise = navigator.getBattery();

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

この節の以降では、［ `入口~某$, `現任の某$, `現在の某$, `某に関連する$ ］の概念について，公式的に定義する。 ◎ The rest of this section deals with formally defining the entry, incumbent, current, and relevant concepts.

<!DOCTYPE html>
<iframe></iframe>
<script>
  new frames[0].MessageChannel();
</script>

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

<!-- 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>

8.1.3.6. ~scriptの強制終了

`走っている~scriptを中止-@ する必要が生じることはときどきある — ~JS仕様はその可能性について織込んでいないが。 これは、［ `ScriptEvaluation$jA ／ `Source Text Module Record$js の `Evaluate$jA ］の呼出があれば即時に止めた上で， `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がこれらの制限-を超過したときは、~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＼

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

~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を走せず，ただ頁~全体を閉じる仕組み ］を利用者に提供することもできる。 ◎ 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.3.7. ~JS~job~queueとの統合

~JS仕様は、［ ~cleanな 【手が加えられていない】 `~JS実行~文脈~stack$による~promise演算を，一定の順序でどう実行するか ］についての ある種の不変則を指定するために、［ ~JS~job, および ~job~queue ］の抽象化を定義している。 しかしながら，この仕様を書いている時点では、 ~JS仕様 `JAVASCRIPT$r の `EnqueueJob$jA の定義は，~HTMLを~host環境として統合できるほど十分に柔軟でない。 ◎ The JavaScript specification defines the JavaScript job and job queue abstractions in order to specify certain invariants about how promise operations execute with a clean JavaScript execution context stack and in a certain order. However, as of the time of this writing the definition of EnqueueJob in that specification is not sufficiently flexible to integrate with HTML as a host environment. [JAVASCRIPT]

注記： これは厳密には真でない。 事実、それらの~algoの多くの “実装により定義される” とされている各~節に与えられる自由度を利用して、この目的のために それをひねくりまわすことも可能ではある。 しかしながら、技術的には，実装により定義される挙動の範囲内として是認される仕方ではあっても、結局は，本質的に~job~queueの基盤をまるごと迂回するような，遠回しでとっ散らかった回避策であふれることになる。 ここでは、この道は採らない代わりに，以下の各~下位~節に与える`故意的な違反$を導入する。 ◎ This is not strictly true. It is in fact possible, by taking liberal advantage of the many "implementation defined" sections of the algorithm, to contort it to our purposes. However, the end result is a mass of messy indirection and workarounds that essentially bypasses the job queue infrastructure entirely, albeit in a way that is technically sanctioned within the bounds of implementation-defined behavior. We do not take this path, and instead introduce the following willful violation.

そのようなわけで、~UAは，~JS仕様~内のそれに代わって，以下に述べる定義を利用し~MUST。 これらは、~JS仕様により~enqueueされる~promise~jobが，~UAの`~event-loop$の中に適正に統合されることを確保する。 ◎ As such, user agents must instead use the following definition in place of that in the JavaScript specification. These ensure that the promise jobs enqueued by the JavaScript specification are properly integrated into the user agent's event loops.

~UAは、~JS仕様の `RunJobs$jA 抽象演算を利用しては~MUST_NOT。 ◎ The RunJobs abstract operation from the JavaScript specification must not be used by user agents.

8.1.3.8. ~JS~module~systemとの統合

~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” ］の用語を通して記されているが、この仕様は，一般に［ `~classic~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.

`~module~map$は、［ ~importされた~JS~moduleが［ ~fetchされ, 構文解析され, 評価される ］のは，［ `文書$／`~worker$ ］ごとに一度限りになる ］ことを確保するために利用される。 ◎ Module maps are used to ensure that imported JavaScript modules are only fetched, parsed, and evaluated once per Document or worker.

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

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";

`~module指定子を解決する@ 手続きは、所与の ( `~URL$ %基底~URL, `~JS文字列$ %指定子 ) に対し，次を走らす — これは［ `~URL~record$, `失敗^i ］のいずれかを返す： ◎ To resolve a module specifier given a URL base URL and a JavaScript string specifier, perform the following steps. It will return either a URL record or failure.

1. %~URL ~LET `~URL構文解析する$( %指定子 ) ◎ Apply the URL parser to specifier.＼
2. ~IF［ %~URL ~NEQ `失敗^i ］ ⇒ ~RET %~URL ◎ If the result is not failure, return the result.

3. ~IF［ %指定子 の頭部は［ `/^l, `./^l, `../^l ］のいずれにも一致しない（文字 `/^l は U+002F SOLIDUS, 文字 `.^l は U+002E FULL STOP ） ］ ⇒ ~RET `失敗^i ◎ If specifier does not start with the character U+002F SOLIDUS (/), the two-character sequence U+002E FULL STOP, U+002F SOLIDUS (./), or the three-character sequence U+002E FULL STOP, U+002E FULL STOP, U+002F SOLIDUS (../), return failure.

   注記： この制約は、将来に，“~~名前のみの” ~import指定子 — import `jquery^l や import `web/crypto^l の様な指定子 — に特別な意味を与えるような，~custom~module読込器を許容できるようにするためにある。 今の所は、そのような~importは，相対~URLとして扱われることなく失敗することになる。 ◎ This restriction is in place so that in the future we can allow custom module loaders to give special meaning to "bare" import specifiers, like import "jquery" or import "web/crypto". For now any such imports will fail, instead of being treated as relative URLs.

4. ~RET `~URL構文解析する$( %指定子, %基底~URL ) ◎ Return the result of applying the URL parser to specifier with script's base URL as the base URL.

8.1.3.8.3. `HostGetImportMetaProperties^jA( %moduleRecord )

import.meta 提案 `JSIMPORTMETA$r には、実装により定義される `HostGetImportMetaProperties$jA 抽象演算がある。 ~UAは、次の実装を利用し~MUST： ◎ The import.meta proposal contains an implementation-defined HostGetImportMetaProperties abstract operation. User agents must use the following implementation: [JSIMPORTMETA]

1. %~module~script ~LET %moduleRecord . `HostDefined^sl ◎ Let module script be moduleRecord.[[HostDefined]].
2. %~URL文字列 ~LET `~URLを直列化する$( %~module~script の`基底~URL$sC ) ◎ Let urlString be module script's base URL, serialized.
3. ~RET « `Record^js{ `Key^sl: `url^l, `Value^sl: %~URL文字列 } » ◎ Return « Record { [[Key]]: "url", [[Value]]: urlString } ».

8.1.3.9. ~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.

~JSは、`~agent$をより詳細に定義するものと期待されている — それは特に、`~Realm$gLの集合を保持する： tc39/ecma262 issue #882 ◎ JavaScript is expected to define agents in more detail; in particular that they hold a set of realms: tc39/ecma262 issue #882.

注記： `~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 need to run in a single execution thread.

この標準が存続期間についてより良く取扱えるときが来るまでは、~UAは，以下に定義する 5 種の型の`~agent$を適切な時点に割り当て~MUST。 ◎ Until such a time that this standard has a better handle on lifetimes, it defines five types of agents that user agents must allocate at the appropriate time.

注記： 将来には、［ `~agent$ ／ `~agent~cluster$ ］が正確にいつ作成されるか，この標準が定義するものと希望されている。 ◎ In the future, this standard hopes to define exactly when agents and agent clusters are created.

`生成元が類似する~window~agent@

次を満たすような`~agent$：

• `CanBlock^sl ~EQ ~F
• その`~realm$の集合は、ある`互いに関係するかつ生成元も類似する閲覧文脈~群$ %U に対し，次を満たす `Window$I ~objすべての`~Realm$gLからなる ⇒ ~objに`関連する設定群~obj$の`担当の閲覧文脈$enV ~IN %U

◎ An agent whose [[CanBlock]] is false and whose set of realms consists of all realms of Window objects whose relevant settings object's responsible browsing context is in the same unit of related similar-origin browsing contexts.

注記： 2 つの `Window$I ~objは、`同一生成元$であっても，それらが属する［ `生成元が類似する~window~agent$ ］は異なることもある — 具体例として、それぞれが自前の［ `互いに関係するかつ生成元も類似する閲覧文脈~群$ ］に属する場合。 ◎ Two Window objects that are same origin can be in different similar-origin window agents, for instance if they are each in their own unit of related similar-origin browsing contexts.

`専用~worker~agent@

次を満たすような`~agent$：

• `CanBlock^sl ~EQ ~T
• その`~realm$の集合は、ある `DedicatedWorkerGlobalScope$I ~objの`~Realm$gLのみからなる

◎ An agent whose [[CanBlock]] is true and whose set of realms consists of a single DedicatedWorkerGlobalScope object's Realm.

`共用~worker~agent@

次を満たすような`~agent$：

• `CanBlock^sl ~EQ ~T
• その`~realm$の集合は、ある `SharedWorkerGlobalScope$I ~objの`~Realm$gLのみからなる

◎ An agent whose [[CanBlock]] is true and whose set of realms consists a single SharedWorkerGlobalScope object's Realm.

`~service-worker~agent@

次を満たすような`~agent$：

• `CanBlock^sl ~EQ ~F
• その`~realm$の集合は、ある `ServiceWorkerGlobalScope$I ~objの`~Realm$gLのみからなる

◎ An agent whose [[CanBlock]] is false and whose set of realms consists of a single ServiceWorkerGlobalScope object's Realm.

`~worklet~agent@

次を満たすような`~agent$：

• `CanBlock^sl ~EQ ~F
• その`~realm$の集合は、ある `WorkletGlobalScope$I ~objの`~Realm$gLのみからなる

◎ An agent whose [[CanBlock]] is false and whose set of realms consists of a single WorkletGlobalScope object's Realm.

注記： 所与の~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.

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

~JSはまた、`~agent~cluster$の概念を定義する。 この標準は， `~memoryを共有できる@ と称される同値関係（詳細は下に与える）を利用して，それを~web~platformに対応付ける。 ~web~platform上では、`~agent~cluster$は，`~memoryを共有できる$同値関係の下で同じ同値類に属するすべての`~agent$からなる。 ◎ JavaScript also defines the concept of an agent cluster, which this standard maps to the web platform using the can share memory with equivalence relation detailed below. On the web platform, an agent cluster consists of all agents in the same equivalence class with respect to the can share memory with equivalence relation.

`~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で施行することにより、処理-~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$ %A, `~agent$ %B ) は、次をすべて満たすならば，`~memoryを共有できる$とされる：

  • %A は［ `生成元が類似する~window~agent$ ／ `専用~worker~agent$ ／ `共用~worker~agent$ ／ `~service-worker~agent$ ］である
  • %B は`専用~worker~agent$である
  • ［［ %B に属する（唯一の）`~realm$の`大域~obj$rM ］の`所有者~集合$ ］内に，次を満たす~itemがある ⇒ ~itemに`関連する~Realm$ ~IN %A

  ◎ A similar-origin window agent, dedicated worker agent, shared worker agent, or service worker agent, agent, can share memory with any dedicated worker agent whose single realm's global object's owner set contains an item whose relevant Realm belongs to agent.

  注記： ここでは、`所有者~集合$は `Document$I ~objを包含し得ることを利用している。 ◎ "Item" is used above as an owner set can contain Document objects.

  `~worklet~agent$は… 現在、~workletには明瞭に定義されている所有者がない — w3c/css-houdini-drafts issue #224 を見よ。 ◎ A worklet agent … currently worklets have no clearly defined owner, see: w3c/css-houdini-drafts issue #224.

• 次のいずれかを満たす ( `~agent$ %A, `~agent$ %B ) も、`~memoryを共有できる$とされる： ◎ In addition, any agent A can share memory with:

  • %A ~EQ %B ◎ A,
  • ( %B, %A ) は`~memoryを共有できる$ ◎ any agent B such that B can share memory with A, and
  • ある`~agent$ %C が存在して，［ ( %A, %C ) は`~memoryを共有できる$ ］~AND［ ( %C, %B ) は`~memoryを共有できる$ ］ ◎ any agent B such that there exists an agent C, where A can share memory with C and C can share memory with B.

  【 すなわち、最初に与えた関係から， 反射律, 対称律, 推移律 を満たすように拡張して得られる同値関係になる。 】

8.1.3.11. 実行時~script~error

1. ~IF［ %標的 は`~error報告~mode下$にある ］ ⇒ ~RET ◎ If target is in error reporting mode, then return; the error is not handled.
2. %標的 を `~error報告~mode下@ におく ◎ Let target be in error reporting mode.
3. %~message ~LET ~errorについて役立つ~~情報を述べるような，~UAにより定義される文字列 ~FINGERPRINTING ◎ Let message be a user-agent-defined string describing the error in a helpful manner. (This is a fingerprinting vector.)

4. %~error値 ~LET 次の様な，~errorを表現する~obj：

   • ~catchされなかった例外の事例では、投出された値になる。
   • ~JS~errorの事例では、 `Error$E ~objになる。
   • 対応する値がない場合、代わりに ~NULL値が利用され~MUST。
   ◎ Let errorValue be the value that represents the error: in the case of an uncaught exception, that would be the value that was thrown; in the case of a JavaScript error that would be an Error object. If there is no corresponding value, then the null value must be used instead.

5. %~url文字列 ~LET `~URLを直列化する$( %~script が得られた資源に対応する`~URL~record$ ) ◎ Let urlString be the result of applying the URL serializer to the URL record that corresponds to the resource from which script was obtained.

   注記： ~scriptを包含している資源は、概して，例えば［ ~inline `script$e 要素 ／ `~event~handler内容~属性$ ］に対しては，構文解析した`文書$の~fileになり、外部~scriptに対しては，それを含んでいる~JS~fileになる。 動的に生成される~scriptに対するときでも、~UAには，~scriptの元の~sourceを保ち続けるよう試みることが強く奨励される。 例えば、~HTMLの構文解析-時に，外部~scriptが `document.write()$m ~APIを利用して~inline `script$e 要素を挿入した場合、当の~scriptとして［ その~scriptを包含している資源の~URL ］が報告され，行番号として［ `document.write()$m ~callの所, あるいは その~callに渡された文字列が最初に構築された所 ］の行0が報告されるのが、理想的になる。 当然、これを実装するには，自明でない部分もある。 ◎ The resource containing the script will typically be the file from which the Document was parsed, e.g. for inline script elements or event handler content attributes; or the JavaScript file that the script was in, for external scripts. Even for dynamically-generated scripts, user agents are strongly encouraged to attempt to keep track of the original source of a script. For example, if an external script uses the document.write() API to insert an inline script element during parsing, the URL of the resource containing the script would ideally be reported as being the external script, and the line number might ideally be reported as the line with the document.write() call or where the string passed to that call was first constructed. Naturally, implementing this can be somewhat non-trivial.

   注記： 同様に，~UAには、文書が構文解析されるに伴い文書を変異させるような `document.write()$m ~callや，複数~行0にまたがっている`~event~handler内容~属性$に直面したとしても、元の行番号を保ち続けることが奨励される。 ◎ User agents are similarly encouraged to keep careful track of the original line numbers, even in the face of document.write() calls mutating the document as it is parsed, or event handler content attributes spanning multiple lines.

6. ~IF［ %~script の`~errorは黙秘する$sC ~EQ ~T ］ ⇒＃ %~message ~SET `Script error.^l, %~url文字列 ~SET 空~文字列, %行番号 ~SET 0, %列番号 ~SET 0, %~error値 ~SET ~NULL ◎ If script's muted errors is true, then set message to "Script error.", urlString to the empty string, line and col to 0, and errorValue to null.
7. %未取扱0 ~LET %標的 に向けて，名前 `error$et の`~eventを発火する$ — `ErrorEvent$I を利用し，次のように初期化して ⇒＃ `cancelable$m ~SET ~T, `message$m ~SET %~message, `filename$m ~SET %~url文字列, `lineno$m ~SET %行番号, `colno$m ~SET %列番号, `error$m ~SET %~error値 ◎ Let notHandled be the result of firing an event named error at target, using ErrorEvent, with the cancelable attribute initialized to true, the message attribute initialized to message, the filename attribute initialized to urlString, the lineno attribute initialized to line, the colno attribute initialized to col, and the error attribute initialized to errorValue.
8. %標的 を`~error報告~mode下$から外す ◎ Let target no longer be in error reporting mode.

9. ~errorの`取扱済み~flag$err ~SET［ %未取扱0 ~EQ ~F ならば ~ON ／ ~ELSE_ ~OFF ］ ◎ If notHandled is false, then the error is handled. Otherwise, the error is not handled.

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

[Constructor(DOMString type, optional `ErrorEventInit$I %eventInitDict),
 Exposed=(Window,Worker)]
interface `ErrorEvent@I : `Event$I {
  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 = null;
};

8.1.3.12. 未取扱いの~promise却下

同期的な`実行時~script~error$に加えて、~scriptは，非同期的な~promise却下に出くわすこともある — それは、［ `unhandledrejection$et, `rejectionhandled$et ］~eventを介して追跡される。 ◎ In addition to synchronous runtime script errors, scripts may experience asynchronous promise rejections, tracked via the unhandledrejection and rejectionhandled events.

`却下-済み~promiseについて通知する@ ときは、所与の ( `環境~設定群~obj$ %設定群~obj ) に対し，次を走らせ~MUST： ◎ When the user agent is to notify about rejected promises on a given environment settings object settings object, it must run these steps:

1. %~list ~LET %設定群~obj の`通知待ちの却下-済み~promise~list$enVの複製 ◎ Let list be a copy of settings object's about-to-be-notified rejected promises list.
2. ~IF［ %~list は空である ］ ⇒ ~RET ◎ If list is empty, return.
3. %設定群~obj の`通知待ちの却下-済み~promise~list$enVを~~空にする ◎ Clear settings object's about-to-be-notified rejected promises list.

4. 次の下位手続きを走らす`~taskを~queueする$： ◎ Queue a task to run the following substep:

   1. %~list 内の~EACH ( ~promise %p ) に対し： ◎ For each promise p in list:

      1. ~IF［ %p の `PromiseIsHandled^sl 内部~slot ~EQ ~T ］ ⇒ ~CONTINUE ◎ If p's [[PromiseIsHandled]] internal slot is true, continue to the next iteration of the loop.
      2. %未取扱0 ~LET %設定群~obj の`大域~obj$enVに向けて，名前 `unhandledrejection$et の`~eventを発火する$ — `PromiseRejectionEvent$I を利用し，次のように初期化して ⇒＃ `cancelable$m ~SET ~T, `promise$m ~SET %p, `reason$m ~SET %p の `PromiseResult^sl 内部~slotの値 ◎ Let notHandled be the result of firing an event named unhandledrejection at settings object's global object, using PromiseRejectionEvent, with the cancelable attribute initialized to true, the promise attribute initialized to p, and the reason attribute initialized to the value of p's [[PromiseResult]] internal slot.
      3. ~IF［ %未取扱0 ~EQ ~F ］ ⇒ この~promise却下の`取扱済み~flag$rej ~SET ~ON ◎ If notHandled is false, then the promise rejection is handled. Otherwise, the promise rejection is not handled.
      4. ~IF［ %p の `PromiseIsHandled^sl 内部~slot ~EQ ~F ］ ⇒ %設定群~obj の`未決の却下-済み~promiseへの弱い参照の集合$enVに %p を追加する ◎ If p's [[PromiseIsHandled]] internal slot is false, add p to settings object's outstanding rejected promises weak set.

この~algoは，~promise却下の `取扱済み~flag@rej を ~ON にし得る — 各~promise却下には，この~flagが結付けられ、初期~時は ~OFF にされる（すなわち，~promise却下は `取扱済みでない@rej ）。 これは、~script~errorに対する`取扱済み~flag$errと並行する概念である。 この~algoの結果、却下の`取扱済み~flag$rejが依然として ~OFF ならば、その却下は，~UAの開発者~consoleに報告されてよい。 ◎ This algorithm results in promise rejections being marked as handled or not handled. These concepts parallel handled and not handled script errors. If a rejection is still not handled after this, then the rejection may be reported to a developer console.

[Constructor(DOMString type, `PromiseRejectionEventInit$I %eventInitDict),
 Exposed=(Window,Worker)]
interface `PromiseRejectionEvent@I : `Event$I {
  readonly attribute Promise<any> `promise$m;
  readonly attribute any `reason$m;
};

dictionary `PromiseRejectionEventInit@I : `EventInit$I {
  required Promise<any> %promise;
  any %reason;
};

8.1.3.13. `HostEnsureCanCompileStrings^jA(%callerRealm, %calleeRealm)

~JS `JAVASCRIPT$r は、その抽象演算 `HostEnsureCanCompileStrings$jA( %callerRealm, %calleeRealm ) を，実装により定義されるものと~~規定している。 ~UAは、次の実装を利用し~MUST： ◎ JavaScript contains an implementation-defined HostEnsureCanCompileStrings(callerRealm, calleeRealm) abstract operation. User agents must use the following implementation: [JAVASCRIPT]

1. Perform ? `EnsureCSPDoesNotBlockStringCompilation$jA( %callerRealm, %calleeRealm) `CSP$r ◎ Perform ? EnsureCSPDoesNotBlockStringCompilation(callerRealm, calleeRealm). [CSP]

8.1.4.1. 各種~定義

~UAは、この節に述べる `~event-loop@ を利用して，［ ~event, 利用者対話, ~script, 描画, ~networking, 等々 ］を互いに協調させ~MUST。 ~event-loopには、次の 2 種類がある： ◎ To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as described in this section. There are two kinds of event loops:＼

注記： ［ `互いに関係する閲覧文脈~群$ ］ %U に対し，`~event-loop$が 2 個~以上あるとすると、［ %U 内のある［ `互いに関係するかつ生成元も類似する閲覧文脈~群$ ］から， %U 内の別の［ それ ］へ切替える ］ように`閲覧文脈$が`~navigate$されたときに、複雑問題が発生する。 この仕様は、現時点では，この複雑問題をどう取扱うかは述べていない。 ◎ When there is more than one event loop for a unit of related browsing contexts, complications arise when a browsing context in that group is navigated such that it switches from one unit of related similar-origin browsing contexts to another. This specification does not currently describe how to handle these complications.

`閲覧文脈~event-loop$は、常に， 1 個~以上の`閲覧文脈$に属する — そのような`閲覧文脈$すべてが消去ると同時に，`~event-loop$も消去る。 `閲覧文脈$には、常に，その活動に協調している`~event-loop$がある。 ◎ A browsing context event loop always has at least one browsing context. If such an event loop's browsing contexts all go away, then the event loop goes away as well. A browsing context always has an event loop coordinating its activities.

`~worker~event-loop$は，もっと単純で、各~workerごとに， 1 個の`~event-loop$がある。 `~worker処理~model$が、その`~event-loop$の存続期間を管理する。 ◎ Worker event loops are simpler: each worker has one event loop, and the worker processing model manages the event loop's lifetime.

`~event-loop$には、 1 個以上の `~task~queue@ がある。 各`~task~queue$は、何個かの `~task@ からなる有順序~listである。 それを成す各~taskは、次に挙げるような仕事を担当する~algoを与える： ◎ An event loop has one or more task queues. A task queue is an ordered list of tasks, which are algorithms that are responsible for such work as:

~event ◎ Events

特定0の `EventTarget$I ~objに向けて `Event$I ~objを`配送-$するときは、専用の~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$は、特定の`~event-loop$向けに意図される。 それは、［ `~task$に結付けられている［ `文書$ ／ `~worker$ ］用の`~task$ ］を取扱っている`~event-loop$である。 ◎ A task is intended for a specific event loop: the event loop that is handling tasks for the task's associated Document or worker.

~UAは， `~taskを~queueする@ ときは、所与の ( `~task$ %~task ) に対し，［ 関連する`~event-loop$に属する いずれかの`~task~queue$ ］に %~task を追加し~MUST。 ◎ When a user agent is to queue a task, it must add the given task to one of the task queues of the relevant event loop.

例えば~UAは、［ ~mouse／~key ］~eventに対しては， 1 個の`~task~queue$（ `利用者対話~task源$ ）をあてがい、他のすべてに対しては，別のものをあてがうこともできる。 その上で，~UAは、~UIを即応可能に保ちつつ, 他の~task~queueも放置しないよう，［ ~keyboard／~mouse ］~eventに時間の半分以上をあてがいつつ, 残りを他の~taskにあてがうこともできる — どの`~task源$においても，その中の各~eventは必ず順序通りに処理しつつ。 ◎ For example, a user agent could have one task queue for mouse and key events (the user interaction task source), and another for everything else. The user agent could then give keyboard and mouse events preference over other tasks three quarters of the time, keeping the interface responsive but not starving other task queues, and never processing events from any one task source out of order.

8.1.4.2. 処理~model

`~event-loop$ %~loop は、存在する限り，次の手続きを継続的に（反復的に）走らせ続け~MUST： ◎ An event loop must continually run through the following steps for as long as it exists:

1. %~task ~LET 次をすべて満たすように選ばれる`~task$：

   • %~task が属する`~task~queue$ %~queue は %~loop に属する
   • %~loop は`閲覧文脈~event-loop$であるならば、 %~task に結付けられている`文書$は`全部的に作動中$である。
   • %~task は、上述に該当する~taskのうち， %~queue 内で最も遠過去のものである — ~UAは %~queue としてどの`~task~queue$を選んでもよい。
   ◎ Let oldestTask be the oldest task on one of the event loop's task queues, if any, ignoring, in the case of a browsing context event loop, tasks whose associated Documents are not fully active. The user agent may pick any task queue.＼

2. ~IF［ 該当する %~task はある ］： ◎ If there is no task to select, then jump to the microtasks step below.

   1. %~loop の`現在~走っている~task$ ~SET %~task ◎ Set the event loop's currently running task to oldestTask.
   2. %~task を走らす ◎ Run oldestTask.
   3. %~loop の`現在~走っている~task$ ~SET ~NULL ◎ Set the event loop's currently running task back to null.
   4. %~task を %~queue から除去する ◎ Remove oldestTask from its task queue.
3. `小task~checkpointを遂行する$ ◎ Microtasks: Perform a microtask checkpoint.

4. ~IF［ %~loop は`閲覧文脈~event-loop$である ］ ⇒ 以下に従って `描画を更新する@： ◎ Update the rendering: If this event loop is a browsing context event loop (as opposed to a worker event loop), then run the following substeps.

   1. %now ~LET `現在の高分解能~時刻$ `HRT$r ◎ Let now be the current high resolution time. [HRT]

   2. %文書s ~LET %~loop に結付けられている`文書$たちの~list — それらの順序は、次の条件を満たさ~MUST（条件~以外は任意） ⇒ ~list内のどの 2 つの`文書$ %D1, %D2 に対しても： ◎ Let docs be the list of Document objects associated with the event loop in question, sorted arbitrarily except that the following conditions must be met:

      • %D2 が`属する閲覧文脈$は %D1 を`通して入子に$されているならば、 %D2 は %D1 より後になる。 ◎ Any Document B that is nested through a Document A must be listed after A in the list.
      • %D1, %D2 が`属する閲覧文脈$は，いずれも 同じある`文書$ %D 内の`閲覧文脈~容器$ %E1, %E2 （同順）を`通して入子に$されているならば、［ ~listにおける %D1, %D2 の順序 ］は，［ %D における`木~順序$による %E1, %E2 の順序 ］に合致する。 ◎ If there are two documents A and B whose browsing contexts are both nested browsing contexts and their browsing context containers are both elements in the same Document C, then the order of A and B in the list must match the relative tree order of their respective browsing context containers in C.

      以下において %文書s 内の ~EACH ( `文書$ ) にわたって反復する手続きでは、この順序で処理され~MUST。 ◎ In the steps below that iterate over docs, each Document must be processed in the order it is found in the list.

   3. %文書s 内の`文書$のうち，［ それが`属する閲覧文脈$ %B が，次のいずれかに該当するもの ］すべてを %文書s から除去する： ◎ ↓

      • %B の`~top-level閲覧文脈$は、この時点で描画を更新しても益はないと予見される。 ◎ If there are top-level browsing contexts B that the user agent believes would not benefit from having their rendering updated at this time, then remove from docs all Document objects whose browsing context's top-level browsing context is in B.

        注記： `~top-level閲覧文脈$の描画を更新しても益はないかどうかは、更新~頻度など，種々の要因に依存する。 例えば~browserは、更新率 60Hz を達成しようと試みている場合、この手続きは、毎 1/60 秒（およそ 16.7ms ）ごとのみに必要とされる。 ~browserは、`~top-level閲覧文脈$はこの更新率を維持できないときは，その`文書$の集合に対しては，~frameを時々落とすのではなく，より維持し易い 30Hz に落とすこともある。 （この仕様は、描画をいつ更新するかについて，特定0の~modelを何ら義務付けない。） 同様に、`~top-level閲覧文脈$が背後に~~回されている場合、~UAは，その頁をずっと遅い 4Hz あるいは，もっと落とすよう決めることもある。 ◎ Whether a top-level browsing context would benefit from having its rendering updated depends on various factors, such as the update frequency. For example, if the browser is attempting to achieve a 60Hz refresh rate, then these steps are only necessary every 60th of a second (about 16.7ms). If the browser finds that a top-level browsing context is not able to sustain this rate, it might drop to a more sustainable 30Hz for that set of Documents, rather than occasionally dropping frames. (This specification does not mandate any particular model for when to update the rendering.) Similarly, if a top-level browsing context is in the background, the user agent might decide to drop that page to a much slower 4Hz, or even less.

        ~browserが描画の更新を飛ばす他の~~理由として、ある種の`~task$たちを~~連続して実行して，間に差挟まれるのは`小task~checkpointを遂行する$ことにのみになることを確保することが挙げられる（例えば，`~animation~frame~callbackたちを走らす$こともなく）。 例えば~UAは、描画の更新を挟まずに，複数の~timer~callbackを結合したいと望むかもしれない。 ◎ Another example of why a browser might skip updating the rendering is to ensure certain tasks are executed immediately after each other, with only microtask checkpoints interleaved (and without, e.g., animation frame callbacks interleaved). For example, a user agent might wish to coalesce timer callbacks together, with no intermediate rendering updates.

      • %B は、`入子の閲覧文脈$であって，この時点で描画を更新しても益はないと予見される。 ◎ If there are a nested browsing contexts B that the user agent believes would not benefit from having their rendering updated at this time, then remove from docs all Document objects whose browsing context is in B.

        注記： `~top-level閲覧文脈$と同様、`入子の閲覧文脈$の描画を更新しても益はないかどうかは、様々な要因に依存する。 例えば，~UAは、第三者主体の内容の描画に費やす資源を減らしたいと望むかもしれない — とりわけ利用者から現在~可視でない, あるいは資源が拘束されている下では。 その場合、~browserは，その種の内容に対する描画の更新を，頻度を落としたり, やめるよう決めることもできる。 ◎ As with top-level browsing contexts, a variety of factors can influence whether it is profitable for a browser to update the rendering of nested browsing contexts. For example, a user agent might wish to spend less resources rendering third-party content, especially if it is not currently visible to the user or if resources are constrained. In such cases, the browser could decide to update the rendering for such content infrequently or never.

   4. この段の中の各~段における “~EACH( %文書 ) ” は、 %文書s 内の`文書$のうち，［ 当の段を走らす時点において，`全部的に作動中$である ］ものたちに対し，順に繰り~~返すものとする： ◎ ↓

      1. ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して， %文書 に対する `~resize手続き$を走らす `CSSOMVIEW$r ◎ For each fully active Document in docs, run the resize steps for that Document, passing in now as the timestamp. [CSSOMVIEW]
      2. ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して， %文書 に対する `~scroll手続き$を走らす `CSSOMVIEW$r ◎ For each fully active Document in docs, run the scroll steps for that Document, passing in now as the timestamp. [CSSOMVIEW]
      3. ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して， %文書 に対する `媒体~queriesを評価して変化を報告する$ `CSSOMVIEW$r ◎ For each fully active Document in docs, evaluate media queries and report changes for that Document, passing in now as the timestamp. [CSSOMVIEW]
      4. ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して， %文書 に対する `~animationを更新して~eventを送信する$ `WEBANIMATIONS$r ◎ For each fully active Document in docs, update animations and send events for that Document, passing in now as the timestamp. [WEBANIMATIONS]
      5. ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して， %文書 に対する `全screen手続き$を走らす `FULLSCREEN$r ◎ For each fully active Document in docs, run the fullscreen steps for that Document, passing in now as the timestamp. [FULLSCREEN]
      6. ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して， %文書 に対する `~animation~frame~callbackたちを走らす$ ◎ For each fully active Document in docs, run the animation frame callbacks for that Document, passing in now as the timestamp.
      7. ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して， %文書 に対する `交差観測の更新~手続き$を走らす `INTERSECTIONOBSERVER$r ◎ For each fully active Document in docs, run the update intersection observations steps for that Document, passing in now as the timestamp. [INTERSECTIONOBSERVER]
      8. ~EACH( %文書 ) に対し ⇒ ［ %文書, および それが`属する閲覧文脈$ ］の描画や~UIを，現在の状態を反映するように更新する。 ◎ For each fully active Document in docs, update the rendering or user interface of that Document and its browsing context to reflect the current state.

5. ~ELIF［ %~loop は`~worker~event-loop$である ］~AND［ %~loop 内のどの`~task~queue$も空である ］~AND［ `WorkerGlobalScope$I ~objの`~closing~flag$ ~EQ ~ON ］：

   1. この手続きは中止した上で， %~loop を破壊する
   2. ~Web~worker 節 にて述べられる`~workerを走らす$手続きを再開する
   ◎ If this is a worker event loop (i.e. one running for a WorkerGlobalScope), but 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.

各`~event-loop$は、 `小task~queue@ を有する。 `小task@ とは、元々は，［ `~task~queue$ではなく，`小task~queue$ ］に~queueされるものとされた`~task$である。 `小task$には、 `孤立~callback小task@, `複合~小task@ の 2 種類がある。 ◎ Each event loop has a microtask queue. A microtask is a task that is originally to be queued on the microtask queue rather than a task queue. There are two kinds of microtasks: solitary callback microtasks, and compound microtasks.

注記： この仕様は、`孤立~callback小task$のみを定義する。 `複合~小task$を利用する各~仕様は、`~event-loopを回す$~algoを取扱うために，`~callbackを包装する$手間をかける必要がある。 ◎ This specification only has solitary callback microtasks. Specifications that use compound microtasks have to take extra care to wrap callbacks to handle spinning the event loop.

~algoにて `小taskを~queueする@ ことが要求される所では、関連する`~event-loop$の`小task~queue$に 当の`小task$を付加し~MUST — `小task~task源@ が、そのような`小task$の`~task源$である。 ◎ When an algorithm requires a microtask to be queued, it must be appended to the relevant event loop's microtask queue; the task source of such a microtask is the microtask task source.

注記： `小task$は、定例の`~task~queue$に移動されることもある — その初期 【初回の？】 実行の間に，それが`~event-loopを回す$場合には。 その事例では、`小task~task源$が`~task源$として利用される。 通常は、`小task$の`~task源$は関連しない。 ◎ It is possible for a microtask to be moved to a regular task queue, if, during its initial execution, it spins the event loop. In that case, the microtask task source is the task source used. Normally, the task source of a microtask is irrelevant.

~UAは、 `小task~checkpointを遂行する@ ときは，次を走らせ~MUST： ◎ When a user agent is to perform a microtask checkpoint,＼

1. ~IF［ `小task~checkpoint遂行-中~flag$ ~EQ ~ON ］ ⇒ ~RET ◎ if the performing a microtask checkpoint flag is false, then the user agent must run the following steps:
2. %~loop ~LET 当の`~event-loop$ ◎ ↓
3. `小task~checkpoint遂行-中~flag$ ~SET ~ON ◎ Set the performing a microtask checkpoint flag to true.

4. ~WHILE［ %~loop の`小task~queue$は空でない ］： ◎ While the event loop's microtask queue is not empty:

   1. %小task ~LET %~loop の`小task~queue$上の最も遠過去の`小task$ ◎ Let oldestMicrotask be the oldest microtask on the event loop's microtask queue.
   2. %~loop の`現在~走っている~task$ ~SET %小task ◎ Set the event loop's currently running task to oldestMicrotask.

   3. %小task を走らす ◎ Run oldestMicrotask.

      注記： これは、~scriptによる~callbackの呼出ingを孕むかもしれず，最終的に `走らせた~scriptを片付ける$手続きを~callする結果、この~algoが再度~callされることになる。 `小task~checkpoint遂行-中~flag$を利用しているのは、その再入性を避けるためである。 ◎ 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. %~loop の`現在~走っている~task$ ~SET ~NULL ◎ Set the event loop's currently running task back to null.
   5. %小task を`小task~queue$から除去する ◎ Remove oldestMicrotask from the microtask queue.
5. ~EACH( `環境~設定群~obj$ %設定群 ) に対し ⇒ ~IF［ %設定群 の`担当の~event-loop$enV ~EQ %~loop ］ ⇒ %設定群 に対し，`却下-済み~promiseについて通知する$ ◎ For each environment settings object whose responsible event loop is this event loop, notify about rejected promises on that environment settings object.
6. Indexed Database ~transactionを片付ける ◎ Cleanup Indexed Database transactions.
7. `小task~checkpoint遂行-中~flag$ ~SET ~OFF ◎ Set the performing a microtask checkpoint flag to false.

~UAは、`複合~小task$が走っている間に［ 所与の `手続き^V を走らすような `複合~小task下位taskを実行する@ ］よう要求されたときは、次を走らせ~MUST： ◎ If, while a compound microtask is running, the user agent is required to execute a compound microtask subtask to run a series of steps, the user agent must run the following steps:

1. %~loop ~LET 当の`~event-loop$ ◎ ↓
2. %親 ~LET %~loop の`現在~走っている~task$ （現在~走っている`複合~小task$）。 ◎ Let parent be the event loop's currently running task (the currently running compound microtask).
3. %下位task ~LET `小task~task源$を`~task源$とする， `手続き^V を走らす新たな`~task$ — この`小task$を指して， `複合~小task下位task@ という。 ◎ Let subtask be a new task that consists of running the given series of steps. The task source of such a microtask is the microtask task source. This is a compound microtask subtask.
4. %~loop の`現在~走っている~task$ ~SET %下位task ◎ Set the event loop's currently running task to subtask.
5. %下位task を走らす ◎ Run subtask.
6. %~loop の`現在~走っている~task$ ~SET %親 ◎ Set the event loop's currently running task back to parent.

~UAは、`並列的$に走っている %~algo において， `安定~状態を待受ける@ ときは、次の手続きを走らす`小taskを~queueする$と同時に， %~algo 自身の実行は いったん停止し~MUST（その実行は、下の手続きに述べるように，小taskを走らせたとき再開される）： ◎ 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 内の`同期区間$は、~~記号 ⌛ が付与される段として与えられる。 【が，和訳では、その~~記号に代えて，明示的な~markupによる下位手続きとして与えることもある。】 ◎ Steps in synchronous sections are marked with ⌛.

~algoにて，所与の条件 %目標 が満たされるまで `~event-loopを回す@ と記されている所では、~UAは，次を走らせ~MUST： ◎ When an algorithm says to spin the event loop until a condition goal is met, the user agent must run the following steps:

1. %~task ~LET 当の`~event-loop$の`現在~走っている~task$ ◎ Let task be the event loop's currently running task.

   注記： これは、`小task$の場合もある — その事例では、`孤立~callback小task$になる。 これは、［ `複合~小task下位task$ ／ `小task$でない定例の`~task$ ］の場合もある。 これが`複合~小task$になることは、ない。 ◎ This might be a microtask, in which case it is a solitary callback microtask. It could also be a compound microtask subtask, or a regular task that is not a microtask. It will not be a compound microtask.

2. %~task源 ~LET %~task の`~task源$ ◎ Let task source be task's task 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.

6. %~task を停止して，それを呼出した~algoを何であれ再開できるようにする一方で、この手続きは 【~taskを呼出した~algoと】 `並列的$に継続する ◎ Stop task, allowing whatever algorithm that invoked it to resume, but continue these steps in parallel.

   注記： これは、次のいずれかの~algoを継続させる：

   • `~event-loop$の~main手続き 【処理~model節】
   • `小task~checkpointを遂行する$
   • `複合~小task下位taskを実行する$

   ◎ This causes one of the following algorithms to continue: the event loop's main set of steps, the perform a microtask checkpoint algorithm, or the execute a compound microtask subtask algorithm.
7. %目標 が満たされるまで待機する ◎ Wait until the condition goal is met.
8. %継続~task ~LET 新たな何もしない`~task$ ◎ ↓
9. `~task源$ %~task源 から， %継続~task を`~queueする$ ◎ Queue a task to continue running these steps, using the task source task source.＼
10. %継続~task が走らされるまで待機する ◎ Wait until this new task runs before continuing these steps.
11. `~JS実行~文脈~stack$を %旧~stack に置換する ◎ Replace the JavaScript execution context stack with the old stack.
12. ~RET — ~call元へ~~制御を返す ◎ Return to the caller.

【 上で停止された %~task はどうなる？ （ %旧~stack に置換した時点から）自動的に再開されるのか？ 】

歴史的~理由から、この仕様の~algoのうち一部は，`~task$ %~task が走っている間，所与の %目標 が満たされるまで、~UAに `静止-@ することを要求する。 これは、次の手続きを走らすことを意味する： ◎ 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. 必要とされるなら、［ `文書$ ／ `閲覧文脈$ ］の描画や~UIを，現在の状態を反映するように更新する ◎ If necessary, update the rendering or user interface of any Document or browsing context to reflect the current state.

2. %目標 が満たされるまで待機する — ~UAが %~task を`静止-$している間は：

   • %~task が属している`~event-loop$は、他の`~task$を走らせては~MUST_NOT。
   • `現在~走っている~task$における~script実行は、阻まれ~MUST。
   • ~UAは、利用者~入力に対しては即応可能であり続けるべきである — しかしながら、`~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.

8.1.4.3. 汎用の~task源

次に挙げる`~task源$は、［ この／他の ］仕様における，互いにほぼ無関係な，いくつもの特色機能により利用される： ◎ The following task sources are used by a number of mostly unrelated features in this and other specifications.

`~DOM操作~task源@ ◎ The DOM manipulation task source

この`~task源$は、~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源@ ◎ The user interaction task source

この`~task源$は、利用者対話に反応する特色機能のために利用される — 例えば［ ~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源$により`~queueされ$る`~task$を利用して発火され~MUST。 ◎ 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源@ ◎ The networking task source

この`~task源$は、~network活動に呼応して誘発される特色機能のために利用される。 ◎ This task source is used for features that trigger in response to network activity.

`履歴~走査~task源@ ◎ The history traversal task source

この`~task源$は、 `history.back()$m や, それに類似する~APIへの~callを~queueするために利用される。 ◎ This task source is used to queue calls to history.back() and similar APIs.

8.1.4.4. 他の仕様における~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 内のどこかを出自にしている。 ◎ 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$を阻むことになる ］ものは，何であれ そのように遂行され~MUST。 これには、少なくとも次が含まれる： ◎ 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処理-の外へ出る” ）ような演算を遂行するとき。 ◎ performing operations which could require involving outside systems (i.e. "going out of process").

次に挙がる複雑問題は，~algoの`並列的$な区間であり、そこでは，特定の［ `~JS~realm$ ／ `大域~obj$ ／ `環境~設定群~obj$ ］に結付けられた~objを 作成したり操作しては~MUST_NOT（馴染みの用語で言明するなら、~main~threadによる遺物に，~background~threadから直に~accessしては~MUST_NOT）。 そうすると，~JS~codeから観測-可能な~data~raceが生じることになる — ~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 JavaScript 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$r にて定義されるものなど — は、操作できる。 それらは~realmに非依存であり，~JSに直に公開されることは決してなく，特有の変換（ Web IDL による`変換-$xを介するものが多い）がそこを占めることはないので。 `WEBIDL$r ◎ You can, however, manipulate specification-level data structures and values from the WHATWG Infra Standard, 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の世界に影響させるためには、次に従わ~MUST： ◎ To affect the world of observable JavaScript objects, then, you must＼

• そのような操作は、それを遂行する~taskとして`~queueする$こと。 これは、当の手続きが，`~event-loop$にて起こる他の~taskの合間に適正に差挟まれることを確保する。 ◎ queue a 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源$も選ぶこと。 これは、自他の手続きの相対的な遂行-順序を統治する。 どの`~task源$を利用するか定かでない場合は、 汎用の~task源 から，最も適用-可能と思しきものを選ぶこと。 ◎ Furthermore, you must choose a task source when queueing a 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.

`~taskを~queueする$ほとんどの呼出は、暗黙的に “関連する`~event-loop$” — すなわち，文脈から明らかなもの — を利用する。 ~algoが複数の~event-loopを孕むような文脈から呼出されることは、ごく稀にしかないので。 例えば`~worker$の操作を取り扱うような仕様を書いていない限り、この引数は，`~taskを~queueする$ときには省略できる（複数の大域~objを孕むような文脈と違って，それは あらゆるときに起きているので）。 ◎ Most invocations of queue a task implicitly use "the relevant event loop", i.e., the one that is obvious from context. That is because it is very rare for algorithms to be invoked in contexts involving multiple event loops. (Unlike contexts involving multiple global objects, which happen all the time!) So unless you are writing a specification which, e.g., deals with manipulating workers, you can omit this argument when queueing a task.

以上をまとめれば、非同期に仕事する必要がある~algo用の代表的なひな形は，次のようになる： ◎ Putting this all together, we can provide a template for a typical algorithm that needs to do work asynchronously:

1. 同期的に設定しておく仕事があれば，まずそれを行う — 依然として`~event-loop$上にある間に。 これは、`~JS~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源$から，次を走らす`~taskを~queueする$ ⇒ ~realmに非依存な結果を変換して、`~event-loop$上の，~JS~objが成す観測-可能な世界における観測-可能な効果に戻す ◎ Queue a task, on a specified task source, to convert the realm-agnostic result back into observable effects on the observable world of JavaScript objects on the event loop.

8.1.5.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$の名前は、常に `on^l から開始し，~handlerに意図される~event名が後続する。 ◎ An event handler has a name, which always starts with "on" and is followed by the name of the event for which it is intended.

`~event~handler$の値は［ ~NULL, ~callback~obj, `内部的な生の未compileの~handler$ ］いずれかをとる。 `EventHandler$I ~callback関数~型は、これが~scriptに どう公開されるかを述べる。 初期~時には、 `~event~handler$の値は~NULLに設定され~MUST。 ◎ An event handler has a value, which is either null, or is a callback object, or is an internal raw uncompiled handler. The EventHandler callback function type describes how this is exposed to scripts. Initially, an event handler's value must be set to null.

各~event~handlerは、次の 2 通りの仕方で公開される： ◎ Event handlers are exposed in one of 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~IDL属性@ は、~obj上の特定の`~event~handler$に対応する，同じ~obj上の~IDL属性である。 その名前は、`~event~handler$の名前と同じである。 ◎ 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属性$は： ◎ Event handler IDL attributes,＼

• 設定子は、次を走らせ~MUST ⇒ 属性に対応している`~event~handler$ ~SET 所与の値 ◎ on setting, must set the corresponding event handler to their new value, and＼
• 取得子は、次を走らせ~MUST ⇒ ~RET `~event~handlerの現在の値を取得する$( 属性に対応している`~event~handler$ ) ◎ on getting, must return the result of getting the current value of the event handler in question.

`~event~handler~IDL属性$が、存在しない~objの`~event~handler$を公開する場合： ◎ If an event handler IDL attribute exposes an event handler of an object that doesn't exist,＼

• 取得子は、常に~NULLを返さ~MUST。 ◎ it must always return null on getting and＼
• 設定子は、何もしては~MUST_NOT。 ◎ must do nothing on setting.

注記： これは特に、対応している`~window$を有さない `body$e 要素~上の`~event~handler~IDL属性$に起こり得る。 【~windowのそれを反映する~IDL属性】 ◎ This can happen in particular for event handler IDL attribute on body elements that do not have corresponding Window objects.

注記： ある種の~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$jA 生成規則に合致するように構文解析される ］ような，妥当な~JS~codeを包含してい~MUST。 ◎ 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内容~属性$ %属性 の設定子は、次の手続きを実行する： ◎ When an event handler content attribute is set, execute the following steps:

1. ~IF［［ ( %属性 を有している`要素$, `script attribute^l, 所与の値 ) を与える下で， 要素の~inline型の挙動は~CSPにより阻止されるべきか？ `CSP$r を実行した結果 ］ ~EQ `阻止ed^i ］ ⇒ ~RET ◎ If the Should element's inline behavior be blocked by Content Security Policy? algorithm returns "Blocked" when executed upon the attribute's element, "script attribute", and the attribute's value, then return. [CSP]
2. 対応している`~event~handler$ ~SET 次の組からなる，`内部的な生の未compileの~handler$ ⇒＃ ~script本体： %属性 に対する新たな値； ~script本体の所在： %属性 がこの値に設定された場所 ◎ Set the corresponding event handler to an internal raw uncompiled handler consisting of the attribute's new value and the script location where the attribute was set to this value

`~event~handler内容~属性$の除去-時には、~UAは，対応している`~event~handler$を~NULLに設定し~MUST。 ◎ When an event handler content attribute is removed, the user agent must set the corresponding event handler to null.

`EventTarget$I ~obj %T 上の`~event~handler$ %H が，最初に非 ~NULL 値に設定されたときは： ◎ When an event handler H of an EventTarget object T is first set to a non-null value, then:

1. %callback ~LET ［ 次のような関数への参照 ］を表現している，~Web~IDL `EventListener$I ~instanceを作成した結果 ⇒ 1 個の引数をとり、 %H, および その引数を与える下で，`~event~handler処理~algo$を実行する関数 ◎ 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 H and its argument.

   `EventListener$I の`~callback文脈$は、任意のものをとれる — それは `~event~handler処理~algo$には影響0しない。 `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 は、 %H 自身ではないことに注意。 どの`~event~handler$も、同じ `~callback^i — すなわち，下に定義される~algo — を登録する結果になる。 その~algoが、~~正しい~callbackを呼出すこと, および その~callbackが返す値の処理を受け持つ。 ◎ 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 callback, and processing the callback's return value.

2. %~listener ~LET 次のようにされた新たな`~event~listener$ ⇒＃ `type$evL ~SET %H に対応する `~event~handler~event型@ `callback$evL ~SET %~callback ◎ Let listener be a new event listener whose type is the event handler event type corresponding to H and callback is callback.

   注記： `~event~listener$は `EventListener$I とは異なることに注意。 ◎ To be clear, an event listener is different from an EventListener.

3. `~event~listenerを追加する$( %T, %~listener ) ◎ Add an event listener with T and listener.

<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~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~handler$ %H , `Event$I ~obj %E ) に対し，次を走らす： ◎ The event handler processing algorithm for an event handler H and an Event object E is as follows:

1. %~callback ~LET `~event~handlerの現在の値を取得する$( %H ) ◎ Let callback be the result of getting the current value of the event handler H.
2. ~IF［ %~callback ~EQ ~NULL ］ ⇒ ~RET ◎ If callback is null, then return.
3. `特別~error~event取扱い^V ~LET ［［ %E は `ErrorEvent$I ~objである ］~AND［ %E の `type$m ~EQ `error$et ］~AND［ %E の `currentTarget$m は `WindowOrWorkerGlobalScope$I ~mixinを実装する ］ならば ~T ／ ~ELSE_ ~F ］ ◎ Let special error event handling be true if E is an ErrorEvent object, E's type is error, and E's currentTarget implements the WindowOrWorkerGlobalScope mixin. Otherwise, let special error event handling be false.

4. %返値 ~LET `~callback関数を呼出す$( %~callback, 次に与える引数~list, %E の`currentTarget$m （`~callback this 値$） ) ⇒ 引数~listは `特別~error~event取扱い^V に応じて ⇒ ~F ならば %E のみ ／ ~T ならば 順に %E の ( `message$m, `filename$m, `lineno$m, `colno$m, `error$m ) 属性~値 ◎ Process the Event object E as follows: ◎ If special error event handling is true • Invoke callback with five arguments, the first one having the value of E's message attribute, the second having the value of E's filename attribute, the third having the value of E's lineno attribute, the fourth having the value of E's colno attribute, the fifth having the value of E's error attribute, and with the callback this value set to E's currentTarget. Let return value be the callback's return value. [WEBIDL] ◎ Otherwise • Invoke callback with one argument, the value of which is the Event object E, with the callback this value set to E's currentTarget. Let return value be the callback's return value. [WEBIDL]

   %~callback から例外が投出されたときは、そのまま伝播させるとする（したがって、この手続きも終える）。 （例外は、 ~DOM~event配送-~logic へ伝播し，その`例外を報告する$ことになる。） ◎ If an exception gets thrown by the callback, end these steps and allow the exception to propagate. (It will propagate to the DOM event dispatch logic, which will then report the exception.)

5. ~IF［ %E は `BeforeUnloadEvent$I ~objである ］~AND［ %E の `type$m ~EQ `beforeunload$et ］： ◎ Process return value as follows: ◎ If E is a BeforeUnloadEvent object and E'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. %E の`取消d~flag$ ~SET ~ON ◎ Set E's canceled flag.
   3. ~IF［ %E の `returnValue$m 属性~値 ~EQ 空~文字列 ］ ⇒ %E の `returnValue$m 属性~値 ~SET %返値 ◎ If E's returnValue attribute's value is the empty string, then set E's returnValue attribute's value to return value.
6. ~ELIF［ `特別~error~event取扱い^V ~EQ ~T ］ ⇒ ~IF［ %返値 ~EQ ~T ］ ⇒ %E の`取消d~flag$ ~SET ~ON ◎ If special error event handling is true • If return value is true, then set E's canceled flag.

7. ~ELIF［ %返値 ~EQ ~F ］ ⇒ %E の`取消d~flag$ ~SET ~ON ◎ Otherwise • If return value is false, then set E's canceled flag.

   注記： ［ %E の `type$m ~EQ `beforeunload$et ］だが［ %E は `BeforeUnloadEvent$I ~objでない ］がため，この段に来た場合、 %返値 は決して ~F にならない — すでに［ ~NULL または `DOMString^I ］型に型強制されているので。 ◎ If we've gotten to this "Otherwise" clause because E's type is beforeunload but E 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を表現する。 それは、次の~WebIDLで表現される： ◎ The EventHandler callback function type represents a callback used for event handlers. It is represented in Web IDL as follows:

[TreatNonObjectAsNull]
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.

<body onload="alert(this)" onclick="alert(this)">

歴史的~理由から、 `onerror$hd ~handlerは，異なる引数をとる: ◎ For historical reasons, the onerror handler has different arguments:

[TreatNonObjectAsNull]
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:

[TreatNonObjectAsNull]
callback `OnBeforeUnloadEventHandlerNonNull@I = DOMString? (`Event$I %event);
typedef `OnBeforeUnloadEventHandlerNonNull$I? `OnBeforeUnloadEventHandler@I;

`内部的な生の未compileの~handler@ は、次の情報の組である： ◎ 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~handler$ %H ) に対し，次を走らせ~MUST： ◎ When the user agent is to get the current value of the event handler H, it must run these steps:

1. ~IF［ %H の値は、`内部的な生の未compileの~handler$でない ］ ⇒ ~RET %H の値 ◎ If H's value is an internal raw uncompiled handler, run these substeps:

2. ( %要素, %文書 ) ~LET %H に応じて：

   ある要素 %E の`~event~handler$である

   ( %E, %E の`~node文書$ )

   ある`~window$ %W の`~event~handler$である

   ( ~NULL, %W に`結付けられている文書$ )

   ◎ If H is an element's event handler, then let element be the element, and document be the element's node document. ◎ Otherwise, H is a Window object's event handler: let element be null, and let document be H's associated Document.
3. ~IF［ %文書 に対する`~scriptingは不能化されて$いる ］ ⇒ ~RET ~NULL ◎ If scripting is disabled for document, then return null.
4. %~script ~LET %H の値 ◎ ↓
5. %本体 ~LET %~script の未compileの~script本体 ◎ Let body be the uncompiled script body in the internal raw uncompiled handler.
6. %所在 ~LET %~script の~script本体が出自にしている所在 ◎ Let location be the location where the script body originated, as given by the internal raw uncompiled handler.
7. %~form所有者 ~LET ~NULL ◎ ↓
8. ~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.
9. %設定群~obj ~LET %文書 に`関連する設定群~obj$ ◎ Let settings object be the relevant settings object of document.

10. ~IF［ %本体 は `FunctionBody$jA として構文解析-可能でない ］~OR［ 構文解析-時に`早期の~error$が検出された ］： ◎ If body is not parsable as FunctionBody or if parsing detects an early error, then follow these substeps:

    1. %H の値 ~SET ~NULL ◎ Set H's value to null.
    2. 次を与える下で，`~errorを報告する$ ⇒＃ ~script： 適切な `~script$ 【？】 問題箇所： %所在 における適切な問題箇所 ( 行番号, 列番号 ) 標的： %設定群~obj の`大域~obj$enV ◎ Report the error for the appropriate script and with the appropriate position (line number and column number) given by location, using settings object's global object.＼
    3. ~IF［ ~errorの`取扱済み~flag$err ~EQ ~OFF ］ ⇒ ~UAは、開発者~consoleに~errorを報告してよい ◎ If the error is still not handled after this, then the error may be reported to a developer console.
    4. ~RET ~NULL ◎ Return null.
11. %strict ~LET［［ %本体 は［ `Use Strict Directive$js を包含する `Directive Prologue$js ］から始まる ］ならば ~T ／ ~ELSE_ ~F ］ ◎ If body begins with a Directive Prologue that contains a Use Strict Directive then let strict be true, otherwise let strict be false.

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.

    これは、後の `FunctionCreate$jA の呼出が正しい`~JS~realm$に属するようにするため，必要とされる。 ◎ This is necessary so the subsequent invocation of FunctionCreate takes place in the correct JavaScript Realm.

13. %関数 ~LET 次を引数に `FunctionCreate$jA を~callした結果： ◎ Let function be the result of calling FunctionCreate, with arguments:

    %kind

    Normal

    %ParameterList

    %H は`~window$の `onerror$hd `~event~handler$である場合： ◎ If H is an onerror event handler of a Window object

    %関数 は、次に与える名前の 5 個の引数をとる ⇒ ( `event^c, `source^c, `lineno^c, `colno^c, `error^c ) ◎ Let the function have five arguments, named event, source, lineno, colno, and error.

    他の場合： ◎ Otherwise

    %関数 は、単独の引数 ( `event^c ) をとる ◎ Let the function have a single argument called event.

    %Body

    %本体 を構文解析した結果 ◎ The result of parsing body above.

    %Scope

    1. ~IF［ %H は要素の`~event~handler$である ］ ⇒ %Scope ~LET `NewObjectEnvironment$jA( %文書, %大域~環境 ) ◎ If H is an element's event handler, then let Scope be NewObjectEnvironment(document, the global environment).
    2. ~ELSE （すなわち %H は`~window$の`~event~handler$である） ⇒ %Scope ~LET %大域~環境 ◎ Otherwise, H is a Window object's event handler: let Scope be the global environment.
    3. ~IF［ %~form所有者 ~NEQ ~NULL ］ ⇒ %Scope ~SET `NewObjectEnvironment$jA(%~form所有者, %Scope ) ◎ If form owner is not null, let Scope be NewObjectEnvironment(form owner, Scope).
    4. ~IF［ %要素 ~NEQ ~NULL ］ ⇒ %Scope ~SET `NewObjectEnvironment$jA( %要素, %Scope ) ◎ If element is not null, let Scope be NewObjectEnvironment(element, Scope).

    %Strict

    %strict ◎ The value of strict.

14. %設定群~obj の`~realm実行~文脈$enVを，`~JS実行~文脈~stack$から除去する ◎ Remove settings object's realm execution context from the JavaScript execution context stack.
15. %H の値 ~SET 次のようにされた~Web~IDL~callback関数を作成した結果 ⇒＃ その~obj参照 ~SET %関数, その`~callback文脈$ ~SET %設定群~obj ◎ Set H's value to the result of creating a Web IDL callback function whose object reference is function and whose callback context is settings object.
16. ~RET %H の値 ◎ Return H's value.

8.1.5.2. ［ 要素 ／ 文書 ／ ~window ］上の各種~event~handler

interface mixin `GlobalEventHandlers@I {
  attribute EventHandler `onabort$hd;
  attribute EventHandler `onauxclick$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 `oncontextmenu$hd;
  attribute EventHandler `oncuechange$hd;
  attribute EventHandler `ondblclick$hd;
  attribute EventHandler `ondrag$hd;
  attribute EventHandler `ondragend$hd;
  attribute EventHandler `ondragenter$hd;
  attribute EventHandler `ondragexit$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 `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 `onloadend$hd;
  attribute EventHandler `onloadstart$hd;
  attribute EventHandler `onmousedown$hd;
  [LenientThis] attribute EventHandler `onmouseenter$hd;
  [LenientThis] attribute EventHandler `onmouseleave$hd;
  attribute EventHandler `onmousemove$hd;
  attribute EventHandler `onmouseout$hd;
  attribute EventHandler `onmouseover$hd;
  attribute EventHandler `onmouseup$hd;
  attribute EventHandler `onwheel$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 `onsecuritypolicyviolation$hd;
  attribute EventHandler `onseeked$hd;
  attribute EventHandler `onseeking$hd;
  attribute EventHandler `onselect$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;
};

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 `onpageshow$hd;
  attribute EventHandler `onpopstate$hd;
  attribute EventHandler `onrejectionhandled$hd;
  attribute EventHandler `onstorage$hd;
  attribute EventHandler `onunhandledrejection$hd;
  attribute EventHandler `onunload$hd;
};

interface mixin `DocumentAndElementEventHandlers@I {
  attribute EventHandler `oncopy$hd;
  attribute EventHandler `oncut$hd;
  attribute EventHandler `onpaste$hd;
};

8.1.5.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]

`合成~mouse~eventを発火する@ ときは、所与の ( ~eventの配送-先 %標的, ~event名 %e, %~trustされない~flag ~IN { `~trustされない^i, ε } （省略時は ε ） ) に対し，次の手続きを走らす： ◎ Firing a synthetic mouse event named e at target, with an optional not trusted flag, means running these steps:

1. %~event ~LET `~eventを作成する$( `MouseEvent$I ) ◎ Let event be the result of creating an event using MouseEvent.

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~flag$ ~SET ~ON ◎ Set event's composed flag.
   5. ~IF［ %~trustされない~flag ~NEQ ε ］ ⇒ `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 ］は、~key入力~装置の現在の状態に則って初期化する（可用でない~keyに対しては ~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 %標的 の`~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は、~key入力~装置の現在の状態を適切に述べる値を返すようにする ◎ event's getModifierState() method is to return values appropriately describing the current state of the key input device.
3. ~RET %標的 に向けて %~event を`配送-$した結果 ◎ Return the result of dispatching event at target.

%標的 に向けて `click ~eventを発火する@ ときは、次を走らす ⇒ `合成~mouse~eventを発火する$( %標的, `click^et ) ◎ Firing a click event at target means firing a synthetic mouse event named click at target.