8.1. ~scripting

【この訳に固有の表記規約】

この訳の,~algoや定義の記述に利用されている各種記号( ~LET, ~IF, ~GOTO 等々)の意味や定義の詳細は,~SYMBOL_DEF_REFを~~参照されたし。

  • 用語 `文書@ は、(~DOMにより定義され,~HTMLにより拡張された) `Document$I ~interfaceを実装する~objの略記である。
  • 用語 `~window@ は、 `Window$I ~interfaceを実装する~objの略記である。
  • 用語 “中途完了( abrupt completion )” は、 `JAVASCRIPT$r にて定義される。
  • 各種~algoのうち一部のものは、 `非同期に完了-@ する( asynchronously complete )ものと定義される。 その種の~algoは:

    • その結果を,それを呼出した~algoに直接的に返すことはなく、 “ %X を結果として,非同期に完了する” と記される所で、字義通り非同期にその実行を終える。 この句は,暗黙的に ~RET も含み、~algoはそこで終了するものとする。
    • その結果は、それを呼出した~algoの中で “(〜の~algoが)非同期に完了したときは…” という句に後続する手続きで取扱われる。

8.1.1. 序論

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

  • `script$e 要素の処理。 ◎ Processing of script elements.
  • `javascript$sc ~URLへ~navigateするとき。 ◎ Navigating to javascript: URLs.
  • 次による~event~handler:

    • DOM の `addEventListener()^m を利用して登録されたもの
    • 明示的な`~event~handler内容~属性$
    • `~event~handler~IDL属性$
    • その他
    ◎ Event handlers, whether registered through the DOM using addEventListener(), by explicit event handler content attributes, by event handler IDL attributes, or otherwise.
  • SVG の様な,自前の~scripting特色機能を有する技術の処理。 ◎ Processing of technologies like SVG that have their own scripting features.

8.1.2. ~scriptingの可能化と不能化

`閲覧文脈$ %B において, `~scriptingは可能化され@ ているとは、次のすべての条件が満たされることを意味する: ◎ Scripting is enabled in a browsing context when all of the following conditions are true:

  • ~UAは~scriptingを~supportする。 ◎ The user agent supports scripting.
  • この時点で、利用者は, %B おいて~scriptingを不能化していない。 (~UAは、利用者に~scriptingを ~~全面的に, あるいは~~細部的に — 例えば,個別の生成元ごとに — 不能化する選択肢を提供してよい) ~FINGERPRINTING ◎ The user has not disabled scripting for this browsing context at this time. (User agents may provide users with the option to disable scripting globally, or in a finer-grained manner, e.g. on a per-origin basis. (This is a fingerprinting vector.)
  • `閲覧文脈~sandbox化( ~script )~flag$ ~NIN [ %B にて`作動中の文書$の`作動中の~sandbox用~flag集合$ ] ◎ The browsing context's active document's active sandboxing flag set does not have its sandboxed scripts browsing context flag set.

`~scriptingは不能化され@ ているとは、上の否定 — `~scriptingは可能化され$ていない — ことを意味する。 ◎ Scripting is disabled in a browsing context when any of the above conditions are false (i.e. when scripting is not enabled).


`~nodeに対し,~scriptingは可能化され@ ているとは、[ その~nodeの`~node文書$が`属する閲覧文脈$はある ], かつ[ その閲覧文脈において`~scriptingは可能化され$ている ]ことを意味する。 ◎ Scripting is enabled for a node if the node's node document has a browsing context, and scripting is enabled in that browsing context.

`~nodeに対し,~scriptingは不能化され@ ているとは、上の否定を意味する。 ◎ Scripting is disabled for a node if there is no such browsing context, or if scripting is disabled in that browsing context.

8.1.3. 処理~model

8.1.3.1. 各種~定義

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

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

`~classic~script@ は、`~script$であることに加え,次のものも有する: ◎ A classic script is a script that has the following additional fields:

`~source~text@ ◎ Source text
実行可能な~codeの~blockを,~JS `Script$js として包含している文字列。 ◎ A string containing a block of executable code to be evaluated as a JavaScript Script.
`黙秘error~flag@ ◎ Optionally, a muted errors flag
~flag値。 ~ON ならば、この~scriptにおける~errorに対しては,~error情報は提供されなくなる(~private情報を漏洩し得る非同一生成元~scriptに対し、~errorを黙秘するために利用される)。 ◎ A flag which, if set, means that error information will not be provided for errors in this script (used to mute errors for cross-origin scripts, since that can leak private information).

`~module~script@ は、`~script$であることに加え,次のものも有する: ◎ A module script is a script that has the following additional fields:

`~module~record@mS ◎ A module record
`Source Text Module Record$js — 構文解析され,実行する準備が整った~moduleを表現する。 ◎ A Source Text Module Record representing the parsed module, ready to be evaluated.
`基底~URL@mS ◎ A base URL
`~module指定子を解決-$するときに利用される基底~URL。 これは、外部~module~scriptに対しては,~scriptが得られた~URLになり、~inline~module~scriptに対しては,それを包含している文書の`基底~URL$になる。 ◎ A base URL used for resolving module specifiers when resolving a module specifier. This will either be the URL from which the script was obtained, for external module scripts, or the document base URL of the containing document, for inline module scripts.
`~instance化~状態@mS
以前に~instance化するのに失敗した~module上の `ModuleDeclarationInstantiation$jA() が再び呼出されるのを防止するために利用される。 次のいずれか ⇒ `uninstantiated^l / `errored^l / `instantiated^l ◎ One of "uninstantiated", "errored", or "instantiated", used to prevent reinvocation of ModuleDeclarationInstantiation on modules that failed to instantiate previously.
`~instance化~error@mS

~JS値。 `~instance化~状態$mS ~EQ `errored^l の場合に限り,意味を持つ。 ◎ A JavaScript value, which has meaning only if the instantiation state is "errored".

`資格証~mode@mS ◎ A credentials mode
~importされた~moduleを~fetchするときに利用される,`資格証~mode$rq ◎ A credentials mode used to fetch imported modules.
`暗号用~nonce@mS ◎ A cryptographic nonce
~importされた~moduleを~fetchするときに利用される,`暗号用~nonce~metadata$rq ◎ A cryptographic nonce used to fetch imported modules.
`構文解析器~状態@mS ◎ A parser state
~importされた~moduleを~fetchするときに利用される,`構文解析器~metadata$rq ◎ The parser metadata used to fetch imported modules.

`環境@ とは、[ 現在の実行~環境,または そうなり得るもの ]の設定群を識別する~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$。 ◎ An absolute URL 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。 初期~時は ~OFF 。 ◎ A flag that indicates whether the environment setup is done. It is initially unset.

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

`~realm実行~文脈@enV ◎ A realm execution context
%設定群 を利用するすべての `~script$x から共有されるような,`~JS実行~文脈$js。 すなわち、これらの~scriptは,この`~JS~realm$js内にある。 [ `~classic~script$ / `~module~script$ ]を走らすときは、この実行~文脈が`~JS実行~文脈~stack$jsの一番上になり,その上に当の~scriptに特有の別の実行~文脈が~pushされる。 (こう設定しておけば、[ `ParseScript$jA / `ModuleEvaluation$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 ModuleEvaluation 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$。 `はっきりした時点で、特定0の~event~loopに振り分けられる(不定な~event~loopであって,他の処理に影響する前に何らかの~event~loopに確定される)ことを意味すると見られる。^tnote ◎ An event loop that is used when it would not be immediately clear what event loop to use.
`担当の文書@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()$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().
`担当の~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
[ この`環境~設定群~obj$を`要請~client$rqに利用して遂行される`~fetch$ ]のための既定の`~referrer施策$。 `REFERRERPOLICY$r ◎ The default referrer policy for fetches performed using this environment settings object as a request client. [REFERRERPOLICY]

各 `環境~設定群~obj$に対しては、次も定義される: ◎ ↓

`通知待ちの却下済み~promise~list@enV ◎ ↓
次の項目とともに, 未取扱いの~promise却下 を追跡するために利用される。 ◎ ↓
`未決の却下済み~promiseへの弱参照~集合@enV ◎ ↓
~promiseへの弱い参照からなる集合 — これらのどの参照も強い参照であっては~MUST_NOT。 実装はまた、含まれる参照の個数を自由に制限してよい — 例えば、新たな参照が追加されたときに,古いものを除去するなど。 ◎ An environment settings object also has an outstanding rejected promises weak set and an about-to-be-notified rejected promises list, used to track unhandled promise rejections. The outstanding rejected promises weak set must not create strong references to any of its members, and implementations are free to limit its size, e.g. by removing old entries from it when new ones are added.

8.1.3.2. ~scriptの~fetching

この節では、~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.

これらの~algoを利用する仕様は、任意選択で `~fetchを遂行する@ ~custom~hookを給して,~algoを~customizeできる — この~custom~hookは:

  • ( `要請$, `~top-level内~flag@V ) が入力に渡される。
  • `応答$を結果とし~MUST(`~network~error$も可)。
  • `~workerが~importする~classic~scriptを~fetchする$ときは,結果を同期的に返し、 他の場合は,`非同期に完了-$し~MUST。
  • `~top-level内~flag$V は:

    • [ `~classic~script$に対する すべての~fetch, および[ `~module~script~graphを~fetchする$ / `~worker用~module~script~graphを~fetchする$ ]ときの初期~fetch ]に対しては, ~ON にされる
    • [ ~module~script~graphを通り抜ける間に遭遇した `import^c 文による結果の~fetch ]に対しては, ~OFF にされる。
◎ The algorithms below can be customized by optionally supplying a custom perform the fetch hook, which takes a request and an is top-level flag. The algorithm must complete with a response (which may be a network error), either synchronously (when using fetch a classic worker-imported script) or asynchronously (otherwise). 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.

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

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

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

注記: Service Workers `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]

`~classic~scriptを~fetchする@ ときは、所与の ( %~url, %設定群~obj, %暗号用~nonce, %完全性~metadata, %構文解析器~状態, %~CORS設定, %文字~符号化方式 ) に対し,次を走らす。 この~algoは、[ (失敗~時には)~NULL / (成功~時には)新たな`~classic~script$ ]いずれかを結果として,`非同期に完了-$する: ◎ To fetch a classic script given a url, a settings object, a cryptographic nonce, an integrity metadata, a parser state, 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
    • `種別$rq ~SET `script^l
    • `暗号用~nonce~metadata$rq ~SET %暗号用~nonce
    • `完全性~metadata$rq ~SET %完全性~metadata
    • `構文解析器~metadata$rq ~SET %構文解析器~状態
    ◎ Set request's client to settings object, its type to "script", its cryptographic nonce metadata to cryptographic nonce, its integrity metadata to integrity metadata and its parser metadata to parser state.
  3. ~IF[ この~algoの~call元にて,`~fetchを遂行する$ ~custom手続き %C が指定されている ]:

    1. 次を与える下で, %C を遂行する ⇒ %要請, [ `~top-level内~flag$V ~SET ~ON ]
    2. ~RET — ただし,以降の手続きは、 %C を完了した結果の`応答$ %応答 に対し走らす
    ◎ 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.

  4. %応答 ~LET %応答 の`非安全~応答$ ◎ Let response be response's unsafe response.
  5. ~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.
  6. ~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).
  7. %~source~text ~LET %文字~符号化方式 を~fallback符号化方式に利用して, %応答 の`本体$rsを `~Unicodeに復号-$した結果 ◎ Let source text be the result of decoding response's body to Unicode, using character encoding as the fallback encoding.

    注記: ~fileに BOM がある場合、 `~Unicodeに復号-$する~algoは, %文字~符号化方式 を上書きする。 ◎ The decode algorithm overrides character encoding if the file contains a BOM.

  8. %黙秘error~flag ~LET [ %応答 は`~CORS非同一生成元$であるならば ~ON / ~ELSE_ ~OFF ] ◎ ↓
  9. %~script ~LET 次を与える下で,`~classic~scriptを作成-$した結果: %~source~text, %設定群~obj, %黙秘error~flag ◎ Let script be the result of creating a classic script using source text and settings object. ◎ If response was CORS-cross-origin, then pass the muted errors flag to the create a classic script algorithm as well.

  10. %~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 `script^l
    • `行先$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, type is "script", 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手続き %C が指定されている ]:

    1. 次を与える下で, %C を遂行する ⇒ %要請, [ `~top-level内~flag$V ~SET ~ON ]
    2. ~RET — ただし,以降の手続きは、 %C を完了した結果の`応答$ %応答 に対し走らす
    ◎ 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 %応答 の`本体$rsを `~UTF-8復号-$した結果 ◎ Let source text be the result of UTF-8 decoding response's body.
  6. %~script ~LET 次を与える下で,`~classic~scriptを作成-$した結果: %~source~text, %~script設定群~obj ◎ Let script be the result of creating a classic script using source text and script settings object.
  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
    • `行先$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, type is "script", 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手続き %C が指定されている ] ⇒ %応答 ~LET 次を与える下で, %C を遂行した結果 ⇒ %要請, [ `~top-level内~flag$V ~SET ~ON ] ◎ 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 and abort these steps.
  5. %~source~text ~LET %応答 の`本体$rsを `~UTF-8復号-$した結果 ◎ Let source text be the result of UTF-8 decoding response's body.
  6. %黙秘error~flag ~LET [ %応答 は`~CORS非同一生成元$であるならば ~ON / ~ELSE_ ~OFF ] ◎ ↓
  7. %~script ~LET 次を与える下で,`~classic~scriptを作成-$した結果: %~source~text, %設定群~obj, %黙秘error~flag ◎ Let script be the result of creating a classic script using source text and settings object. ◎ If response was CORS-cross-origin, then pass the muted errors flag to the create a classic script algorithm as well.
  8. ~RET %~script ◎ Return script.

`~module~script~graphを~fetchする@ ときは、所与の ( %~url, %設定群~obj, %行先, %暗号用~nonce, %構文解析器~状態, %資格証~mode, ) に対し,次を走らす。 この~algoは、[ (失敗~時には)~NULL / (成功~時には)`~module~script$ ]いずれかを結果として,`非同期に完了-$する: ◎ To fetch a module script graph given a url, a settings object, a destination, a cryptographic nonce, a parser state, and a credentials mode, run these steps. The algorithm will asynchronously complete with either null (on failure) or a module script (on success).

  1. 次を与える下で,`~module~script~graphを~fetchする内部手続き$を遂行する: %~url, %設定群~obj, %行先, %暗号用~nonce, %構文解析器~状態, %資格証~mode, %設定群~obj, 新たな空~list, `client^l, %~top-level~module~fetch~flag ~ON — この~algoの~call元にて`~fetchを遂行する$ ~custom手続きが指定されている場合、それも渡す。 ◎ Perform the internal module script graph fetching procedure given url, settings object, destination, cryptographic nonce, parser state, credentials mode, settings object, a new empty list, "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.
  2. `~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. 次を与える下で,`~module~script~graphを~fetchする内部手続き$を遂行する: %~url, %~fetch~client設定群~obj, %行先, 空~文字列, `not-parser-inserted^l, %資格証~mode, %~module~map設定群~obj 新たな空~list, `client^l, %~top-level~module~fetch~flag ~ON — この~algoの~call元にて`~fetchを遂行する$ ~custom手続きが指定されている場合、それも渡す。 ◎ Perform the internal module script graph fetching procedure given url, fetch client settings object, destination, the empty string, "not parser-inserted", credentials mode, module map settings object, a new empty list, "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.
  2. `~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, %行先, %暗号用~nonce, %構文解析器~状態, %資格証~mode, %~module~map設定群~obj, %先祖~list, %~referrer, %~top-level~module~fetch~flag ) に対し,次の手続きを遂行する。 この~algoは、[ (失敗~時には)~NULL / (成功~時には)`~module~script$ ]いずれかを結果として,`非同期に完了-$する: ◎ To perform the internal module script graph fetching procedure given a url, a fetch client settings object, a destination, a cryptographic nonce, a parser state, a credentials mode, a module map settings object, an ancestor list, 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. 次を与える下で,`単独の~module~scriptを~fetchする$: %~url, %~fetch~client設定群~obj, %行先, %暗号用~nonce, %構文解析器~状態, %資格証~mode, %~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, cryptographic nonce, parser state, credentials mode, 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.

    この段の~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. %結果 は`~module~script$である — 次を与える下で, %結果 の`子孫を~fetchする$ ⇒ %行先, [ %先祖~list に %~url を付加した結果 ] ◎ Otherwise, result is a module script. Fetch the descendants of result given destination and an ancestor list obtained by appending url to ancestor list. Wait for fetching the descendants of a module script to asynchronously complete with descendants result before proceeding to the next step.

      この段の~fetchが %子孫~結果 を結果として`非同期に完了-$したときは: ◎ ↑

      1. %~record ~LET %結果 の`~module~record$mS ◎ Let record be result's module record.
      2. %~instance化~status ~LET %~record . `ModuleDeclarationInstantiation$jA() ◎ Let instantiationStatus be record.ModuleDeclarationInstantiation().

        注記: この段は、当の~moduleの~instance化されていない依存関係すべてに対し,再帰的に `ModuleDeclarationInstantiation$jA() を~callする。 ◎ This step will recursively call ModuleDeclarationInstantiation all of the module's uninstantiated dependencies.

      3. ~FOR %結果 の`~instance化されていない広義~子孫~module~script$内の ~EACH( `~module~script$ %~script ) に対し: ◎ For each module script script in result's uninstantiated inclusive descendant module scripts, perform the following steps:

        1. ~IF[ %~instance化~status は中途完了である ]:
          • %~script の`~instance化~状態$mS ~SET `errored^l
          • %~script の`~instance化~error$mS ~SET %~instance化~status .`Value^sl
          • %~script の`~module~record$mS ~SET ~NULL
          ◎ If instantiationStatus is an abrupt completion, then set script's instantiation state to "errored", its instantiation error to instantiationStatus.[[Value]], and its module record to null.
        2. ~ELSE ⇒ %~script の`~instance化~状態$mS `instantiated^l ◎ Otherwise, set script's instantiation state to "instantiated".
      4. %子孫~結果 を結果として`非同期に完了-$する ◎ Asynchronously complete this algorithm with descendants result.

        注記: ここで %結果 ではなく %子孫~結果 で完了することは意図的である — これにより、~error合図は~call元まで伝播するようになる。 ◎ It is intentional that we complete with descendants result here, and not result, as this allows us to propagate error signals to the caller.

上の~algoにおける`~module~script$ %~script の `~instance化されていない広義~子孫~module~script@ とは、次に従って決定される`~module~script$の`有順序~集合$である: ◎ In the above algorithm, a module script script's uninstantiated inclusive descendant module scripts is a set of module scripts determined as follows:

  1. %~module~map ~LET %~script の`設定群~obj$の`~module~map$enV ◎ Let moduleMap be script's settings object's module map.
  2. %~stack ~LET `~stack$ « %script » ◎ Let stack be the stack « script ».
  3. %広義~子孫 ~LET 空の`有順序~集合$ ◎ Let inclusive descendants be an empty set.
  4. ~WHILE[ %~stack は`空$でない ]: ◎ While stack is not empty:

    1. %現~script ~LET %~stack から`~pop$した結果 ◎ Let current the result of popping from stack. Let current be the last element of stack. Remove it from stack.
    2. ~IF[ %現~script `~NIN$ %広義~子孫 ]~AND[ %現~script `~NIN$ %~stack ]: ◎ If inclusive descendants and stack both do not contain current, then:

      1. %現~script を %広義~子孫 に`付加-$する ◎ Append current to inclusive descendants.
      2. ~FOR ( %現~script の`~module~record$mS ) . `RequestedModules^sl 内の ~EACH ( %指定子 ) に対し:

        1. %~URL ~LET 次を与える下で,`~module指定子を解決-$した結果 ⇒ ( %現~script, %指定子 )
        2. ~IF[ %~URL ~EQ `失敗^i ] ⇒ ~CONTINUE
        3. %子~module ~LET %~module~map[ %~URL ]
        4. ~IF[ %子~module ~EQ ε ] ⇒ ~CONTINUE
        5. ~IF[ %子~module `~NIN$ %広義~子孫 ] ⇒ %子~module を %~stack に`~push$する
        ◎ Let child specifiers be the value of current's module record's [[RequestedModules]] internal slot. ◎ Let child URLs be the list obtained by calling resolve a module specifier once for each item of child specifiers, given current and that item. Omit any failures. ◎ Let child modules be the list obtained by getting each value in moduleMap whose key is given by an item of child URLs. ◎ For each s in child modules that is not contained by inclusive descendants, push s onto stack.
  5. ~RET %広義~子孫 内の~itemのうち[ `~instance化~状態$mS ~EQ `uninstantiated^l ]なる~itemすべてからなる`有順序~集合$ ◎ Return a set containing all items of inclusive descendants whose instantiation state is "uninstantiated".

注記: 上の~algoは、~moduleの依存関係~graphを深さ~~優先で探索する。 ここでの主な関心は,この~graphの “辺” を決定する方法であり、実際の探索~法は重要でない — 出力の`有順序~集合$は, `~NIN$ かどうかを試すために利用されるのみであり、その順序は重要でないので。 ◎ The above algorithm gives a depth-first search of the module dependency graph. The main interesting part is in how the "edges" of this graph are determined. The actual search implementation is not important; any other technique for exploring the graph will suffice, given that the output is a set only used for membership testing and whose order is thus not important.

`単独の~module~scriptを~fetchする@ するときは、所与の ( %~url, %~fetch~client設定群~obj, %行先, %暗号用~nonce, %構文解析器~状態, %資格証~mode, %~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, a cryptographic nonce, a parser state, a credentials mode, 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を待入する$ ◎ 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 %行先
    • `種別$rq ~SET `script^l
    • `~mode$rq ~SET `cors^l
    • `資格証~mode$rq ~SET %資格証~mode
    • `暗号用~nonce~metadata$rq ~SET %暗号用~nonce
    • `構文解析器~metadata$rq ~SET %構文解析器~状態
    • `~referrer$rq ~SET %~referrer
    • `~client$rq ~SET %~fetch~client設定群~obj
    ◎ Let request be a new request whose url is url, destination is destination, type is "script", mode is "cors", credentials mode is credentials mode, cryptographic nonce metadata is cryptographic nonce, parser metadata is parser state, referrer is referrer, and client is fetch client settings object.
  6. ~IF[ この~algoの~call元にて,`~fetchを遂行する$ ~custom手続き %C が指定されている ]:

    1. 次を与える下で, %C を遂行する ⇒ %要請, [ `~top-level内~flag$V ~SET %~top-level~module~fetch~flag ]
    2. ~RET — ただし,以降の手続きは、 %C を完了した結果の`応答$ %応答 に対し走らす
    ◎ 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.

  7. ~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 ~NIN { `~ok~status$rs } ◎ response's status is not an ok status
    • %応答 の`~header~list$rsから`~MIME型を抽出-$した結果 ~NIN { `~JS~MIME型$ } (~MIME~parameterは無視して) ◎ The result of extracting a MIME type from response's header list (ignoring parameters) 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.

  8. %~source~text ~LET %応答 の`本体$rsを `~UTF-8復号-$した結果 ◎ Let source text be the result of UTF-8 decoding response's body.
  9. %~module~script ~LET 次を与える下で,`~module~scriptを作成-$した結果: %~source~text, %~module~map設定群~obj, %応答 の`~url$rs, %暗号用~nonce, %構文解析器~状態, %資格証~mode ◎ Let module script be the result of creating a module script given source text, module map settings object, response's url, cryptographic nonce, parser state, and credentials mode.
  10. %~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$mSは`応答~URL$rsに設定されるのは、意図的である。 前者は~fetchを重複する`させなくする?^tnoteために利用される一方で、後者は~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 の `子孫を~fetchする@ ときは、所与の ( %行先, %先祖~list ) に対し,次を走らす。 この~algoは、[ (失敗~時には)~NULL / (成功~時には)`~module~script$ ]いずれかを結果として,`非同期に完了-$する: ◎ To fetch the descendants of a module script module script, given a destination and an ancestor list, run these steps. The algorithm will asynchronously complete with either null (on failure) or with module script (on success).

  1. %~record ~LET %~module~script の`~module~record$mS ◎ Let record be module script's module record.
  2. ~IF[ %~record . `RequestedModules^sl は`空$である ] ⇒ %~module~script を結果として,`非同期に完了-$する ◎ If record.[[RequestedModules]] is empty, asynchronously complete this algorithm with module script.
  3. %~url~list ~LET 新たな空`~list$ ◎ Let urls be a new empty list.
  4. ~FOR %~record . `RequestedModules^sl 内の `~EACH$ ( 文字列 %requested ) に対し: ◎ For each string requested of record.[[RequestedModules]],

    1. %~url ~LET 次を与える下で,`~module指定子を解決-$した結果 ⇒ %~module~script, %requested ◎ Let url be the result of resolving a module specifier given module script and requested.
    2. ~IF[ %~url ~EQ `失敗^i ]: ◎ If the result is error:

      1. %~error ~LET 新たな `TypeError$js 例外 ◎ Let error be a new TypeError exception.
      2. 次を与える下で,`例外を報告する$ ⇒ %~module~script, %~error ◎ Report the exception error for module script.
      3. ~NULL を結果として,`非同期に完了-$する ◎ Abort this algorithm, and asynchronously complete it with null.
    3. ~ELIF[ %~url `~NIN$ %先祖~list ] ⇒ %~url~list に %~url を`付加-$する ◎ Otherwise, if ancestor list does not contain url, append url to urls.
  5. %~url~list 内の `~EACH$ ( %~url ) に対し ⇒ 次を与える下で,`~module~script~graphを~fetchする内部手続き$を遂行する: %~url, %~module~script の`資格証~mode$mS, %~module~script の`暗号用~nonce$mS, %~module~script の`構文解析器~状態$mS, %行先, %~module~script の`設定群~obj$, %~module~script の`設定群~obj$, %先祖~list, %~module~script の`基底~URL$mS, %~top-level~module~fetch~flag ~OFF — この~algoの~call元にて`~fetchを遂行する$ ~custom手続きが指定されている場合、それも渡す。 ◎ For each url in urls, perform the internal module script graph fetching procedure given url, module script's credentials mode, module script's cryptographic nonce, module script's parser state, destination, module script's settings object, module script's settings object, ancestor list, 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.

    すべての %~url に対する~fetchingが`非同期に完了-$するまで待機した上で:

    • ある %~url に対する~fetchingが[ ~NULL を結果として,`非同期に完了-$した ]ときは ⇒ ~NULL を結果として,`非同期に完了-$する
    • 他の場合 ⇒ %~module~script を結果として,`非同期に完了-$する
    ◎ Wait for all of the internal module script graph fetching procedure invocations to asynchronously complete. If any of them asynchronously complete with null, then asynchronously complete this algorithm with null. Otherwise, asynchronously complete this algorithm with module script.

8.1.3.3. ~scriptの作成法

`~classic~scriptを作成-@ するときは、所与の ( %~script~source, %環境~設定群~obj, %黙秘error~flag ) に対し,次を走らす: ◎ To create a classic script, given some script source, an environment settings object, and an optional muted errors flag:

  1. %~script ~LET 新たな`~classic~script$ ◎ Let script be a new classic script that this algorithm will subsequently initialize.
  2. %~script の`設定群~obj$ ~SET %環境~設定群~obj ◎ Set script's settings object to the environment settings object provided.
  3. %~script の`~source~text$ ~SET[ %環境~設定群~obj の`担当の閲覧文脈$enVにおいて `~scriptingは不能化され$ているならば 空~文字列 / ~ELSE_ %~script~source ] ◎ If scripting is disabled for the given environment settings object's responsible browsing context, then set script's source text to the empty string. Otherwise, set script's source text to the supplied script source.
  4. ~IF[ %黙秘error~flag ~EQ ~ON ] ⇒ %~script の`黙秘error~flag$ ~SET ~ON ◎ If the muted errors flag was set, then set script's muted errors flag.
  5. ~RET %~script ◎ Return script.

`~module~scriptを作成-@ するときは、所与の ( %~script~source, %環境~設定群~obj, %~script基底~URL, %暗号用~nonce, %構文解析器~状態, %資格証~mode ) に対し,次を走らす: ◎ To create a module script, given some script source, an environment settings object, a script base URL, a cryptographic nonce, a parser state, and a credentials mode:

  1. %~script ~LET 新たな`~module~script$ ◎ Let script be a new module script that this algorithm will subsequently initialize.
  2. %~script の`設定群~obj$ ~SET %環境~設定群~obj ◎ Set script's settings object to the environment settings object provided.
  3. %~realm ~LET %環境~設定群~obj の`~Realm$ ◎ Let realm be the provided environment settings object's Realm.
  4. ~IF[ %環境~設定群~obj の`担当の閲覧文脈$enVにおいて `~scriptingは不能化され$ている ] ⇒ %~script~source ~SET 空~文字列 ◎ If scripting is disabled for the given environment settings object's responsible browsing context, then let script source be the empty string. Otherwise, let script source be the provided script source.
  5. %結果 ~LET `ParseModule$jA( %~script~source, %~realm, %~script ) ◎ Let result be ParseModule(script source, realm, script).
  6. ~IF[ %結果 は ~errorたちの`~list$である ]

    1. 次を与える下で,`例外を報告する$ ⇒ %~script, %結果 の最初の要素
    2. ~RET ~NULL
    ◎ If result is a List of errors, report the exception given by the first element of result for script, return null, and abort these steps.
  7. %~script の`~module~record$mS ~SET %結果 ◎ Set script's module record to result.
  8. %~script の`基底~URL$mS ~SET %~script基底~URL ◎ Set script's base URL to the script base URL provided.
  9. %~script の`暗号用~nonce$mS ~SET %暗号用~nonce ◎ Set script's cryptographic nonce to the cryptographic nonce provided.
  10. %~script の`構文解析器~状態$mS ~SET %構文解析器~状態 ◎ Set script's parser state to the parser state.
  11. %~script の`資格証~mode$mS ~SET %資格証~mode ◎ Set script's credentials mode to the credentials mode provided.
  12. ~RET %~script ◎ Return script.

8.1.3.4. ~scriptの~call法

`~classic~scriptを走らす@ ときは、所与の ( `~classic~script$ %~script, %再投出error~flag ) に対し,次を走らす: ◎ To run a classic script given a classic script s and an optional rethrow errors flag:

  1. %設定群 ~LET %~script の`設定群~obj$ ◎ Let settings be the settings object of s.
  2. ~IF[ %設定群 を用いて`~scriptは走れるかどうか検査-$した結果 ~EQ `走るな^i ] ⇒ ~RET undefined ◎ Check if we can run script with settings. If this returns "do not run", then return undefined and abort these steps.
  3. %~realm ~LET %設定群 の`~Realm$ ◎ Let realm be settings's Realm.
  4. %設定群 を用いて`~scriptを走らすために準備する$ ◎ Prepare to run script with settings.
  5. %結果 ~LET `ParseScript$jA( %~script の`~source~text$, %~realm, %~script ) ◎ Let result be ParseScript(s's source text, realm, s).
  6. ~IF[ %結果 は ~errorたちの`~list$である ] ⇒ %結果 ~SET %結果 の最初の要素;
    ~GOTO `~error^i ◎ If result is a List of errors, set result to the first element of result and go to the step labeled error.
  7. %評価~status ~LET `ScriptEvaluation$jA( %結果 ) ◎ Let evaluationStatus be ScriptEvaluation(result).
  8. %評価~status に応じて:

    中途完了である
    %結果 ~SET %評価~status . `Value^sl;
    ~GOTO `~error^i
    正常完了である
    存在しない(~UAは`走っている~scriptを中止-$したため `ScriptEvaluation^jA は完了しなかった)
    ~GOTO `片付け^i
    ◎ If evaluationStatus is an abrupt completion, set result to evaluationStatus.[[Value]] and go to the next step (labeled error). If evaluationStatus is a normal completion, or if ScriptEvaluation does not complete because the user agent has aborted the running script, skip to the step labeled cleanup.
  9. `~error^i (この時点で %結果 は例外である): ◎ Error: At this point result must be an exception. Perform the following steps:

    1. ~IF[ %再投出error~flag ~EQ ~ON ]:

      1. ~IF[ %~script の %黙秘error~flag ~EQ ~ON ] ⇒ `NetworkError$E を投出する†
      2. ~ELSE ⇒ %結果 を再投出する†

      【† この手続きの最後の段の記述から、例外を投出した後も,この手続きは続行すると見られる。 】

      ◎ If the rethrow errors flag is set and s's muted errors flag is not set, rethrow result. ◎ If the rethrow errors flag is set and s's muted errors flag is set, throw a "NetworkError" DOMException.
    2. ~ELSE ⇒ 次を与える下で,`例外を報告する$ ⇒ %~script, %結果 ◎ If the rethrow errors flag is not set, report the exception given by result for the script s.
  10. `片付け^i: %設定群 を用いて,`走らせた~scriptを片付ける$ ◎ Cleanup: Clean up after running script with settings.
  11. ~IF[ %評価~status は正常完了である ] ⇒ ~RET %評価~status . `Value^sl ◎ ↓
  12. ~ELSE ⇒ ~script実行は、次のいずれかのため,成功しなかったことになる ⇒ 構文解析-時に~errorが生じた / 評価の間に例外が生じた / 尚早に`中止-$された ◎ If evaluationStatus exists and is a normal completion, return evaluationStatus.[[Value]]. Otherwise, script execution was unsuccessful, either because an error occurred during parsing, or an exception occurred during evaluation, or because it was aborted prematurely.

`~module~scriptを走らす@ ときは、所与の ( `~module~script$ %~script ) に対し,次を走らす: ◎ To run a module script given a module script s:

  1. %設定群 ~LET %~script の`設定群~obj$ ◎ Let settings be the settings object of s.
  2. ~IF[ %設定群 を用いて`~scriptは走れるかどうか検査-$した結果 ~EQ `走るな^i ] ⇒ ~RET ◎ Check if we can run script with settings. If this returns "do not run" then abort these steps.
  3. ~IF[ %~script の`~instance化~状態$mS ~EQ `errored^l ]:

    1. 次を与える下で,`例外を報告する$ ⇒ %~script, %~script の`~instance化~error$mS
    2. ~RET
    ◎ If s's instantiation state is "errored", then report the exception given by s's instantiation error for s and abort these steps.
  4. ~Assert: %~script の`~instance化~状態$mS ~EQ `instantiated^l (したがって, %~script の`~module~record$mS ~NEQ ~NULL ) ◎ Assert: s's instantiation state is "instantiated" (and thus its module record is not null).
  5. %~record ~LET %~script の`~module~record$mS ◎ Let record be s's module record.
  6. %設定群 を用いて`~scriptを走らすために準備する$ ◎ Prepare to run script given settings.
  7. %評価~status ~LET %~record . `ModuleEvaluation$jA() ◎ Let evaluationStatus be record.ModuleEvaluation().

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

  8. ~IF[ %評価~status は中途完了である ] ⇒ 次を与える下で,`例外を報告する$ ⇒ %~script, %評価~status . `Value^sl

    (~UAが`走っている~scriptを中止-$したため `ModuleEvaluation$jA は完了しなかった場合には、この段は遂行しないこと。)

    ◎ If evaluationStatus is an abrupt completion, then report the exception given by evaluationStatus.[[Value]] for s. (Do not perform this step if ModuleEvaluation fails to complete as a result of the user agent aborting the running script.)
  9. %設定群 を用いて,`走らせた~scriptを片付ける$ ◎ Clean up after running script with settings.

`環境~設定群~obj$ %設定群 を用いて `~scriptは走れるかどうか検査-@ する手続きは、次で与えられ,[ `走れ^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$sT は`~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" and abort these steps.
  2. ~IF[ %設定群 により指定される`担当の閲覧文脈$enVにおいて `~scriptingは不能化され$ている ] ⇒ ~RET `走るな^i ◎ If scripting is disabled for the responsible browsing context specified by settings, then return "do not run" and abort these steps.
  3. ~RET `走れ^i ◎ Return "run".

`環境~設定群~obj$ %設定群 を用いて, `~scriptを走らすために準備する@ 手続きは、次で与えられる: ◎ The steps to prepare to run script with an environment settings object settings are as follows:

  1. %設定群 の`~realm実行~文脈$enVの`入場~counter$ ~INCBY 1 ◎ Increment settings's realm execution context's entrance counter by one.
  2. %設定群 の`~realm実行~文脈$enVを`~JS実行~文脈~stack$jsに~pushする — この時点で、それが`走っている~JS実行~文脈$jsになる。 ◎ Push settings's realm execution context onto the JavaScript execution context stack; it is now the running JavaScript execution context.

`環境~設定群~obj$ %設定群 を用いて, `走らせた~scriptを片付ける@ 手続きは、次で与えられる: ◎ The steps to clean up after running script with an environment settings object settings are as follows:

  1. ~Assert: %設定群 の`~realm実行~文脈$enVは、`走っている~JS実行~文脈$jsである ◎ Assert: settings's realm execution context is the running JavaScript execution context.
  2. `~JS実行~文脈~stack$jsから, %設定群 の`~realm実行~文脈$enVを除去する ◎ Remove settings's realm execution context from the JavaScript execution context stack.
  3. %設定群 の`~realm実行~文脈$enVの`入場~counter$ ~DECBY 1 ◎ Decrement settings's realm execution context's entrance counter by one.
  4. ~IF[ `~JS実行~文脈~stack$jsは空になった ] ⇒ `極小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実行~文脈$jsの `ScriptOrModule^jA 成分の `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$jsの `GlobalObject^sl ~fieldである~JS~objである。 ◎ A global object is a JavaScript object that is the [[GlobalObject]] field of a JavaScript realm.

この仕様では、すべての`~JS~realm$jsは,[[ `Window$I, `WorkerGlobalScope$I ]いずれかの~objである`大域~obj$ ]で`初期化-$jsされる。 ◎ In this specification, all JavaScript realms are initialized with global objects that are either Window or WorkerGlobalScope objects.

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

  • %R 視点からは:

    • %R の `HostDefined^sl ~fieldが,対応する %S を与える — %S を指して ~Realm %R の `設定群~obj@rM という。
    • %R の `GlobalObject^sl ~fieldが,対応する %G を与える — %G を指して ~Realm %R の `大域~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 は,対応する %R が`初期化-$jsされる間に作成される。 %R を指して %G の `~Realm@gL という。
    • %G は,対応する %S と並行して作成される。 %S は %G に`関連する設定群~obj$と呼ばれる。
    ◎ Each global object in this specification is created during the initialization 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.
  • %S 視点からは:

    • %S の`~realm実行~文脈$enVの~Realm成分が,対応する %R を与える — %R を指して %S の `~Realm@ という。
    • 対応する %G (すなわち, %S の`~Realm$ の `GlobalObject^sl ~field)を指して %S の `大域~obj@sT という。
    ◎ 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.

この仕様~全体を通して、~algoの手続きを定義するときに,どの`~JS~realm$jsが利用されるか — あるいは,同じことだが、どの`大域~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 某)
これは、現在~走っている~script動作を起動した~scriptに対応する `もしあれば^tnote : すなわち、[ 作者~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 某)

これは、作者による[ 関数/~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 某)
これは、現在~走っている関数~objに対応する。 これには、~JSとして実装されていないかもしれないような,~UAに組込みの関数も含まれる(それは`現在の~JS~realm$jsから導出される)。 ◎ 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$jsである。 ~algoを書くときに,[ `関連する~Realm$が重要になり得るような`~platform~obj$ ]として,真っ先に挙がるのは、現在~走っている関数~objの `this^b 値になる。 一部の事例では、引数のそれなど,`関連する~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^s は~browser~window内に読込まれていて, `b.html^s は 示されているように `iframe$e 内に読込まれていて, `c.html^s, `d.html^s は省略されている(単純に,空~文書でもよい) とする: ◎ Consider the following pages, with a.html being loaded in a browser window, b.html being loaded in an iframe as shown, and c.html and d.html omitted (they can simply be empty documents):

<!-- a.html -->
<!DOCTYPE html>
<html lang="ja">
<title>入口~頁</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>

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

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

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

`現任の某$, `入口~某$ の概念は、あまりに複雑で直感的でないので,新たな仕様には利用されるべきでない。 既存の利用は,~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^b 値になる)に適用して利用するべきである。 これは、~JS仕様と合致していない — そこでは、一般に,`現在の某$が既定として利用されている(例: `Array.prototype.map^c の結果を構築する際に利用されるべき `Array^c 構築子が属する`~JS~realm$jsを決定するときなど)。 が、この不一致は,策定を進めるためには受容する必要があるものとして,~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^b 値がまだないので,`現在の某$ の概念が適切な既定になることに注意。 ◎ Note that in constructors, where there is no this value yet, the current concept is the appropriate default.

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

<!-- outer.html -->
<!DOCTYPE html>
<html lang="ja">
<title>関連する~Realmの例証: outer 頁</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>

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


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

8.1.3.5.1. 入口~某

すべての`~realm実行~文脈$enVは、自身の~code評価~状態の一部として, `入場~counter@ 値 — 初期~時は 0 — を包含し~MUST。 この値は、 ~callしている~script の処理-において,増減されることになる。 ◎ All realm execution contexts must contain, as part of their code evaluation state, an entrance counter value, which is initially zero. In the process of calling scripts, this value will be incremented and decremented.

これをもって, `入口~実行~文脈@ は、`~JS実行~文脈~stack$js内の[ `入場~counter$ 値 ~GT 0 ]なる~entryのうち,最も近過去に~pushされたものとして定義される。 `入口~Realm@ は、`入口~実行~文脈$の~Realm成分で与えられる。 ◎ With this in hand, we define the entry execution context to be the most recently pushed entry in the JavaScript execution context stack whose entrance counter value is greater than zero. The entry Realm is the entry execution context's Realm component.

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

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

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

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

[ 作者~codeを ~WebIDLを利用して`呼出す$x / `EnqueueJob^jA が~promise~jobを呼出す ]ときは、次の~algoを利用して,[ `現任の設定群~obj$を決定するときに関連する~data ]を追跡する: ◎ When Web IDL is used to invoke author code, or when EnqueueJob invokes a promise job, they use the following algorithms to track relevant data for determining the incumbent settings object:

`環境~設定群~obj$ %設定群 で `~callbackを走らすために準備する@ ときは: ◎ To prepare to run a callback with an environment settings object settings:

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

`環境~設定群~obj$ %設定群 で `走らせた~callbackを片付ける@ ときは: ◎ To clean up after running a callback with an environment settings object settings:

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

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

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

ここでの `~scriptを有している最上端の実行~文脈@ は、[ `~JS実行~文脈~stack$jsの最上端の~entryが[ 非 ~NULL の `ScriptOrModule^jA 成分を有する ]ならば それ / ~ELSE_ ~NULL ]である。 ◎ Here, the topmost script-having execution context is the topmost entry of the JavaScript execution context stack that has a non-null ScriptOrModule component, or null if there is no such entry in the JavaScript execution context stack.

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

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

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

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

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

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

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

以下に示す一連の例は、各種 仕組みが `現任の某$ の概念の定義にどう関わるかを,はっきりさせるために意図されている: ◎ The following series of examples is intended to make it clear how all of the different mechanisms contribute to the definition of the incumbent concept:

次のごく単純な例を考える: ◎ Consider the following very simple example:

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

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

(この例では、 `frames[0]^c の`環境~設定群~obj$は,全く孕まれない。 それが`現在の設定群~obj$になるが、 `MessageChannel()$m 構築子は,現在の某ではなく 現任の某についてのみ~careする。) ◎ (In this example, the environment settings object of frames[0] is not involved at all. It is the current settings object, but the MessageChannel() constructor cares only about the incumbent, not current.)

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

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

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

その~algoを起こした担当の作者~scriptは, `frames[0]^c ではなく `window^c 内で実行されているので、直感的に捉えるなら, `window^c のそれになるべきである。 この直感は、[ `現任の某$ の概念は、非同期な~algoの呼出ing(この事例では `setTimeout()$m を介するそれ)により変化するべきでない ]と捉えることもできる。 ◎ It should be that of window, to capture the intuitive notion that the author script responsible for causing the algorithm to happen is executing in window, not frames[0]. Another way of capturing the intuition here is that invoking algorithms asynchronously (in this case via setTimeout()) should not change the incumbent concept.

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

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

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

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

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

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

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

<!-- b.html -->
<!DOCTYPE html>
<iframe src="a.html"></iframe>
<script>
  const %iframe = document.querySelector("iframe");
  %iframe.onload = function onLoad() {
    %iframe.contentWindow.document.querySelector("button").click();
  };
</script>

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

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

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

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

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

8.1.3.5.3. 現在の某

~JS仕様は、 `現在の~Realm~Record$jsを定義している — “現在の~Realm” と略称されることもある。 `JAVASCRIPT$r ◎ The JavaScript specification defines the current Realm Record, sometimes abbreviated to the "current Realm". [JAVASCRIPT]

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

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

`~platform~obj$に `関連する設定群~obj@ は、次に従って定義される: ◎ The relevant settings object for a platform object is defined as follows:

~objが`大域~obj$である場合:
この仕様における各`大域~obj$は、[ それに`関連する設定群~obj$である,対応する`環境~設定群~obj$ ]に並行して,作成される。 ◎ Each global object in this specification is created alongside a corresponding environment settings object; that is its relevant settings object.
他の場合:

~objが`属する大域~環境$に`関連する設定群~obj$。 ◎ The relevant settings object for a non-global platform object o is the environment settings object whose global object is the global object of the global environment associated with o.

注記: “〜が`属する大域~環境$” ( global environment associated with 〜 ) の概念は、現代の~JS仕様と その`~JS~realm$jsの概念が~~出現する以前の,昔ながらのものである。 ~WebIDL仕様が更新されたときには、どの`~platform~obj$にも `~JS~realm$jsが結付けられ、この定義は,それらの用語で書き直せるようになることが期待されている。 `JAVASCRIPT$r `WEBIDL$r ◎ The "global environment associated with" concept is from the olden days, before the modern JavaScript specification and its concept of realms. We expect that as the Web IDL specification gets updated, every platform object will have a Realm associated with it, and this definition can be re-cast in those terms. [JAVASCRIPT] [WEBIDL]

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

  • `~platform~obj$に `関連する~Realm@ は、それに`関連する設定群~obj$の`~Realm$である。 ◎ Then, the relevant Realm for a platform object is the Realm of its relevant settings object.
  • `~platform~obj$に `関連する大域~obj@ は、それに`関連する設定群~obj$の`大域~obj$sTである。 ◎ Similarly, the relevant global object for a platform object is the global object of its relevant settings object.

8.1.3.6. ~scriptの強制終了

`走っている~scriptを中止-@ する必要が生じることはときどきある — ~JS仕様はその可能性について織込んでいないが。 これは、どの `ScriptEvaluation$jA / `ModuleEvaluation$jA も即時に止めた上で, `finally^c ~blockの様な通常の仕組みを誘発することなく,`~JS実行~文脈~stack$jsを空にする。 `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 ModuleEvaluation to cease immediately, emptying the JavaScript execution context stack without triggering any of the normal mechanisms like finally blocks. [JAVASCRIPT]

~UAは、~scriptに~~割り振る計算資源に制限を課してよい — 例えば[ CPU ~quota / 記憶域 / 実行~時間の総計 / 帯域幅 ]に対する制限など。 ~scriptがこれらの制限-を超過したときは、~UAは,次のいずれかをしてよい:

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

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

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

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

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

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

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

例えば上の例で言及した~promptは、[ `unload$et ~event~handlerを走せず,ただ頁~全体を閉じる仕組み ]を利用者に提供0することもできる。 ◎ 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待行列との統合

~JS仕様は、[ ~cleanな `手が加えられていない^tnote `~JS実行~文脈~stack$jsによる~promise演算を,一定の順序でどう実行するか ]についての ある種の不変則を指定するために、[ ~JS~job, および ~job待行列 ]の抽象化を定義している。 しかしながら,この仕様を書いている時点では、 ~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の多くの “実装定義” とされている各~節に与えられる自由度を利用して、この目的0のために それをひねくりまわすことも可能0ではある。 しかしながら、技術的には,実装定義の挙動の範囲内として是認される仕方ではあっても、結局は,本質的に~job待行列の基盤をまるごと迂回するような,遠回しでとっ散らかった回避策であふれることになる。 ここでは、この道は採らない代わりに,以下の各~下位~節に与える`故意的な違反$を導入する。 ◎ 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仕様により待加えられる~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.7.1. `EnqueueJob^jA(%queueName , %job , %arguments )

~JS仕様の `EnqueueJob$jA 抽象演算を~callすると記されている所では、それに代わって,次の~algoが利用され~MUST: ◎ When the JavaScript specification says to call the EnqueueJob abstract operation, the following algorithm must be used in place of JavaScript's EnqueueJob:

  1. ~Assert: %queueName ~EQ `PromiseJobs^l ( ~UAは、 `ScriptJobs^l を利用してはならない) ◎ Assert: queueName is "PromiseJobs". ("ScriptJobs" must not be used by user agents.)
  2. %~job設定群 ~LET 何らかの適切な`環境~設定群~obj$ ◎ Let job settings be some appropriate environment settings object.

    ここで利用すべき`環境~設定群~obj$をどう指定するかは、まだはっきりしていない。 実施においては、これは,~jobを実行している間に`入口~某$の概念が正しく指定されていないことを意味する。 issue #1189 における論点 を見よ。 ◎ It is not yet clear how to specify the environment settings object that should be used here. In practice, this means that the entry concept is not correctly specified while executing a job. See discussion in issue #1189.

  3. %現任の設定群 ~LET `現任の設定群~obj$ ◎ Let incumbent settings be the incumbent settings object.
  4. %~job設定群 の`担当の~event~loop$enV上に,次の手続きを遂行する`極小taskを待入する$: ◎ Queue a microtask, on job settings's responsible event loop, to perform the following steps:

    1. ~IF[ %~job設定群 を用いて`~scriptは走れるかどうか検査-$した結果 ~EQ `走るな^i ] ⇒ ~RET ◎ Check if we can run script with job settings. If this returns "do not run" then abort these steps.
    2. %~job設定群 を用いて,`~scriptを走らすために準備する$ ◎ Prepare to run script with job settings.
    3. %現任の設定群 を用いて,`~callbackを走らすために準備する$ ◎ Prepare to run a callback with incumbent settings.
    4. %結果 ~LET %arguments を引数たちに用いて %job により指定される抽象演算を遂行した結果 ◎ Let result be the result of performing the abstract operation specified by job, using the elements of arguments as its arguments.
    5. %現任の設定群 を用いて,`走らせた~callbackを片付ける$ ◎ Clean up after running a callback with incumbent settings.
    6. %~job設定群 を用いて,`走らせた~scriptを片付ける$ ◎ Clean up after running script with job settings.
    7. ~IF[ %結果 は中途完了である ] ⇒ %結果 . `Value^sl で与えられる例外を報告する ◎ If result is an abrupt completion, report the exception given by result.[[Value]].

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@ とは、`絶対~URL$から[ 次のいずれかとして与えられる値 ]への`有順序~map$である。

  • `~module~script$
  • ~NULL — 失敗した~fetchを表現するために利用される
  • `fetching^l — `後で前 2 項のいずれかの値に確定される,^tnote 仮入力~値

`~module~map$は、~importされた~JS~moduleが[ ~fetchされ, 構文解析され, 評価される ]のは、[ `文書$/`~worker$ ]ごとに一度限りになることを確保するために利用される。

◎ A module map is a map of absolute URLs to values that are either a module script, null (used to represent failed fetches), or a placeholder value "fetching". Module maps are used to ensure that imported JavaScript modules are only fetched, parsed, and evaluated once per Document or worker.

`~module~map$は ~URLを~keyとするので、次の~codeは, `~module~map$内に 3 個の別々の~entryを作成させることになる — それらの結果は 3 個の異なる~URLになるので: ◎ Since module maps are keyed by URL, the following code will create three separate entries in the module map, since it results in three different URLs:

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

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

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

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

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

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

`~module指定子を解決-@ する手続きは、所与の ( `~module~script$ %~script, 文字列 %指定子 ) に対し,次を走らす — これは[ `絶対~URL$, `失敗^i ]のいずれかを返す: ◎ To resolve a module specifier given a module script script and a string specifier, perform the following steps. It will return either an absolute URL or failure.

  1. ~IF[ %指定子 を`~URL構文解析器$にかけた結果 ~NEQ `失敗^i ] ⇒ ~RET その結果 ◎ Apply the URL parser to specifier. If the result is not failure, return the result.
  2. ~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 and abort these steps.

    注記: この制約は、将来に,“~~名前のみの” ~import指定子 — import `jquery^limport `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.

  3. ~RET [ 基底~URL: %~script の`基底~URL$mS ]の下で %指定子 を`~URL構文解析器$にかけた結果 ◎ Return the result of applying the URL parser to specifier with script's base URL as the base URL.

次のものは、上の~algoに則って妥当な~module指定子になる: ◎ The following are valid module specifiers according to the above algorithm:

  • `https://example.com/apples.js^l
  • `http:example.com\pears.mjs^l ( `http://example.com/pears.mjs^l になる — 段 1 は基底~URLなしで構文解析するので) ◎ http:example.com\pears.mjs (becomes http://example.com/pears.mjs as step 1 parses with no base URL)
  • `//example.com/bananas^l
  • `./strawberries.js.cgi^l
  • `../lychees^l
  • `/limes.jsx^l
  • `data:text/javascript,export default 'grapes';^l
  • `blob:https://whatwg.org/d0360e2f-caee-469f-9a2f-87d5b0456f6f^l

次のものは,上の~algoに則って妥当な~module指定子になるが、`単独の~module~scriptを~fetchする$ときには,常に失敗にされる: ◎ The following are valid module specifiers according to the above algorithm, but will invariably cause failures when they are fetched:

  • `javascript:export default 'artichokes';^l
  • `data:text/plain,export default 'kale';^l
  • `about:legumes^l
  • `wss://example.com/celery^l

次のものは、上の~algoに則って妥当な~module指定子にならない: ◎ The following are not valid module specifiers according to the above algorithm:

  • `https://eggplant:b/c^l
  • `pumpkins.js^l
  • `.tomato^l
  • `..zucchini.js^l
  • `.\yam.es^l
8.1.3.8.1. `HostResolveImportedModule^jA(%referencingModule , %specifier)

~JS `JAVASCRIPT$r は、その抽象演算 `HostResolveImportedModule$jA( %参照元~module , %指定子 ) を,実装定義であると~~規定している。 ~UAは、次の実装を利用し~MUST: ◎ JavaScript contains an implementation-defined HostResolveImportedModule abstract operation. User agents must use the following implementation: [JAVASCRIPT]

  1. %参照元~module~script ~LET %参照元~module . `HostDefined^sl ◎ Let referencing module script be referencingModule.[[HostDefined]].
  2. %~module~map ~LET %参照元~module~script の`設定群~obj$の`~module~map$enV ◎ Let moduleMap be referencing module script's settings object's module map.
  3. %~url ~LET 次を与える下で,`~module指定子を解決-$した結果 ⇒ %参照元~module~script, %指定子 ◎ ↓
  4. ~IF[ %~url ~EQ `失敗^i ] ⇒ ~THROW `TypeError$js ◎ Let url be the result of resolving a module specifier given referencing module script and specifier. If the result is failure, then throw a TypeError exception and abort these steps.
  5. %解決済~module~script ~LET %~module~map[ %~url ] ◎ ↓
  6. ~IF[ %解決済~module~script ~IN { ε, ~NULL, `fetching^l } ] ⇒ ~THROW `TypeError$js ◎ Let resolved module script be moduleMap[url]. If no such entry exists, or if resolved module script is null or "fetching", then throw a TypeError exception and abort these steps.
  7. ~IF[ %解決済~module~script の`~instance化~状態$mS ~EQ `errored^l ] ⇒ ~THROW %解決済~module~script の`~instance化~error$mS ◎ If resolved module script's instantiation state is "errored", then throw resolved module script's instantiation error.
  8. ~Assert: %解決済~module~script の`~instance化~状態$mS ~EQ `instantiated^l (したがって,その`~module~record$mS ~NEQ ~NULL ) ◎ Assert: resolved module script's instantiation state is "instantiated" (and thus its module record is not null).
  9. ~RET %解決済~module~script の`~module~record$mS ◎ Return resolved module script's module record.

8.1.3.9. 実行時~script~error

~UAは、 `~errorを報告する@ よう要求されたときは、所与の ( `~script$: %~script, 問題箇所: ( %行番号, %列番号 ), `大域~obj$: %標的 ) に対し,以下を走らせ~MUST。 この手続きは、その結果として,~errorの `取扱済み~flag@err を ~ON にし得る — 各~errorには,この~flagが結付けられ、初期~時は ~OFF (すなわち,~errorは `取扱済みでない@err )にされる。

◎ When the user agent is required to report an error for a particular script script with a particular position line:col, using a particular target target, it must run these steps, after which the error is either handled or not handled:
  1. ~IF[ %標的 は`~error報告~mode下$にある ] ⇒ ~RET ◎ If target is in error reporting mode, then abort these steps; 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 %~script が得られた資源に対応する`~URL~record$を`~URL直列化器$にかけた結果 ◎ 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~flag$ ~EQ ~ON ]:

    1. %~message ~SET `Script error.^l
    2. %~url文字列 ~SET 空~文字列
    3. %行番号 ~SET 0
    4. %列番号 ~SET 0
    5. %~error値 ~SET ~NULL
    ◎ If script has muted errors, then set message to "Script error.", urlString to the empty string, line and col to 0, and errorValue to null.
  7. %未取扱0 ~LET %標的 に向けて,次のようにされた`~eventを発火-$した結果:

    • 名前 `error$et
    • `ErrorEvent$I を利用する
    • ~eventの各種~属性は次のように初期化する:
      • `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.

8.1.3.9.1. 文書における実行時~script~error

`例外を報告する@ ときは、所与の ( `~script$ %~script, 例外 %E ) に対し,次を走らせ~MUST:

  1. 次を与える下で,その`~errorを報告する$: ~script: %~script 問題箇所: %~script を包含している資源~内の問題箇所 ( 行番号, 列番号 ) 標的: %~script の`設定群~obj$の`大域~obj$sT
  2. ~IF[ %E の`取扱済み~flag$err ~EQ ~OFF ] ⇒ 任意選択で、 %E を~UAの開発者~consoleに報告する
◎ When the user agent is to report an exception E, the user agent must report the error for the relevant script, with the problematic position (line number and column number) in the resource containing the script, using the global object specified by the script's settings object as the target. If the error is still not handled after this, then the error may be reported to a developer console.
8.1.3.9.2. `ErrorEvent^I ~interface
⇒! [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; }; ◎

`message@m 属性は、初期化-時の値を返さ~MUST。 これは、~error~messageを表現する。 ◎ The message attribute must return the value it was initialized to. It represents the error message.

`filename@m 属性は、初期化-時の値を返さ~MUST。 これは、~scriptにおいて~errorが元々生じた所の`~URL$を表現する。 ◎ The filename attribute must return the value it was initialized to. It represents the URL of the script in which the error originally occurred.

`lineno@m 属性は、初期化-時の値を返さ~MUST。 これは、~scriptにおいて~errorが元々生じた所の行番号を表現する。 ◎ The lineno attribute must return the value it was initialized to. It represents the line number where the error occurred in the script.

`colno@m 属性は、初期化-時の値を返さ~MUST。 これは、~scriptにおいて~errorが元々生じた所の列番号を表現する。 ◎ The colno attribute must return the value it was initialized to. It represents the column number where the error occurred in the script.

`error@m 属性は、初期化-時の値を返さ~MUST。 適切になる所では、これは,~errorを表現している~objに設定される(例: ~catchされなかった DOM 例外の事例では、例外~objになる)。 ◎ The error attribute must return the value it was initialized to. Where appropriate, it is set to the object representing the error (e.g., the exception object in the case of an uncaught DOM exception).

8.1.3.10. 未取扱いの~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, abort these steps.
  3. %設定群~obj の`通知待ちの却下済み~promise~list$enVを~~空にする ◎ Clear settings object's about-to-be-notified rejected promises list.
  4. 次の下位手続きを走らす`~taskを待入する$: ◎ Queue a task to run the following substep:

    1. ~FOR %~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$sTに向けて,次のようにされた`~eventを発火-$した結果:

        • `PromiseRejectionEvent$I ~interfaceを利用する
        • 名前 `unhandledrejection$et
        • ~eventの各種~属性は次のように初期化する:
          • `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.

8.1.3.10.1. `HostPromiseRejectionTracker^jA (%promise, %operation)

~JS `JAVASCRIPT$r は、その抽象演算 `HostPromiseRejectionTracker$jA( %promise, %演算 ) を,実装定義であると~~規定している。 ~UAは、次の実装を利用し~MUST: ◎ JavaScript contains an implementation-defined HostPromiseRejectionTracker(promise, operation) abstract operation. User agents must use the following implementation: [JAVASCRIPT]

  1. %~script ~LET `走っている~script$ ◎ Let script be the running script.

  2. ~IF[ %~script の`黙秘error~flag$ ~EQ ~ON ] ⇒ ~RET ◎ If script has muted errors, terminate these steps.
  3. %設定群~obj ~LET %~script の`設定群~obj$ ◎ Let settings object be script's settings object.
  4. ~IF[ %演算 ~EQ `reject^l ] ⇒ %設定群~obj の`通知待ちの却下済み~promise~list$enVに %promise を追加する ◎ If operation is "reject", ◎ Add promise to settings object's about-to-be-notified rejected promises list.

  5. ~ELIF[ %演算 ~EQ `handle^l ]: ◎ If operation is "handle",

    1. ~IF[ %promise ~IN %設定群~obj の`通知待ちの却下済み~promise~list$enV ] ⇒ その~listから %promise を除去する;
      ~RET ◎ If settings object's about-to-be-notified rejected promises list contains promise, remove promise from that list and abort these steps.
    2. ~IF[ %promise ~NIN %設定群~obj の`未決の却下済み~promiseへの弱参照~集合$enV ] ⇒ ~RET ◎ If settings object's outstanding rejected promises weak set does not contain promise, abort these steps.
    3. %設定群~obj の`未決の却下済み~promiseへの弱参照~集合$enVから %promise を除去する ◎ Remove promise from settings object's outstanding rejected promises weak set.
    4. 次を走らす`~taskを待入する$ ⇒ %設定群~obj の`大域~obj$sTに向けて,次のようにされた`~eventを発火-$する:

      • `PromiseRejectionEvent$I ~interfaceを利用する
      • 名前 `rejectionhandled$et
      • ~eventの各種~属性は次のように初期化する:
        • `promise$m ~SET %promise
        • `reason$m ~SET %promise の `PromiseResult^sl 内部slotの値
      ◎ Queue a task to fire an event named rejectionhandled at settings object's global object, using PromiseRejectionEvent, with the promise attribute initialized to promise, and the reason attribute initialized to the value of promise's [[PromiseResult]] internal slot.
8.1.3.10.2. `PromiseRejectionEvent^I ~interface
⇒! [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; }; ◎

`promise@m 属性は、初期化-時の値を返さ~MUST。 これは、この通知が~~対象にしている~promiseを表現する。 ◎ The promise attribute must return the value it was initialized to. It represents the promise which this notification is about.

`reason@m 属性は、初期化-時の値を返さ~MUST。 これは、~promiseの却下~事由を表現する。 ◎ The reason attribute must return the value it was initialized to. It represents the rejection reason for the promise.

8.1.3.11. `HostEnsureCanCompileStrings^A(%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. ~event~loop

8.1.4.1. 各種~定義

~UAは、この節に述べる `~event~loop@ を利用して,[ ~event, 利用者対話, ~script, 描画, ~networking, 等々 ]を互いに協調させ~MUST。 ~event~loopには、次の 2 種類がある:

`閲覧文脈~event~loop@
`閲覧文脈$に対するもの。
`~worker~event~loop@
`~worker$に対するもの(すなわち, `WorkerGlobalScope$I に対し走っている ~event~loop
◎ 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: those for browsing contexts, and those for workers.

`閲覧文脈~event~loop$は:

  • ~UAごとに,一つ以上~MUST。
  • 各[ `互関係かつ類似生成元の閲覧文脈~群$ ]ごとに,一つ以下で~MUST。
◎ There must be at least one browsing context event loop per user agent, and at most one per unit of related similar-origin browsing contexts.

注記: [ `互関係~閲覧文脈~群$ ] %U に対し,`~event~loop$が二つ以上あるとすると、[ %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$は、常に,一つ以上の`閲覧文脈$に属する — そのような`閲覧文脈$すべてが消去ると同時に,`~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ごとに,一つの`~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$は 一つ以上の `~task待行列@ を持つ。 `~task待行列$は何個かの `~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待行列$を利用して配送されるわけではない。 他の~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.

`閲覧文脈~event~loop$内の各`~task$には、`文書$が結付けられる — それは、~taskに応じて次で与えられる文書になる:

~taskは 要素の文脈~下で待入されたものである場合
要素の`~node文書$。
~taskは `閲覧文脈$の文脈~下で待入されたものである場合
待入された時点で,`閲覧文脈$にて`作動中の文書$。
~taskは `~script$[ により/に向けて ]待入されたものである場合
~scriptの`設定群~obj$により指定される`担当の文書$enV。
◎ Each task in a browsing context event loop is associated with a Document; if the task was queued in the context of an element, then it is the element's node document; if the task was queued in the context of a browsing context, then it is the browsing context's active document at the time the task was queued; if the task was queued by or for a script then the document is the responsible document specified by the script's settings object.

`~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 %~task を `待入する@ ときは ⇒ %~task を,それに関連する`~event~loop$に属する いずれかの`~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.

どの`~task$も,特定の `~task源@ から来るものとして定義される。 [ 特定0の`~task源$からの,特定0の`~event~loop$を行先にする ]ような,すべての~taskは、常に同じ`~task待行列$に追加され~MUST(例: `文書$の~timerにより生成される各~callback / `文書$上での~mouse移動により発火される各~event / `文書$の構文解析器により待入される各~task)。 一方で、異なる`~task源$からの`~task$は,異なる`~task待行列$に入れられてよい。 ◎ Each task is defined as coming from a specific task source. All the tasks from one particular task source and destined to a particular event loop (e.g. the callbacks generated by timers of a Document, the events fired for mouse movements over that Document, the tasks queued for the parser of that Document) must always be added to the same task queue, but tasks from different task sources may be placed in different task queues.

例えば~UAは、[ ~mouse/~key ]~eventに対しては,一つの`~task待行列$( `利用者対話~task源$ )をあてがい、他のすべてに対しては,別のものをあてがうこともできる。 その上で,~UAは、~UIを即応可能に保ちつつ, 他の~task待行列も放置しないよう,[ ~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.

各`~event~loop$は、 `現在~走っている~task@ (初期~時は ~NULL )を持つ。 これは、再入性を取扱うために利用される。 各`~event~loop$は、 `極小task~checkpoint遂行-中~flag@ (初期~時は ~OFF )も持つ。 これは、`極小task~checkpointを遂行する$~algoが再入的に呼出されるのを防止するために利用される。 ◎ Each event loop has a currently running task. Initially, this is null. It is used to handle reentrancy. Each event loop also has a performing a microtask checkpoint flag, which must initially be false. It is used to prevent reentrant invocation of the perform a microtask checkpoint algorithm.

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 は、 %~loop に属する ある`~task待行列$ %待行列 に属する — ~UAはどの`~task待行列$を~~選んでもよい。
    • %~loop は`閲覧文脈~event~loop$であるならば、 %~task に結付けらている`文書$は`全部的に作動中$である。
    • %~task は、上述に該当する~taskのうち,%待行列 内で最も遠過去のもの。
    ◎ Select 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. If there is no task to select, then jump to the microtasks step below.
  2. ~IF[ 該当する %~task はある ]: ◎ ↑

    1. %~loop の`現在~走っている~task$ ~SET %~task ◎ Set the event loop's currently running task to the task selected in the previous step.
    2. %~task を走らす ◎ Run: Run the selected task.
    3. %~loop の`現在~走っている~task$ ~SET ~NULL ◎ Set the event loop's currently running task back to null.
    4. %~task を %待行列 から除去する ◎ Remove the task that was run in the run step above from its task queue.
  3. `極小task~checkpointを遂行する$ ◎ Microtasks: Perform a microtask checkpoint.
  4. ~IF[ %~loop は`閲覧文脈~event~loop$である ] ⇒ 以下に従って`描画を更新する^i: ◎ 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 `Performance$I ~objの `now()$m ~methodから返される値 `HRT$r ◎ Let now be the value that would be returned by the Performance object's now() method. [HRT]
    2. %文書s ~LET %~loop に結付けられている`文書$たちの~list — それらの順序は、次の条件を満たさ~MUST(条件~以外は任意) ⇒ ~list内のどの二つの`文書$ %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閲覧文脈$はこの更新率を維持0できないときは,その`文書$の集合に対しては,~frameを時々落とすのではなく,より維持0し易い 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. ~FOR ~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. ~FOR ~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. ~FOR ~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. ~FOR ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して, %文書 に対する `~CSS~animationを走らせて~eventを送信する@ `CSSANIMATIONS$r ◎ For each fully active Document in docs, run CSS animations and send events for that Document, passing in now as the timestamp. [CSSANIMATIONS]
      5. ~FOR ~EACH( %文書 ) に対し ⇒ ( 時刻印: %now ) を渡して, %文書 に対する `全screen描画~手続き@ を走らす `FULLSCREEN$r ◎ For each fully active Document in docs, run the fullscreen rendering steps for that Document, passing in now as the timestamp. [FULLSCREEN]

        `28001$bug
      6. ~FOR ~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. ~FOR ~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. ~FOR ~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待行列$も空である ]~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.
  6. ~GOTO 最初の段 ◎ Return to the first step of the event loop.

各`~event~loop$は、 `極小task待行列@ を有する。 `極小task@ とは、元々は,`~task待行列$ではなく,`極小task待行列$に入れられた`~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を待入する@ ことが要求される所では、当の`極小task$を,関連する`~event~loop$の`極小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待行列$に移動されることもある — その初期 `初回の?^tnote 実行の間に,それが`~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, if the performing a microtask checkpoint flag is false, then the user agent must run the following steps:

  1. ~IF[ `極小task~checkpoint遂行-中~flag$ ~EQ ~ON ] ⇒ ~RET ◎ ↑
  2. %~loop ~LET 当の`~event~loop$
  3. `極小task~checkpoint遂行-中~flag$ ~SET ~ON ◎ Let the performing a microtask checkpoint flag be true.
  4. ~WHILE[ %~loop の`極小task待行列$は空でない ]: ◎ Microtask queue handling: If the event loop's microtask queue is empty, jump to the done step below.

    1. %極小task ~LET %~loop の`極小task待行列$上の最も遠過去の`極小task$ ◎ Select the oldest microtask on the event loop's microtask queue.
    2. %~loop の`現在~走っている~task$ ~SET 以前の段で選択された`~task$ ◎ Set the event loop's currently running task to the task selected in the previous step.
    3. %極小task を走らす ◎ Run: Run the selected task.

      注記: これは、~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待行列$から除去する;
      ◎ Remove the microtask run in the step above from the microtask queue, and return to the microtask queue handling step.
  5. ~FOR ~EACH( `環境~設定群~obj$ %設定群 ) に対し ⇒ ~IF[ %設定群 の`担当の~event~loop$enV ~EQ %~loop ] ⇒ %設定群 に対し,`却下済み~promiseについて通知する$ ◎ Done: 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 ◎ Let the performing a microtask checkpoint flag be 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. %親 ~LET %~loop の`現在~走っている~task$ (現在~走っている`複合~極小task$)。 ◎ Let parent be the event loop's currently running task (the currently running compound microtask).
  2. %下位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.
  3. %~loop の`現在~走っている~task$ ~SET %下位task ◎ Set the event loop's currently running task to subtask.
  4. %下位task を走らす ◎ Run subtask.
  5. %~loop の`現在~走っている~task$ ~SET %親 ◎ Set the event loop's currently running task back to parent.

~UAは、`並列的$に走っている %~algo において, `安定~状態を待受ける@ ときは、次の手続きを走らす`極小taskを待入する$と同時に, %~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による下位手続きとして与えることもある。^tnote ◎ 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$jsの複製 ◎ Let old stack be a copy of the JavaScript execution context stack.
  4. `~JS実行~文脈~stack$jsを空にする ◎ Empty the JavaScript execution context stack.
  5. `極小task~checkpointを遂行する$ ◎ Perform a microtask checkpoint.
  6. %~task を停止して,それを呼出した~algoを何であれ再開できるようにする一方で、この手続きは`並列的$に継続する ◎ Stop task, allowing whatever algorithm that invoked it to resume, but continue these steps in parallel.

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

    • `~event~loop$の~~主~手続き `処理~model節^tnote
    • `極小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 を`待入する$ ◎ ↓
  10. %継続~task が走らされるまで待機する ◎ Queue a task to continue running these steps, using the task source task source. Wait until this new task runs before continuing these steps.
  11. `~JS実行~文脈~stack$jsを %旧~stack で置換する ◎ Replace the JavaScript execution context stack with the old stack.
  12. ~RET — ~call元へ~~制御を返す ◎ Return to the caller.

【 上で停止された %~task はどうなる? 自動的に再開されるのか? 次の`一時停止-$に関連付けられているのか? 】


歴史的~理由から、この仕様の~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.

`一時停止-$は、とりわけ,複数の文書が単独の`~event~loop$を共有している局面では、利用者~体験をひどく~~害する。 ~UAには、既存の内容との互換性を保全しつつ可能0なら,`一時停止-$の別法 — `~event~loopを回す$, あるいは単純に あらゆる種類の実行を休止させずに,続行するなど — を試験することが奨励される。 より円滑で~web互換な別法が発見されたなら、この仕様は,積極的にそれを取り入れることになる。 ◎ Pausing is highly detrimental to the user experience, especially in scenarios where a single event loop is shared among multiple documents. User agents are encouraged to experiment with alternatives to pausing, such as spinning the event loop or even simply proceeding without any kind of suspended execution at all, insofar as it is possible to do so while preserving compatibility with existing content. This specification will happily change if a less-drastic alternative is discovered to be web-compatible.

実装者は、~UAが試験し得る様々な別法が,`~event~loop$の挙動の微妙な側面 — `~task$や`極小task$の時機も含め — を変更し得ることを,当分の間は意識しておくべきである。 実装は、そうすることが `一時停止-$演算に含意される正確な意味論に違反するとしても,試験し続けるべきである。 ◎ In the interim, implementers should be aware that the variety of alternatives that user agents might experiment with can change subtle aspects of event loop behavior, including task and microtask timing. Implementations should continue experimenting even if doing so causes them to violate the exact semantics implied by the pause operation.

8.1.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源$により`待入され$る`~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を待入するために利用される。 ◎ This task source is used to queue calls to history.back() and similar APIs.

8.1.5. ~event

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は、次の二つの仕方で公開される: ◎ 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$を,所与の値に設定し~MUST。
  • 取得子は、対応している`~event~handlerの現在の値を取得-$した結果を返さ~MUST。
◎ Event handler IDL attributes, on setting, must set the corresponding event handler to their new value, and on getting, must return the result of getting the current value of the event handler in question

`~event~handler~IDL属性$が、存在しない~objの`~event~handler$を公開する場合:

  • 取得子は、常に~NULLを返さ~MUST。
  • 設定子は、何もしては~MUST_NOT。
◎ If an event handler IDL attribute exposes an event handler of an object that doesn't exist, it must always return null on getting and must do nothing on setting.

注記: これは特に、対応している`~window$を有さない `body$e 要素~上の`~event~handler~IDL属性$に起こり得る。 `~windowのそれを反映する~IDL属性^tnote ◎ 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挿入$js後に, `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 abort these steps. [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 ~interfaceを実装している要素または~obj %T 上の`~event~handler$ %H が,最初に非 ~NULL 値に設定されるときは、~UAは、 %T に結付けられている[ `~event~listener$の~list ]に,次の組からなる`~event~listener$を付加し~MUST:

  • `type^i : %H に対応する `~event~handler~event型@
  • `callback^i : [ 1 個の引数をとる関数であって、 %H, およびその引数を与える下で,`~event~handler処理~algo$を実行するもの ]への参照を表現している,~Web~IDL `EventListener$I ~instanceを作成した結果

`EventListener$I の`~callback文脈$は、任意のものをとれる — それは `~event~handler処理~algo$には影響0しない。 `DOM$r

◎ When an event handler H of an element or object T implementing the EventTarget interface is first set to a non-null value, the user agent must append an event listener to the list of event listeners associated with T with type set to the event handler event type corresponding to H and callback set to 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. 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.

注記: ~event~listenerの付加-が起こるのは、 %H の値が初回に設定されるときに限られる。 ~listenerたちは、登録-順に~callされるので、 %T 上の特定0の~event型に対する~event~listenerたちは,常に次の順序で~callされる:

  1. %H が最初に非 ~NULL 値に設定される前に, %T 上の `addEventListener()$m で登録された~listenerたち
  2. 現在, %H に設定されている~callbackがあれば,その~listener
  3. %H が最初に非 ~NULL 値に設定された後に, %T 上の `addEventListener()$m で登録された~listenerたち
◎ This only happens the first time the event handler's value is set. Since listeners are called in the order they were registered, the order of event listeners for a particular event type will always be first the event listeners registered with addEventListener() before the first time the event handler was set to a non-null value, then the callback to which it is currently set, if any, and finally the event listeners registered with addEventListener() after the first time the event handler was set to a non-null value.

~event~listenerが呼出される順序を,次の~codeで例証する。 利用者がこの例の~buttonを~clickしたとき、頁は,順に~text[ `一^l, `二^l, `三^l, `四^l ]を伴う 4 回の~alertを示すことになる。 ◎ This example demonstrates the order in which event listeners are invoked. If the button in this example is clicked by the user, the page will show four alerts, with the text "ONE", "TWO", "THREE", and "FOUR" respectively.

<button id="test">Start Demo</button>
<script>
  var %button = document.getElementById('test');
  %button.addEventListener(
    'click', function(){ alert('一') }, false
  );
  %button.setAttribute(
    'onclick', "alert('この~alertは呼ばれない')"
  ); /* 
~event~handler~listenerはこの時点で登録される。
◎
event handler listener is registered here */

  %button.addEventListener(
    'click', function(){ alert('三') }, false
  );
  %button.onclick = function(){ alert('二'); };
  %button.addEventListener(
    'click', function(){ alert('四') }, false
  );
</script>

注記: ~event~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 %H に対し,`~event~handlerの現在の値を取得-$した結果 ◎ 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 abort these steps.
  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 を 呼出した 結果: ◎ Process the Event object E as follows:

    • `~callback this 値$ ~SET %E の`currentTarget$m ◎ ↓
    • 引数 ~SET `特別~error~event取扱い^V に応じて,[ ~F ならば %E のみ / ~T ならば 順に %E の ( `message$m, `filename$m, `lineno$m, `colno$m, `error$m ) 属性~値 ] ◎ ↓

      ◎ 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]

    ~IF[ %~callback から例外が投出された ] ⇒ ~RET — 例外は伝播させる(それは、 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. %返値 を処理する — 次のうち,最初に該当する条件に対応する段を走らす: ◎ Process return value as follows:

    [ %E は `BeforeUnloadEvent$I ~objである ]~AND[ %E の `type$m ~EQ `beforeunload$et ] ◎ 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.

    ~IF[ %返値 ~NEQ ~NULL ]: ◎ If return value is not null, then:

    1. %E の`取消ed~flag$ ~SET ~ON ◎ Set E's canceled flag.
    2. ~IF[ %E の `returnValue$m 属性~値 ~EQ 空~文字列 ] ⇒ %E の `returnValue$m 属性~値 ~SET %返値 ◎ E's returnValue attribute's value is the empty string, then set the returnValue attribute's value to return value.
    `特別~error~event取扱い^V ~EQ ~T ◎ If special error event handling is true
    ~IF[ %返値 ~EQ ~T ] ⇒ %E の`取消ed~flag$ ~SET ~ON ◎ If return value is true, then set E's canceled flag.
    その他 ◎ Otherwise
    ~IF[ %返値 ~EQ ~F ] ⇒ %E の`取消ed~flag$ ~SET ~ON ◎ 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.

例えば、次の文書~片で: ◎ For example, the following document fragment:

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

文書が読込まれたときは `[object Window]^l が~alertされ、利用者が頁~内のどこかを~clickしたなら `[object HTMLBodyElement]^l が~alertされる。 ◎ ...leads to an alert saying "[object Window]" when the document is loaded, and an alert saying "[object HTMLBodyElement]" whenever the user clicks something in the page.

注記: 関数の返値は,~eventが取消されるかどうかに影響する — 上で述べたように、返値 ~EQ ~F の場合,~eventは取消される。 ◎ The return value of the function affects whether the event is canceled or not: as described above, if the return value is false, the event is canceled.

歴史的~理由から、~platformには 2 つの例外がある ◎ There are two exceptions in the platform, for historical reasons:

  • 大域~obj上の `onerror$hd ~handlerは、 ~T を返した場合に~eventを取消す。 ◎ The onerror handlers on global objects, where returning true cancels the event
  • `onbeforeunload$hd ~handlerは、 ~NULL でも undefined でもない値を返した場合に~eventを取消すことになる。 ◎ The onbeforeunload handler, where returning any non-null and non-undefined value will cancel the event.

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

⇒! [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; ◎

同様に、 `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 %H に対し `~event~handlerの現在の値を取得-@ するときは,次を走らせ~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. ~IF[ %H は、ある要素 %E の`~event~handler$である ] ⇒ %要素 ~LET %E;
    %文書 ~LET %E の`~node文書$ ◎ If H is an element's event handler, then let element be the element, and document be the element's node document.
  3. ~ELSE — すなわち %H は、ある`~window$ %W の`~event~handler$である ⇒ %要素 ~LET ~NULL;
    %文書 ~LET %W に最も近過去に結付けられている`文書$ ◎ Otherwise, H is a Window object's event handler: let element be null, and let document be the Document most recently associated with that Window object.
  4. ~IF[ %文書 に対する`~scriptingは不能化され$ている ] ⇒ ~RET ~NULL ◎ If scripting is disabled for document, then return null. If document does not have a browsing context, or if scripting is disabled for document's browsing context, then return null.
  5. %~script ~LET %H の値 ◎ ↓
  6. %本体 ~LET %~script の未compileの~script本体 ◎ Let body be the uncompiled script body in the internal raw uncompiled handler.
  7. %所在 ~LET %~script の~script本体が出自にしている所在 ◎ Let location be the location where the script body originated, as given by the internal raw uncompiled handler.
  8. %~form所有者 ~LET ~NULL ◎ ↓
  9. ~IF[ %要素 ~NEQ ~NULL ]~AND[ %要素 には`~form所有者$ %F がある ] ⇒ %~form所有者 ~LET %F ◎ If element is not null and element has a form owner, let form owner be that form owner. Otherwise, let form owner be null.
  10. %設定群~obj ~LET %文書 に`関連する設定群~obj$ ◎ Let settings object be the relevant settings object of document.
  11. ~IF[ %本体 は `FunctionBody$jA として構文解析可能でない ]~OR[ 構文解析-時に`早期の~error$jsが検出された ]: ◎ 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$ `?^tnote 問題箇所: %所在 における適切な問題箇所 ( 行番号, 列番号 ) 標的: %設定群~obj の`大域~obj$sT
    3. ~IF[ ~errorの`取扱済み~flag$err ~EQ ~OFF ] ⇒ ~UAは、開発者~consoleに~errorを報告してよい

      ◎ 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. If the error is still not handled after this, then the error may be reported to a developer console.
    4. ~RET ~NULL ◎ Return null.
  12. %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.
  13. %設定群~obj の`~realm実行~文脈$enVを,`~JS実行~文脈~stack$jsに~pushする — それが,現在 `走っている~JS実行~文脈$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$jsに属するようにするため,必要とされる。 ◎ This is necessary so the subsequent invocation of FunctionCreate takes place in the correct JavaScript Realm.

  14. %関数 ~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.
  15. %設定群~obj の`~realm実行~文脈$enVを,`~JS実行~文脈~stack$jsから除去する ◎ Remove settings object's realm execution context from the JavaScript execution context stack.
  16. %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.
  17. ~RET %H の値 ◎ Return H's value.

8.1.5.2. [ 要素 / 文書 / ~window ]上の各種~event~handler

以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • `~HTML要素$においては、[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]の両者として,~supportされ~MUST。
  • [ `文書$ / `~window$ ]においては、`~event~handler~IDL属性$として,~supportされ~MUST。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements, as both event handler content attributes and event handler IDL attributes; and that must be supported by all Document and Window objects, as event handler IDL attributes:
`~event~handler$ `~event~handler~event型$
`onabort@hd `abort$et
`onauxclick@hd `auxclick$et
`oncancel@hd `cancel$et
`oncanplay@hd `canplay$et
`oncanplaythrough@hd `canplaythrough$et
`onchange@hd `change$et
`onclick@hd `click$et
`onclose@hd `close$et
`oncontextmenu@hd `contextmenu$et
`oncuechange@hd `cuechange$et
`ondblclick@hd `dblclick$et
`ondrag@hd `drag$et
`ondragend@hd `dragend$et
`ondragenter@hd `dragenter$et
`ondragexit@hd `dragexit$et
`ondragleave@hd `dragleave$et
`ondragover@hd `dragover$et
`ondragstart@hd `dragstart$et
`ondrop@hd `drop$et
`ondurationchange@hd `durationchange$et
`onemptied@hd `emptied$et
`onended@hd `ended$et
`oninput@hd `input$et
`oninvalid@hd `invalid$et
`onkeydown@hd `keydown$et
`onkeypress@hd `keypress$et
`onkeyup@hd `keyup$et
`onloadeddata@hd `loadeddata$et
`onloadedmetadata@hd `loadedmetadata$et
`onloadend@hd `loadend$et
`onloadstart@hd `loadstart$et
`onmousedown@hd `mousedown$et
`onmouseenter@hd `mouseenter$et
`onmouseleave@hd `mouseleave$et
`onmousemove@hd `mousemove$et
`onmouseout@hd `mouseout$et
`onmouseover@hd `mouseover$et
`onmouseup@hd `mouseup$et
`onwheel@hd `wheel$et
`onpause@hd `pause$et
`onplay@hd `play$et
`onplaying@hd `playing$et
`onprogress@hd `progress$et
`onratechange@hd `ratechange$et
`onreset@hd `reset$et
`onseeked@hd `seeked$et
`onseeking@hd `seeking$et
`onselect@hd `select$et
`onshow@hd `show$et
`onstalled@hd `stalled$et
`onsubmit@hd `submit$et
`onsuspend@hd `suspend$et
`ontimeupdate@hd `timeupdate$et
`ontoggle@hd `toggle$et
`onvolumechange@hd `volumechange$et
`onwaiting@hd `waiting$et

以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • [ `body$e, `frameset$e ]要素を除く `~HTML要素$においては、[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]の両者として,~supportされ~MUST。
  • `文書$においては、`~event~handler~IDL属性$として,~supportされ~MUST。
  • `~window$においては、`~event~handler~IDL属性$として,~supportされ~MUST。
  • 前項に対応する[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]が、当の`~window$に`結付けられている文書$が所有する[ `body$e / `frameset$e ]要素において公開され~MUST。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements other than body and frameset elements, as both event handler content attributes and event handler IDL attributes; that must be supported by all Document objects, as event handler IDL attributes; and that must be supported by all Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's associated Document:
`~event~handler$ `~event~handler~event型$
`onblur@hd `blur$et
`onerror@hd `error$et
`onfocus@hd `focus$et
`onload@hd `load$et
`onresize@hd `resize$et
`onscroll@hd `scroll$et

以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • `~window$においては,`~event~handler~IDL属性$として,~supportされ~MUST。
  • 前項に対応する[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]が、当の`~window$に`結付けられている文書$が所有する[ `body$e / `frameset$e ]要素において公開され~MUST。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported by Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's associated Document:
`~event~handler$ `~event~handler~event型$
`onafterprint@hd `afterprint$et
`onbeforeprint@hd `beforeprint$et
`onbeforeunload@hd `beforeunload$et
`onhashchange@hd `hashchange$et
`onlanguagechange@hd `languagechange$et
`onmessage@hd `message$et
`onoffline@hd `offline$et
`ononline@hd `online$et
`onpagehide@hd `pagehide$et
`onpageshow@hd `pageshow$et
`onpopstate@hd `popstate$et
`onrejectionhandled@hd `rejectionhandled$et
`onstorage@hd `storage$et
`onunhandledrejection@hd `unhandledrejection$et
`onunload@hd `unload$et

以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • `~HTML要素$においては、[ `~event~handler内容~属性$, `~event~handler~IDL属性$ ]の両者として,~supportされ~MUST。
  • `文書$においては、`~event~handler~IDL属性$として,~supportされ~MUST。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements, as both event handler content attributes and event handler IDL attributes; and that must be supported by all Document objects, as event handler IDL attributes:
`~event~handler$ `~event~handler~event型$
`oncut@hd `cut$et
`oncopy@hd `copy$et
`onpaste@hd `paste$et

以下に挙げる各種`~event~handler$, および 対応する各種`~event~handler~event型$は:

  • `文書$においては、`~event~handler~IDL属性$として,~supportされ~MUST。
◎ The following are the event handlers (and their corresponding event handler event types) that must be supported on Document objects as event handler IDL attributes:
`~event~handler$ `~event~handler~event型$
`onreadystatechange@hd `readystatechange$et
8.1.5.2.1. IDL 定義
⇒! [NoInterfaceObject] interface `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 `onseeked$hd; attribute EventHandler `onseeking$hd; attribute EventHandler `onselect$hd; attribute EventHandler `onshow$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; }; ◎ ⇒! [NoInterfaceObject] interface `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 `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; }; [NoInterfaceObject] interface `DocumentAndElementEventHandlers@I { attribute EventHandler `oncopy$hd; attribute EventHandler `oncut$hd; attribute EventHandler `onpaste$hd; }; ◎

8.1.5.3. ~eventの発火

ある種の演算や~methodは、要素に向けて~eventを発火するものとして定義される。 例えば, `HTMLElement$I ~interface上の `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の配送-先)
  • %e (~event名)
  • %非~trusted~flag (省略時は ~OFF )

に対し,次の手続きを走らす:

◎ Firing a synthetic mouse event named e at target, with an optional not trusted flag, means running these steps:
  1. %~event ~LET `MouseEvent$I を用いて`~eventを作成-$した結果 ◎ 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. ~IF[ %非~trusted~flag ~EQ ~ON ] ⇒ `isTrusted$m ~SET ~F ◎ If the not trusted flag is set, initialize event's isTrusted attribute to false.
    5. [ `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).
    6. `view$m ~SET %標的 の`~node文書$の`~window$が[ あれば それ/ なければ ~NULL ] ◎ Initialize event's view attribute to target's node document's Window object, if any, and null otherwise.
    7. `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を発火する@ とは、 %標的 に向けて 名前 `click^et の`合成~mouse~eventを発火する$ことを意味する。 ◎ Firing a click event at target means firing a synthetic mouse event named click at target.