4.12. ~scriptの利用
~scriptにより、 作者は,文書に対話性を追加できるようになる。 ◎ Scripts allow authors to add interactivity to their documents.
作者には、 アリな所では, ~scriptingを代替する宣言的な仕組みを利用することが奨励される — そうした方が保守し易くなることが多く、 また,~scriptingを不能化している利用者も多くいる。 ◎ Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.
例えば、 ~scriptを利用して,ある一節の詳細表示を切り替える代わりに、 `details$e 要素を利用することもできる。 ◎ For example, instead of using a script to show or hide a section to show more details, the details element could be used.
作者には,また、[ ~scripting~supportが無い下では,自身の~appを上品に退行させる ]ことも奨励される。 ◎ Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support.
例えば作者は、 ~tableの~header内に,~tableを動的に~sortし直すような~linkを供している場合、 ~serverに~sort済みな~tableを要請することで,~scriptなしに~linkを機能させることもできる。 ◎ For example, if an author provides a link in a table header to dynamically resort the table, the link could also be made to function without scripts by requesting the sorted table from the server.
【この訳に特有な表記規約】
◎表記記号用語 `文書片@ は、 `DocumentFragment$I ~objの略記である。
4.12.1. `script^e 要素
- `分類$:
- `~metadata内容$ / `~flow内容$ / `句ng内容$ / `~scriptを~supportする要素$ ◎ Metadata content. ◎ Flow content. ◎ Phrasing content. ◎ Script-supporting element.
- `この要素を利用できる文脈$:
- `~metadata内容$ / `句ng内容$ / `~scriptを~supportする要素$ が期待される所。 ◎ Where metadata content is expected. ◎ Where phrasing content is expected. ◎ Where script-supporting elements are expected.
- `内容~model$:
- `src$a 属性を有さない場合、 `type$a 属性の値にも依存するが,`~script内容~制約$に合致しなければナラナイ。 ◎ If there is no src attribute, depends on the value of the type attribute, but must match script content restrictions.
- `src$a 属性を有する場合、 要素は空にされているか, または `~script内容~制約$にも合致するような`~script文書化$のみを包含していなければナラナイ。 ◎ If there is a src attribute, the element must be either empty or contain only script documentation that also matches script content restrictions.
- `text/html における~tag省略$:
- 両~tagとも省略不可。 ◎ Neither tag is omissible.
- `内容~属性$:
- `大域~属性$ ◎ Global attributes
- `src$a — 資源の~address ◎ src — Address of the resource
- `type$a — ~scriptの種別 ◎ type — Type of script
- `nomodule$a — `~module~script$を~supportする~UAにおける実行を防止する ◎ nomodule — Prevents execution in user agents that support module scripts
- `async$a — ~scriptが可用になったら実行する — ~fetchしている間は他を阻むことなく ◎ async — Execute script when available, without blocking while fetching
- `defer$a — ~script実行を先送りする ◎ defer — Defer script execution
- `crossorigin$a — 要素は非同一-生成元 要請をどう取扱うか ◎ crossorigin — How the element handles crossorigin requests
- `integrity$a — `Subresource Integrity^cite `SRI$r(下位資源の完全性)検査に利用される完全性~metadata ◎ integrity — Integrity metadata used in Subresource Integrity checks [SRI]
- `referrerpolicy$a — 要素により起動された`~fetch$用の`~referrer施策$ ◎ referrerpolicy — Referrer policy for fetches initiated by the element
- `blocking$a — 要素に`具現化を阻む能性$があるかどうか。 ◎ blocking — Whether the element is potentially render-blocking
- `fetchpriority$a — 要素により起動される`~fetch$用の`優先度$rqを設定する。 ◎ fetchpriority — Sets the priority for fetches initiated by the element
- `~accessibilityの考慮点$
- `script$AA ◎ For authors. For implementers.
- `~DOM~interface$
-
[Exposed=Window] interface `HTMLScriptElement@I : `HTMLElement$I { [`HTMLConstructor$] constructor(); [`CEReactions$] attribute USVString `src$m; [`CEReactions$] attribute DOMString `type$m; [`CEReactions$] attribute boolean `noModule$m; [`CEReactions$] attribute boolean `async$m; [`CEReactions$] attribute boolean `defer$m; [`CEReactions$] attribute DOMString? `crossOrigin$m; [`CEReactions$] attribute DOMString `text$m; [`CEReactions$] attribute DOMString `integrity$m; [`CEReactions$] attribute DOMString `referrerPolicy$m; [SameObject, PutForwards=`value$m] readonly attribute `DOMTokenList$I `blocking$m; [`CEReactions$] attribute DOMString `fetchPriority$m; static boolean `supports$m(DOMString %type); // `HTMLScriptElement$obsMb };
`script$e 要素により、 作者は,文書~内に[ 動的~script / ~data~block ]を含めることが可能になる。 この要素は、 利用者~向けの内容は`表現-$しない。 ◎ The script element allows authors to include dynamic script and data blocks in their documents. The element does not represent content for the user.
`type@a 属性は、 表現される~scriptの種別を~custom化できるようにする: ◎ The type attribute allows customization of the type of script represented:
- この属性を省略した場合, あるいは `~JS~MIME型に~essence合致-$するものに設定した場合、 当の~scriptは`古典~script$であるとされ, ~JSの `Script$P ~top-level生成規則に則って解釈されることになる。 古典~scriptは、 `src$a 属性が設定されている場合に限り,[ `async$a, `defer$a ]属性に影響される。 `type$a 属性を設定するのは冗長であり、 作者は,代わりに省略するべきである。 ◎ Omitting the attribute, setting it to the empty string, or setting it to a JavaScript MIME type essence match, means that the script is a classic script, to be interpreted according to the JavaScript Script top-level production. Classic scripts are affected by the async and defer attributes, but only when the src attribute is set. Authors should omit the type attribute instead of redundantly setting it.
- この属性を[ `~ASCII大小無視$で `module^l に合致する文字列 ]に設定することは、 当の~scriptが`~JS~module~script$になり,[ ~JSの `Module$P ~top-level生成規則に則って解釈される ]ことになることを意味する。 ~module~scriptは、 `defer$a 属性からは影響されないが, `async$a 属性からは影響される( `src$a 属性の状態に関わらず)。 ◎ Setting the attribute to an ASCII case-insensitive match for "module" means that the script is a JavaScript module script, to be interpreted according to the JavaScript Module top-level production. Module scripts are not affected by the defer attribute, but are affected by the async attribute (regardless of the state of the src attribute).
- この属性を[ `~ASCII大小無視$で `importmap^l に合致する文字列 ]に設定することは、 当の~scriptは,`~import~map$になることを意味する — それは、[ `~module指定子を解決する$ときの挙動を制御する ]ために利用される~JSONを包含する。 ~import~mapは、 ~inlineに限られる — すなわち, `src$a 属性, および他のほとんどの属性は無意味になり、 ~import~mapと併に利用されることはない。 ◎ Setting the attribute to an ASCII case-insensitive match for "importmap" means that the script is an import map, containing JSON that will be used to control the behavior of module specifier resolution. Import maps can only be inline, i.e., the src attribute and most other attributes are meaningless and not to be used with them.
- この属性を他の値に設定した場合、 ~scriptは `~data~block@ であるとされ,処理されなくなる。 当の `script$e 要素の どの属性も,~data~blockに効果を及ぼすことはない ( `type$a 自身は除いて)。 作者は、 ~data~blockを~~指示するときは, `~JS~MIME型に~essence合致-$しない`妥当な~MIME型~文字列$を利用しなければナラナイ。 ◎ Setting the attribute to any other value means that the script is a data block, which is not processed. None of the script attributes (except type itself) have any effect on data blocks. Authors must use a valid MIME type string that is not a JavaScript MIME type essence match to denote data blocks.
注記: `~data~block$に,`妥当な~MIME型~文字列$を利用しなければナラナイとする要件は、 将来に起こり得る衝突を避けるためにある。 さもなければ、[ この仕様が,いつか`~script$に追加的な種別を追加した場合 ]に,それらが — 値 `module^l が`~module~script$を~~指示するのと同様に — 何かを誘発し得ることになる。 今,妥当な~MIME型~文字列を利用しておけば、[ 当の~data~blockは、 将来の~UAからも,何か別の~script種別に解釈し直されない ]ことを確保できる。 ◎ The requirement that data blocks must be denoted using a valid MIME type string is in place to avoid potential future collisions. If this specification ever adds additional types of script, they will be triggered by setting the type attribute to something which is not a MIME type, like how the "module" value denotes module scripts. By using a valid MIME type string now, you ensure that your data block will not ever be reinterpreted as a different script type, even in future user agents.
[ `古典~script$, `~JS~module~script$ ]どちらも、 ~inlineに埋込むことも, `src@a 属性を指定して外部~fileから取込むこともできる。 この `src^a 属性~値は、 利用する外部~script資源の`~URL$を与える — その値は、 `前後~空白~可の妥当かつ空でない~URL$でなければナラナイ。 ◎ Classic scripts and JavaScript module scripts can be embedded inline, or be imported from an external file using the src attribute, which if specified gives the URL of the external script resource to use. If src is specified, it must be a valid non-empty URL potentially surrounded by spaces.
[ ~inlineな `script$e 要素 / 外部~script資源 ]の内容は、[ `古典~script$の場合は,~JS仕様 `JAVASCRIPT$r の `Script$P 生成規則/ `~JS~module~script$の場合は,同~仕様の `Module$P 生成規則 ]による要件に適合しなければナラナイ。 ◎ The contents of inline script elements, or the external script resource, must conform with the requirements of the JavaScript specification's Script or Module productions, for classic scripts and JavaScript module scripts respectively. [JAVASCRIPT]
`~CSS~module~script$用の外部~script資源の内容は、 ~CSS仕様 `CSS$r の要件に適合しなければナラナイ。 ◎ The contents of the external script resource for CSS module scripts must conform to the requirements of the CSS specification. [CSS]
`~JSON~module~script$用の外部~script資源の内容は、 ~JSON仕様 `JSON$r の要件に適合しなければナラナイ。 ◎ The contents of the external script resource for JSON module scripts must conform to the requirements of the JSON specification. [JSON]
`~import~map$用の~inlineな `script$e 要素の内容は、 `~import~map著作~要件$に適合しなければナラナイ。 ◎ The contents of inline script elements for import maps must conform with the import map authoring requirements.
`~import~map$を与える `script$e 要素には、 次に挙げる属性を指定してはナラナイ ⇒# `src$a, `async$a, `nomodule$a, `defer$a, `crossorigin$a, `integrity$a, `referrerpolicy$a ◎ For import map script elements, the src, async, nomodule, defer, crossorigin, integrity, and referrerpolicy attributes must not be specified.
文書には、 `~import~map$を与える `script$e 要素が複数個~在ってはナラナイ。 ◎ A document must not have more than one import map script element.
`script$e 要素を,`~data~block$を含めるために利用する場合: ◎ When used to include data blocks,\
- ~dataは、 ~inlineに埋込まなければナラナイ。 ◎ the data must be embedded inline,\
- `type$a 属性を利用して,~dataの形式も与えなければナラナイ。 ◎ the format of the data must be given using the type attribute, and\
- 要素の内容は、 利用される形式に定義される要件に適合していなければナラナイ。 ◎ the contents of the script element must conform to the requirements defined for the format used.\
- 次に挙げる属性は、 要素に指定してはナラナイ ⇒# `src$a, `async$a, `nomodule$a, `defer$a, `crossorigin$a, `integrity$a, `referrerpolicy$a, `fetchpriority$a ◎ The src, async, nomodule, defer, crossorigin, integrity, referrerpolicy, and fetchpriority attributes must not be specified.
`nomodule@a 属性は,`真偽-属性$であり、 `~module~script$を~supportする~UAにおいて~scriptが実行されるのを防止する。 これにより、 `下の例に示す@#script-nomodule-example$ように,[ 現代の~UAには`~module~script$/ 旧い~UAには`古典~script$ ]を選択的に実行させれるようになる。 `nomodule$a 属性は、 `~module~script$上に指定されてはナラナイ(また,指定されても無視される)。 ◎ The nomodule attribute is a boolean attribute that prevents a script from being executed in user agents that support module scripts. This allows selective execution of module scripts in modern user agents and classic scripts in older user agents, as shown below. The nomodule attribute must not be specified on module scripts (and will be ignored if it is).
`async@a, `defer@a 属性は,`真偽-属性$であり、 当の~scriptがどう評価されるべきかを指示する。 `古典~script$に対しては、 両~属性とも指定してヨイ — が、 `src$a 属性を有していない場合は,どちらも指定してはナラナイ。 `~module~script$に対しては、 `async$a 属性は指定してもヨイが, `defer$a 属性は指定してはナラナイ。 ◎ The async and defer attributes are boolean attributes that indicate how the script should be evaluated. Classic scripts may specify defer or async, but must not specify either unless the src attribute is present. Module scripts may specify the async attribute, but must not specify the defer attribute.
これらの属性を利用して選択され得る/できる~modeとしてアリなものは、 ~scriptの種別に依存して,いくつかある: ◎ There are several possible modes that can be selected using these attributes, and depending on the script's type.
-
`古典~script$に対しては: ◎ For classic scripts,\
- 要素は `async$a 属性を有する場合 ⇒ ~scriptは,~pageの構文解析と`並列的$に~fetchされ、 可用になり次第,評価されることになる (構文解析が完了する前にもなり得る)。 ◎ if the async attribute is present, then the classic script will be fetched in parallel to parsing and evaluated as soon as it is available (potentially before parsing completes).\
- 要素は `async$a 属性を有さないが, `defer$a 属性は有する場合 ⇒ ~scriptは`並列的$に~fetchされ,~pageが構文解析を終えた時点で評価される。 ◎ If the async attribute is not present but the defer attribute is present, then the classic script will be fetched in parallel and evaluated when the page has finished parsing.\
- 要素は両~属性とも有さない場合 ⇒ ~scriptは,即時に~fetchされた上で評価され、 両者とも完了するまで~pageの構文解析を阻むことになる。 ◎ If neither attribute is present, then the script is fetched and evaluated immediately, blocking parsing until these are both complete.
-
`~module~script$に対しては: ◎ For module scripts,\
- 要素は `async$a 属性を有する場合 ⇒ ~scriptとそのすべての依存物 【~scriptが取込む他の~script】 は,~pageの構文解析と`並列的$に~fetchされ、 可用になり次第,評価されることになる (構文解析が完了する前にもなり得る)。 ◎ if the async attribute is present, then the module script and all its dependencies will be fetched in parallel to parsing, and the module script will be evaluated as soon as it is available (potentially before parsing completes).\
- 他の場合 ⇒ ~scriptとその依存物は,構文解析と`並列的$に~fetchされ、 ~pageが構文解析を終えた時点で評価されることになる。 ◎ Otherwise, the module script and its dependencies will be fetched in parallel to parsing and evaluated when the page has finished parsing.\
- ( `defer$a 属性による効果は、 ~module~scriptにはない。) ◎ (The defer attribute has no effect on module scripts.)
これらすべては、 次の図式に要約される: ◎ This is all summarized in the following schematic diagram:
注記: これらの属性に対する正確な処理の詳細は、 ほとんどが歴史的な理由によるものであり,~HTMLの[ いくぶん自明でない,いくつもの側面 ]が孕まれている。 したがって,実装の要件は、 この仕様~全体に散らばらざるを得なくなっている。 以下に示す(この節の)各種~algoは,この処理の中核を述べるが、 それらの~algoは,次に挙げるもの等々と相互に参照し合う:
- [ ~HTML内 / `外来な内容~内@~HTMLparsing#scriptForeignEndTag$ / `~XML内@~HTMLxml#scriptTagXML$ ]における[ `script$e の `開始~tag@~HTMLparsing#scriptTag$, `終了~tag@~HTMLparsing#scriptEndTag$ ]に対する各種 構文解析~規則
- `document.write()$m ~methodの規則
- `~scripting$の取扱い
注記: `document.write()$m ~methodを利用して挿入された `script$e 要素は、 `通例的には@~HTMLparsing#document-written-scripts-intervention$実行される (概して,その間は、 更なる[ ~script実行/~HTML構文解析 ]は阻まれる)。 [ `innerHTML$m / `outerHTML$m ]属性を利用して挿入されたものは、 まったく実行されない。 ◎ When inserted using the document.write() method, script elements usually execute (typically blocking further script execution or HTML parsing). When inserted using the innerHTML and outerHTML attributes, they do not execute at all.
`async$a 属性が指定されている下でも, `defer$a 属性が指定されてヨイ — そうすることで、[ `defer$a は~supportするが `async$a は~supportしないような,旧来の~web~browser ]においても、 既定である他を阻む挙動に代えて, `defer$a による挙動に~fall-backするようになる。 ◎ The defer attribute may be specified even if the async attribute is specified, to cause legacy web browsers that only support defer (and not async) to fall back to the defer behavior instead of the blocking behavior that is the default.
`crossorigin@a 属性は、 `~CORS設定群~属性$である。 この属性は、 `古典~script$に対しては[ 他の`生成元$から得された~scriptによる~error情報が公開されるかどうか ]を制御し, `~module~script$に対しては[ 非同一-生成元 要請に利用される`資格証~mode$ ]を制御する。 ◎ The crossorigin attribute is a CORS settings attribute. For classic scripts, it controls whether error information will be exposed, when the script is obtained from other origins. For module scripts, it controls the credentials mode used for cross-origin requests.
注記: `古典~script$と違って,`~module~script$では、 非同一-生成元へ~fetchするときには,`~CORS~protocol$の利用が要求される。 ◎ Unlike classic scripts, module scripts require the use of the CORS protocol for cross-origin fetching.
`integrity@a 属性は、[ この要素が担当する要請 ]の`完全性~metadata$rqを表現する。 値は~textである。 この属性は、 `src$a 属性を指定していない場合には,指定してはナラナイ。 `SRI$r ◎ The integrity attribute represents the integrity metadata for requests which this element is responsible for. The value is text. The integrity attribute must not be specified when the src attribute is not specified. [SRI]
`referrerpolicy@a 属性は、 `~referrer施策~属性$である。 その目的は、[ ~script, および それが取込む~script ]を`~fetch$するときに利用される`~referrer施策$を設定することである。 `REFERRERPOLICY$r ◎ The referrerpolicy attribute is a referrer policy attribute. Its purpose is to set the referrer policy used when fetching the script, as well as any scripts imported from it. [REFERRERPOLICY]
他の下位資源ではなく,取込まれる~scriptを~fetchするときに利用される `script^e 要素の~referrer施策の例: ◎ An example of a script element's referrer policy being used when fetching imported scripts but not other subresources:
<script referrerpolicy="origin"> fetch('/api/data'); /* `script^e の~referrer施策では~fetchされない。 ◎ not fetched with <script>'s referrer policy */ import('./utils.mjs'); /* `script^e の~referrer施策(この事例では `origin^l )で~fetchされる。 ◎ is fetched with <script>'s referrer policy ("origin" in this case) */ </script>
`blocking@a 属性は、 `他を阻む属性$である。 ◎ The blocking attribute is a blocking attribute.
`fetchpriority@a 属性は、 `~fetch優先度~属性$である。 その目的は、 ~scriptの`~fetch$時に利用される`優先度$rqを設定することである。 ◎ The fetchpriority attribute is a fetch priority attribute. Its purpose is to set the priority used when fetching the script.
次に挙げる内容~属性を動的に変更しても,直接的な効果はない — これらの属性は、 下に述べる特定の時点に限り利用される ⇒# `src$a, `type$a, `nomodule$a, `async$a, `defer$a, `crossorigin$a, `integrity$a, `referrerpolicy$a, `fetchpriority$a ◎ Changing the src, type, nomodule, async, defer, crossorigin, integrity, referrerpolicy, and fetchpriority attributes dynamically has no direct effect; these attributes are only used at specific times described below.
`src@m ~IDL属性は、 `src$a 内容~属性を`反映する$モノトスル。
`type@m ~IDL属性は、 `type$a 内容~属性を`反映する$モノトスル。
`defer@m ~IDL属性は、 `defer$a 内容~属性を`反映する$モノトスル。
`integrity@m ~IDL属性は、 `integrity$a 内容~属性を`反映する$モノトスル。
`blocking@m ~IDL属性は、 `blocking$a 内容~属性を`反映する$モノトスル。
◎ The IDL attributes src, type, defer, integrity, and blocking, must each reflect the respective content attributes of the same name.`referrerPolicy@m ~IDL属性は、 `既知な値のみに制限され$る下で, `referrerpolicy$a 内容~属性を`反映する$モノトスル。 ◎ The referrerPolicy IDL attribute must reflect the referrerpolicy content attribute, limited to only known values.
`fetchPriority@m ~IDL属性は、 `既知な値のみに制限され$る下で, `fetchpriority$a 内容~属性を`反映する$モノトスル。 ◎ The fetchPriority IDL attribute must reflect the fetchpriority content attribute, limited to only known values.
`crossOrigin@m ~IDL属性は、 `既知な値のみに制限され$る下で, `crossorigin$a 内容~属性を`反映する$モノトスル。 ◎ The crossOrigin IDL attribute must reflect the crossorigin content attribute, limited to only known values.
`noModule@m ~IDL属性は、 `nomodule$a 内容~属性を`反映する$モノトスル。 ◎ The noModule IDL attribute must reflect the nomodule content attribute.
`async$m 設定子~手続きは: ◎ The async setter steps are:
- コレの`非同期cを強制するか$scE ~SET ~F ◎ Set this's force async to false.
- ~IF[ 所与の値 ~EQ ~T ] ⇒ コレの `async$a 内容~属性 ~SET 空~文字列 ◎ If the given value is true, then set this's async content attribute to the empty string.
- ~ELSE ⇒ コレの `async$a 内容~属性を除去する ◎ Otherwise, remove this's async content attribute.
- %script.`text$m [ = %value ]
- 要素の`子~text内容$を返す。 ◎ Returns the child text content of the element.
- 設定して,要素の子たちを所与の値に置換できる。 ◎ Can be set, to replace the element's children with the given value.
- `HTMLScriptElement$I.`supports(type)$m
- 所与の %type は~UAが~supportする~script種別であるならば ~T を返す。 この仕様においてアリな~script種別は[ `classic^l, `module^l, `importmap^l ]に限られるが、 将来には,他の種別も追加されるかもしれない 【`説明書き@https://github.com/horo-t/explainers/blob/main/script_element_supports.md$】 。 ◎ Returns true if the given type is a script type supported by the user agent. The possible script types in this specification are "classic", "module", and "importmap", but others might be added in the future.
`supports(type)@m ~method手続きは: ◎ The supports(type) method steps are:
- ~IF[ %type ~IN { `classic^l, `module^l, `importmap^l } ] ⇒ ~RET ~T ◎ If type is "classic", then return true. ◎ If type is "module", then return true. ◎ If type is "importmap", then return true.
- ~RET ~F ◎ Return false.
注記: %type 引数は挙げられた値に正確に合致する必要がある — `~ASCII大小無視$で照合されることはない。 これは、[ `type$a 内容~属性~値どう扱われるか / `DOMTokenList$I の `supports()@~DOM4#dom-domtokenlist-supports$m ~methodがどう働くか ]とは異なるが, `new Worker()$m 構築子にて利用される `WorkerType$I 列挙に揃う。 ◎ The type argument has to exactly match these values; we do not perform an ASCII case-insensitive match. This is different from how type content attribute values are treated, and how DOMTokenList's supports() method works, but it aligns with the WorkerType enumeration used in the Worker() constructor.
次の例には、 2 個の `script$e 要素 — 外部`古典~script$を埋込むもの, および `~data~block$として何らかの~dataを含むもの — が利用されている。 ◎ In this example, two script elements are used. One embeds an external classic script, and the other includes some data as a data block.
`script-2^xCodeこの事例における~dataは、 その~scriptにより,~video~gameの~mapを生成するために利用されているであろう — が、 この仕方で利用する必要があるわけではない: 実際の~map~dataは~pageの他所に埋込まれていて、 この~data~blockは,単に[ 利用者が~game~mapの特定0の特能を探し易くするため ]として[ ~siteの探索~engine向けに~~用意されたもの ]かもしれない。 ◎ The data in this case might be used by the script to generate the map of a video game. The data doesn't have to be used that way, though; maybe the map data is actually embedded in other parts of the page's markup, and the data block here is just used by the site's search engine to help users who are looking for particular features in their game maps.
次の見本に、 `script$e 要素を利用して, 文書の他所から利用される関数を `古典~script$の一部として定義する方法を示す。 同時に,別の `script$e 要素を利用して、 文書が構文解析されている間に~scriptを呼出す方法も示す — この事例では、 ~formの出力を初期化する。 ◎ The following sample shows how a script element can be used to define a function that is then used by other parts of the document, as part of a classic script. It also shows how a script element can be used to invoke script while the document is being parsed, in this case to initialize the form's output.
`script-3^xCode次の見本では、 `script$e 要素を利用して,外部`~JS~module~script$を含める方法を示す。 ◎ The following sample shows how a script element can be used to include an external JavaScript module script.
`script-4^xCodeこの~module, およびそのすべての依存物 (~source~file内の ~JS `import^c 文を通して表出される)は、 ~fetchされることになる。 結果の~module~graph全体が取込まれ,文書が構文解析を終えたなら、 `app.mjs^s の内容は評価されることになる。 ◎ This module, and all its dependencies (expressed through JavaScript import statements in the source file), will be fetched. Once the entire resulting module graph has been imported, and the document has finished parsing, the contents of app.mjs will be evaluated.
加えて,同じ `Window$I 内の別の `script$e 要素からの~codeが `app.mjs^s からの~moduleを取込む場合(例: `import "./app.mjs";^s を介して)、 前者の `script$e 要素により作成された同じ`~JS~module~script$が取込まれることになる。 ◎ Additionally, if code from another script element in the same Window imports the module from app.mjs (e.g. via import "./app.mjs";), then the same JavaScript module script created by the former script element will be imported.
現代の~UA用には`~JS~module~script$, 旧い~UA用には`古典~script$を含める例を示す: ◎ This example shows how to include a JavaScript module script for modern user agents, and a classic script for older user agents:
`script-5^xCode`~JS~module~script$を~supportする現代の~UAでは、 前者の `script$e 要素( `type$a 属性は `module^l )は, ~fetchされた上で (`~JS~module~script$として)評価される一方で、 後者の `script$e 要素( `nomodule$a 属性を有する)は無視されることになる。 逆に,旧い~UAにとっては、 前者は,未知な~script型なので無視することになる — が、 `nomodule$a 属性は実装していないので, 後者を(`古典~script$として)~fetchして評価することには問題はない。 ◎ In modern user agents that support JavaScript module scripts, the script element with the nomodule attribute will be ignored, and the script element with a type of "module" will be fetched and evaluated (as a JavaScript module script). Conversely, older user agents will ignore the script element with a type of "module", as that is an unknown script type for them — but they will have no problem fetching and evaluating the other script element (as a classic script), since they do not implement the nomodule attribute.
次の見本に、 `script$e 要素を利用して,[ (例えば,ニュースサイト上の)文書~内の~textを曖昧な読み物で代用してしまうような, ~inlineな`~JS~module~script$ ]を書く方法を示す: 【![XKCD1288]】 ◎ The following sample shows how a script element can be used to write an inline JavaScript module script that performs a number of substitutions on the document's text, in order to make for a more interesting reading experience (e.g. on a news site): [XKCD1288]
`script-6^xCode~JS~module~scriptを利用して得られる特能のうち,注目すべきものには、 次が挙げられる:
- 他の~JS~moduleから関数を取込む能。
- 既定で~strict~modeになる。
- ~top-level宣言であっても,`大域~obj$上に新たな~propを導入しない。
また,この `script$e 要素が文書~内のどこに現れようが、[ 文書~構文解析が完了して,なおかつ その依存物(この例では `dom-utils.mjs^s )が~fetchされ, 評価される ]までは,評価されないことに注意。 ◎ Also note that no matter where this script element appears in the document, it will not be evaluated until both document parsing has complete and its dependency (dom-utils.mjs) has been fetched and evaluated.
次の見本に,`~JS~module~script$の内側から`~JSON~module~script$を どう取込めるかを示す: ◎ The following sample shows how a JSON module script can be imported from inside a JavaScript module script:
<script type="module"> import peopleInSpace from "http://api.open-notify.org/astros.json" with { type: "json" }; const %list = document.querySelector("#people-in-space"); for (const { %craft, %name } of peopleInSpace.people) { const %li = document.createElement("li"); %li.textContent = ``^${name} / ${craft}``^; %list.append(%li); } </script>
~module~script用の~MIME型に対する検査-法は厳密である。 `~JSON~module~script$の~fetchが成功するためには、 ~HTTP応答の~MIME型は`~JSON~MIME型$ — 例: `Content-Type: text/json^c — でなければならない。 他方,`import^c 文を成す `with { type: "json" }^c の部分が省略された場合、 その意図は`~JS~module~script$を取込むものと見做され、 ~HTTP応答の~MIME型が`~JS~MIME型$でない場合,~fetchは失敗することになる。 ◎ MIME type checking for module scripts is strict. In order for the fetch of the JSON module script to succeed, the HTTP response must have a JSON MIME type, for example Content-Type: text/json. On the other hand, if the with { type: "json" } part of the statement is omitted, it is assumed that the intent is to import a JavaScript module script, and the fetch will fail if the HTTP response has a MIME type that is not a JavaScript MIME type.
4.12.1.1. 処理~model
各 `script$e 要素には、 その各種 状態を~~保持するものとして,次に挙げるものが結付けられる: ◎ A script element has several associated pieces of state.
- `構文解析器~文書@scE ◎ A script element has a parser document,\
- ~NULL /`文書$ — 初期~時は ~NULL とする。 ◎ which is either null or a Document, initially null.\
- これは、[ `~HTML構文解析器$ / `~XML構文解析器$ ]により `script$e 要素が挿入されるとき設定され,それらの要素の処理に影響する。 ~NULL でないとき、 当の要素は `構文解析器により挿入された@ ともいう。 ◎ It is set by the HTML parser and the XML parser on script elements they insert, and affects the processing of those elements. script elements with non-null parser documents are known as parser-inserted.
- `準備~時点の文書@scE ◎ A script element has a preparation-time document,\
- ~NULL /`文書$ — 初期~時は ~NULL とする。 ◎ which is either null or a Document, initially null.\
- これは、 当の要素が`~script要素を準備する$間に他の文書へ移動された場合に, `~script要素を実行する$のを防止するために利用される。 ◎ It is used to prevent scripts that move between documents during preparation from executing.
- `非同期cを強制するか@scE ◎ A script element has a force async\
- 真偽値 — 初期~時は ~T とする。 ◎ boolean, initially true.\
-
次のときは、 ~F にされる:
- 当の要素が[ `~HTML構文解析器$ / `~XML構文解析器$ ]により挿入されたとき
- 当の要素に `async$a 内容~属性が追加されたとき
- `外部~fileか@scE ◎ A script element has a from an external file\
- 真偽値 — 初期~時は ~F とする。 ◎ boolean, initially false.\
- これは、 `~script要素を準備する$時点で,当の要素の `src$a 属性に基づいて決定される。 ◎ It is determined when the script is prepared, based on the src attribute of the element at that time.
- `構文解析器にて実行されるに準備済みか@scE ◎ A script element has a ready to be parser-executed\
- 真偽値 — 初期~時は ~F とする。 ◎ boolean, initially false.\
- これは,構文解析器に当の~scriptがいつ実行されるか知らせるためにあり、 当の要素が`構文解析器により挿入された$場合に限り,利用される。 ◎ This is used only used for elements that are also parser-inserted, to let the parser know when to execute the script.
- `すでに開始したか@scE ◎ A script element has an already started\
- 真偽値 — 初期~時は ~F とする。 ◎ boolean, initially false.
- `~load~eventを遅延しているか@scE ◎ A script element has a delaying the load event\
- 真偽値 — 初期~時は ~F とする。 ◎ boolean, initially false.
- `種別@scE ◎ A script element has a type,\
- 次に挙げるいずれか — 初期~時は ~NULL とする ⇒# ~NULL, `classic^l, `module^l, `importmap^l ◎ which is either null, "classic", "module", or "importmap", initially null.\
- これは、 `~script要素を準備する$時点で,当の要素の `type$a 属性に基づいて決定される。 ◎ It is determined when the element is prepared, based on the type attribute of the element at that time.
- `結果@scE ◎ A script element has a result,\
- 次に挙げるいずれか — 初期~時は `未初期化^i とする ⇒# `未初期化^i, ~NULL (~errorを表現する), `~script$, `~import~map構文解析-結果$ ◎ which is either "uninitialized", null (representing an error), a script, or an import map parse result. It is initially "uninitialized".
- `結果は準備済み時の手続き@scE ◎ A script element has steps to run when the result is ready,\
- 手続き / ~NULL — 初期~時は ~NULL とする。 ◎ which are a series of steps or null, initially null.\
`~script要素を準備済みにする@ ときは、 所与の ( `script$e 要素 %S, %結果 ) に対し ◎ To mark as ready a script element el given a script, import map parse result, or null result:
- ~Assert: %結果 は次に挙げるいずれかである ⇒# `~script$/ `~import~map構文解析-結果$/ ~NULL ◎ ↑
- %S の`結果$scE ~SET %結果 ◎ Set el's result to result.
- ~IF[ %S の`結果は準備済み時の手続き$scE ~NEQ ~NULL ] ⇒ %S の`結果は準備済み時の手続き$scEを走らす ◎ If el's steps to run when the result is ready are not null, then run them.
- %S の`結果は準備済み時の手続き$scE ~SET ~NULL ◎ Set el's steps to run when the result is ready to null.
- %S の`~load~eventを遅延しているか$scE ~SET ~F ◎ Set el's delaying the load event to false.
`script$e 要素 %S は、 次を満たすならば, `暗黙的に具現化を阻む能性$があるとする ⇒ [ %S の`種別$scE ~EQ `classic^l ]~AND[ %S の`構文解析器~文書$scE ~NEQ ~NULL ]~AND[ %S は[ `async$a, `defer$a ]どちらの属性も有さない ] ◎ A script element el is implicitly potentially render-blocking if el's type is "classic", el is parser-inserted, and el does not have an async or defer attribute.
`script$e 要素~用の`~clone時の手続き$は、 所与の ( %~node, %複製, … ) に対し ⇒ %複製 の`すでに開始したか$scE ~SET %~node の`すでに開始したか$scE ◎ The cloning steps for script elements given node, copy, and subtree are to set copy's already started to node's already started.
`script$e 要素 %S に `async$a 属性が追加されたときは、 %S の`非同期cを強制するか$scEを ~F に設定するモノトスル。 ◎ When an async attribute is added to a script element el, the user agent must set el's force async to false.
`script$e 要素 %S が[ その`~load~eventを遅延しているか$scE ~EQ ~T ]を満たしている間は、 %S の`準備~時点の文書$scEの`~load~eventを遅延する$モノトスル。 ◎ Whenever a script element el's delaying the load event is true, the user agent must delay the load event of el's preparation-time document.
`script$e 用の`~HTML要素~接続~後の手続き$は、 所与の ( %挿入された~node ) に対し: ◎ The script HTML element post-connection steps, given insertedNode, are:
-
~IF[ %挿入された~node は`接続されて$いない ] ⇒ ~RET ◎ If insertedNode is not connected, then return.
これは、 先に挿入された `script$e が後から挿入された `script$e ( %挿入された~node )を除去する事例で起こり得る。 一例として: ◎ This can happen in the case where an earlier-inserted script removes a later-inserted script. For instance:
`script-processing-model-1^xCodeこの例では、 ~consoleへは何も~printされない。 2 個の `script$e %script1, %script2 は, `append()$m により不可分に挿入されるが、 %script1 は[ %script1 用に`~HTML要素~接続~後の手続き$を走らす時点 ]までに[ %script2 が~DOMへ`接続されて$いること ]を観測でき,[ %script2 用に`~HTML要素~接続~後の手続き$を走らす時点 ]までに %script2 を除去する — その結果、 %script2 は,その時点では`接続されて$いなくなり、 %script2 用に`~script要素を準備する$こともなくなる。 ◎ Nothing is printed to the console in this example. By the time the HTML element post-connection steps run for the first script that was atomically inserted by append(), it can observe that the second script is already connected to the DOM. It removes the second script, so that by the time its HTML element post-connection steps run, it is no longer connected, and does not get prepared.
- ~IF[ %挿入された~node は`構文解析器により挿入された$ ] ⇒ ~RET ◎ If insertedNode is parser-inserted, then return.
- `~script要素を準備する$( %挿入された~node ) ◎ Prepare the script element given insertedNode.
これには、[ ある `script$e 要素, 新たに挿入される子 `script$e 要素たち ]の実行~順序について関心事になる含意がある。 次の~code片を考える: ◎ This has an interesting implication on the execution order of a script element and any newly-inserted child script elements. Consider the following snippet:
`script-processing-model-2^xCode1 個目の~script~block( `id=outer-script^c / %outerScript )は、 2 個目の~script~blockが実行される時点までには`準備-$済みになるが, まだ空なので実行されない — したがって,その`すでに開始したか$scEは ~F のままになる。 ◎ By the time the second script block executes, the outer-script has already been prepared, but because it is empty, it did not execute and therefore is not marked as already started.\
2 個目の~script~blockが実行されるとき、 %outerScript の子として[ `Text$I ~node %start, 入子な `script$e 要素 %innerScript, もう一つの `Text$I ~node %end ]を不可分に挿入することによる効果は: ◎ The atomic insertion of the Text nodes and nested script element have the following effects: • All three child nodes get atomically inserted as children of outer-script;\
- 挿入された各~node用に`挿入-時の手続き$が走る — この事例では、 それらには観測-可能な帰結は無い。 ◎ all of their insertion steps run, which have no observable consequences in this case.
- %outerScript 用に`子~群~変更-時の手続き$が走る。 それに伴い, %outerScript が`準備-$される — その本体は今や空でないので、 %start, %end の内容が順に実行される。 【 %innerScript の内容は %outerScript の`子~text内容$を成さないので無視される。】 ◎ The outer-script's children changed steps run, which prepares that script; because its body is now non-empty, this executes the contents of the two Text nodes, in order.
- %innerScript 用に `script$e 用の`~HTML要素~接続~後の手続き$が走る。 その結果、 %innerScript の本体が実行される。 ◎ The script HTML element post-connection steps finally run for innerScript, causing its body to execute.
`~script要素を準備する@ ときは、 所与の ( `script$e 要素 %S ) に対し: ◎ To prepare the script element given a script element el:
- ~IF[ %S の`すでに開始したか$scE ~EQ ~T ] ⇒ ~RET ◎ If el's already started is true, then return.
- %構文解析器~文書 ~LET %S の`構文解析器~文書$scE ◎ Let parser document be el's parser document.
-
%S の`構文解析器~文書$scE ~SET ~NULL ◎ Set el's parser document to null.
注記: この段は、[ `構文解析器により挿入された$ `script$e 要素を当の構文解析器が走らせようと試行して失敗した場合 (例: 空あるいは, 未~supportな~scripting言語を指定していた) ]に,後で[ 別の~scriptがそれを変異させて再度~走らす ]ことを可能にするために行われる。 ◎ This is done so that if parser-inserted script elements fail to run when the parser tries to run them, e.g. because they are empty or specify an unsupported scripting language, another script can later mutate them and cause them to run again.
-
~IF[ %構文解析器~文書 ~NEQ ~NULL ]~AND[ %S は `async$a 属性を有さない ] ⇒ %S の`非同期cを強制するか$scE ~SET ~T ◎ If parser document is non-null and el does not have an async attribute, then set el's force async to true.
注記: この段は、[ `構文解析器により挿入された$ `script$e 要素を当の構文解析器が走らせようと試行して失敗したが、 他の~scriptが動的にそれを更新した後に,後で実行された場合 ]に[ `async$a 属性が設定されていなくとも, 非同期cな流儀で実行されるようにする ]ために行われる。 ◎ This is done so that if a parser-inserted script element fails to run when the parser tries to run it, but it is later executed after a script dynamically updates it, it will execute in an async fashion even if the async attribute isn't set.
- %~source~text ~LET %S の`子~text内容$ ◎ Let source text be el's child text content.
- %src ~LET [ %S は `src$a 属性を有するならば その値 / ~ELSE_ ε ] ◎ ↓
- ~IF[ %src ~EQ ε ]~AND[ %~source~text ~EQ 空~文字列 ] ⇒ ~RET ◎ If el has no src attribute, and source text is the empty string, then return.
- ~IF[ %S は`接続されて$いない ] ⇒ ~RET ◎ If el is not connected, then return.
-
%~script~blockの種別~文字列 ~LET 次に与える[ %type, %language ]が満たす条件に応じて、 下の表tの 3 列目に与えられる値:
- %type ~LET[ %S は `type$a 属性を有するならば その値 / ~ELSE_ ε ]
- %language ~LET[ %S は `language$a 属性を有するならば その値 / ~ELSE_ ε ]
%type %language %~script~blockの種別~文字列 ε ε `text/javascript^l ε 空~文字列 `text/javascript^l ε 空でない文字列 [ `text/^l, %language ]を連結した結果 空~文字列 任意 `text/javascript^l 空でない文字列 任意 `前後の~ASCII空白~列を剥ぐ$( %type ) 注記: `language$a 属性は、 決して適合せず, `type$a 属性が在るときは常に無視される。 ◎ The language attribute is never conforming, and is always ignored if there is a type attribute present.
- ~IF[ %~script~blockの種別~文字列 は`~JS~MIME型に~essence合致-$する ] ⇒ %S の`種別$scE ~SET `classic^l ◎ If the script block's type string is a JavaScript MIME type essence match, then set el's type to "classic".
- ~ELIF[ %~script~blockの種別~文字列 は `module^l に`~ASCII大小無視$で合致する ] ⇒ %S の`種別$scE ~SET `module^l ◎ Otherwise, if the script block's type string is an ASCII case-insensitive match for the string "module", then set el's type to "module".
- ~ELIF[ %~script~blockの種別~文字列 は `importmap^l に`~ASCII大小無視$で合致する ] ⇒ %S の`種別$scE ~SET `importmap^l ◎ Otherwise, if the script block's type string is an ASCII case-insensitive match for the string "importmap", then set el's type to "importmap".
- ~ELSE ⇒ ~RET (実行される~scriptはなく, %S の`種別$scEは ~NULL のまま。) ◎ Otherwise, return. (No script is executed, and el's type is left as null.)
- ~IF[ %構文解析器~文書 ~NEQ ~NULL ] ⇒# %S の`構文解析器~文書$scE ~SET %構文解析器~文書; %S の`非同期cを強制するか$scE ~SET ~F ◎ If parser document is non-null, then set el's parser document back to parser document and set el's force async to false.
- ~Assert: %S の`構文解析器~文書$scE ~EQ %構文解析器~文書 【この段は、この訳による補完。】
- %S の`すでに開始したか$scE ~SET ~T ◎ Set el's already started to true.
- %文書 ~LET %S の`~node文書$ ◎ ↓
- %S の`準備~時点の文書$scE ~SET %文書 ◎ Set el's preparation-time document to its node document.
- ~IF[ %構文解析器~文書 ~NIN { ~NULL, %文書【!%S の`準備~時点の文書$scE】 } ] ⇒ ~RET ◎ If parser document is non-null, and parser document is not equal to el's preparation-time document, then return.
-
~IF[ %S 用の`~scriptingは不能化されて$いる ] ⇒ ~RET ◎ If scripting is disabled for el, then return.
注記: `~scriptingは不能化されて$いる,の定義により、 次に該当する~scriptは,実行されない:
- `XMLHttpRequest$I の `responseXML$m 文書~内の~script。 `XHR$r
- `DOMParser$I が作成した文書~内の~script。 `DOMPARSING$r
- `XSLTProcessor$I の `transformToDocument()$m 特能により作成された文書~内の~script。 `XSLTP$r
- [ `createDocument()$m ~APIを利用して作成された`文書$ ]の中に,ある~scriptにより先ず挿入された~script。 `DOM$r 【! *先ず】
- %種別 ~LET %S の`種別$scE ◎ ↓
-
~IF[ %S は `nomodule$a 内容~属性を有する ]~AND[ %種別 ~EQ `classic^l ] ⇒ ~RET ◎ If el has a nomodule content attribute and its type is "classic", then return.
注記: これは、[ `~module~script$に対し `nomodule$a を指定しても効果はなく, ~algoはそのまま継続される ]ことを意味する。 ◎ This means specifying nomodule on a module script has no effect; the algorithm continues onward.
- ~IF[ %src ~EQ ε ] ⇒ ~IF[ `要素における~inline型の挙動は~CSPにより阻止されるべきか?$( %S, `script^l, %~source~text ) `CSP$r の結果 ~EQ `阻止される^i ] ⇒ ~RET ◎ If el does not have a src content attribute, and the Should element's inline behavior be blocked by Content Security Policy? algorithm returns "Blocked" when given el, "script", and source text, then return. [CSP]
-
~IF[ %種別 ~EQ `classic^l ]~AND[ %S は `event$a 属性を有する ]~AND[ %S は `for$a 属性を有する ]:
- %event ~LET `~ASCII小文字~化する$( `前後の~ASCII空白~列を剥ぐ$( %S の `event$a 属性の値 ) )
- ~IF[ %event ~NIN { `onload^l, `onload()^l } ] ⇒ ~RET
- %for ~LET `~ASCII小文字~化する$( `前後の~ASCII空白~列を剥ぐ$( %S の `for$a 属性の値 ) )
- ~IF[ %for ~NEQ `window^l ] ⇒ ~RET
-
%符号化法 ~LET [[ %S は `charset$a 属性を有していて[ `~labelから符号化法を取得する$( その属性~値 ) の結果 ~NEQ `失敗^i ]]ならば その結果 / ~ELSE_ %文書 の`符号化法$doc ] ◎ If el has a charset attribute, then let encoding be the result of getting an encoding from the value of the charset attribute. ◎ If el does not have a charset attribute, or if getting an encoding failed, then let encoding be el's node document's the encoding.
注記: [ %種別 ~EQ `module^l ]の場合、 この符号化法は無視されることになる。 ◎ If el's type is "module", this encoding will be ignored.
- %古典~script~CORS設定 ~LET %S の `crossorigin$a 内容~属性の現在の状態 ◎ Let classic script CORS setting be the current state of el's crossorigin content attribute.
- %~module~script資格証~mode ~LET %S の `crossorigin$a 内容~属性~用の`~CORS設定群~属性の資格証~mode$ ◎ Let module script credentials mode be the CORS settings attribute credentials mode for el's crossorigin content attribute.
- %暗号用~nonce ~LET %S の `CryptographicNonce$sl 内部~slotの値 ◎ Let cryptographic nonce be el's [[CryptographicNonce]] internal slot's value.
- %完全性~metadata ~LET [ %S は `integrity$a 属性を有するならば その値 / ~ELSE_ 空~文字列 ] ◎ If el has an integrity attribute, then let integrity metadata be that attribute's value. ◎ Otherwise, let integrity metadata be the empty string.
- %~referrer施策 ~LET %S の `referrerpolicy$a 内容~属性の現在の状態 ◎ Let referrer policy be the current state of el's referrerpolicy content attribute.
- %~fetch優先度 ~LET %S の `fetchpriority$a 内容~属性の現在の状態 ◎ Let fetch priority be the current state of el's fetchpriority content attribute.
- %構文解析器~metadata ~LET [ %構文解析器~文書 ~NEQ ~NULL ならば `parser-inserted^l / ~ELSE_ `not-parser-inserted^l ] ◎ Let parser metadata be "parser-inserted" if el is parser-inserted, and "not-parser-inserted" otherwise.
- %~option群 ~LET 新たな`~script~fetch~option群$ — その ⇒# `暗号用~nonce$sfO ~SET %暗号用~nonce, `完全性~metadata$sfO ~SET %完全性~metadata, `構文解析器~metadata$sfO ~SET %構文解析器~metadata, `資格証~mode$sfO ~SET %~module~script資格証~mode, `~referrer施策$sfO ~SET %~referrer施策, `~fetch優先度$sfO ~SET %~fetch優先度 ◎ Let options be a script fetch options whose cryptographic nonce is cryptographic nonce, integrity metadata is integrity metadata, parser metadata is parser metadata, credentials mode is module script credentials mode, referrer policy is referrer policy, and fetch priority is fetch priority.
- %設定群~obj ~LET %文書 に`関連な設定群~obj$ ◎ Let settings object be el's node document's relevant settings object.
-
~IF[ %src ~NEQ ε ]: ◎ If el has a src content attribute, then:
-
~IF[ %S の`種別$scE ~EQ `importmap^l ]: ◎ If el's type is "importmap", then\
-
`要素~taskを~queueする$( `~DOM操作~task~source$, %S, 次の手続き ) ◎ queue an element task on the DOM manipulation task source given el to\
手続きは ⇒ `~eventを発火する$( %S, `error$et ) ◎ fire an event named error at el,\ - ~RET ◎ and return.
注記: 現時点では、 外部~import~map~scriptは,~supportされない。 ~supportを追加することについての論点は、 `WICG/import-maps 課題 #235@https://github.com/WICG/import-maps/issues/235$ を見よ。 ◎ External import map scripts are not currently supported. See WICG/import-maps issue #235 for discussions on adding support.
-
-
~IF[ %src ~EQ 空~文字列 ]: ◎ ↑↑Let src be the value of el's src attribute. ◎ If src is the empty string, then\
-
`要素~taskを~queueする$( `~DOM操作~task~source$, %S, 次の手続き ) ◎ queue an element task on the DOM manipulation task source given el to\
手続きは ⇒ `~eventを発火する$( %S, `error$et ) ◎ fire an event named error at el,\ - ~RET ◎ and return.
-
- %S の`外部~fileか$scE ~SET ~T ◎ Set el's from an external file to true.
- %~URL ~LET `~URLを符号化法の下で相対的に構文解析する$( %src, %文書 ) ◎ Let url be the result of encoding-parsing a URL given src, relative to el's node document.
-
~IF[ %~URL ~EQ `失敗^i ]: ◎ If url is failure, then\
-
`要素~taskを~queueする$( `~DOM操作~task~source$, %S, 次の手続き ) ◎ queue an element task on the DOM manipulation task source given el to\
手続きは ⇒ `~eventを発火する$( %S, `error$et ) ◎ fire an event named error at el,\ - ~RET ◎ and return.
-
- ~IF[ %S には`具現化を阻む能性$がある ] ⇒ `具現化を阻む$( %S ) ◎ If el is potentially render-blocking, then block rendering on el.
- %S の`~load~eventを遅延しているか$scE ~SET ~T ◎ Set el's delaying the load event to true.
- ~IF[ %S は現在`具現化を阻んで$いる ] ⇒ %~option群 の`具現化を阻んでいるか$sfO ~SET ~T ◎ If el is currently render-blocking, then set options's render-blocking to true.
- %完了-時の手続き ~LET 所与の ( %結果 ) に対し,次を走らす手続き ⇒ `~script要素を準備済みにする$( %S, %結果 ) ◎ Let onComplete given result be the following steps: • Mark as ready el given result.
-
%種別 に応じて: ◎ Switch on el's type:
- `classic^l ⇒ `古典~scriptを~fetchする$( ↓ ) ⇒# %~URL, %設定群~obj, %~option群, %古典~script~CORS設定, %符号化法, %完了-時の手続き ◎ "classic" • Fetch a classic script given url, settings object, options, classic script CORS setting, encoding, and onComplete.
-
`module^l:
- ~IF[ %S は `integrity$a 属性を有さない ] ⇒ %~option群 の`完全性~metadata$sfO ~SET `~module完全性~metadataを解決する$( %~URL, %設定群~obj ) ◎ If el does not have an integrity attribute, then set options's integrity metadata to the result of resolving a module integrity metadata with url and settings object.
- `外部~module~script~graphを~fetchする$( ↓ ) ⇒# %~URL, %設定群~obj, %~option群, %完了-時の手続き ◎ "module" • Fetch an external module script graph given url, settings object, options, and onComplete.
処理能の理由から、 ~UAは: ◎ For performance reasons, user agents\
- %S の `src$a 属性が設定され次第,すぐに[ 古典~script/~module~graph ]の~fetchingを(上に定義したとおりに)開始してもヨイ — ~~実際に %S が`接続され$る (かつ,それまでは %S の `crossorigin$a 属性の値は変更されない) まで待つことなく。 いずれにせよ, %S が`接続され$たなら、 この段に述べたとおりに,読込nを開始するモノトスル。 ◎ may start fetching the classic script or module graph (as defined above) as soon as the src attribute is set, instead, in the hope that el will become connected (and that the crossorigin attribute won't change value in the meantime). Either way, once el becomes connected, the load must have started as described in this step.\
-
前項のような事前~fetchingを遂行する下で,次のいずれかに該当する場合…:
- %S は、 ~~実際には,`接続され$なかった
- %S は文書~内に挿入されたが、 それまでに %S の[ `src$a / `crossorigin$a ]属性が動的に変更された
…場合、 そのように得された~scriptは実行しないとする — ~fetchingは、 実質的に浪費されることになる。
◎ If the UA performs such prefetching, but el never becomes connected, or the src attribute is dynamically changed, or the crossorigin attribute is dynamically changed, then the user agent will not execute the script so obtained, and the fetching process will have been effectively wasted.
-
-
~ELSE ( %src ~EQ ε ): ◎ If el does not have a src content attribute:
- %基底~URL ~LET %文書 の`文書~基底~URL$ ◎ Let base URL be el's node document's document base URL.
-
%種別 に応じて: ◎ Switch on el's type:
-
`classic^l: ◎ "classic"
- %~script ~LET `古典~scriptを作成する$( ↓ ) ⇒# %~source~text, %設定群~obj, %基底~URL, %~option群 ◎ Let script be the result of creating a classic script using source text, settings object, base URL, and options.
- `~script要素を準備済みにする$( %S, %~script ) ◎ Mark as ready el given script.
-
`module^l: ◎ "module"
- %S の`~load~eventを遅延しているか$scE ~SET ~T ◎ Set el's delaying the load event to true.
-
~IF[ %S には`具現化を阻む能性$がある ]: ◎ If el is potentially render-blocking, then:
- `具現化を阻む$( %S ) ◎ Block rendering on el.
- %~option群 の`具現化を阻んでいるか$sfO ~SET ~T ◎ Set options's render-blocking to true.
-
`~inline~module~script~graphを~fetchする$( ↓ ) ⇒# %~source~text, %基底~URL, %設定群~obj, %~option群, 次の手続き ◎ Fetch an inline module script graph, given source text, base URL, settings object, options, and with\
手続きは、 所与の ( %結果 ) に対し ⇒ `要素~taskを~queueする$( `~network用~task~source$, %S, 次の手続き ) ◎ the following steps given result: • Queue an element task on the networking task source given el to perform\
手続きは ⇒ `~script要素を準備済みにする$( %S, %結果 ) ◎ the following steps: • Mark as ready el given result.注記: ここで~taskを~queueすることは、 当の~inline~module~scriptは[ 依存物が無い/ その結果が同期的に構文解析-~errorになる ]場合でも, `~script要素を実行する$手続きを同期的に続行しないことを意味する。 ◎ Queueing a task here means that, even if the inline module script has no dependencies or synchronously results in a parse error, we won't proceed to execute the script element synchronously.
-
`importmap^l: ◎ "module"
- %結果 ~LET `~import~map構文解析-結果を作成する$( %~source~text, %基底~URL ) ◎ Let result be the result of creating an import map parse result given source text and base URL.
- `~script要素を準備済みにする$( %S, %結果 ) ◎ Mark as ready el given result.
-
-
~IF[[ %種別 ~EQ `classic^l ]~AND[ %src ~NEQ ε ]]~OR[ %種別 ~EQ `module^l ]: ◎ If el's type is "classic" and el has a src attribute, or el's type is "module":
- ~Assert: %S の`結果$scE ~EQ `未初期化^i ◎ Assert: el's result is "uninitialized".
-
~IF[ %S は `async$a 属性を有する ]~OR[ %S の`非同期cを強制するか$scE ~EQ ~T ]: ◎ If el has an async attribute or el's force async is true:
- %~script群 ~LET %S の`準備~時点の文書$scEの`アリな限りすぐに実行される~scriptたちが成す集合$ ◎ Let scripts be el's preparation-time document's set of scripts that will execute as soon as possible.
- %~script群 に %S を`付加する$set ◎ Append el to scripts.
-
%S の`結果は準備済み時の手続き$scE ~SET 次を走らす手続き: ◎ Set el's steps to run when the result is ready to the following:
- `~script要素を実行する$( %S ) ◎ Execute the script element el.
- %~script群 から %S を`除去する$ ◎ Remove el from scripts.
-
~ELIF[ %構文解析器~文書 ~EQ ~NULL ]: ◎ Otherwise, if el is not parser-inserted:
- %~script群 ~LET %S の`準備~時点の文書$scEの`アリな限りすぐに順に実行される~scriptたちが成す~list$ ◎ Let scripts be el's preparation-time document's list of scripts that will execute in order as soon as possible.
- %~script群 に %S を`付加する$ ◎ Append el to scripts.
-
%S の`結果は準備済み時の手続き$scE ~SET 次を走らす手続き: ◎ Set el's steps to run when the result is ready to the following:
- ~IF[ %~script群[ 0 ] ~NEQ %S ] ⇒ ~RET ◎ If scripts[0] is not el, then abort these steps.
-
~WHILE[ %~script群 は空でない ]~AND[ %~script群[ 0 ] の`結果$scE ~NEQ `未初期化^i ]: ◎ While scripts is not empty, and scripts[0]'s result is not "uninitialized":
- `~script要素を実行する$( %~script群[ 0 ] ) ◎ Execute the script element scripts[0].
- %~script群 から %~script群[ 0 ] を`除去する$ ◎ Remove scripts[0].
-
~ELIF[ %S は `defer$a 属性を有する ]~OR[ %種別 ~EQ `module^l ]: ◎ Otherwise, if el has a defer attribute or el's type is "module":
- %構文解析器~文書 の`文書を構文解析し終えたときに実行されることになる~scriptたちが成す~list$に %S を`付加する$ ◎ Append el to its parser document's list of scripts that will execute when the document has finished parsing.
- %S の`結果は準備済み時の手続き$scE ~SET 次を走らす手続き ⇒ %S の`構文解析器にて実行されるに準備済みか$scE ~SET ~T (当の構文解析器が,この~scriptの実行ngを取扱うことになる。) ◎ Set el's steps to run when the result is ready to the following: set el's ready to be parser-executed to true. (The parser will handle executing the script.)
-
~ELSE: ◎ Otherwise:
- %構文解析器~文書 の`構文解析器を阻んでいる~script$ ~SET %S ◎ Set el's parser document's pending parsing-blocking script to el.
- `具現化を阻む$( %S ) ◎ Block rendering on el.
- %S の`結果は準備済み時の手続き$scE ~SET 次を走らす手続き ⇒ %S の`構文解析器にて実行されるに準備済みか$scE ~SET ~T (当の構文解析器が,この~scriptの実行ngを取扱うことになる。) ◎ Set el's steps to run when the result is ready to the following: set el's ready to be parser-executed to true. (The parser will handle executing the script.)
-
~ELSE: ◎ Otherwise:
- ~Assert: %S の`結果$scE ~NEQ `未初期化^i ◎ Assert: el's result is not "uninitialized".
-
~IF[ ~AND↓ ]… ◎ If all of the following are true:
- %S の`種別$scE ~EQ `classic^l ◎ el's type is "classic";
- %構文解析器~文書 ~NEQ ~NULL ◎ el is parser-inserted;
- `~scriptを阻んでいる~stylesheetは在るか?$( %構文解析器~文書 ) ~EQ ~T ◎ el's parser document has a style sheet that is blocking scripts; and
-
%S を作成した構文解析器は ~OR↓ を満たす:
- `~XML構文解析器$である
- [ `~HTML構文解析器$である ]~AND[ その`~script入子ng~level$ ~LTE 1 ]
…ならば: ◎ then:
- %構文解析器~文書 の`構文解析器を阻んでいる~script$ ~SET %S ◎ Set el's parser document's pending parsing-blocking script to el.
- %S の`構文解析器にて実行されるに準備済みか$scE ~SET ~T (当の構文解析器が,この~scriptの実行ngを取扱うことになる。) ◎ Set el's ready to be parser-executed to true. (The parser will handle executing the script.)
- ~ELSE ⇒ `~script要素を実行する$( %S ) — 他の~scriptがすでに実行-中にあっても,`即時$に ◎ Otherwise, immediately execute the script element el, even if other scripts are already executing.
各 `文書$には、 次に挙げるものが結付けられる: ◎ ↓
- `構文解析器を阻んでいる~script@ ◎ Each Document has a pending parsing-blocking script,\
- `script$e 要素 / ~NULL — 初期~時は ~NULL とする。 ◎ which is a script element or null, initially null. ◎
- `アリな限りすぐに実行される~scriptたちが成す集合@ ◎ Each Document has a set of scripts that will execute as soon as possible,\
- `script$e 要素たちが成す`有順序~集合$ — 初期~時は空とする。 ◎ which is a set of script elements, initially empty. ◎
- `アリな限りすぐに順に実行される~scriptたちが成す~list@ ◎ Each Document has a list of scripts that will execute in order as soon as possible,\
- `script$e 要素たちが成す`~list$ — 初期~時は空とする。 ◎ which is a list of script elements, initially empty.
- `文書を構文解析し終えたときに実行されることになる~scriptたちが成す~list@ ◎ Each Document has a list of scripts that will execute when the document has finished parsing,\
- `script$e 要素たちが成す`~list$ — 初期~時は空とする。 ◎ which is a list of script elements, initially empty. ◎
注記: ある構文解析器 %構文解析器 を阻んでいる `script$e 要素 %~script が[ 通常に %構文解析器 を阻まなくなる ]前に別の`文書$へ移動された場合でも、[ %構文解析器 を阻んでいる条件が,それ以上~適用されなくなる ]まで, %構文解析器 を阻み続ける (例: %~script が,構文解析-時には[ 元の`文書$に`~scriptを阻んでいる~stylesheetが在る@~HEmetadata#has-a-style-sheet-that-is-blocking-scripts$ ]ことにより `構文解析器を阻んでいる~script$であった場合、[ 阻んでいる~stylesheetたちが読込まれる前に, %~script が別の`文書$へ移動された ]としても, %~script は[ それらの~stylesheetすべてが読込まれる ]まで %構文解析器 を阻む — その時点で、 %~script は実行され, %構文解析器 を阻まなくなる)。 ◎ If a script element that blocks a parser gets moved to another Document before it would normally have stopped blocking that parser, it nonetheless continues blocking that parser until the condition that causes it to be blocking the parser no longer applies (e.g., if the script is a pending parsing-blocking script because the original Document has a style sheet that is blocking scripts when it was parsed, but then the script is moved to another Document before the blocking style sheet(s) loaded, the script still blocks the parser until the style sheets are all loaded, at which time the script executes and the parser is unblocked).
`~script要素を実行する@ ときは、 所与の ( `script$e 要素 %S ) に対し: ◎ To execute the script element given a script element el:
- %文書 ~LET %S の`~node文書$ ◎ Let document be el's node document.
- ~IF[ %S の`準備~時点の文書$scE ~NEQ %文書 ] ⇒ ~RET ◎ If el's preparation-time document is not equal to document, then return.
- `具現化を阻まなくする$( %S ) ◎ Unblock rendering on el.
- ~IF[ %S の`結果$scE ~EQ ~NULL ] ⇒ `~eventを発火する$( %S, `error$et ); ~RET ◎ If el's result is null, then fire an event named error at el, and return.
- %~counterを増減するか ~LET ~IS[ %S の`外部~fileか$scE ~EQ ~T ]~OR[ %種別 ~EQ `module^l ] ◎ ↓
- ~IF[ %~counterを増減するか ] ⇒ %文書 の`破壊的な書込nは無視する~counter$ ~INCBY 1 ◎ If el's from an external file is true, or el's type is "module", then increment document's ignore-destructive-writes counter.
-
%種別 に応じて: ◎ Switch on el's type:
-
`classic^l: ◎ "classic"
- %旧-~script要素 ~LET %文書 の `currentScript$m 属性の値 【!object was most recently set】 ◎ Let oldCurrentScript be the value to which document's currentScript object was most recently set.
-
%文書 の`currentScript$m 属性 ~SET [ %S の`根$は`~shadow根$でないならば %S / ~ELSE_ ~NULL ] ◎ If el's root is not a shadow root, then set document's currentScript attribute to el. Otherwise, set it to null.
注記: ここでは、 %S が`文書~tree内$にあるかどうかは検査しない — `script$e 要素は,実行に先立って文書から除去されていることもあり、 その局面でも依然として, `currentScript$m は それを指す必要があるので。 ◎ This does not use the in a document tree check, as el could have been removed from the document prior to execution, and in that scenario currentScript still needs to point to it.
- `古典~scriptを走らす$( %S の`結果$scE ) ◎ Run the classic script given by el's result.
- %文書 の`currentScript$m 属性 ~SET %旧-~script要素 ◎ Set document's currentScript attribute to oldCurrentScript.
-
`module^l: ◎ "module"
- ~Assert: %文書 の`currentScript$m 属性 ~EQ ~NULL ◎ Assert: document's currentScript attribute is null.
- `~module~scriptを走らす$( %S の`結果$scE ) ◎ Run the module script given by el's result.
- `importmap^l ⇒ `~import~mapを登録する$( %S に`関連な大域~obj$, %S の`結果$scE ) ◎ "importmap" • Register an import map given el's relevant global object and el's result.
-
- ~IF[ %~counterを増減するか ~EQ ~T ] ⇒ %文書 の`破壊的な書込nは無視する~counter$ ~DECBY 1 ◎ Decrement the ignore-destructive-writes counter of document, if it was incremented in the earlier step.
- ~IF[ %S の`外部~fileか$scE ~EQ ~T ] ⇒ `~eventを発火する$( %S, `load$et ) ◎ If el's from an external file is true, then fire an event named load at el.
4.12.1.2. ~scripting言語
~UAには、 ~JSを~supportすることは要求されない。 この標準は、 ~JS以外の言語が~JS同様に~web~browserに広く採用されたならば, 更新される必要がある。 ~JS以外の言語を実装するのは、 そのときが来ない限り, この標準に定義されている `script$e 要素~用の処理~modelと競合することになる。 ◎ User agents are not required to support JavaScript. This standard needs to be updated if a language other than JavaScript comes along and gets similar wide adoption by web browsers. Until such a time, implementing other languages is in conflict with this standard, given the processing model defined for the script element.
~serverは、 ~JS資源に対しては:
- [ `Updates to ECMAScript Media Types^cite (~JS~MIME型に対する更新) `RFC9239$r ]に則って, `text/javascript$c を利用するべきである — 他の`~JS~MIME型$は利用するべきでない。
- 非`~JS~MIME型$を利用してはナラナイ。
外部~JS資源に対しては、 その `~Content-Type~header$内の~MIME型~parameterは,一般に無視される ( `charset^c ~parameterについては、効果がある事例もある)。 一方で, `script$e 要素の `type$a 属性~内のそれは、 有意になる — `~JS~MIME型に~essence合致-$の概念を利用するので。 ◎ For external JavaScript resources, MIME type parameters in `Content-Type` headers are generally ignored. (In some cases the `charset` parameter has an effect.) However, for the script element's type attribute they are significant; it uses the JavaScript MIME type essence match concept.
注記: 例えば、 `type$a 属性が `text/javascript; charset=utf-8^l に設定されている~scriptは, 評価されないことになる — 構文解析-時には妥当な`~JS~MIME型$であったとしても。 ◎ For example, scripts with their type attribute set to "text/javascript; charset=utf-8" will not be evaluated, even though that is a valid JavaScript MIME type when parsed.
外部~JS資源に対しては、 その`~Content-Type~header$の処理~周りにも,特別な考慮点が適用される — 詳細は、 `~script要素を準備する$~algo, および `Fetch^cite `FETCH$r を見よ。 ◎ Furthermore, again for external JavaScript resources, special considerations apply around `Content-Type` header processing as detailed in the prepare the script element algorithm and Fetch. [FETCH]
4.12.1.3. `script^e 要素の内容に課される制約
注記: この節に述べる変則的な制約を避ける最も容易かつ安全な仕方は、 ~script内に(例えば 文字列, 正規表現, ~comment として)~literalで現れるもののうち[ `<!--^l / `<script^l / `</script^l ]に~ASCII大小無視で合致するものは,常に[ `\x3C!--^l / `\x3Cscript^l / `\x3C/script^l ]に~escapeして、 式の中でそのような構成子を利用するような~codeを書くのは,避けることである。 この節における制約は,ちょっとしたことで抵触し易く、 そうすることで,陥穽は避けられる。 すなわち,~HTML内の `script$e ~blockの構文解析は、 歴史的な理由から,[ これらの文字~並びに面した際のふるまいが直感に反する ]ような[ 変則的で風変わりな実施 ]になっている。 ◎ The easiest and safest way to avoid the rather strange restrictions described in this section is to always escape an ASCII case-insensitive match for "<!--" as "\x3C!--", "<script" as "\x3Cscript", and "</script" as "\x3C/script" when these sequences appear in literals in scripts (e.g. in strings, regular expressions, or comments), and to avoid writing code that uses such constructs in expressions. Doing so avoids the pitfalls that the restrictions in this section are prone to triggering: namely, that, for historical reasons, parsing of script blocks in HTML is a strange and exotic practice that acts unintuitively in the face of these sequences.
`script$e 要素の`子孫~text内容$は、 次の~ABNFで与えられる `script^P 生成規則に合致しなければナラナイ — この ABNF の文字~集合は~Unicodeとする `ABNF$r: ◎ The script element's descendant text content must match the script production in the following ABNF, the character set for which is Unicode. [ABNF]
script = outer *( comment-open inner comment-close outer ) outer = < not-in-outer に合致する文字列は含まない任意の文字列 > not-in-outer = comment-open inner = < not-in-inner に合致する文字列は含まない任意の文字列 > not-in-inner = comment-close / script-open comment-open = "<!--" comment-close = "-->" script-open = "<" s c r i p t tag-end s = `0053^0x ; U+0053 LATIN CAPITAL LETTER S / `0073^0x ; U+0073 LATIN SMALL LETTER S c = `0043^0x ; U+0043 LATIN CAPITAL LETTER C / `0063^0x ; U+0063 LATIN SMALL LETTER C r = `0052^0x ; U+0052 LATIN CAPITAL LETTER R / `0072^0x ; U+0072 LATIN SMALL LETTER R i = `0049^0x ; U+0049 LATIN CAPITAL LETTER I / `0069^0x ; U+0069 LATIN SMALL LETTER I p = `0050^0x ; U+0050 LATIN CAPITAL LETTER P / `0070^0x ; U+0070 LATIN SMALL LETTER P t = `0054^0x ; U+0054 LATIN CAPITAL LETTER T / `0074^0x ; U+0074 LATIN SMALL LETTER T tag-end = `0009^0x ; U+0009 CHARACTER TABULATION (tab) / `000A^0x ; U+000A LINE FEED (LF) / `000C^0x ; U+000C FORM FEED (FF) / `0020^0x ; U+0020 SPACE / `002F^0x ; U+002F SOLIDUS (/) / `003E^0x ; U+003E GREATER-THAN SIGN (>)
`script$e 要素が`~script文書化$を包含する場合、 要素の内容にも,下の節で述べる制約が更に課される。 ◎ When a script element contains script documentation, there are further restrictions on the contents of the element, as described in the section below.
この~~問題を,次のような文字列を包含している~scriptで~~説明する: ◎ The following script illustrates this issue. Suppose you have a script that contains a string, as in:
const %example = 'Consider this string: <!-- <script>'; console.log(%example);
仮に,この文字列が `script$e ~block内に直に記された場合、 上の制約に違反することになる: ◎ If one were to put this string directly in a script block, it would violate the restrictions above:
<script> const %example = 'Consider this string: <!-- <script>'; console.log(%example); </script>
より大きな問題であり,なぜそれが制約に違反することになるかの理由は、 上の~script~blockが,`実際には終了していない^emことにある。 この~scriptに対する構文解析され方は~~理解しがたいものであり, 終了~tagの様に見える `</script>^l は、 実際には,依然として `script$e ~blockの一部を成す。 ~scriptは(終端していないので)実行されないが、 どうにかして実行されるようになっていた場合 — 例えば,~markupが次のようになっていた場合 — ~script(強調表示されている部分)は、 妥当な~JSでないので,失敗することになる: ◎ The bigger problem, though, and the reason why it would violate those restrictions, is that actually the script would get parsed weirdly: the script block above is not terminated. That is, what looks like a "</script>" end tag in this snippet is actually still part of the script block. The script doesn't execute (since it's not terminated); if it somehow were to execute, as it might if the markup looked as follows, it would fail because the script (highlighted here) is not valid JavaScript:
<script> const %example = 'Consider this string: <!-- <script>'; console.log(%example); </script> <!-- 見かけに反し、実際には,ここも~scriptの一部になる。 --> <script> ... // ここもまだ同じ~script~block内にある... </script>
ここで起きていることは、 旧来の理由から, `script$e 要素~内の文字列[ `<!--^l / `<script^l ]を対にしなければ、 ~HTMLの構文解析器からは,~blockが閉じたものと見なされなくなることである。 ◎ What is going on here is that for legacy reasons, "<!--" and "<script" strings in script elements in HTML need to be balanced in order for the parser to consider closing the block.
この節の冒頭で言及したように、 問題になり得る文字列を~escapeすれば,この問題をまるごと避けられる: ◎ By escaping the problematic strings as mentioned at the top of this section, the problem is avoided entirely:
<script>
/*
`\x3C^l は `<^l 用の~escape列を与えることに注意。
◎
Note: `\x3C` is an escape sequence for `<`.
*/
const %example = 'Consider this string: \x3C!-- \x3Cscript>';
console.log(%example);
</script>
<!-- ここは単に 2 つの~script~blockの合間にある~commentになる -->
<script>
... // 新たな~script~block
</script>
これらの文字~並びが~scriptの式の中に自然に生じる可能性もある — 次の例のように: ◎ It is possible for these sequences to naturally occur in script expressions, as in the following examples:
if (x<!--y) { ... } if ( player<script ) { ... }
このような事例では,文字たちは~escapeできないが、 この式は,そのような文字~並びが生じないように書き直せる: ◎ In such cases the characters cannot be escaped, but the expressions can be rewritten so that the sequences don't occur, as in:
if (x < !--y) { ... } if (!--y > x) { ... } if (!(--y) > x) { ... } if (player < script) { ... } if (script > player) { ... }
こうすることで,別の陥穽 — 歴史的な理由から、 `古典~script$内の文字列 `<!--^l は, 実際には[ `//^l と同じく, 行~commentの開始として扱われる ]こと — も避けられる。 ◎ Doing this also avoids a different pitfall as well: for related historical reasons, the string "<!--" in classic scripts is actually treated as a line comment start, just like "//".
4.12.1.4. 外部~scriptに対する~inlineな文書化
`script$e 要素に `src$a 属性が指定されている場合、 要素の内容は,[ 内容から導出される `text$m ~IDL属性の値が, 次の~ABNFによる `documentation^P 生成規則に合致する ]ようにならなければナラナイ — この ABNF の文字~集合は~Unicodeとする: `ABNF$r ◎ If a script element's src attribute is specified, then the contents of the script element, if any, must be such that the value of the text IDL attribute, which is derived from the element's contents, matches the documentation production in the following ABNF, the character set for which is Unicode. [ABNF]
documentation = *( *( space / tab / comment ) [ line-comment ] newline ) comment = slash star *( not-star / star not-slash ) 1*star slash line-comment = slash slash *not-newline ; characters tab = `0009^0x ; U+0009 CHARACTER TABULATION (tab) newline = `000A^0x ; U+000A LINE FEED (LF) space = `0020^0x ; U+0020 SPACE star = `002A^0x ; U+002A ASTERISK (*) slash = `002F^0x ; U+002F SOLIDUS (/) not-newline = `0000-0009^0x / `000B-10FFFF^0x ; U+000A LINE FEED (LF) 以外の `~scalar値$ not-star = `0000-0029^0x / `002B-10FFFF^0x ; U+002A ASTERISK (*) 以外の `~scalar値$ not-slash = `0000-002E^0x / `0030-10FFFF^0x ; U+002F SOLIDUS (/) 以外の `~scalar値$
注記: これは、 要素の内容を ~JS~comment内に置くことに対応する。 ◎ This corresponds to putting the contents of the element in JavaScript comments.
注記: この要件は、[ 前節に述べた, `script$e 要素の内容の構文に課される制約 ]に対する追加である。 ◎ This requirement is in addition to the earlier restrictions on the syntax of contents of script elements.
これにより,作者は、 依然として外部~script~fileを指しつつ,[ 文書の内側にも,~license情報や~API情報などの文書化を含める ]ことが可能になる。 この構文では、[ `src$a 属性も供している作者が, 妥当な~scriptの様に見える~dataを不用意に含めることがない ]よう拘束される。 ◎ This allows authors to include documentation, such as license information or API information, inside their documents while still referring to external script files. The syntax is constrained so that authors don't accidentally include what looks like valid script while also providing a src attribute.
`inline-documentation-1^xCode4.12.1.5. `script$e 要素と XSLT との相互作用
◎非規範的この仕様は、 ~XSLTと `script$e 要素とが,どう相互作用するかは定義しない。 しかしながら,ここでは、[ これを実際に定義している別の仕様が無い下での, 既存の実装に基づく実装者~向けの指針 ]を いくつか述べる: ◎ This specification does not define how XSLT interacts with the script element. However, in the absence of another specification actually defining this, here are some guidelines for implementers, based on existing implementations:
- ~browserが~DOMへの直接的な形式変換を実装する下で, `<?xml-stylesheet?>^c 処理命令により ~XSLT形式変換~programが誘発された場合、 ~XSLT処理器により作成される各 `script$e 要素は, その`構文解析器~文書$scEを正しく設定した上で, 形式変換が生じるに伴って`即時$に, 文書~順序で (ただし,[ `defer$a / `async$a ]による順序は除く) 走らす必要がある。 ◎ When an XSLT transformation program is triggered by an <?xml-stylesheet?> processing instruction and the browser implements a direct-to-DOM transformation, script elements created by the XSLT processor need to have its parser document set correctly, and run in document order (modulo scripts marked defer or async), immediately, as the transformation is occurring.
-
`XSLTProcessor$I の `transformToDocument()$m ~methodは、[ `属する閲覧~文脈$ ~EQ ~NULL ]なる`文書$に要素を追加する。 それに則り、 作成される どの `script$e 要素も,次のようにしておく必要がある:
- `~script要素を準備する$~algoの中で,その`すでに開始したか$scEを ~T に設定して、 決して実行されないようにする (`~scriptingは不能化-@~WAPI#concept-environment-noscript$される)。
- 要素の`構文解析器~文書$scEを設定する。
- 要素の `async$m ~IDL属性は、[ 要素が `async$a 内容~属性を有さないときは ~F を返す ]ようにする。
- `XSLTProcessor$I の `transformToFragment()$m ~methodは、[ `document.createElementNS()$m を利用して要素を作成することにより, 手動で築かれた`文書片$ ]と等価なものを作成する必要がある。 一例として、 `script$e 要素を作成する際には,その[ `構文解析器~文書$scEは ~NULL, `すでに開始したか$scEは ~F ]に設定した上で[ 当の`文書片$が文書~内に挿入された時点で実行される ]ようにする必要がある。 ◎ The XSLTProcessor transformToFragment() method needs to create a fragment that is equivalent to one built manually by creating the elements using document.createElementNS(). For instance, it needs to create script elements with null parser document and with their already started set to false, so that they will execute when the fragment is inserted into a document.
上の 1, 2 番目の事例と, 3 番目の事例との間の主な違いは、 前者は`文書$に対し演算する一方で, 後者は`文書片$に対し演算することにある。 ◎ The main distinction between the first two cases and the last case is that the first two operate on Documents and the last operates on a fragment.
4.12.2. `noscript^e 要素
- `分類$:
- `~metadata内容$ / `~flow内容$ / `句ng内容$ ◎ Metadata content. ◎ Flow content. ◎ Phrasing content.
- `この要素を利用できる文脈$:
- `~HTML文書$の `head$e 要素~内, または `~HTML文書$内の `句ng内容$が期待される所 — ただし、いずれにせよ,先祖に `noscript$e 要素がある所は除く。 ◎ In a head element of an HTML document, if there are no ancestor noscript elements. ◎ Where phrasing content is expected in HTML documents, if there are no ancestor noscript elements.
- `内容~model$:
-
要素~用の`~scriptingは不能化されて$いる場合:
- 要素が `head$e 要素~内にある場合、 順序は問わず,それぞれが[ `link$e, `style$e, `meta$e ]のいずれかであるような, 0 個以上の要素。
- 要素が `head$e 要素~外にある場合、 `透過的$になる — ただし、子孫に `noscript$e 要素があってはナラナイ。
- 他の場合、下の注釈文に与える要件に適合するような~text。 ◎ Otherwise: text that conforms to the requirements given in the prose.
- `text/html における~tag省略$:
- 両~tagとも省略不可。 ◎ Neither tag is omissible.
- `内容~属性$:
- `大域~属性$ ◎ Global attributes
- `~accessibilityの考慮点$
- `noscript$AA ◎ For authors. For implementers.
- `~DOM~interface$
- `HTMLElement$I を利用する ◎ Uses HTMLElement.
`noscript$e 要素は、[ `~scriptingは可能化されて$いる場合は,何も`表現-$しない/ `~scriptingは不能化されて$いる場合は,その子たちを`表現-$する ]。 それは、[ ~UAが~scriptingを~supportするかどうかに応じて,文書がどう構文解析されるかを違える ]ことにより,~UAに異なる~markupを提示するために利用される。 ◎ The noscript element represents nothing if scripting is enabled, and represents its children if scripting is disabled. It is used to present different markup to user agents that support scripting and those that don't support scripting, by affecting how the document is parsed.
`noscript$e 要素 %noscript が `~HTML文書$に利用される場合に許容される内容~modelは、次に従う: ◎ When used in HTML documents, the allowed content model is as follows:
- %noscript は `head$e 要素~内にある場合: ◎ ↓
-
- `~scriptingは不能化されて$いる場合: ◎ In a head element, if scripting is disabled for the noscript element
- %noscript は[ `link$e, `style$e, `meta$e ]要素のみを包含していなければナラナイ。 ◎ The noscript element must contain only link, style, and meta elements.
- `~scriptingは可能化されて$いる場合: ◎ In a head element, if scripting is enabled for the noscript element
-
%noscript は、~textのみを包含するか, または次を満たさなければナラナイ:
-
`~HTML素片~構文解析~algo$を ( `文脈~要素$V, %入力 ) として ( %noscript, %noscript の~text内容 ) を与える下で呼出したとき、 ~AND↓ を満たす:
- `構文解析-~error$は生じない
- ~algoの結果は、 ~nodeたちが成す~listであり,次に挙げる要素のみからなる ⇒ `link$e, `style$e, `meta$e
- 前項の~listが %noscript の子たちであったとするとき,適合する
-
- %noscript は `head$e 要素~外にある場合: ◎ ↓
-
- `~scriptingは不能化されて$いる場合: ◎ Outside of head elements, if scripting is disabled for the noscript element
-
%noscript の内容~modelは`透過的$になる
— ただし, %noscript の先祖に `noscript$e 要素があってはナラナイ
(すなわち, `noscript$e は入子にできない)。
◎
The noscript element's content model is transparent, with the additional restriction that a noscript element must not have a noscript element as an ancestor (that is, noscript can't be nested).
- `~scriptingは可能化されて$いる場合: ◎ Outside of head elements, if scripting is enabled for the noscript element
-
%noscript は、 ~textのみを包含するか, または次を満たさなければナラナイ:
-
下に与える~algoを走らせたとき、 ~AND↓ を満たす:
- 例外は投出されない
- 結果の文書は、[ `noscript$e, `script$e ]要素を含まない,適合~文書になる
- `~HTML構文解析器$において,`構文解析-~error$は生じない
-
-
~algoは、 次に従う: ◎ ↑
- 当の文書からすべての `script$e 要素を除去する ◎ Remove every script element from the document.
-
当の文書~内の ~EACH( `noscript$e 要素 %要素 ) に対し ⇒ %要素 の `outerHTML$m 属性 ~SET %要素 の`子~text内容$ ◎ Make a list of every noscript element in the document. For every noscript element in that list, perform the following steps: • Let s be the child text content of the noscript element. • Set the outerHTML attribute of the noscript element to the value of s.\
(これによる副作用として, %要素 は当の文書から除去される。) ◎ (This, as a side-effect, causes the noscript element to be removed from the document.)
注記: 上述の ひねくれた取扱いすべてが要求される — 歴史的な理由から、 `~HTML構文解析器$による `noscript$e 要素に対する取扱いは,[ 構文解析器が呼出されたとき, 当の要素~用の`~scriptingは可能化されていたかどうか@~HTMLparsing#scripting-flag$ ]に応じて異なるので。 ◎ All these contortions are required because, for historical reasons, the noscript element is handled differently by the HTML parser based on whether scripting was enabled or not when the parser was invoked.
`~XML文書$には、 `noscript$e 要素を利用してはナラナイ。 ◎ The noscript element must not be used in XML documents.
注記: `noscript$e 要素による効果があるのは、 `~HTML構文$に限られる — `~XML構文$に対する効果は無い。 この要素は、 ~scriptが可能化されている下では, 本質的に構文解析器を “切る” ように働く — すなわち、 要素の内容は[ 本物の要素たちではなく,純粋な~text ]として扱われる — が、 ~XMLには,これを行う仕組みは定義されていないので。 ◎ The noscript element is only effective in the HTML syntax, it has no effect in the XML syntax. This is because the way it works is by essentially "turning off" the parser when scripts are enabled, so that the contents of the element are treated as pure text and not as real elements. XML does not define a mechanism by which to do this.
`noscript$e 要素には、 他の要件は無い。 特に,当の要素~用の`~scriptingは可能化されて$いるときでも、 `noscript$e 要素の各~子が `~form提出$, ~scripting, 等々, から免れることはない。 ◎ The noscript element has no other requirements. In particular, children of the noscript element are not exempt from form submission, scripting, and so forth, even when scripting is enabled for the element.
次の例では、 ある~script用の~fallbackを供するために `noscript$e 要素が利用されている: ◎ In the following example, a noscript element is used to provide fallback for a script.
`noscript-1^xCode~scriptが不能化されている下では、 ~server側で計算を行わせるような~buttonが現れる。 一方で,~scriptが可能化されている下では、 その場で値が算出される。 ◎ When script is disabled, a button appears to do the calculation on the server side. When script is enabled, the value is computed on-the-fly instead.
`noscript$e 要素は、 “なまくら” である。 ~pageの~scriptが可能化されていても,何らかの理由で失敗することはある。 よって、 一般に, `noscript$e の利用は避ける方が良い — 次の例のように、 まず~scriptなしが~~前提の~pageにした上で,[ ~scriptが成功したなら、 その結果を その場で利用するよう,~pageを変更する ]よう設計することにより: ◎ The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, as in the next example:
`noscript-2^xCodeこの技法は、 `noscript$e が許容されない`~XML文書$においても有用になる。 ◎ The above technique is also useful in XML documents, since noscript is not allowed there.
4.12.3. `template^e 要素
- `分類$:
- `~metadata内容$ / `~flow内容$ / `句ng内容$ / `~scriptを~supportする要素$ ◎ Metadata content. ◎ Flow content. ◎ Phrasing content. ◎ Script-supporting element.
- `この要素を利用できる文脈$:
- `~metadata内容$が期待される所。 ◎ Where metadata content is expected.
- `句ng内容$が期待される所。 ◎ Where phrasing content is expected.
- `~scriptを~supportする要素$が期待される所。 ◎ Where script-supporting elements are expected.
- `span$a 属性を有さない `colgroup$e 要素の子として。 ◎ As a child of a colgroup element that doesn't have a span attribute.
- `内容~model$:
- `なし$(より明確には, `例を見よ@#template-example$。 ) ◎ Nothing (for clarification, see example).
- `text/html における~tag省略$:
- 両~tagとも省略不可。 ◎ Neither tag is omissible.
- `内容~属性$:
- `大域~属性$ ◎ Global attributes
-
`shadowrootmode$a — 宣言的な~shadow根による~stream法を可能化する
【 “~stream法” とは、 `~server側~具現化@https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#motivation$ (略称 SSR) — ~JSを利用せずに~shadow~DOMを構築すること — を指すと思われる。 】
◎ shadowrootmode — Enables streaming declarative shadow roots - `shadowrootdelegatesfocus$a — 宣言的な~shadow根に対し,その`~focusを委任するか$sRを ~T に設定する ◎ shadowrootdelegatesfocus — Sets delegates focus on a declarative shadow root
- `shadowrootclonable$a — 宣言的な~shadow根に対し,その`~clone可能か$sRを ~T に設定する ◎ shadowrootclonable — Sets clonable on a declarative shadow root
- `shadowrootserializable$a — 宣言的な~shadow根に対し,その`直列化-可能か$sRを ~T に設定する ◎ shadowrootserializable — Sets serializable on a declarative shadow root
- `~accessibilityの考慮点$
- `template$AA ◎ For authors. For implementers.
- `~DOM~interface$
-
[Exposed=Window] interface `HTMLTemplateElement@I : `HTMLElement$I { [`HTMLConstructor$] constructor(); readonly attribute `DocumentFragment$I `content$m; [`CEReactions$] attribute DOMString `shadowRootMode$m; [`CEReactions$] attribute boolean `shadowRootDelegatesFocus$m; [`CEReactions$] attribute boolean `shadowRootClonable$m; [`CEReactions$] attribute boolean `shadowRootSerializable$m; };
`template$e 要素は、[ ~scriptにより[ ~cloneできる/文書~内に挿入できる ]~HTML素片 ]を宣言するために利用される。 ◎ The template element is used to declare fragments of HTML that can be cloned and inserted in the document by script.
具現化においては、 `template$e 要素は何も`表現-$しない。 ◎ In a rendering, the template element represents nothing.
`shadowrootmode@a 内容~属性は、 `列挙d属性$であり, 次に挙げる~keyword, とり得る状態, それらの対応付けが定義される: ◎ The shadowrootmode content attribute is an enumerated attribute with the following keywords and states:
~keyword | 状態 | 概略的な記述 |
---|---|---|
`open@v | `開な@st | 当の `template^e 要素は、 開な宣言的~shadow根を表現する。 |
`closed@v | `閉な@st | 当の `template^e 要素は、 閉な宣言的~shadow根を表現する。 |
(なし) | `なし@st | 【当の `template^e 要素は、宣言的な~shadow根を表現しない。】 |
【 [ `open^v, `closed^v ]は、 `~shadow根$の`~mode$sR用の値を`指示する@~HTMLparsing#_template-shadowrootmode$。 】
◎ Keyword|State|Brief description open|open|The template element represents an open declarative shadow root. closed|closed|The template element represents a closed declarative shadow root.`shadowrootmode$a 属性の[ `妥当でない値~用の既定の状態$/ `欠落~値~用の既定の状態$ ]は、 `なし$st になるとする。 ◎ The shadowrootmode attribute's invalid value default and missing value default are both the none state.
`shadowrootdelegatesfocus@a 内容~属性は、 `真偽-属性$である。 ◎ The shadowrootdelegatesfocus content attribute is a boolean attribute.
`shadowrootclonable@a 内容~属性は、 `真偽-属性$である。 ◎ The shadowrootclonable content attribute is a boolean attribute.
`shadowrootserializable@a 内容~属性は、 `真偽-属性$である。 ◎ The shadowrootserializable content attribute is a boolean attribute.
`template$e 要素の`~template内容$は、 要素~自身の子ではない。 ◎ The template contents of a template element are not children of the element itself.
注記: ~DOM操作の結果として,[ `template$e 要素が `Text$I ~nodeや要素~nodeを包含する ]こともアリだが、 `template$e 要素の内容~modelは`なし$と定義されているので,それは違反になる。 ◎ It is also possible, as a result of DOM manipulation, for a template element to contain Text nodes and element nodes; however, having any is a violation of the template element's content model, since its content model is defined as nothing.
例えば、次の文書を考える: ◎ For example, consider the following document:
`template-1^xCode`template$e 内の `p$e 要素は、 ~DOM内では `template$e の子`ではない^em — それは、 `template$e 要素の `content$m ~IDL属性から返される`文書片$の子である。 ◎ The p element in the template is not a child of the template in the DOM; it is a child of the DocumentFragment returned by the template element's content IDL attribute.
~scriptが `template$e 要素に対し `appendChild()$m を~callした場合、 `template$e 要素に子を追加することになる (他の要素に対するときと同様に) — しかしながら、 そうすると, `template$e 要素の内容~modelに違反することになる。 ◎ If the script were to call appendChild() on the template element, that would add a child to the template element (as for any other element); however, doing so is a violation of the template element's content model.
- %~template.`content$m
- `~template内容$( `文書片$ )を返す。 ◎ Returns the template contents (a DocumentFragment).
各 `template$e 要素には、 ある`文書片$が結付けられる — それが、 当の要素の `~template内容@ になる。 `~template内容$には 【構文~以外に】 `適合性~要件は無い@~HTMLdom#no-browsing-context$。 ◎ Each template element has an associated DocumentFragment object that is its template contents. The template contents have no conformance requirements.\
~UAは, `template$e 要素 %要素 を作成したときは、 %要素 の`~template内容$を確立するために, 次の手続きを走らすモノトスル: ◎ When a template element is created, the user agent must run the following steps to establish the template contents:
- %文書 ~LET %要素 の`~node文書$の`~template内容を所有する適切な文書$ ◎ Let doc be the template element's node document's appropriate template contents owner document.
- %文書片 ~LET 新たな`文書片$ — その ⇒# `~node文書$ ~SET %文書, `~host$ ~SET %要素 ◎ Create a DocumentFragment object whose node document is doc and host is the template element.
- %要素 の`~template内容$ ~SET %文書片 ◎ Set the template element's template contents to the newly created DocumentFragment object.
`文書$ %文書 の `~template内容を所有する適切な文書@ は、 次の~algoが返す`文書$として定義される:
-
~IF[ %文書 は、 ある`文書$の`不活~template文書$である ]
- ~Assert: %文書 は、 この~algoの中で作成されたものである。
- ~RET %文書
- %不活~文書 ~LET %文書 の`不活~template文書$
- ~IF[ %不活~文書 ~NEQ ε ] ⇒ ~RET %不活~文書
- %不活~文書 ~LET 新たな`文書$ (それが`属する閲覧~文脈$ ~EQ ~NULL )
- ~IF[ %文書 は`~HTML文書$である ] ⇒ %不活~文書 の`種別$doc ~SET `html^l ( %不活~文書 も~HTML文書にする)
- %文書 の`不活~template文書$ ~SET %不活~文書
- ~RET %不活~文書
この~algoの目的においては、 各`文書$には, `不活~template文書@ が結付けられる 【その用途は,次の注記を見よ】 — それは、[ ε/`文書$ ]であり,初期~時は ε (~~存在しない)とする(必要に応じて作成される)。
注記: したがって,この~algoの中で作成されたもの以外の各`文書$は、[ 自身の `template$e 要素すべての`~template内容$ ]を[ それらが どの`閲覧~文脈$にも属さず,不活であり続ける(例: ~scriptを走らせない)ようにする ]ために所有するための[ 代理として動作する単独の`文書$ ]を`不活~template文書$として取得する。 `不活~template文書$の内側にある `template$e 要素は、 当面の間は【不活でなくなるまでは】, 単に同じ`文書$を その`~template内容$の所有者として再利用することになる 【上の~algoの最初の段】。
◎ A Document doc's appropriate template contents owner document is the Document returned by the following algorithm: • If doc is not a Document created by this algorithm, then: •• If doc does not yet have an associated inert template document, then: ••• Let new doc be a new Document (whose browsing context is null). This is "a Document created by this algorithm" for the purposes of the step above. ••• If doc is an HTML document, mark new doc as an HTML document also. ••• Let doc's associated inert template document be new doc. •• Set doc to doc's associated inert template document. • Each Document not created by this algorithm thus gets a single Document to act as its proxy for owning the template contents of all its template elements, so that they aren't in a browsing context and thus remain inert (e.g. scripts do not run). Meanwhile, template elements inside Document objects that are created by this algorithm just reuse the same Document owner for their contents. • Return doc.`template$e 要素~用の`受入-時の手続き$は、 所与の ( %~node, %旧-文書 ) に対し,次を走らす: ◎ The adopting steps (with node and oldDocument as parameters) for template elements are the following:
-
%文書 ~LET %~node の`~node文書$の`~template内容を所有する適切な文書$ ◎ Let doc be node's node document's appropriate template contents owner document.
注記: %~node の`~node文書$は、 直前に %~node を受入した`文書$である。 【 %旧-文書 ではなく( %旧-文書 は、この手続きにおいては利用されない)。】 ◎ node's node document is the Document object that node was just adopted into.
- %文書 に`~nodeを受入する$( %~node の(`文書片$である)`~template内容$ ) ◎ Adopt node's template contents (a DocumentFragment object) into doc.
`content@m 取得子~手続きは:
- %~template内容 ~LET コレの`~template内容$
- ~IF[ %~template内容 は `ShadowRoot$I ~nodeでない ] ⇒ ~RET %~template内容
- ~RET ~NULL
`shadowRootMode@m ~IDL属性は、 `既知な値のみに制限され$る下で, `shadowrootmode$a 内容~属性を`反映する$モノトスル。 ◎ The shadowRootMode IDL attribute must reflect the shadowrootmode content attribute, limited to only known values.
`shadowRootDelegatesFocus@m ~IDL属性は、 `shadowrootdelegatesfocus$a 内容~属性を`反映する$モノトスル。 ◎ The shadowRootDelegatesFocus IDL attribute must reflect the shadowrootdelegatesfocus content attribute.
`shadowRootClonable@m ~IDL属性は、 `shadowrootclonable$a 内容~属性を`反映する$モノトスル。 ◎ The shadowRootClonable IDL attribute must reflect the shadowrootclonable content attribute.
`shadowRootSerializable@m ~IDL属性は、 `shadowrootserializable$a 内容~属性を`反映する$モノトスル。 ◎ The shadowRootSerializable IDL attribute must reflect the shadowrootserializable content attribute.
`template$e 要素~用の`~clone時の手続き$は、 所与の ( %~node, %複製, %下位treeか ) に対し: ◎ The cloning steps for template elements given node, copy, and subtree are: The cloning steps for a template element node being cloned to a copy copy must run the following steps:
- ~IF[ %下位treeか ~EQ ~F ] ⇒ ~RET ◎ If subtree is false, then return.
- %~node の`~template内容$の`子~群$を成す ~EACH( %子 ) に対し,`~tree順序$で ⇒ `~nodeを~cloneする$( %子, ~T, %複製 の`~template内容$の`~node文書$, %複製 の`~template内容$ ) ◎ For each child of node's template contents's children, in tree order:\ clone a node given child with document set to copy's template contents's node document, subtree set to true, and parent set to copy's template contents.
次の例の~scriptは、 要素~構造を供する `template$e を利用して, 4 ~columnからなる~tableを ある~data構造からの~dataで拡充する — 手動で~markupして構造を生成する代わりに: ◎ In this example, a script populates a table four-column with data from a data structure, using a template to provide the element structure instead of manually generating the structure from markup.
`template-2^xCodeこの例では、 `template$e の内容~上で `cloneNode()$m を利用しているが,同じことを行う `document.importNode()$m を利用しても等価になる。 これらの~APIの唯一の相違は、 いつ`~node文書$が更新されるかになる — [ `cloneNode()$m では, `appendChild()$m で~nodeが付加されるとき/ `document.importNode()$m では,~nodeが~cloneされるとき ]に更新される。 ◎ This example uses cloneNode() on the template's contents; it could equivalently have used document.importNode(), which does the same thing. The only difference between these two APIs is when the node document is updated: with cloneNode() it is updated when the nodes are appended with appendChild(), with document.importNode() it is updated when the nodes are cloned.
4.12.3.1. `template$e 要素と~XSLT, ~XPathとの相互作用
◎非規範的この仕様は、 ~XSLTと `template$e 要素とが,どう相互作用するかは定義しない。 しかしながら,ここでは、[ これを実際に定義している別の仕様が無い下での, 既存の実装に基づく実装者~向けの指針 ]を いくつか述べる — これらの指針は、 この仕様に述べる他の処理と整合するように意図されている: ◎ This specification does not define how XSLT and XPath interact with the template element. However, in the absence of another specification actually defining this, here are some guidelines for implementers, which are intended to be consistent with other processing described in this specification:
- ~XSLT処理器は、[ この仕様に述べるとおりに動作する`~XML構文解析器$ ]に基づくならば,形式変換-の目的においては[ `template$e 要素が その`~template内容$の子孫を包含していた ]かのように動作する必要がある。 ◎ An XSLT processor based on an XML parser that acts as described in this specification needs to act as if template elements contain as descendants their template contents for the purposes of the transform.
- ~DOMを出力する~XSLT処理器は、[ `template$e 要素の中へ行く~nodeが,要素の`~template内容$の中に置かれる ]ことを確保する必要がある。 ◎ An XSLT processor that outputs a DOM needs to ensure that nodes that would go into a template element are instead placed into the element's template contents.
- ~XPath~DOM~APIを利用して~XPath式を評価する際には、 この仕様に述べる[ `~HTML構文解析器$/`~XML構文解析器$ ]を利用して構文解析された`文書$に適用するときは, `~template内容$を無視する必要がある。 ◎ XPath evaluation using the XPath DOM API when applied to a Document parsed using the HTML parser or the XML parser described in this specification needs to ignore template contents.
4.12.4. `slot^e 要素
- `分類$:
- `~flow内容$ / `句ng内容$ ◎ Flow content. ◎ Phrasing content.
- `この要素を利用できる文脈$:
- `句ng内容$が期待される所。 ◎ Where phrasing content is expected.
- `内容~model$:
- `透過的$ ◎ Transparent
- `text/html における~tag省略$:
- 両~tagとも省略不可。 ◎ Neither tag is omissible.
- `内容~属性$:
- `大域~属性$ ◎ Global attributes
- `name$a — `~shadow~tree$の`~slot$の`~slot名$ ◎ name — Name of shadow tree slot
- `~accessibilityの考慮点$
- `slot$AA ◎ For authors. For implementers.
- `~DOM~interface$
-
[Exposed=Window] interface `HTMLSlotElement@I : `HTMLElement$I { [`HTMLConstructor$] constructor(); [`CEReactions$] attribute DOMString `name$m; sequence<Node> `assignedNodes$m(optional `AssignedNodesOptions$I %options = {}); sequence<Element> `assignedElements$m(optional `AssignedNodesOptions$I %options = {}); undefined `assign$m((`Element$I or `Text$I)... %nodes); }; dictionary `AssignedNodesOptions@I { boolean `flatten@m = false; };
`slot$e 要素は、 `~slot$を定義する。 それは概して,`~shadow~tree$に利用される。 `slot$e 要素は、[ それに`割当された~node群$は空でないならば それらの~node / ~ELSE_ 自身の内容 ]を`表現-$する。 ◎ The slot element defines a slot. It is typically used in a shadow tree. A slot element represents its assigned nodes, if any, and its contents otherwise.
`name@a 内容~属性が包含する値は、 どのような文字列でもヨイ。 それは、 `~slot$の`~slot名$を表現する。 ◎ The name content attribute may contain any string value. It represents a slot's name.
注記: `name$a 属性は、 他の要素を,この要素が定義する`~slotに割当する$ために利用される: `name$a 属性を有する `slot$e 要素 %slot は、 その属性~値を`~slot名$とする`~slot$を作成し, 次を満たすような他の要素を その`~slotに割当する$ことが可能になる ⇒ [ 要素の `slot$a 属性の値は~slot名に合致する ]~AND[ %slot を子とする`~shadow~tree$の`根$の`~host$が,対応する `slot$a 属性~値を持つ【?】 ] 【!要素は slot の~shadow根の~hostの子/子孫である?】 ◎ The name attribute is used to assign slots to other elements: a slot element with a name attribute creates a named slot to which any element is assigned if that element has a slot attribute whose value matches that name attribute's value, and the slot element is a child of the shadow tree whose root's host has that corresponding slot attribute value.
- %slot.`name$m
- %slot の`~slot名$を取得したり設定するために利用できる。 ◎ Can be used to get and set slot's name.
- %slot.`assignedNodes(options)$m
-
%options の `flatten^m ~member値に応じて:
- ~F ( %options の省略時も含む)ならば ⇒ %slot に`割当された~node群$を返す。
- ~T ならば ⇒ %slot に`割当された~node群$は[ 空でないならば それを成す~nodeたち / 空ならば %slot の子たち ]に加えて、 それらに含まれる各 `slot$e 要素に対しても, `slot$e 要素が尽きるまで,再帰的に同じことをして得られる~node群を返す。
- %slot.`assignedElements(options)$m
- `assignedNodes(options)$m と同じ結果を,要素のみに制限した上で返す。 ◎ Returns slot's assigned nodes, limited to elements. ◎ slot . assignedElements({ flatten: true }) ◎ Returns the same as assignedNodes({ flatten: true }), limited to elements.
- %slot.`assign(...nodes)$m
- %~slot に`手動で割当された~node群$を所与の %nodes に設定する。 ◎ Sets slot's manually assigned nodes to the given nodes.
`name@m ~IDL属性は、 `name$a 内容~属性を`反映する$モノトスル。 ◎ The name IDL attribute must reflect the content attribute of the same name.
各 `slot$e 要素には `手動で割当された~node群@ がある — それは、 `~slot可能$たちが成す`有順序~集合$であり,初期~時は空とする。 この集合は、 `assign()$m により設定される。 ◎ The slot element has manually assigned nodes, which is an ordered set of slottables set by assign(). This set is initially empty.
注記: `手動で割当された~node群$は、 ~scriptからは直に~access可能でないので, `~slot可能$への弱い参照を利用して実装できる/され得る。 ◎ The manually assigned nodes set can be implemented using weak references to the slottables, because this set is not directly accessible from script.
`assignedNodes(options)@m ~method手続きは: ◎ The assignedNodes(options) method steps are:
- ~RET %options[ "`flatten$m" ] に応じて ⇒# ~F ならば コレに`割当された~node群$ / ~T ならば `~slot用に平坦~化された~slot可能なものを見出す$( コレ ) ◎ If options["flatten"] is false, then return this's assigned nodes. ◎ Return the result of finding flattened slottables with this.
`assignedElements(options)@m ~method手続きは: ◎ The assignedElements(options) method steps are:
- %結果 ~LET %options[ "`flatten$m" ] に応じて ⇒# ~F ならば コレに`割当された~node群$ / ~T ならば `~slot用に平坦~化された~slot可能なものを見出す$( コレ ) ◎ If options["flatten"] is false, then return this's assigned nodes, filtered to contain only Element nodes. ◎ Return the result of finding flattened slottables with this, filtered to contain only Element nodes.
- ~RET %結果 を `Element$I ~nodeのみを包含するように絞込んだ結果 ◎ ↑
`assign(...nodes)@m ~method手続きは: ◎ The assign(...nodes) method steps are:
- コレに`手動で割当された~node群$を成す ~EACH( %~node ) に対し ⇒ %~node の`手動~割当-先~slot$ ~SET ~NULL ◎ For each node of this's manually assigned nodes, set node's manual slot assignment to null.
- %~node集合 ~LET 新たな`有順序~集合$ ◎ Let nodesSet be a new ordered set.
-
%nodes を成す ~EACH( %~node ) に対し: ◎ For each node of nodes:
- %~slot ~LET %~node の`手動~割当-先~slot$
- ~IF[ %~slot ~NEQ ~NULL ] ⇒ %~slot に`手動で割当された~node群$から %~node を除去する ◎ If node's manual slot assignment refers to a slot, then remove node from that slot's manually assigned nodes.
- %~node の`手動~割当-先~slot$ ~SET コレ ◎ Set node's manual slot assignment to this.
- %~node集合 に %~node を`付加する$set ◎ Append node to nodesSet.
- コレに`手動で割当された~node群$ ~SET %~node集合 ◎ Set this's manually assigned nodes to nodesSet.
- `~treeに~slot可能なものを割当する$( コレの`根$ ) ◎ Run assign slottables for a tree for this's root.