HTML — 共通基盤

2.1.1. 並列処理

所与の手続きを `並列的@ （ `parallel^en ）に走らすとは、 その手続きを，この標準~内の他の~logicと~~同時並行的に走らすことを意味する （例： `~event~loop$と~~同時並行的に）。 この標準は、 これが達成される精確な仕組みは定義しない — 例えば、 時間を協力的に共有する［ `multitasking, fibers, threads, processes^en ］, あるいは異なる［ `hyperthread, core, CPU, machine^en ］の利用, 等々。 対照的に， `即時@ （ `immediate^en ）に走らす演算は、 現在~走っている~taskを中断して, 当の演算を走らせ終えてから, 中断した~taskを再開するモノトスル。 ◎ 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.

注記： 並列処理を活用して仕様を書く指導については、 `§ 他の仕様における~event~loopの~~扱い方＠~WAPI#event-loop-for-spec-authors$を見よ。 ◎ For guidance on writing specifications that leverage parallelism, see Dealing with the event loop from other specifications.

`並列的$に走る複数の~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にて並列的に走らすことも有用になり得る。 ◎ 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は、 利用している圧縮~形式が~supportされないならば — 実装が その~metadataから動画の寸法を決定できたとしても — ~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 ）と称されるもの 【`参照先＠~HTTPinfra#representation$】 は、 この仕様においては， `資源@ と称される。 `HTTP$r ◎ What some specifications, in particular the HTTP specifications, 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.

`~CSS~stylesheet$用に必須な下位資源は、 とりあえずここでは， `@import^css 規則を介して取込まれる他の~stylesheetたち — それらの~stylesheetが取込む間接的なものも含む — として定義される。 ◎ For CSS style sheets, we tentatively define here that their critical subresources are other style sheets imported via @import rules, including those indirectly imported by other imported style sheets.

この定義は、 全部的に相互運用可能ではない。 さらに，一部の~UAは、 背景~画像や~web~fontの様な資源も必須な下位資源に数えるよう見受けられる。 理想的には， `~CSS~WG^cite がこれを定義することになろう — それについての進捗は、 `w3c/csswg-drafts 課題 #1088＠~CSSissue/1088$ を見よ。 ◎ This definition is not fully interoperable; furthermore, some user agents seem to count resources like background images or web fonts as critical subresources. Ideally, the CSS Working Group would define this; see w3c/csswg-drafts issue #1088 to track progress on that front.

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, user agents 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.

他が言明されない限り、 この仕様に言及される ⇒＃ どの要素も，`~HTML名前空間$に属する。 どの属性も，属する名前空間は無い。 ◎ Except where otherwise stated, all elements defined or mentioned in this specification are in the HTML namespace ("http://www.w3.org/1999/xhtml"), and all attributes defined or mentioned in this specification have no namespace.

用語 `要素~型@ は、 要素のうち［ 所与の局所~名を有する ］かつ［ 所与の名前空間に属する ］ものからなる集合を指すために利用される。 例えば， `button$e 要素の要素~型は `button$e であり、 次を意味する ⇒ ［ その局所~名 ~EQ `button^l ］~AND［ `~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 生成規則に合致する ］~AND［ `003A^U `COLON^cn (:) は包含しない ］ ◎ 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~tree

要素または属性 が［ `無視される@ ／ 何か他の値として扱われる ／ それが他の何かであったかのように取扱われる ］ものと言明される所は、［ 当の~nodeが~DOM内にある後における~nodeの処理 ］のみを指す。 ~UAは、 そのような状況においては~DOMを変異させないモノトスル。 ◎ 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.

内容~属性が所与の値 %値 に `変更される／変化した^dfn と記されるのは、 %値 が~~元の値と異なる場合に限られる — 属性に~~元の値と同じ値が設定されても，それは変化しない。 ◎ 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^cn や`制御~文字$も包含しない）。 ◎ 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).

~HTML要素には、 `局所~名$elごとに，特定の［ `~HTML要素~挿入-時の手続き@ ／ `~HTML要素~除去-時の手続き@ ］が定義され得る。 ◎ An HTML element can have specific HTML element insertion steps defined for the element's local name. Similarly, an HTML element can have specific HTML element removing steps defined for the element's local name.

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

• %N が `文書の中へ挿入された@ とは、 次が生じたことをいう ⇒ `文書~tree内$に無かった %N が、 `挿入-時の手続き$が引数 %N を伴って呼出された結果，`文書~tree内$に在るようになった。 ◎ 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 が `文書から除去された@ とは、 逆に，次が生じたことをいう ⇒ `文書~tree内$に在った %N が、 `除去-時の手続き$が 1 個目の引数 %N を伴って呼出された結果，`文書~tree内$に無いようになった。 ◎ 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 が、 `除去-時の手続き$が 1 個目の引数 %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 ~NULL ］ ◎ A node is browsing-context connected when it is connected and its shadow-including root's browsing context is non-null.＼

• %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 が、［ `除去-時の手続き$が 1 個目の引数 %N を伴って呼出された ］か, または［ %N の`~shadowも含めた根$が`属する閲覧~文脈$ ~EQ ~NULL になった ］結果，`閲覧~文脈に接続されて$いないようになった。 ◎ 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's browsing context becomes null.

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も含まれる。 】

~IDL属性に対し，（例えば，作者~scriptから）［ その値を得る／ それに新たな値をアテガう ］ときの挙動を記すときは、［ 取得子（ `getter^en ）は… ／ 設定子（ `setter^en ）は… ］のように表記される。 ◎ An IDL attribute is said to be getting when its value is being retrieved (e.g. by author script), and is said to be setting when a new value is assigned to it.

`~liveである@ とされた~DOM~objに対しては、 その~obj上の［ 属性, ~method ］は、 ~dataの~snapshotではなく，実際の 【すなわち，現在の】 下層の~dataに対し演算するモノトスル。 ◎ 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が利用する`実装定義$な内容~handlerのうち，次に該当するものを指す ⇒ ~UAによる`文書$の具現化の一部を成し得るが、［ `文書$の`子~navigable$として動作する ］ことも［ `文書$の~DOMに `Node$I ~objを導入する ］こともない。 ◎ The term plugin refers to an implementation-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 navigables 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$は常に無い ］と見なすモノトスル。 ◎ A user agent must not consider the types text/plain and application/octet-stream as having a registered plugin.

~pluginの一例として、［ 利用者が~PDF~fileへ~navigateしたとき， `~navigable$内で~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 navigable 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には、 ~pluginを~~選択的に組み込む仕組み — Netscape Plugin ~API `NPAPI$r など — を~supportするものもあれば，［ ~remote内容~変換器を利用するもの／ 一定の内容~型に対しては組込みの~pluginで~supportするもの ］もある。 ~~実際、 この仕様では，~UAによる~pluginの~supportは まったく要求されない。 ◎ 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]

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

◎追跡路 利用者が有する`~plugin$の集合は利用者ごとに異なり， 利用者が一意に識別される機会cを増やすような追跡~行路を供するので、 ~UAには，［ どの利用者に対しても，正確に同じ`~plugin$の集合を~supportする ］ことが奨励される。 ◎ (This is a tracking vector.) Since different users having different sets of plugins provides a tracking 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. 文字~符号化法

`文字~符号化法@ （`参照先＠~ENCODING#encoding$）は、 ~byte~streamと~Unicode文字列との間で相互に変換する仕方であり， `Encoding^cite `ENCODING$r にて定義される。 多義的にならない所では、 単に “符号化法” とも称される。 各 `符号化法$には、［ `符号化法~名@ （`参照先＠~ENCODING#name$） と 1 個以上の `符号化法~label@ （`参照先＠~ENCODING#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 Encoding. 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]

2.1.8. 各種 適合性の類別

この仕様は、 次の 2 つに対する適合性~判定基準を述べる： ◎ 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は、 下に説明されるとおり，追加的な規則の~subjectになる。） ◎ 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 要素を利用してはナラナイ” と言明されている場合、 それは，［ 文書が名前 `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.

~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は、 ~XML文書~内に見出された［ 要素, 属性 ］のうち，`~HTML名前空間$に属するものを — 他の仕様により，それらの要素の意味論が上書きされていない限り — この仕様に述べるとおりに処理して，利用者がそれらとヤリトリできるようにするモノトスル。 ◎ 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型$に~~識別される文書を この仕様に述べるとおりに処理して，利用者が文書とヤリトリできるようにするモノトスル。 ◎ 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片に対しても， `~Web~IDL^cite `WEBIDL$r に述べられるとおりに適合~実装になるモノトスル。 ◎ User agents that support scripting must also be conforming implementations of the IDL fragments in this specification, as described in Web IDL. [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と同じ適合性~判定基準に準拠するモノトスル。 ◎ 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】の代表的な例として、 印刷機（静的~UA）や頭上display（動的~UA）が挙げられる。 静的であって対話的でない呈示~UAのほとんどは、 `~scripting~supportも欠く＠#non-scripted$ことが予期される。 ◎ 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は、 そう指名されている間は， `§ 具現化＠~HTMLrendering#rendering$にて［ ~UAに実装することが`期待される^em（ `expected^en ）挙動 ］として定義される規則を実装するモノトスル。 ◎ 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していたかのように動作するモノトスル。 ◎ 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するモノトスル。 自動化された適合性~検査器には、 作者の意図の解釈を要求するよう~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$は `不能化^i にすることを意味する） 構文解析して、 適合するかどうかを検査するモノトスル。
• また， `属する閲覧~文脈$が在る下で構文解析して、 適合するかどうかを — その中で~scriptを実行して，~scriptが適合しない状態を （~script実行の間に一時的にそうなるときを除いて） 決して生じさせないかどうかを — 検査するベキである （この要件は “するベキ” までに限られ， “するモノトスル” ではない — それは不可能なことが証明されているので `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だけでは，適合性~検査器を成し得ない。 また、 この仕様にて定義される `2 つの著作~形式＠#_authoring-formats$は，どちらも~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.

別の仕方で記すなら、 適合性~判定基準には，次の 3 種がある： ◎ 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.

適合性~検査器は、 最初の 2 項目に対しては検査するモノトスル。 ~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^en ）~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のうち，［ 入子ng~levelを 各~段落に対しては増やしつつ，各~見出しに対しては増やさないもの ］は、 適合しない。 ◎ A tool that generates document outlines but increases the nesting level for each paragraph and does not increase the nesting level for headings would not be conforming.

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

［ 著作~tool／~markup生成器 ］は、 `適合~文書$を生成しなければナラナイ。 作者に適用される適合性~判定基準は、 適切になる所では，著作~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は、 要素を自動的に誤用したり，利用者にそうするよう奨励してはナラナイ。 ◎ 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を保全してもヨイ （すなわち、 編集~toolには，~error含みの内容を往復することは許容される）。 しかしながら，著作~toolは、 そのように~errorが保全された出力を，適合するものと主張してはナラナイ。 ◎ 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は、 次の 2 つに大別されるものと予期される： ◎ 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が正当でないわけではない。 ~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.

［ 既存の内容／先立つ仕様 ］との互換性を得るため、 この仕様は，次に挙げる 2 つの著作~形式を述べる： ◎ 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).＼

実装は、 これら 2 つの形式のうち，どちらかは~supportするモノトスル — 両方とも~supportすることが奨励されるが。 ◎ Implementations must support at least one of these two formats, although supporting both is encouraged.

適合性~要件のうち一部は、［ 要素 ／ 属性 ／ ~method ／ ~obj ］に課される要件として句される。 そのような要件は、 次の 2 つに~~分類される： ◎ 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. 依存関係

【 この節の内容は、 `別~pageにて＠~HTMLdep#dependencies$ 】

2.1.10. 拡張能

この仕様に対する~vendorに特有な~proprietaryな~UA拡張は、 強く忌避される。 文書は、 そのような拡張を利用してはナラナイ。 そのような行為は、 当の内容への~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.

すべての拡張は、 その利用が，この仕様にて定義される機能性に［ 矛盾する／適合しなくなる ］ように定義されてはナラナイ。 ◎ 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は適合である ］と定義するような仕様を書いた上で，そのような~randomな~junkを適合であると主張することもできる。 しかしながらそれは、 その~randomな~junkが皆の目的に適合であることを実際に意味するものではない。 他の誰かが，その仕様を自身の作業に適用しないものと裁定したなら、 その誰かは，まったく正当に［ 前述の~junkは，単に~junkであり まったく適合でない ］と言える。 特定0の~communityにおいて何が問題mとされるかは，その~communityが何に`合意するか^emであり、 適合性が適用-可能なのは，その限りにおいてである。 ◎ 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は、 自身が解さない［ 要素／属性 ］を， 次のように意味論的に中立的なものとして扱うモノトスル： ◎ 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を不能化するときは （例： ~security問題を軽減するための緊急~措置として／ 開発を援助するため／ 処理能の理由から），［ 当の特能を何ら~supportしていなかった ］かつ［ 当の特能は，この仕様に言及されていなかった ］かのように動作するモノトスル。 例えば， 特定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 仕様に，次の編集-が適用されたかのように動作するモノトスル： ◎ 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.

注記： この変更は、 `XPATH10$r 仕様に対する`故意的な違反$であり， 上に挙げた動機のうち最初の 2 項目が その動機にある。 ◎ 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を構築するに先立って — 次を行わなければナラナイ： ◎ 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 stop parsing if they successfully complete,＼

• 加えて、 次を行う：

  1. `文書の現在の準備度を更新する$( %文書, `interactive^l )
  2. 中止された場合、 次も行う ⇒ `文書の現在の準備度を更新する$( %文書, `complete^l )
  ◎ and must update 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~pageがどう取扱われることになるか （例：~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^e 要素 にある。 ◎ the interaction of XSLT and HTML in the script element section, and＼
• ［ ~XSLT, ~XPath, ~HTML ］に対するそれは、 § `template^e 要素 にある。 ◎ of XSLT, XPath, and HTML in the template element section.