2.1.1 並列処理

所与の手続きを `並列的@ （ `parallel^en ）に走らすとは、その手続きを，この標準~内の他の~logicと~~同時並行的に走らすことを意味する（例えば `~event-loop$と~~同時並行的に）。 この標準は、これが達成される精確な仕組みは定義しない — 例えば、時間を共有する協調的［ `multitasking, fibers, threads, processes^en ］, あるいは異なる［ `hyperthread, core, CPU, machine^en ］の利用, 等々。 対照的に、 `即時@ （ `immediate^en ）に走らすような演算は、現在~走っている~taskを中断して, その演算を走らせ終えてから, 中断した~taskを再開し~MUST。 ◎ To run steps in parallel means those steps are to be run, one after another, at the same time as other logic in the standard (e.g., at the same time as the event loop). This standard does not define the precise mechanism by which this is achieved, be it time-sharing cooperative multitasking, fibers, threads, processes, using different hyperthreads, cores, CPUs, machines, etc. By contrast, an operation that is to run immediately must interrupt the currently running task, run itself, and then resume the previously running task.

異なる`並列的$~algoが同じ~data上で演算するときの競合を避けるためには、`並列~queue$を利用できる。 ◎ To avoid race conditions between different in parallel algorithms that operate on the same data, a parallel queue can be used.

`並列~queue@ は、［ 順々に走らすことが要求される，~algo手続きたち ］からなる~queueを表現する。 ◎ A parallel queue represents a queue of algorithm steps that must be run in series.

各`並列~queue$は、 `~algo~queue@ を持つ — それは、`~queue$であり，初期~時には空とする。 ◎ A parallel queue has an algorithm queue (a queue), initially empty.

`並列~queue$ %並列~queue に，所与の `手続きを~enqueueする@ ときは ⇒ %並列~queue の`~algo~queue$に，その手続きを`~enqueue$する ◎ To enqueue steps to a parallel queue, enqueue the algorithm steps to the parallel queue's algorithm queue.

`新たな並列~queueを開始-@ するときは、次の手続きを走らす： ◎ To start a new parallel queue, run the following steps:

1. %並列~queue ~LET 新たな`並列~queue$ ◎ Let parallelQueue be a new parallel queue.

2. 次の手続きを`並列的$に走らす： ◎ Run the following steps in parallel:

   1. ~WHILE 無条件： ◎ While true:

      1. %手続き ~LET %並列~queue の`~algo~queue$から`~dequeue$した結果 ◎ Let steps be the result of dequeueing from parallelQueue's algorithm queue.
      2. %手続き を走らす （ %手続き が空なら何もしないことになる） ◎ If steps is not nothing, then run steps.
      3. ~Assert： %手続き を走らせても例外は投出されない — `並列的$に走っている手続きには、投出することは許容されないので。 ◎ Assert: running steps did not throw an exception, as steps running in parallel are not allowed to throw.

      注記： これは、継続的に走らす~loopとして実装することを実装に期待するものではない。 標準における~algoには、理解し易くなるよう，~battery-lifeや処理能に重きを置くことは必要とされないので。 ◎ Implementations are not expected to implement this as a continuously running loop. Algorithms in standards are to be easy to understand and are not necessarily great for battery life or performance.

3. ~RET %並列~queue ◎ Return parallelQueue.

注記： `並列的$に走っている手続き自身も，他の手続きを`並列的$に走らすことができる。 例： `並列~queue$の内側で、一連の段を，当の~queueにて並列的に走らすことも有用になり得る。 ◎ Steps running in parallel can themselves run other steps in in parallel. E.g., inside a parallel queue it can be useful to run a series of steps in parallel with the queue.

2.1.2. 資源

資源に対する用語 `~support^dfn される, 〜されている, 〜する, 等々は、~UAの実装が当の外部~資源の意味論を復号する能力を有することを指す。 実装は、外部~資源の［ 形式／型 ］を，その形式／型において必須とされる側面を無視することなく処理できるならば、~supportするという。 特定の資源が~supportされるかどうかは、その資源の形式に備わる どの特色機能が利用-中にあるかにも依存し得る。 ◎ The specification uses the term supported when referring to whether a user agent has an implementation capable of decoding the semantics of an external resource. A format or type is said to be supported if the implementation can process an external resource of that format or type without critical aspects of the resource being ignored. Whether a specific resource is supported can depend on what features of the resource's format are in use.

例えば PNG 画像は、その~pixel~dataを復号して具現化できるならば、その画像に，実装が知識を有さない~animation~dataが包含されていたとしても、~supportされる形式と見なされるであろう。 ◎ For example, a PNG image would be considered to be in a supported format if its pixel data could be decoded and rendered, even if, unbeknownst to the implementation, the image also contained animation data.

実装は、 MPEG-4 動画~fileの~metadataから動画の寸法を決定できたとしても，利用されている圧縮~形式を~supportしないならば、その形式を~supportするとは見なされないことになる。 ◎ An MPEG-4 video file would not be considered to be in a supported format if the compression format used was not supported, even if the implementation could determine the dimensions of the movie from the file's metadata.

一部の他の仕様 — 特に~HTTP仕様 — において `表現^i （ `representation^en ）と称されるもの 【参照先】 は、この仕様では `資源@ と称される。 `HTTP$r ◎ What some specifications, in particular the HTTP specification, refer to as a representation is referred to in this specification as a resource. [HTTP]

資源の `必須の下位資源@ とは、その資源を正しく処理するためには，可用になる必要がある資源である。 どの資源が必須（ `critical^en ）と見なされるかは、当の資源の形式を定義する仕様により定義される。 ◎ A resource's critical subresources are those that the resource needs to have available to be correctly processed. Which resources are considered critical or not is defined by the specification that defines the resource's format.

2.1.3. ~XMLとの互換性

~HTMLから~XMLへの移行を容易にするため、この仕様に適合している~UAは、少なくとも ~DOM／~CSSの目的においては，~HTML内の要素を`~HTML名前空間$（ `http://www.w3.org/1999/xhtml^l ）に属させることになる。 用語 `~HTML要素@ は、その名前空間に属する~~任意の要素を指す — 要素が~XML文書~内にある場合でも。 ◎ To ease migration from HTML to XML, UAs conforming to this specification will place elements in HTML in the http://www.w3.org/1999/xhtml namespace, at least for the purposes of the DOM and CSS. The term "HTML elements" refers to any element in that namespace, even in XML documents.

用語 `要素~型@ とは、［ 所与の局所~名を持つ, かつ 所与の名前空間に属する ］ような要素からなる集合を指す。 例えば `button$e 要素の要素~型は `button$e であり、次を意味する ⇒＃ その局所~名は `button^l である，かつ （上述にて定義したように，暗黙的に）`~HTML名前空間$に属する。 ◎ The term element type is used to refer to the set of elements that have a given local name and namespace. For example, button elements are elements with the element type button, meaning they have the local name "button" and (implicitly as defined above) the HTML namespace.

次を満たす属性~名は、 `~XML互換@ とされる ⇒＃ `XML$r にて定義される `Name$P 生成規則に合致する，かつ `003A^U COLON (:) は包含しない。 ◎ Attribute names are said to be XML-compatible if they match the Name production defined in XML and they contain no U+003A COLON characters (:). [XML]

2.1.4. DOM 木

要素または属性 が［ `無視される@ ／ 何か他の値として扱われる ／ それが他の何かであったかのように取扱われる ］ものと言明される所は、［ 当の~nodeが~DOM内にある後における~nodeの処理 ］のみを指す。 ~UAは、そのような状況において~DOMを変異させては~MUST_NOT。 ◎ When it is stated that some element or attribute is ignored, or treated as some other value, or handled as if it was something else, this refers only to the processing of the node after it is in the DOM. A user agent must not mutate the DOM in such situations.

内容~属性が所与の値 %V に `変更される／変化した^dfn と記されるのは、 %V が元の値と異なる場合に限られる — 属性に その元の値と同じ値を設定しても，それは変化しない。 ◎ A content attribute is said to change value only if its new value is different than its previous value; setting an attribute to a value it already has does not change it.

［ 属性~値 ／ `Text$I ~node ／ 文字列 ］に対し利用される用語 `空^dfn は、~textの長さが 0 であることを意味する（すなわち、 `0020^U SPACE や`制御~文字$も包含しない）。 ◎ The term empty, when used for an attribute value, Text node, or string, means that the length of the text is zero (i.e., not even containing controls or U+0020 SPACE).

所与の~node %N, %P に対し： ◎ ↓

• %N が %P の中へ `挿入された@node とは、次が生じたことをいう ⇒ %N を引数に`挿入-時の手続き$が呼出され， %N の新たな親は %P になった。 ◎ A node A is inserted into a node B when the insertion steps are invoked with A as the argument and A's new parent is B.＼
• %N が %P から `除去された@node とは、逆に，次が生じたことをいう ⇒ ( 除去される~node %N, ~nodeの旧~親 %P ) を引数に`除去-時の手続き$が呼出された。 ◎ Similarly, a node A is removed from a node B when the removing steps are invoked with A as the removedNode argument and B as the oldParent argument.

所与の~node %N に対し： ◎ ↓

• %N が `文書の中へ挿入された@ とは、次が生じたことをいう ⇒ `文書~木~内$に無かった %N が、 %N を引数に`挿入-時の手続き$が呼出された結果，`文書~木~内$に在るようになった。 ◎ A node is inserted into a document when the insertion steps are invoked with it as the argument and it is now in a document tree.＼

• %N が `文書から除去された@ とは、逆に，次が生じたことをいう ⇒ `文書~木~内$に在った %N が、 %N を引数に`除去-時の手続き$が呼出された結果，`文書~木~内$に無いようになった。 ◎ Analogously, a node is removed from a document when the removing steps are invoked with it as the argument and it is now no longer in a document tree.

所与の~node %N に対し： ◎ ↓

• %N が `接続された@ （ `becomes connected^en ）とは、次が生じたことをいう ⇒ `接続されて$いなかった %N が、 %N を引数に`挿入-時の手続き$が呼出された結果，`接続されて$いるようになった。 ◎ A node becomes connected when the insertion steps are invoked with it as the argument and it is now connected.＼
• %N が `切断された@ （ `becomes disconnected^en ）とは、逆に，次が生じたことをいう ⇒ `接続されて$いた %N が、 %N を引数に`除去-時の手続き$が呼出された結果，`接続されて$いないようになった。 ◎ Analogously, a node becomes disconnected when the removing steps are invoked with it as the argument and it is now no longer connected.

所与の~node %N に対し： ◎ ↓

• %N は `閲覧文脈に接続されて@ いるとは、 %N が次を満たすことをいう ⇒ ［ %N は`接続されて$いる ］~AND［ %N の`~shadowも含む根$が`属する閲覧文脈$ ~NEQ ε ］ ◎ A node is browsing-context connected when it is connected and its shadow-including root has a browsing context.＼

• %N が `閲覧文脈に接続された@ （ `becomes browsing-context connected^en ）とは、次が生じたことをいう ⇒ `閲覧文脈に接続されて$いなかった %N が、 %N を引数に`挿入-時の手続き$が呼出された結果，`閲覧文脈に接続されて$いるようになった。 ◎ A node becomes browsing-context connected when the insertion steps are invoked with it as the argument and it is now browsing-context connected.＼
• %N が `閲覧文脈から切断された@ （ `becomes browsing-context disconnected^en ）とは、逆に，次が生じたことをいう ⇒ `閲覧文脈に接続されて$いた %N が、［ %N を引数に`除去-時の手続き$が呼出された ］か, または［ %N の`~shadowも含む根$が`属する閲覧文脈$ ~EQ ε になった ］結果，`閲覧文脈に接続されて$いないようになった。 ◎ A node becomes browsing-context disconnected either when the removing steps are invoked with it as the argument and it is now no longer browsing-context connected, or when its shadow-including root no longer has a browsing context.

2.1.5. ~scripting

所与の~interface `Foo^I に対する句 “`Foo^I ~obj” は、 “~interface `Foo^I を実装している~obj” の略記である。 ◎ The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of the more accurate "an object implementing the interface Foo".

【 `Foo^I を継承する~interfaceを実装している~objも含まれる。 】

`~liveである@ とされた~DOM~objに対しては、その~obj上の［ 属性, ~method ］は、~dataの~snapshotではなく，実際の 【すなわち，現在の】 下層の~dataに対し演算され~MUST。 ◎ If a DOM object is said to be live, then the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data.

2.1.6. ~plugin

用語 `~plugin@ は、~UAが利用し, ~UAにより定義される内容~handlerであって、~UAによる`文書$の具現化の一部を成し得るが，［ `文書$の`子~閲覧文脈$として動作する ］ことも, ［ `文書$の~DOMに `Node$I ~objを導入する ］こともないものを指す。 ◎ The term plugin refers to a user-agent defined set of content handlers used by the user agent that can take part in the user agent's rendering of a Document object, but that neither act as child browsing contexts of the Document nor introduce any Node objects to the Document's DOM.

そのような内容~handlerは、概して 第三者主体から供される — ~UAも，自身に組込みの内容~handlerを~pluginとして指名できるが。 ◎ Typically such content handlers are provided by third parties, though a user agent can also designate built-in content handlers as plugins.

~UAは、~MIME型［ `text/plain$c ／ `application/octet-stream$c ］に対しては、登録-済みの`~plugin$があるものと見なしては~MUST_NOT。 ◎ A user agent must not consider the types text/plain and application/octet-stream as having a registered plugin.

~pluginの一例として、利用者が~PDF~fileへ~navigateしたときに`閲覧文脈$内で~instance化される~PDF~viewerが挙げられる。 これは、~UA自身が~PDF~viewer部品を実装した主体であるかどうかに関わらず，~pluginに数えられることになる。 一方で、~UAが（自身の~UIは利用せずに，）別々の~PDF~viewer~appを~~起動させる場合、その~appは，この定義においては~pluginではない。 ◎ One example of a plugin would be a PDF viewer that is instantiated in a browsing context when the user navigates to a PDF file. This would count as a plugin regardless of whether the party that implemented the PDF viewer component was the same as that which implemented the user agent itself. However, a PDF viewer application that launches separate from the user agent (as opposed to using the same interface) is not a plugin by this definition.

注記： この仕様は、~pluginと対話する仕組みは定義しない — それは［ ~UA／~platform ］に特有と予期されているので。 ~UAには、 Netscape Plugin ~API などの~pluginを~~選択的に組み込める仕組みを~supportするものもあれば、遠隔操作の内容~変換器を利用するものや, 一定の内容~型に対しては組込みの~pluginで~supportするものもある。 ~~実際、この仕様では，~UAによる~pluginの~supportは全く要求されない。 `NPAPI$r ◎ This specification does not define a mechanism for interacting with plugins, as it is expected to be user-agent- and platform-specific. Some UAs might opt to support a plugin mechanism such as the Netscape Plugin API; others might use remote content converters or have built-in support for certain types. Indeed, this specification doesn't require user agents to support plugins at all. [NPAPI]

~pluginは、 `sandbox$a 属性の意味論を尊守するならば， `保安化-@ できる。 ◎ A plugin can be secured if it honors the semantics of the sandbox attribute.

例えば，保安化された~pluginは、~sandbox化された `iframe$e の内側で~instance化されたときには，その内容は~pop-up-windowを作成できなくされることになる。 ◎ For example, a secured plugin would prevent its contents from creating pop-up windows when the plugin is instantiated inside a sandboxed iframe.

~browserは、`~plugin$用に意図される外部~内容と対話するときには，特段の注意を払うべきである。 第三者主体の手による~softwareを~UA自身と同じ特権で走らせた場合、その~software内の脆弱性は，~UA内のそれと同等に危険になる。 ◎ Browsers should take extreme care when interacting with external content intended for plugins. When third-party software is run with the same privileges as the user agent itself, vulnerabilities in the third-party software become as dangerous as those in the user agent.

~FINGERPRINTING 利用者が有する`~plugin$の集合は利用者ごとに異なり、利用者が一意に識別されるような機会を増やすような指紋収集の~~手段を供するので、~UAには，どの利用者に対しても 正確に同じ`~plugin$の集合を~supportすることが奨励される。 ◎ Since different users having different sets of plugins provides a fingerprinting vector that increases the chances of users being uniquely identified, user agents are encouraged to support the exact same set of plugins for each user.

2.1.7. 文字~符号化法

`文字~符号化法@（ 参照先 ）は、~byte~streamと~Unicode文字列との間で相互に変換する仕方であり， WHATWG Encoding 標準 `ENCODING$r にて定義される。 多義的にならない所では、単に “符号化法” とも称される。 各 `符号化法$には、［ `符号化法~名@（ 参照先 ）と 1 個以上の `符号化法~label@（ 参照先 ） ］が~~定義されている。 ◎ A character encoding, or just encoding where that is not ambiguous, is a defined way to convert between byte streams and Unicode strings, as defined in the WHATWG Encoding standard. An encoding has an encoding name and one or more encoding labels, referred to as the encoding's name and labels in the Encoding standard. [ENCODING]

`UTF-16@ 符号化法とは、`符号化法~名$が［ `UTF-16BE$, または `UTF-16LE$ ］である符号化法を指す。 `ENCODING$r ◎ A UTF-16 encoding is UTF-16BE or UTF-16LE. [ENCODING]

`符号化法$のうち，`UTF-16$ でないものは、 `~ASCII互換@ という。 `ENCODING$r ◎ An ASCII-compatible encoding is any encoding that is not a UTF-16 encoding. [ENCODING]

注記： WHATWG Encoding 標準にて定義されていない`符号化法$に対する~supportは禁制されるので、この仕様が`~ASCII互換$でないものとして扱う必要がある符号化法は、 `UTF-16$ に限られる。 ◎ Since support for encodings that are not defined in the WHATWG Encoding standard is prohibited, UTF-16 encodings are the only encodings that this specification needs to treat as not being ASCII-compatible encodings.

2.1.8. 各種 適合性の類別

この仕様は、次の二つに対する適合性~判定基準を述べる： ◎ This specification describes the conformance criteria for＼

• ~UA（実装者に関連する） ◎ user agents (relevant to implementers) and＼
• 文書（作者／著作~tool実装者に関連する） ◎ documents (relevant to authors and authoring tool implementers).

`適合~文書@ は、文書に課されるすべての適合性~判定基準に準拠するものである。 可読性のため、これらの適合性~要件のうち一部は，作者に対する適合性~要件として句される。 そのような要件は、暗黙的に文書に課されるものとされる。 定義により、すべての文書には，その作者があるものと見做される。 （一部の事例では、~UA自身がその作者になることもある — そのような~UAは、下に説明されるように，追加の規則の対象0になる。） ◎ Conforming documents are those that comply with all the conformance criteria for documents. For readability, some of these conformance requirements are phrased as conformance requirements on authors; such requirements are implicitly requirements on documents: by definition, all documents are assumed to have had an author. (In some cases, that author may itself be a user agent — such user agents are subject to additional rules, as explained below.)

例えば、要件にて “作者は `foobar^e 要素を利用しては~MUST_NOT” と言明されている場合、それは［ 文書が，名前 `foobar^e の要素を包含することは、許容されない ］ことを含意することになる。 ◎ For example, if a requirement states that "authors must not use the foobar element", it would imply that documents are not allowed to contain elements named foobar.

文書, 実装 に課される適合性~要件の間には、含意される関係性はない。 ~UAは、適合しない文書を好きに取扱う自由はない — この仕様にて述べる処理~modelは、入力~文書が適合するかどうかに関わらず，実装に適用される。 ◎ There is no implied relationship between document conformance requirements and implementation conformance requirements. User agents are not free to handle non-conformant documents as they please; the processing model described in this specification applies to implementations regardless of the conformity of the input documents.

【 しかしながら，適合しないあらゆる事例に対し処理~modelが指定されているわけではないので（おそらく，そうするのは現実的でない）、文書が適合しない場合の各 実装~間の挙動の一貫性は，原則的に仕様からは保障されないと考えるべきであろう。 】

~UAは、適合性~要件が互いに異なるような，いくつかの（互いに重なり合う）種類に分けられる： ◎ User agents fall into several (overlapping) categories with different conformance requirements.

~web~browserその他の，対話的~UA ◎ Web browsers and other interactive user agents

`~XML構文$を~supportする~web~browserは、`~HTML名前空間$に属する ~XML文書~内に見出された［ 要素, 属性 ］を — 他の仕様により，それらの要素の意味論が上書きされていない限り — この仕様にて述べるように処理して，利用者がそれらと対話できるようにし~MUST。 ◎ Web browsers that support the XML syntax must process elements and attributes from the HTML namespace found in XML documents as described in this specification, so that users can interact with them, unless the semantics of those elements have been overridden by other specifications.

適合~Web~browserは、~XML文書~内に `script$e 要素を見出した際に，その要素に包含されている~scriptを実行することになる。 しかしながら，要素が ~XSLTによる形式変換に見出された場合（~UAは~XSLTも~supportするとする）、代わりに~XML処理器は， `script$e 要素を形式変換-の一部を形成する不透明な要素として扱うことになる。 ◎ A conforming Web browser would, upon finding a script element in an XML document, execute the script contained in that element. However, if the element is found within a transformation expressed in XSLT (assuming the user agent also supports XSLT), then the processor would instead treat the script element as an opaque element that forms part of the transform.

`~HTML構文$における~scriptingを~supportする~web~browserは、`~HTML~MIME型$に~~識別される文書を この仕様にて述べるように処理して，利用者が文書と対話できるようにし~MUST。 ◎ Web browsers that support the HTML syntax must process documents labeled with an HTML MIME type as described in this specification, so that users can interact with them.

~scriptingを~supportする~UAは、この仕様における~IDL片に対しても， `WEBIDL$r 仕様に述べられる適合~実装で~MUST。 ◎ User agents that support scripting must also be conforming implementations of the IDL fragments in this specification, as described in the Web IDL specification. [WEBIDL]

注記： 明示的に言明されない限り、~HTML要素の意味論を上書きする仕様であっても，その要素を表現している~DOM~objに課されている要件は上書きしないとする。 例えば，上の例の `script$e 要素は、依然として， `HTMLScriptElement$I ~interfaceを実装することになる。 ◎ Unless explicitly stated, specifications that override the semantics of HTML elements do not override the requirements on DOM objects representing those elements. For example, the script element in the example above would still implement the HTMLScriptElement interface.

対話的でない呈示のみの~UA ◎ Non-interactive presentation user agents

純粋に， ~HTML／~XML 文書の対話的でない~versionを具現化するために処理する~UAは、利用者~対話に関する要件については免除されることを除き，~Web~browserと同じ適合性~判定基準に準拠し~MUST。 ◎ User agents that process HTML and XML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.

注記： 対話的でない呈示~UAの代表的な例として、印刷機（静的~UA）や頭上display（動的~UA）が挙げられる。 静的であって対話的でない呈示~UAのほとんどは、 ~scripting~supportも欠く ことが予期される。 ◎ Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support.

対話的でないが，動的な呈示~UAは、依然として［ ~scriptを実行する, ~formを動的に提出する, 等々 ］を許容する。 しかしながら、利用者が文書と対話できない下では， “~focus” の概念は無関係なので、~UAは，~focusに関係するどの~DOM~APIも~supportする必要はないことになる。 ◎ A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.

示唆される既定の具現化を~supportする視覚的~UA ◎ Visual user agents that support the suggested default rendering

対話的かどうかにかかわらず、~UAは、この仕様に定義され, 示唆される（ `suggested^en ），既定の具現化（ `rendering^en ）を~supportするものとして指名され得る（場合によっては 利用者の任意選択として）。 ◎ User agents, whether interactive or not, may be designated (possibly as a user option) as supporting the suggested default rendering defined by this specification.

このことは要求されてはいない。 特に，~UAには、示唆される既定の具現化を実装するとしても，利用者~体験を改善するためとして，既定の具現化を上書きするような設定群を提供することが奨励される。 例えば、色の~contrastを変更する, ~focusに異なる~styleを利用する, その他、利用者がより~access可能, かつ利用-可能にするものなど。 ◎ This is not required. In particular, even user agents that do implement the suggested default rendering are encouraged to offer settings that override this default to improve the experience for the user, e.g. changing the color contrast, using different focus styles, or otherwise making the experience more accessible and usable to the user.

示唆される既定の具現化を~supportするものと指名された~UAは、そう指名されている間は， 具現化~節 にて［ ~UAに実装することが期待される（ `expected^en ）挙動 ］として定義されている規則を実装し~MUST。 ◎ User agents that are designated as supporting the suggested default rendering must, while so designated, implement the rules the rendering section defines as the behavior that user agents are expected to implement.

~scriptingを~supportしない~UA ◎ User agents with no scripting support

~scriptingを~supportしない（または，まるごと不能化されている）実装は、この仕様に言及される［ ~event＆~DOM~interface ］を~supportすることは，免除される。 そのような~UAは、この仕様の~event~modelや~DOMの用語で定義される各部分に対しては、依然として ~event＆~DOMを~supportしていたかのように動作し~MUST。 ◎ Implementations that do not support scripting (or which have their scripting features disabled entirely) are exempt from supporting the events and DOM interfaces mentioned in this specification. For the parts of this specification that are defined in terms of an events model or in terms of the DOM, such user agents must still act as if events and the DOM were supported.

注記： ~scriptingが、~appの不可欠な部分を形成することもある。 ~scriptingを~supportしない（または不能化されている）~web~browserは、作者の意図を全部的に伝達できないかもしれない。 ◎ Scripting can form an integral part of an application. Web browsers that do not support scripting, or that have scripting disabled, might be unable to fully convey the author's intent.

適合性~検査器 ◎ Conformance checkers

適合性~検査器は、この仕様にて述べる適合性~判定基準のうち 適用-可能なものについて，文書が適合するかどうかを検証yし~MUST。 自動化された適合性~検査器には、作者の意図の解釈を要求するような~errorを検出することは免除される（例えば、［ 内容が引用でない `blockquote$e 要素 ］を含むような文書は，適合しないが、人による判定の下で走らせてない適合性~検査器には， `blockquote$e 要素が引用された素材のみを包含していることを検査する必要はない）。 ◎ Conformance checkers must verify that a document conforms to the applicable conformance criteria described in this specification. Automated conformance checkers are exempt from detecting errors that require interpretation of the author's intent (for example, while a document is non-conforming if the content of a blockquote element is not a quote, conformance checkers running without the input of human judgement do not have to check that blockquote elements only contain quoted material).

適合性~検査器は、入力~文書に対し：

• `属する閲覧文脈$がない下で（~scriptを走らせてない, かつ 構文解析器の`~scripting~flag$は不能化されていることを意味する）構文解析して、適合するかどうかを検査し~MUST。
• また，`属する閲覧文脈$がある下で構文解析して、適合するかどうかを — その中で~scriptを実行して，~scriptが適合しない状態を（~script実行の間に一時的にそうなるときを除いて）決して生じさせないかどうかを — 検査するべきである（この要件は “~SHOULD” までに限られ， “~MUST” ではない — それは不可能なことが証明されているので `COMPUTABLE$r ）

◎ Conformance checkers must check that the input document conforms when parsed without a browsing context (meaning that no scripts are run, and that the parser's scripting flag is disabled), and should also check that the input document conforms when parsed with a browsing context in which scripts execute, and that the scripts never cause non-conforming states to occur other than transiently during script execution itself. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible. [COMPUTABLE])

この仕様による要件のうち，適用-可能なものに適合するような適合性~検査器は、 “~HTML検証器” とも称される。 ◎ The term "HTML validator" can be used to refer to a conformance checker that itself conforms to the applicable requirements of this specification.

注記： ~XML~DTDは、この仕様の適合性~要件すべてを表すことはできない。 したがって、~XML処理器と~DTDだけでは，適合性~検査器として~~不足になる。 また、この仕様にて定義される 二つの著作~形式 のいずれも，~SGMLの応用ではないので、それらを検証する~SGML~systemも，適合性~検査器としては~~不足になる。 ◎ XML DTDs cannot express all the conformance requirements of this specification. Therefore, a validating XML processor and a DTD cannot constitute a conformance checker. Also, since neither of the two authoring formats defined in this specification are applications of SGML, a validating SGML system cannot constitute a conformance checker either.

別の仕方で記すなら、適合性~判定基準には次の三種がある： ◎ To put it another way, there are three types of conformance criteria:

1. ~DTDで表せるもの。 ◎ Criteria that can be expressed in a DTD.
2. ~DTDでは表せないが、機械的に検査できるもの。 ◎ Criteria that cannot be expressed by a DTD, but can still be checked by a machine.
3. 人によってのみ検査できるもの。 ◎ Criteria that can only be checked by a human.

適合性~検査器は、最初の二項目に対しては検査し~MUST。 ~DTDのみに基づく単純な検証器は、最初の類別の~errorしか検査しないので、この仕様に則る適合性~検査器には適合しない。 ◎ A conformance checker must check for the first two. A simple DTD-based validator only checks for the first class of errors and is therefore not a conforming conformance checker according to this specification.

~data-mining~tool ◎ Data mining tools

［ 文書を具現化する, 適合性を検査する ］以外の理由で［ ~HTML／~XML ］文書を処理する~appや~toolは、自身が処理する文書の意味論に則って動作するべきである。 ◎ Applications and tools that process HTML and XML documents for reasons other than to either render the documents or check them for conformance should act in accordance with the semantics of the documents that they process.

`文書の~outline$を生成する~toolであって、入子~levelを 各~段落に対しては増やしつつ，各~節に対しては増やさないものは、適合しない。 ◎ A tool that generates document outlines but increases the nesting level for each paragraph and does not increase the nesting level for each section would not be conforming.

著作~tool／~markup生成器 ◎ Authoring tools and markup generators

著作~tool／~markup生成器 は、`適合~文書$を生成し~MUST。 作者に適用される適合性~判定基準は、適切になる所では，著作~toolにも適用される。 ◎ Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate.

著作~toolには、~tool自身が作者の意図を決定できない範囲tに限り，［ 要素をそれに指定された目的に限って利用するとする，厳格な要件 ］からは免除される。 しかしながら，著作~toolは、要素を自動的に誤用したり，利用者にそうするよう奨励しては~MUST_NOT。 ◎ Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, but only to the extent that authoring tools are not yet able to determine author intent. However, authoring tools must not automatically misuse elements or encourage their users to do so.

例えば、 `address$e 要素を任意の連絡先~情報に利用することは適合でない — その要素は、最も近い先祖の［ `article$e ／ `body$e ］要素~用の連絡先~情報を~markupするために限り，利用できるので。 しかしながら、著作~toolは，およそ その相違は決定できないであろうから、その要件は免除される。 そうであっても，これは、著作~toolが［ （例えば）~italic体の~textのどの~blockにも `address$e 要素を利用できる ］ことを意味するわけではない — それは単に、著作~toolが，［ 利用者が~toolを利用して `article$e 要素~用の連絡先~情報を挿入するときに、利用者が本当にそれを行っていて，何か別のものを挿入していない ］ことを検証yする必要はないことを意味する。 ◎ For example, it is not conforming to use an address element for arbitrary contact information; that element can only be used for marking up contact information for its nearest article or body element ancestor. However, since an authoring tool is likely unable to determine the difference, an authoring tool is exempt from that requirement. This does not mean, though, that authoring tools can use address elements for any block of italics text (for instance); it just means that the authoring tool doesn't have to verify that when the user uses a tool for inserting contact information for an article element, that the user really is doing that and not inserting something else instead.

注記： 適合性を検査するにあたっては、~editorは，［ 適合性~検査器が検証yするのと同じ範囲tまでにおいて，適合する ］ような文書を出力する必要がある。 ◎ In terms of conformance checking, an editor has to output documents that conform to the same extent that a conformance checker will verify.

著作~toolが適合しない文書を編集するために利用されるときは、編集~sessionの間に，文書~内の未~編集-部分における適合性~errorを保全しても~MAY（すなわち、編集~toolには、~error含みの内容を往来することは許容される）。 しかしながら，著作~toolは、そのように~errorが保全された出力を，適合するものと主張しては~MUST_NOT。 ◎ When an authoring tool is used to edit a non-conforming document, it may preserve the conformance errors in sections of the document that were not edited during the editing session (i.e. an editing tool is allowed to round-trip erroneous content). However, an authoring tool must not claim that the output is conformant if errors have been so preserved.

著作~toolは、次の二つに大別されることが予期される： ◎ Authoring tools are expected to come in two broad varieties:＼

• 構造~上のまたは意味論上の~dataに対し働くもの。 ◎ tools that work from structure or semantic data, and＼
• 媒体~特有な~WYSIWYG（ `What-You-See-Is-What-You-Get^en ）編集に基づいて働くもの。 ◎ tools that work on a What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG).

前者は、~HTMLを著作する~toolに選好される仕組みである — 最も適切な~HTML要素／属性を選ぶ際の判断材料に，~source情報~内の構造を利用できるので。 ◎ The former is the preferred mechanism for tools that author HTML, since the structure in the source information can be used to make informed choices regarding which HTML elements and attributes are most appropriate.

しかしながら，~WYSIWYG~toolは `legitimate^en である 【？】 。 ~WYSIWYG~toolは、適切であると知る要素のみを利用するべきであり，そうでない要素は利用するべきでない。 これは、ある種の極端な事例では，~flow要素の利用を［ `div$e, `b$e, `i$e, `span$e ］の様な，ごく少数のものに制限した上で， `style$a 属性を最大限に活用することを意味するかもしれない。 ◎ However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are appropriate, and should not use elements that they do not know to be appropriate. This might in certain extreme cases mean limiting the use of flow elements to just a few elements, like div, b, i, and span and making liberal use of the style attribute.

~WYSIWYGかどうかにかかわらず，すべての著作~toolは、利用者が［ きちんと構造~化され, 意味論的に多彩な，媒体依存の内容 ］を作成できるようにすべく，でき得る限り努めるべきである。 ◎ All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling users to create well-structured, semantically rich, media-independent content.

~FINGERPRINTING ~UAは、さもなければ拘束されない入力に，実装~特有な制限-を課して~MAY。 例えば［ ~DOS攻撃を防止する ／ ~memoryの枯渇に抗して防護する ／ ~platform特有な制限に対処する ］など。 ◎ User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

［ 既存の内容や, 先立つ仕様 ］との互換性をとるため、この仕様は，次の二つの著作~形式を述べる： ◎ For compatibility with existing content and prior specifications, this specification describes two authoring formats:＼

• `~XML構文$に基づくもの。 ◎ one based on XML, and＼
• ~SGMLに~~由来する`~custom形式$を利用するもの（`~HTML構文$とも称される）。 ◎ one using a custom format inspired by SGML (referred to as the HTML syntax).＼

実装は、これら二つの形式のうち，少なくとも一方は~supportし~MUST — 両者とも~supportすることが奨励されるが。 ◎ Implementations must support at least one of these two formats, although supporting both is encouraged.

適合性~要件のうち一部は、［ 要素 ／ 属性 ／ ~method ／ ~obj ］に課される要件として句される。 そのような要件は、次の二つに~~分類される： ◎ Some conformance requirements are phrased as requirements on elements, attributes, methods or objects. Such requirements fall into two categories: those describing content model restrictions, and those describing implementation behavior.＼

• 内容~modelに対する制約について述べるもの。 これは、［ 文書／著作~tool ］に課される要件になる。 ◎ Those in the former category are requirements on documents and authoring tools.＼
• 実装の挙動について述べるもの。 これは、~UAに課される要件になる。 ◎ Those in the second category are requirements on user agents.＼

同様に，適合性~要件のうち一部は、作者に課される要件として句される。 そのような要件は、作者が生産する文書に課される適合性~要件として解釈されることになる（言い換えれば、この仕様は，作者に課される適合性~判定基準と, 文書に課されるそれとを区別しない）。 ◎ Similarly, some conformance requirements are phrased as requirements on authors; such requirements are to be interpreted as conformance requirements on the documents that authors produce. (In other words, this specification does not distinguish between conformance criteria on authors and conformance criteria on documents.)

2.1.9. 依存関係

【 この節の和訳は 別ページにて 】

2.1.10. 拡張性

この仕様に対する~vendor特有な~proprietaryな~UA拡張は、強く忌避される。 文書は、そのような拡張を利用しては~MUST_NOT。 そのような行為は、当の内容への~accessが特定の~UAの利用者に限られてしまい，相互運用性の悪化と利用者~層の細分化を招くことになるので。 ◎ Vendor-specific proprietary user agent extensions to this specification are strongly discouraged. Documents must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question.

すべての拡張は、その利用が，この仕様にて定義される機能性に矛盾したり適合しなくなるように定義されては~MUST_NOT。 ◎ All extensions must be defined so that the use of extensions neither contradicts nor causes the non-conformance of functionality defined in the specification.

例えば，そうすることは強く忌避されてはいるが、実装は，ある~controlに［ 利用者が その~controlの現在の値を選択するときにかかった時間 ］を返すような，新たな~IDL属性 `typeTime^m を追加することもできる。 一方で、~formの `elements$m 配列に出現するような，新たな~controlを定義することは、上の要件に対する違反になる — それは、この仕様が与える `elements$m の定義に違反するので。 ◎ For example, while strongly discouraged from doing so, an implementation could add a new IDL attribute "typeTime" to a control that returned the time it took the user to select the current value of a control (say). On the other hand, defining a new control that appears in a form's elements array would be in violation of the above requirement, as it would violate the definition of elements given in this specification.

この仕様に対し ~vendorに中立的な拡張が必要されるときは、それに則って，この仕様が更新されるか，この仕様の要件を上書きするような拡張~仕様が記され得る。 自身の活動にこの仕様を適用している誰かが、そのような拡張~仕様の要件を認めるものと決めたとき、それは，この仕様に対する適合性~要件の目的において `適用-可能な仕様@ になる。 ◎ When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When someone applying this specification to their activities decides that they will recognize the requirements of such an extension specification, it becomes an applicable specification for the purposes of conformance requirements in this specification.

注記： 誰かが，［ 任意の~byte~streamは適合である ］と定義するような仕様を書いた上で，そのような無作為な~junkを適合であると主張することもできる。 しかしながらそれは、その無作為な~junkが皆の目的に適合であることを実際に意味するものではない。 他の誰かが，その仕様を自身の仕事に適用しないものと決めたなら、その誰かは，全く正当に［ 前述の~junkは，単に~junkであり全く適合でない ］と言える。 特定0の~communityにおいて何が問題0とされるかは，その~communityが何に同意するかであり、適合性が適用-可能なのは，その限りにおいてである。 ◎ Someone could write a specification that defines any arbitrary byte stream as conforming, and then claim that their random junk is conforming. However, that does not mean that their random junk actually is conforming for everyone's purposes: if someone else decides that that specification does not apply to their work, then they can quite legitimately say that the aforementioned random junk is just that, junk, and not conforming at all. As far as conformance goes, what matters in a particular community is what that community agrees is applicable.

~UAは、自身が解さない要素や属性を，次のように意味論的に中立的であるものと扱わ~MUST： ◎ User agents must treat elements and attributes that they do not understand as semantically neutral;＼

• ~DOM処理器においては、それらを~DOM内に残すこと。 ◎ leaving them in the DOM (for DOM processors), and＼
• ~CSS処理器においては、~CSSに則ってそれらに~styleをあてがうこと。 ◎ styling them according to CSS (for CSS processors), but＼
• それらから いかなる意味も推定しないこと。 ◎ not inferring any meaning from them.

~UAは、特色機能の~supportを不能化するときは（例： 保安~問題を軽減するための緊急の措置として ／ 開発を援助するため ／ 処理能~上の理由から），［ その特色機能をまったく~supportしていなかった ／ その特色機能は，この仕様に言及されていなかった ］かのように動作し~MUST。 例えば、特定0の特色機能が ~Web~IDL~interface内の属性を介して~accessされる場合、属性~自身は，その~interfaceを実装する~objから外されることになる — ~obj上にその属性を残した上で，~NULL を返したり, 例外を投出させるのでは、不十分である。 ◎ When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient.

2.1.11. ~XPath＆~XSLT との相互作用

この仕様に述べる方式で［ 構文解析される／作成される `~HTML文書$ ］上で演算する XPath 1.0 実装（例： `document.evaluate()^c ~APIの一部で）は、 XPath 1.0 仕様に，次の編集-が適用されたかのように動作し~MUST： ◎ Implementations of XPath 1.0 that operate on HTML documents parsed or created in the manners described in this specification (e.g. as part of the document.evaluate() API) must act as if the following edit was applied to the XPath 1.0 specification.

先ず，次の段落を除去した上で： ◎ First, remove this paragraph:

A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.

その場所に次を挿入する： ◎ Then, insert in its place the following:

A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. If the QName has a prefix, then there must be a namespace declaration for this prefix in the expression context, and the corresponding namespace URI is the one that is associated with this prefix. It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.

If the QName has no prefix and the principal node type of the axis is element, then the default element namespace is used. Otherwise if the QName has no prefix, the namespace URI is null. The default element namespace is a member of the context for the XPath expression. The value of the default element namespace when executing an XPath expression through the DOM3 XPath API is determined in the following way:

1. If the context node is from an HTML DOM, the default element namespace is "http://www.w3.org/1999/xhtml".
2. Otherwise, the default element namespace URI is null.

注記： この変更は、上述の最初の 2 項目を動機とする， `XPATH10$r 仕様に対する`故意的な違反$である。 ◎ This change is a willful violation of the XPath 1.0 specification, motivated by desire to have implementations be compatible with legacy content while still supporting the changes that this specification introduces to HTML regarding which namespace is used for HTML elements. [XPATH10]

~XSLT 1.0 処理器が，（ 明示的に, または XSLT 1.0 の規則による既定~法を介して）出力~method `html^l の下で~DOMを出力するときは、次のように影響される： ◎ XSLT 1.0 processors outputting to a DOM when the output method is "html" (either explicitly or via the defaulting rule in XSLT 1.0) are affected as follows:

形式変換~programが 名前空間に属さない要素を出力する場合、処理器は，対応する~DOM要素~nodeを構築するに先立って，次を行わ~MUST： ◎ If the transformation program outputs an element in no namespace, the processor must, prior to constructing the corresponding DOM element node,＼

• 要素の名前空間を`~HTML名前空間$に変更する ◎ change the namespace of the element to the HTML namespace,＼
• 要素の局所~名を`~ASCII小文字~化する$ ◎ ASCII-lowercase the element's local name, and＼
• 要素~上のどの属性 %A に対しても、 %A が名前空間に属さないならば， %A の名前を`~ASCII小文字~化する$。 ◎ ASCII-lowercase the names of any non-namespaced attributes on the element.

注記： この要件は、 `XSLT10$r に対する`故意的な違反$である — これが要求されるのは、そうしなければ，この仕様による~HTMLの名前空間と文字大小区別の有無に関する変更が，~DOMに基づく~XSLT形式変換と非互換になるためである。 （出力を直列化する処理器は影響されない。） ◎ This requirement is a willful violation of the XSLT 1.0 specification, required because this specification changes the namespaces and case-sensitivity rules of HTML in a manner that would otherwise be incompatible with DOM-based XSLT transformations. (Processors that serialize the output are unaffected.) [XSLT10]

この仕様は、~XSLT処理と`~HTML構文解析器$ 基盤とがどう相互作用するかについては、精確に指定しない（例えば、~XSLT処理器は，要素を`~open要素~stack$の中へ置いたかのように動作するのかどうか）。 しかしながら，~XSLT処理器は： ◎ This specification does not specify precisely how XSLT processing interacts with the HTML parser infrastructure (for example, whether an XSLT processor acts as if it puts any elements into a stack of open elements). However, XSLT processors＼

• 成功裡に完了したときには、`構文解析を停止-$し~MUST。 ◎ must stop parsing if they successfully complete, and＼
• 加えて，`文書の現在の準備度$は、先ず `interactive^l に設定した上で，中止された場合は `complete^l に設定し~MUST。 ◎ must set the current document readiness first to "interactive" and then to "complete" if they are aborted.

この仕様は、次については指定しない： ◎ This specification does not specify＼

• ~XSLTと`~navi$~algoとが，どう相互作用するか。 ◎ how XSLT interacts with the navigation algorithm,＼
• ~XSLTが`~event-loop$内にどう収まるか。 ◎ how it fits in with the event loop, nor＼
• ~error頁がどう取扱われることになるか（例：~XSLT~errorは，~XSLTによる増分的~出力を置換するのか, ~inlineに具現化されるのか, 等々）。 ◎ how error pages are to be handled (e.g. whether XSLT errors are to replace an incremental XSLT output, or are rendered inline, etc).

注記： ~HTMLとの相互作用に関する，追加の規範的でない~commentもある： ◎ There are also additional non-normative comments regarding＼

• ~XSLTに対するそれは ~script要素~節 にある。 ◎ the interaction of XSLT and HTML in the script element section, and＼
• ［ ~XSLT, ~XPath, ~HTML ］に対するそれは ~template要素~節 にある。 ◎ of XSLT, XPath, and HTML in the template element section.