2. 共通基盤

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

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

2.1. 各種用語

この仕様は、同じ文脈~内で[ ~HTML/~XML ]属性, および~IDL属性( ~IDL~interfaceに定義される属性)の両者を指すことが多い。 どちらを指すか明瞭でない所では、[ ~HTML/~XML ]属性を指すときは `内容~属性@ と記され、~IDL属性を指すときは `~IDL属性@ と記される。 同様に、用語 “~prop” も[ ~JS~obj~prop, ~CSS~prop ]の両者に利用される。 多義的になる所では、順に `~obj~prop^dfn, `~CSS~prop^dfn と記される。 ◎ This specification refers to both HTML and XML attributes and IDL attributes, often in the same context. When it is not clear which is being referred to, they are referred to as content attributes for HTML and XML attributes, and IDL attributes for those defined on IDL interfaces. Similarly, the term "properties" is used for both JavaScript object properties and CSS properties. When these are ambiguous they are qualified as object properties and CSS properties respectively.

一般に、仕様にて,ある特色機能を[ `~HTML構文$, `~XML構文$ ]のいずれかに適用するよう定められる所では、他方も含まれる。 特色機能を,この二つの言語の片方にのみ特に適用する所では、次のように,他方の形式には適用されないものと定められる ⇒ “~HTML に対しては、 ... (これは~XMLには適用されない)”。 ◎ Generally, when the specification states that a feature applies to the HTML syntax or the XML syntax, it also includes the other. When a feature specifically only applies to one of the two languages, it is called out by explicitly stating that it does not apply to the other format, as in "for HTML, ... (this does not apply to XML)".

この仕様における用語 文書 は、~HTMLの~~任意の利用を指す — 短い静的な文書から 多彩な~multimediaを伴う長い小論や報告書,更には本格的な対話的~appまでににわたるような。 この用語は、文脈に依存して[ `Document$I ~objとその 子孫~DOM木, ], [ `~HTML構文$ / `~XML構文$ を利用して直列化された~byte~stream ]のいずれかを指す: ◎ This specification uses the term document to refer to any use of HTML, ranging from short static documents to long essays or reports with rich multimedia, as well as to fully-fledged interactive applications. The term is used to refer both to Document objects and their descendant DOM trees, and to serialized byte streams using the HTML syntax or the XML syntax, depending on context.

  • ~DOM構造の文脈における用語 `~HTML文書$ / `~XML文書$ は、~DOM仕様 `DOM$r にて定義される,二つの異なる~modeを指す。 `文書$は、このいずれかの~mode下に属する。 (そのような利用は、常にその定義に~hyperlinkされる) ◎ In the context of the DOM structures, the terms HTML document and XML document are used as defined in the DOM specification, and refer specifically to two different modes that Document objects can find themselves in. [DOM] (Such uses are always hyperlinked to their definition.)
  • ~byte~streamの文脈における用語[ ~HTML文書 / ~XML文書 ]は、[ `~HTML~MIME型$ / `~XML~MIME型$ ]の資源を指す。 ◎ In the context of byte streams, the term HTML document refers to resources labeled as text/html, and the term XML document refers to resources labeled with an XML MIME type.

~~記述を単純にするため、利用者~向けに文書を具現化する仕方を指す際に[ “示される( shown )” / “表示される( displayed )” / “可視の( visible )” ]などの語が利用されることもある。 これらの用語は、視覚的~媒体のみを含意するものではなく、他の媒体にも,等価な仕方で適用されるものと見なされ~MUST。 ◎ For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a document is rendered to the user. These terms are not meant to imply a visual medium; they must be considered to apply to other media in equivalent ways.

ある~algo %A が~algo %B を~callしている下で,~algo %B にて[ ~RET / “〜を返す” ]と記された所では、実装は, %A において %B を~callした所から継続し~MUST。 ◎ When an algorithm B says to return to another algorithm A, it implies that A called B. Upon returning to A, the implementation must continue from where it left off in calling B.\

一部の~algoにおいては、[ `並列的に@ 走らす ]と記される所がある — これは、その~algoの後続の手続きを,仕様~内の他の~logic(例えば `~event-loop$)と~~同時並行的に走らすことを意味する。 この仕様は、これが達成される精確な仕組みは定義しない — 例えば、時間を共有する協調的[ multitasking, fibers, threads, processes ], あるいは異なる[ hyperthread, core, CPU, machine ]の利用, 等々。 対照的に、 `即時に@ 走らすような演算は、現在~走らせている~taskを中断して, その演算を走らせ終えてから, 中断した~taskを再開し~MUST。 ◎ Some algorithms run in parallel; this means that the algorithm's subsequent steps are to be run, one after another, at the same time as other logic in the specification (e.g. at the same time as the event loop). This specification 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.

用語 “黒地透明” は、 ( ~red, ~green, ~blue, ~alpha ) 各~channelがすべて 0 にされた色を指す。 ◎ The term "transparent black" refers to the color with red, green, blue, and alpha channels all set to zero.

2.1.1. 資源

資源に対する用語 `~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 )と称されるもの `参照先^tnote は、この仕様では `資源@ と称される。 `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 )と見なされるかは、当の資源の形式を定義する仕様により定義される。 ◎ 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.2. ~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.

他から定められない限り、この仕様に言及される:

  • どの要素も, `~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 であり、次を意味する:

  • その局所~名は `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.3. 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 %A, %B に対し: ◎ ↓

  • %A が %B の中へ `挿入される@node とは、 ( ~node %A, 新たな親 %B ) を引数に`挿入-時の手続き$が呼出されることをいう。 ◎ 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.\
  • 逆に, %A が %B から `除去される@node とは、 ( 除去される~node %A, ~nodeの旧~親 %B ) を引数に`除去-時の手続き$が呼出されることをいう。 ◎ 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 を引数に`挿入-時の手続き$が呼出され, %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 を引数に`除去-時の手続き$が呼出され, %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が元々`文書~木~内$にあったとしても, “挿入し直される” ような処理-時には、除去-, 挿入- 2 つの~eventが連続して生じるかもしれない。 】【 この定義が、変化させる手段も含めているのか,[ 単に,状態の変化のみに基づくものであって、状態を変化させる手段は述べられたものに限られる ]ことを述べているのか、判別できない。 下の定義も同様。 】

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

  • %N は `接続された@ ( becomes connected )とは ⇒ %N は`接続されて$いない下で、 %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 )とは、逆に ⇒ %N は`接続されて$いる下で、 %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が元々`接続されて$いたとしても, “接続し直される” ような処理-時には、切断-, 接続- 2 つの~eventが連続して生じるかもしれない。 】

所与の~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 )とは ⇒ %N は`閲覧文脈に接続されて$いない下で、 %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 )とは、逆に ⇒ %N は`閲覧文脈に接続されて$いる下で、[ %N を引数に`除去-時の手続き$が呼出された ]か, または[ %N の`~shadowも含む根$が`属する閲覧文脈$ ~EQ ε ]になった結果, %N は`閲覧文脈に接続されて$いないようになったことをいう。 ◎ 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.4. ~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から)[ その値を得ようと/新たな値をあてがおうと ]~~試みられるときの挙動を記すときは、[ `取得子は…^dfn / `設定子は…^dfn ]のように表記される。

【 “~~取得子( ...’s getter )” は,原文では “On getting, ...” (訳すなら “被取得時” )であるが、同じ文脈で前者の getter も利用されている。 設定子( “...’s setter” / “On setting, ...” )についても同様。 ~web~platform全般にわたり,この 2 種類のどちらで表記しても特に違いはない/区別を要する箇所はないと見られるので、和訳では “取得子”, “設定子” の表記に統一している。 】【 ~IDL~methodにおける対応する表記( “..., when invoked, ...” )は、 “被呼出時には…” と記される。 】

◎ 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ではなく,実際の `すなわち,現在の^tnote 下層の~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.5. ~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.

利用者が有する`~plugin$の集合は利用者ごとに異なり、利用者が一意に識別されるような機会を増やすような指紋収集の~~手段を提供するので、~UAには,どの利用者に対しても 正確に同じ`~plugin$の集合を~supportすることが奨励される。 ~FINGERPRINTING ◎ 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.6. 文字~符号化方式

`文字~符号化方式@( 参照先 )は、~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.7. 各種 適合性の類別

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

  • ~UA(実装者に関連する) ◎ user agents (relevant to implementors) and\
  • 文書(作者/著作~tool実装者に関連する) ◎ documents (relevant to authors and authoring tool implementors).

`適合~文書@ は、文書に課されるすべての適合性~判定基準に準拠するものである。 可読性のため、これらの適合性~要件のうち一部は,作者に対する適合性~要件として句される。 そのような要件は、暗黙的に文書に課されるものとされる。 定義により、すべての文書には,その作者があるものと見做される。 (一部の事例では、~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.

【 別の言い方をするなら,文書が適合でないことは、原則的に,各 実装~間での挙動の一貫性が 仕様からは保障されない(現実の実装では、たまたま一致するかもしれないが)。 場合によっては,適合しない事例に対する挙動も規定されているので、すべてがそうとは限らないが。 】

~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 ),既定の具現化( rendering )を~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には、示唆される既定の具現化を実装するとしても,利用者~体験を改善するためとして,既定の具現化を上書きするような設定群を提供0することが奨励される。 例えば、色の~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 )挙動 ]として定義されている規則を実装し~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
適合性~検査器は、この仕様にて述べる適合性~判定基準のうち 適用し得るものについて,文書が適合するかどうかを検証0し~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自身が作者の意向を決定できない範囲0に限り,[ 要素をそれに指定された目的に限って利用するとする,厳格な要件 ]からは免除される。 しかしながら,著作~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 要素を任意の連絡先~情報に利用することは適合でない — その要素は、文書またはその一節の著作者に対する連絡先~情報を~markupするために限って利用できるので。 しかしながら、著作~toolは,およそ その相違は決定できないであろうから、その要件は免除される。 そうであっても,これは、著作~toolが[ (例えば)~italic体の~textのどの~blockにも `address$e 要素を利用できる ]ことを意味するわけではない — それは単に、著作~toolが,[ 利用者が~toolを利用して連絡先~情報を挿入するときに,利用者が本当にそれを行っていて 何か別のものを挿入していない ]ことを検証0する必要はないことを意味する。 ◎ 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 the author of the document or section. 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 a section, that the user really is doing that and not inserting something else instead.
注記: 適合性を検査するにあたっては、~editorは,[ 適合性~検査器が検証0するのと同じ範囲0までにおいて,適合する ]ような文書を出力する必要がある。 ◎ 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 )編集に基づいて働くもの。 ◎ 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 である `?^tnote 。 ~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.

~UAは、さもなければ拘束されない入力に,実装~特有の制限-を課して~MAY。 例えば[ ~DOS攻撃を防止する / ~memoryの枯渇に抗して防護する / ~platform特有の制限に対処する ]など。 ~FINGERPRINTING ◎ 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.8. 依存関係

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

2.1.9. 拡張性

この仕様に対する~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。 ◎ 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.10. ~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.

~node-testにおける `QName^P は、~XPath式~文脈( the expression context )からの名前空間~宣言を利用して, `expanded-name$P に展開される。 これは、[ `xmlns^a により宣言される,既定の名前空間 ]は利用されないことは除いて, 開始~tag/終了~tag における要素~型~名に対する展開と同じ仕方で行われる:

  • `QName$P に接頭辞( prefix )がない場合、名前空間 URI ( namespace URI )は ~NULL とする(これは、属性~名( attribute name )が展開されるときと同じ仕方になる)。
  • `QName$P に接頭辞がある場合、対する~XPath式~文脈に名前空間~宣言がないならば,~errorとする。

その場所に次を挿入する: ◎ 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.

~node-testにおける `QName^P は、~XPath式~文脈からの名前空間~宣言を利用して `expanded-name$P に展開される。

  • `QName^P に接頭辞がある場合、~XPath式~文脈に,この接頭辞に対する名前空間~宣言が~~存在し~MUST — 存在しない場合は~errorとする。 この接頭辞には、その宣言により宣言される名前空間 URI が結付けられる。
  • `QName^P に接頭辞がない場合の名前空間 URI は:

    • the axis の the principal ~node型は要素である場合、要素に対する既定の名前空間が利用される。
    • 他の場合、~NULL とする。

要素に対する既定の名前空間は、~XPath式が属する文脈の一員である。 DOM3 XPath API を通して~XPath式を実行するときの,要素に対する既定の名前空間の値は、次に従って決定される:

  1. 文脈~nodeが~HTML~DOMに属するならば: `http://www.w3.org/1999/xhtml^l
  2. 他の場合: ~NULL

注記: これは、 XPath 2.0 の特色機能である[ 要素に対する既定の名前空間( the default element namespace ) ]を XPath 1.0 に追加した上で、~HTML文書においては,~HTML名前空間を[ 要素に対する既定の名前空間 ]として利用することに等価である。 それは、次が欲されることが動機にある: ◎ This is equivalent to adding the default element namespace feature of XPath 2.0 to XPath 1.0, and using the HTML namespace as the default element namespace for HTML documents. It is motivated by the desire to\

  • 実装が旧来の~HTML内容と互換であり続けること。 ◎ have implementations be compatible with legacy HTML content\
  • ただし、この仕様により~HTMLに導入される,~HTML要素に利用される名前空間に関する変更点は~supportすること。 ◎ while still supporting the changes that this specification introduces to HTML regarding the namespace used for HTML elements, and\
  • XPath 2.0 ではなく XPath 1.0 を利用すること。 ◎ by the desire to use XPath 1.0 rather than XPath 2.0.

注記: この変更は、上述の最初の 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.

2.2. 文字大小区別の有無と文字列の比較

2 つの文字列を `文字大小区別@ で比較するとは、符号位置ごとに正確に比較することを意味する。 ◎ Comparing two strings in a case-sensitive manner means comparing them exactly, code point for code point.

他から定められない限り,文字列は`文字大小区別$で比較され~MUST。 ◎ Except where otherwise stated, string comparisons must be performed in a case-sensitive manner.

【 この訳(または他の仕様の和訳)では、`文字大小区別$による比較は,単に “~EQ” や “~NEQ” で表現する(特に明示する必要がある場合を除いて)。 】

文字列 %~pattern が文字列 %S に `先頭一致@ するとは、 %L を %~pattern の文字~数とするとき,[ %~pattern ~EQ [ %S の中の,先頭から %L 個までの文字が成す文字列 ]]であることを意味する。 ◎ A string pattern is a prefix match for a string s when pattern is not longer than s and truncating s to pattern's length leaves the two strings as matches of each other.