2.1.7. 各種 適合性の類別

この仕様は、次の二つに対する適合性~判定基準を述べる:

  • ~UA(実装者に関連する)
  • 文書(作者/著作~tool実装者に関連する)
◎ This specification describes the conformance criteria for user agents (relevant to implementors) and 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に限り,[ 要素をそれに指定された目的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は、次の二つに大別されることが予期される:

  • 構造~上のまたは意味論上の~dataに対し働くもの。
  • 媒体~特有の WYSIWYG( What-You-See-Is-What-You-Get )編集に基づいて働くもの。
◎ Authoring tools are expected to come in two broad varieties: tools that work from structure or semantic data, and 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.

[ 既存の内容や, 先立つ仕様 ]との互換性をとるため、この仕様は,次の二つの著作~形式を述べる:

  • `~XML構文$に基づくもの。
  • ~SGMLに~~由来する`~custom形式$を利用するもの(`~HTML構文$とも称される)。

実装は、これら二つの形式のうち,少なくとも一方は~supportし~MUST — 両者とも~supportすることが奨励されるが。

◎ For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML, and one using a custom format inspired by SGML (referred to as the HTML syntax). Implementations must support at least one of these two formats, although supporting both is encouraged.

適合性~要件のうち一部は、[ 要素 / 属性 / ~method / ~obj ]に課される要件として句される。 そのような要件は、次の二つに~~分類される:

  • 内容~modelに対する制約について述べるもの。 これは、[ 文書/著作~tool ]に課される要件になる。
  • 実装の挙動について述べるもの。 これは、~UAに課される要件になる。

同様に,適合性~要件のうち一部は、作者に課される要件として句される。 そのような要件は、作者が生産する文書に課される適合性~要件として解釈されることになる(言い換えれば、この仕様は,作者に課される適合性~判定基準と, 文書に課されるそれとを区別しない)。

◎ 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. Those in the former category are requirements on documents and authoring tools. 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. 依存関係

この仕様は、他のいくつかの下層~仕様に依拠する。 ◎ This specification relies on several other underlying specifications.

Infra `INFRA$r

次の各種~用語は、 WHATWG Infra 標準にて定義される:

  • 一般の反復~用語:`~WHILE!, `~CONTINUE!, `~BREAK!
  • `符号位置!とその同義語 `文字!
  • `~surrogate!
  • `~scalar値!
  • `非文字!
  • `~JS文字列の長さ!
  • `文字列の長さ!
  • `~ASCII空白!
  • `制御~文字!
  • `~ASCII数字!
  • `~ASCII~hex数字(大文字)!
  • `~ASCII~hex数字(小文字)!
  • `~ASCII~hex数字!
  • `~ASCII英大文字!
  • `~ASCII英小文字!
  • `~ASCII英字!
  • `~ASCII英数字!
  • `~ASCII小文字~化!
  • `~ASCII大文字~化!
  • `~ASCII大小無視!
  • `改行文字を剥ぐ!
  • `前後の~ASCII空白~列を剥ぐ!
  • `~ASCII空白を剥いで縮約-!
  • `~ASCII空白で分割-!
  • `~commaで分割-!
  • `符号位置~並びを収集-!, および その`位置~変数!
  • `~ASCII空白を読飛ばす!
  • `有順序~map!~data構造, および
    • `~map内に存在する!
    • `~entryの値を取得する!
    • `~entryの値を設定する!
  • `~list!~data構造, および
    • `~listに付加する!
    • `~listから除去する!
    • `~listを空にする!
    • `~list内に包含する!
    • `~listの~size!
    • `~listは空!
    • `~listを反復する!
  • `~stack!~data構造, および
    • `~stackに~pushする!
    • `~stackから~popする!
  • `有順序~集合!~data構造, および
    • `有順序~集合に付加する!
  • `~HTML名前空間!
  • `~MathML名前空間!
  • `~SVG名前空間!
  • `~XLink名前空間!
  • `~XML名前空間!
  • `~XMLNS名前空間!
◎ The following terms are defined in the WHATWG Infra standard: [INFRA] • The general iteration terms while, continue, and break. • code point and its synonym character • surrogate • scalar value • noncharacter • JavaScript string length • string length • ASCII whitespace • control • ASCII digit • ASCII upper hex digit • ASCII lower hex digit • ASCII hex digit • ASCII upper alpha • ASCII lower alpha • ASCII alpha • ASCII alphanumeric • ASCII lowercase • ASCII uppercase • ASCII case-insensitive • strip newlines • strip leading and trailing ASCII whitespace • strip and collapse ASCII whitespace • split a string on ASCII whitespace • split a string on commas • collect a sequence of code points and its associated position variable • skip ASCII whitespace • The ordered map data structure and the associated definitions for exists, getting the value of an entry, and setting the value of an entry • The list data structure and the associated definitions for append, remove, empty, contains, size, is empty, and iterate • The stack data structure and the associated definitions for push and pop • The ordered set data structure and the associated definition for append • HTML namespace • MathML namespace • SVG namespace • XLink namespace • XML namespace • XMLNS namespace • ASCII case-insensitive • ASCII uppercase • ASCII lowercase
~Unicode `UNICODE$r
Encoding 標準 `ENCODING$r ◎ Unicode and Encoding
~text的~dataは、~Unicode文字~集合を利用して表現される。 WHATWG Encoding 標準が`符号化方式$に関わる要件を定義する。 ◎ The Unicode character set is used to represent textual data, and the WHATWG Encoding standard defines requirements around character encodings. [UNICODE]
注記: この仕様は、前述したように,これらの仕様に定義される用語に基づいて, 各種用語を導入する。 ◎ This specification introduces terminology based on the terms defined in those specifications, as described earlier.

次の各種~用語は、 Encoding 標準にて定義される:

  • `符号化方式を取得する!
  • `出力~符号化方式を取得する!
  • `汎用~復号-! ~algo — これは、 ( ~byte~stream, `符号化方式$ ) を~~入力にとり,文字~streamを返す。
  • `~UTF-8復号する! ~algo — これは、~byte~streamを~~入力にとり,頭部に~UTF-8~BOM( Byte Order Mark )があればそれを剥いだ上で,文字~streamを返す。
  • `~BOMを取扱わずに~UTF-8復号する! ~algo — これは、頭部の~UTF-8~BOMは剥がないことを除いて, `~UTF-8復号する$のと同じになる。
  • `~BOMも失敗-も取扱わずに~UTF-8復号する! ~algo — これは、~errorに遭遇したときは `失敗^i を返すことを除いて,前項の~BOMを取扱わずに~UTF-8復号する~algoと同じになる。
  • `符号化-! ~algo — これは、 ( 文字~stream, `符号化方式$ ) を~~入力にとり,~byte~streamを返す。
  • `~UTF-8符号化-! ~algo — これは、文字~streamを~~入力にとり,~byte~streamを返す。
◎ The following terms are used as defined in the WHATWG Encoding standard: [ENCODING] • Getting an encoding • Get an output encoding • The generic decode algorithm which takes a byte stream and an encoding and returns a character stream • The UTF-8 decode algorithm which takes a byte stream and returns a character stream, additionally stripping one leading UTF-8 Byte Order Mark (BOM), if any • The UTF-8 decode without BOM algorithm which is identical to UTF-8 decode except that it does not strip one leading UTF-8 Byte Order Mark (BOM) • The UTF-8 decode without BOM or fail algorithm which is identical to UTF-8 decode without BOM except that it returns failure upon encountering an error • The encode algorithm which takes a character stream and an encoding and returns a byte stream • The UTF-8 encode algorithm which takes a character stream and returns a byte stream.
~XML, および関係する仕様 ◎ XML and related specifications
~HTML用の`~XML構文$を~supportする実装は、~XMLの何らかの~versionを,それに対応する名前空間~仕様とともに~supportし~MUST — その構文は、名前空間を伴う~XML直列化を利用するので。 `XML$r `XMLNS$r ◎ Implementations that support the XML syntax for HTML must support some version of XML, as well as its corresponding namespaces specification, because that syntax uses an XML serialization with namespaces. [XML] [XMLNS]
~data-mining~tool等の~UAのうち,[ ~scriptを走らす / ~CSSを評価する / XPath 式を伴う / その他 結果の~DOMを任意の内容に公開する ]ことなく,演算を遂行するものは、[ 上に挙げた文字列を実際に公開する ]ことなく,[ 単に,[ その種の~DOM~nodeに相当するものは,ある名前空間に属する ]ものと言明する ]ことにより, “名前空間を~support” してもよい。 ◎ Data mining tools and other user agents that perform operations on content without running scripts, evaluating CSS or XPath expressions, or otherwise exposing the resulting DOM to arbitrary content, may "support namespaces" by just asserting that their DOM node analogues are in certain namespaces, without actually exposing the above strings.
注記: `~HTML構文$における[ 名前空間~接頭辞, 名前空間~宣言 ]による効果は、~XMLにおけるそれと同じでない。 具体的には、~HTML要素~名における~colonは,特別な意味を持たない。 ◎ In the HTML syntax, namespace prefixes and namespace declarations do not have the same effect as in XML. For instance, the colon has no special meaning in HTML element names.
`~XML名前空間$に属する~tag名 `xml:space^e を伴う属性は、 `XML$r 仕様にて定義される。 ◎ The attribute with the tag name xml:space in the XML namespace is defined by the XML specification. [XML]
この仕様は、 `XMLSSPI$r 仕様にて定義される処理命令 `<?xml-stylesheet?>!c も参照する。 ◎ This specification also references the <?xml-stylesheet?> processing instruction, defined in the Associating Style Sheets with XML documents specification. [XMLSSPI]

この仕様はまた、次のものを非~規範的に言及する `XSLTP$r:

  • `XSLTProcessor@I ~interface, および その:
    • `transformToFragment()@m ~method
    • `transformToDocument()@m ~method
◎ This specification also non-normatively mentions the XSLTProcessor interface and its transformToFragment() and transformToDocument() methods. [XSLTP]
WHATWG URL 標準 `URL$r ◎ URLs

次の各種~用語は、 URL 標準にて定義される:

  • `~host0!
  • `~domain!
  • `IPv4 ~address!
  • `IPv6 ~address!
  • `~URL!
  • ~URLの`生成元!
  • `絶対~URL!
  • `相対~URL!
  • `相対~scheme@
  • `~URL構文解析器!
  • `基本~URL構文解析器!, および その各種~state:
    • `~scheme開始~state!
    • `~host~state!
    • `~path~state!
    • `~path開始~state!
    • `~hostname~state!
    • `~port~state!
    • `~query~state!
    • `素片~state!
  • `~URL~record!, および その各種~成分:
    • `~scheme!
    • `~username!
    • `~password!
    • `~host!
    • `~port!
    • `~path!
    • `~query!
    • `素片!
    • `~cannot-be-a-base-URL~flag!
    • `~obj!
  • `妥当な~URL文字列!
  • `~username/~password/~portを持てない! の概念
  • `~URL直列化器!
  • `~host構文解析器!
  • `~host直列化器!
  • `~hostとして同等!
  • `~URLとして同等!
  • `整数を直列化する!
  • `~path~percent-符号化-集合!
  • `~UTF-8~percent-符号化する!
  • `~percent-復号する!
  • `~usernameを設定する!
  • `~passwordを設定する!
  • `~domainから~Unicodeへ~~変換する! ~algo
  • `~FORMENC 形式!
  • `~FORMENC 直列化器!
◎ The following terms are defined in the WHATWG URL standard: [URL] • host • domain • IPv4 address • IPv6 address • URL • Origin of URLs • Absolute URL • Relative URL • Relative schemes • The URL parser and basic URL parser as well as these parser states: • scheme start state • host state • hostname state • port state • path start state • query state • fragment state • URL record, as well as its individual components: • scheme • username • password • host • port • path • query • fragment • cannot-be-a-base-URL flag • object • URL string • The cannot have a username/password/port concept • The URL serializer • The host parser • The host serializer • Host equals • URL equals • The serialize an integer • Default encode set • UTF-8 percent encode • Percent decode • set the username • set the password • The domain to Unicode algorithm • The application/x-www-form-urlencoded format • The application/x-www-form-urlencoded serializer

この仕様では、次に挙げる各種 ~scheme, ~protocolも参照する:

  • `about_!sc `ABOUT$r
  • `blob_!sc `FILEAPI$r
  • `data_!sc `RFC2397$r
  • `http_!sc `HTTP$r
  • `https_!sc `HTTP$r
  • `mailto_!sc `MAILTO$r
  • `sms_!sc `SMS$r
  • `urn_!sc `URN$r
◎ A number of schemes and protocols are referenced by this specification also: • The about: scheme [ABOUT] • The blob: scheme [FILEAPI] • The data: scheme [RFC2397] • The http: scheme [HTTP] • The https: scheme [HTTP] • The mailto: scheme [MAILTO] • The sms: scheme [SMS] • The urn: scheme [URN]
Media Fragments URI `MEDIAFRAG$r

次の用語が定義される:

  • `媒体~素片~構文!
◎ Media fragment syntax is defined in the Media Fragments URI specification. [MEDIAFRAG]
~HTTP, および関係する各~仕様 ◎ HTTP and related specifications

次の各種~headerは、~HTTP仕様にて定義される: `HTTP$r

  • `Accept!h
  • `Accept-Language!h
  • `Cache-Control!h
  • `Content-Disposition!h
  • `Content-Language!h
  • `Last-Modified!h
  • `Referer!h
◎ The following terms are defined in the HTTP specifications: [HTTP] • `Accept` header • `Accept-Language` header • `Cache-Control` header • `Content-Disposition` header • `Content-Language` header • `Last-Modified` header • `Referer` header

次の各種~用語は、~cookie仕様にて定義される: `COOKIES$r

  • `cookie-string@P
  • `set-cookie-string を受信した@
  • `Cookie!h ~header
◎ The following terms are defined in the Cookie specification: [COOKIES] • cookie-string • receives a set-cookie-string • `Cookie` header

次の用語は、 Web Linking 仕様にて定義される: `WEBLINK$r

  • `Link!h ~header
◎ The following term is defined in the Web Linking specification: [WEBLINK] • `Link` header

次の用語は、 WHATWG MIME Sniffing 標準にて定義される: `MIMESNIFF$r

  • `~XML~MIME型!
  • `~HTML~MIME型!
  • `~MIME型!
  • `妥当な~MIME型!
  • `~parameterを伴わない妥当な~MIME型!
◎ The following terms are defined in the WHATWG MIME Sniffing standard: [MIMESNIFF] • MIME type • valid MIME type • valid MIME type with no parameters • XML MIME type • HTML MIME type
Fetch `FETCH$r, および周辺~仕様

次の各種~用語は、 WHATWG Fetch 標準にて定義される:

  • `about_blank@sc
  • `局所~scheme!
  • `~HTTP_S~scheme!
  • `~network~scheme!
  • `~fetch~scheme!
  • `~HTTPS状態~値!
  • `~CORS~protocol!
  • `既定の User-Agent 値!
  • `MIME 型を抽出する!
  • `~fetch!
  • `~HTTP-redirect~fetch!
  • `ok ~status!
  • `~navi要請!
  • `~network~error!
  • `Origin!h ~header
  • `応答を処理する!
  • `設定する!
  • `終了する!
  • `RequestCredentials!I 列挙~型
  • `RequestDestination!I 列挙~型
  • `応答!, および その:
    • `種別!rs
    • `~url!rs
    • `~url~list!rs
    • `~status!rs
    • `~header~list!rs
    • `本体!rs
    • `内部~応答!rs
    • `~CSP~list!rs
    • `~HTTPS状態!rs
    • `所在~URL!rs
  • `要請!, および その:
    • `~url!rq
    • `~method!rq
    • `~header~list!rq
    • `本体!rq
    • `~client!rq
    • `予約済み~client!rq
    • `~target閲覧文脈!rq
    • `起動元!rq
    • `種別!rq
    • `行先!rq
    • `優先度!rq
    • `生成元!rq
    • `~referrer!rq
    • `同期~mode!rq
    • `~mode!rq
    • `資格証~mode!rq
    • `~URL資格証~利用~mode!rq
    • `~cache~mode!rq
    • `非安全~要請~flag!rq
    • `~redirect~mode!rq
    • `~referrer施策!rq
    • `暗号用~nonce~metadata!rq
    • `完全性~metadata!rq
    • `構文解析器~metadata!rq
◎ The following terms are defined in the WHATWG Fetch standard: [FETCH] • about:blank • local scheme • HTTP(S) scheme • A network scheme • A fetch scheme • HTTPS state value • CORS protocol • extract a MIME type • fetch • HTTP-redirect fetch • ok status • navigation request • network error • `Origin` header • process response • set • terminate • the RequestCredentials enumeration • response and its associated: • type • url • url list • status • header list • body • internal response • CSP list • HTTPS state • location URL • request and its associated: • url • method • header list • body • client • reserved client • target browsing context • initiator • type • destination • priority • origin • referrer • synchronous flag • mode • credentials mode • use-URL-credentials flag • unsafe-request flag • cache mode • redirect mode • referrer policy • cryptographic nonce metadata • integrity metadata • parser metadata
`Referrer Policy^cite `REFERRERPOLICY$r

次の用語が定義される:

  • `~referrer施策!
  • `Referrer-Policy!h ~HTTP~header
  • `Referrer-Policy ~headerを構文解析する!~algo
  • 次の各種~referrer施策
    • `no-referrer!l
    • `no-referrer-when-downgrade!l
    • `origin-when-cross-origin!l
    • `unsafe-url!l
◎ The following terms are defined in Referrer Policy: [REFERRERPOLICY] • referrer policy • The `Referrer-Policy` HTTP header • The parse a referrer policy from a `Referrer-Policy` header algorithm • The "no-referrer", "no-referrer-when-downgrade", "no-referrer-when-downgrade", and "unsafe-url" referrer policies
`Mixed Content^cite `MIX$r

次の用語が定義される:

  • `先天的に認証済みの~URL!
◎ The following terms are defined in Mixed Content: [MIX] • a priori authenticated URL
~WebIDL `WEBIDL$r
この仕様~内の各~IDL片は、[ ~WebIDL仕様に規定される,適合~IDL片 ]として解釈され~MUST。 ◎ The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [WEBIDL]

次の各種~用語は、~WebIDL仕様にて定義される:

  • `拡張属性!
  • `有名~構築子!
  • `配列~index~prop名!
  • `被support~prop~index!
  • `有index~propの値を決定する!
  • `既存の有index~propの値を設定する!
  • `新たな有index~propの値を設定する!
  • `有名~propを~supportする!
  • `被support~prop名!
  • `有名~propの値を決定する!
  • `既存の有名~propの値を設定する!
  • `新たな有名~propの値を設定する!
  • `既存の有名~propを削除する!
  • `保安~検査を遂行する!
  • `~platform~obj!
  • `首~interface!
  • `~interface~obj!
  • `~interface~prototype~obj!
  • ~platform~objが`属する大域~環境!
  • `~callback文脈!
  • `凍結~配列!
  • `凍結~配列を作成する!
  • `~callback this 値!
  • 各種~WebIDL型と各種~JS型との間の`変換法!
  • `~WebIDL~callback関数を呼出す!
  • `~callback関数で構築-!
  • `~Unicode~scalar値~列に変換する!
◎ The following terms are defined in the Web IDL specification: • extended attribute • named constructor • array index property name • supported property indices • determine the value of an indexed property • set the value of an existing indexed property • set the value of a new indexed property • support named properties • supported property names • determine the value of a named property • set the value of an existing named property • set the value of a new named property • delete an existing named property • perform a security check • platform object • primary interface • interface object • interface prototype object • inherited interfaces • global environment associated with a platform object • callback context • frozen array and creating a frozen array • callback this value • converting between Web IDL types and JS types • invoke the Web IDL callback function • converting to a sequence of Unicode scalar values

~WebIDL仕様は、この仕様の~WebIDL片にて利用される,次の各種~型も定義する: ◎ The Web IDL specification also defines the following types that are used in Web IDL fragments in this specification:

  • `ArrayBuffer!I
  • `ArrayBufferView!I
  • `boolean!I
  • `DOMString!I
  • `double!I
  • `列挙!
  • `Error!I
  • `Function!I
  • `long!I
  • `object!I
  • `RegExp!I
  • `Uint8ClampedArray!I
  • `unrestricted double!I
  • `unsigned long!I
  • `USVString!I

この仕様に利用される用語 `投出! ( throw )は、~WebIDL仕様にて定義される。 `DOMException!I 型, および次の 例外~名 は、~WebIDLにて定義され,この仕様で利用される: ◎ The term throw in this specification is used as defined in the Web IDL specification. The DOMException type and the following exception names are defined by Web IDL and used by this specification: The :

  • `IndexSizeError!E
  • `HierarchyRequestError!E
  • `InvalidCharacterError!E
  • `NotFoundError!E
  • `NotSupportedError!E
  • `InvalidStateError!E
  • `SyntaxError!E
  • `InvalidAccessError!E
  • `SecurityError!E
  • `NetworkError!E
  • `AbortError!E
  • `QuotaExceededError!E
  • `DataCloneError!E
  • `EncodingError!E
  • `NotAllowedError!E
この仕様が、特定0の時刻を表現するような `Date ~objを作成する@ よう~UAに要求するときは、新たに作成される `Date$jC ~objの時刻~値(特別な値 NaN にもなり得るが,そうでない場合)は、その時刻のミリ秒~成分の小数は切り捨てて整数に丸めた結果の時刻を表現し~MUST。 ◎ When this specification requires a user agent to create a Date object representing a particular time (which could be the special value Not-a-Number), the milliseconds component of that time, if any, must be truncated to an integer, and the time value of the newly created Date object must represent the resulting truncated time.
具体的には、時刻[ 01:00 UTC on January 1st 2000 ( 2000 年 1 月 1 日の UTC 時間帯 午前 1 時) ]から ( 23045 ÷ 1000 ÷ 1000 ) 秒~後の時刻 — すなわち 2000-01-01T00:00:00.023045Z — に対し作成される `Date$jC ~objは,それより ( 45 ÷ 1000 ÷ 1000 ) 秒~早い時刻 — すなわち 2000-01-01T00:00:00.023Z — に対し作成されるそれと同じ時刻を表現する。 NaN に対し作成される `Date$jC ~objは、時刻~値 NaN を表現する(これは、特定の時刻を表現しないことを指示する)。 ◎ For instance, given the time 23045 millionths of a second after 01:00 UTC on January 1st 2000, i.e. the time 2000-01-01T00:00:00.023045Z, then the Date object created representing that time would represent the same time as that created representing the time 2000-01-01T00:00:00.023Z, 45 millionths earlier. If the given time is NaN, then the result is a Date object that represents a time value NaN (indicating that the object does not represent a specific instant of time).
~JS
この仕様が述べる言語の ある部分は、下層の~scripting言語として~JSのみを~supportする。 `JAVASCRIPT$r ◎ Some parts of the language described by this specification only support JavaScript as the underlying scripting language. [JAVASCRIPT]
~JSを~supportする~UA は、 `ECMAScript Internationalization API Specification^cite も実装し~MUST。 `JSINTL$r ◎ Users agents that support JavaScript must also implement the ECMAScript Internationalization API Specification. [JSINTL]
注記: 用語 “~JS” は、 ECMA-262 を指す。 公式的な用語として ECMAScript もあるが、 ~JS の方がより広く知られているなので。 また, `~MIME型$ `text/javascript^c は、~JSを指す — `RFC4329$r により公式的には廃用にされた型である にもかかわらず、それは最も共通的に利用されている型なので。 ◎ The term "JavaScript" is used to refer to ECMA-262, rather than the official term ECMAScript, since the term JavaScript is more widely known. Similarly, the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC 4329. [RFC4329]

この仕様は、~JS仕様にて定義される次の用語を利用する:

  • `作動中の関数~obj!
  • `自動的~semicolon挿入!
  • `現在の~Realm~Record!
  • `early error!
  • `Directive Prologue!
  • `~essential内部~methodに対する不変則!
  • `~JS実行~文脈!
  • `~JS実行~文脈~stack!
  • `~JS~realm!
  • `走っている~JS実行~文脈!
  • `Use Strict Directive!
  • 次を含む `Well-Known Symbols!:
    • `hasInstance@jS
    • `isConcatSpreadable@jS
    • `toPrimitive@jS
    • `toStringTag@jS
  • 次を含む `Well-Known Intrinsic Objects!:
    • `ArrayBuffer!jI
    • `ArrayPrototype!jI
    • `ObjProto_valueOf!jI
  • 次に挙げる各種 生成規則:
    • `FunctionBody!P
    • `Module!P
    • `Pattern!P
    • `Script!P
  • `Type! 記法
  • `List! 仕様~型
  • `Record! 仕様~型
  • `Property Descriptor! 仕様~型
  • `Source Text Module Record! 仕様~型 , および その:
    • `ModuleEvaluation@jM ~method
    • `ModuleDeclarationInstantiation@jM ~method
  • 次に挙げる各種 抽象演算:
    • `ArrayCreate!jA
    • `Call!jA
    • `Construct!jA
    • `CopyDataBlockBytes!jA
    • `CreateByteDataBlock!jA
    • `CreateDataProperty!jA
    • `DetachArrayBuffer!jA
    • `EnqueueJob!jA
    • `EnumerableOwnProperties!jA
    • `FunctionCreate!jA
    • `Get!jA
    • `GetFunctionRealm!jA
    • `HasOwnProperty!jA
    • `HostEnsureCanCompileStrings!jA
    • `HostPromiseRejectionTracker!jA
    • `HostResolveImportedModule!jA
    • `InitializeHostDefinedRealm!jA
    • `IsAccessorDescriptor!jA
    • `IsCallable!jA
    • `IsConstructor!jA
    • `IsDataDescriptor!jA
    • `NewObjectEnvironment!jA
    • `OrdinaryGetPrototypeOf!jA
    • `OrdinarySetPrototypeOf!jA
    • `OrdinaryIsExtensible!jA
    • `OrdinaryPreventExtensions!jA
    • `OrdinaryGetOwnProperty!jA
    • `OrdinaryDefineOwnProperty!jA
    • `OrdinaryGet!jA
    • `OrdinarySet!jA
    • `OrdinaryDelete!jA
    • `OrdinaryOwnPropertyKeys!jA
    • `ParseModule!jA
    • `ParseScript!jA
    • `RunJobs!jA
    • `SameValue!jA
    • `ScriptEvaluation!jA
    • `SetImmutablePrototype!jA
    • `ToBoolean!jA
    • `ToString!jA
    • `ToUint32!jA
    • `TypedArrayCreate!jA
  • `Abstract Equality Comparison! ~algo
  • `Strict Equality Comparison! ~algo
  • `Date!jC ~class
  • `TypeError!jC ~class
  • `RangeError!jC ~class
  • `typeof!js 演算子
  • `TypedArray の各種~構築子!
◎ The following terms are defined in the JavaScript specification and used in this specification: • active function object • automatic semicolon insertion • The current Realm Record • early error • Directive Prologue • invariants of the essential internal methods • JavaScript execution context • JavaScript execution context stack • JavaScript realm • running JavaScript execution context • Use Strict Directive • Well-Known Symbols, including @@hasInstance, @@isConcatSpreadable, @@toPrimitive, and @@toStringTag • Well-Known Intrinsic Objects, including %ArrayBuffer%, %ArrayPrototype%, and %ObjProto_valueOf% • The FunctionBody production • The Module production • The Pattern production • The Script production • The Type notation • The List and Record specification types • The Property Descriptor specification type • The Source Text Module Record specification type and its ModuleEvaluation and ModuleDeclarationInstantiation methods • The ArrayCreate abstract operation • The Call abstract operation • The Construct abstract operation • The CopyDataBlockBytes abstract operation • The CreateByteDataBlock abstract operation • The CreateDataProperty abstract operation • The DetachArrayBuffer abstract operation • The EnqueueJob abstract operation • The EnumerableOwnProperties abstract operation • The FunctionCreate abstract operation • The Get abstract operation • The GetFunctionRealm abstract operation • The HasOwnProperty abstract operation • The HostEnsureCanCompileStrings abstract operation • The HostPromiseRejectionTracker abstract operation • The HostResolveImportedModule abstract operation • The InitializeHostDefinedRealm abstract operation • The IsAccessorDescriptor abstract operation • The IsCallable abstract operation • The IsConstructor abstract operation • The IsDataDescriptor abstract operation • The IsDetachedBuffer abstract operation • The NewObjectEnvironment abstract operation • The OrdinaryGetPrototypeOf abstract operation • The OrdinarySetPrototypeOf abstract operation • The OrdinaryIsExtensible abstract operation • The OrdinaryPreventExtensions abstract operation • The OrdinaryGetOwnProperty abstract operation • The OrdinaryDefineOwnProperty abstract operation • The OrdinaryGet abstract operation • The OrdinarySet abstract operation • The OrdinaryDelete abstract operation • The OrdinaryOwnPropertyKeys abstract operation • The ParseModule abstract operation • The ParseScript abstract operation • The RunJobs abstract operation • The SameValue abstract operation • The ScriptEvaluation abstract operation • The SetImmutablePrototype abstract operation • The ToBoolean abstract operation • The ToString abstract operation • The ToUint32 abstract operation • The TypedArrayCreate abstract operation • The Abstract Equality Comparison algorithm • The Strict Equality Comparison algorithm • The Date class • The TypeError class • The RangeError class • The typeof operator • The TypedArray Constructors table
DOM ( Document Object Model ) `DOM$r
~DOMは、文書とその内容の表現~modelである。 ~DOMは~APIに留まるものではない — この仕様では、~HTML実装の適合性~判定基準は,~DOMに対する演算の用語を通して定義する。 ◎ The Document Object Model (DOM) is a representation — a model — of a document and its content. The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM. [DOM]
この仕様にて~DOMの用語で定義される特色機能のうち一部は,~DOM~interfaceに対する拡張として定義されるので、実装は,[ ~DOMおよび UI Events `UIEVENTS$r ]に定義される各種~eventを~supportし~MUST。 ◎ Implementations must support DOM and the events defined in UI Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [UIEVENTS]

特に、次の特色機能は WHATWG ~DOM標準にて定義される:

  • `Attr!I ~interface
  • `Comment!I ~interface
  • `DOMImplementation!I ~interface, および その:
    • `createDocument()!m ~method
    • `createHTMLDocument()!m ~method
  • `Document!I ~interface, および その:
    • `createElement()!m ~method
    • `createElementNS()!m ~method
    • `getElementsByClassName()!m ~method
    • `importNode()!m ~method
  • 要素/文書の `getElementById()!m ~method
  • `DocumentFragment!I ~interface
  • `DocumentType!I ~interface
  • `ChildNode!I ~interface
  • `Element!I ~interface, および その:
    • `id!m 属性
  • `Node!I ~interface, および その:
    • `appendChild()!m ~method
    • `cloneNode()!m ~method
    • `textContent!m 属性
  • `NodeList!I ~interface
  • `ProcessingInstruction!I ~interface
  • `ShadowRoot!I ~interface
  • `Text!I ~interface
  • `HTMLCollection!I ~interface, および その:
    • `length!m 属性
    • `item()!m ~method
    • `namedItem()!m ~method
  • `~collection!
  • `~collectionで表現される!
  • `DOMTokenList!I ~interface, および その:
    • `value!m 属性
  • `~node文書! の概念
  • `~host!doc の概念
  • `木!, `~shadow木! の概念
  • `~shadow根! の概念
  • `木~順序!, `~shadowも含む木~順序! の概念
  • `子! の概念
  • `根!, `~shadowも含む根! の概念
  • `広義先祖!, `~shadowも含む子孫! の概念
  • `最初の子!, `次の同胞! の概念
  • `文書~要素! の概念
  • `文書~木~内にある!, `文書~内にある!(旧来の), `接続されて!いる の概念
  • `~slot!, `~slot名!, ~slotに`割当されている~nodeたち! の概念
  • `平坦化された~slotableたちを見出す! ~algo
  • `~slotに割当する! ~algo
  • ~nodeに対する次の~algo:
    • `前挿入する!
    • `挿入する!
    • `付加する!
    • `置換する!
    • `すべてを置換する!
    • `除去する!
    • `受入する!
  • 内容~属性に対する次の~algo:
    • `属性を変更する!
    • `属性を付加する!
    • `属性を除去する!
    • `属性を置換する!
    • `属性~値を設定する!
  • ~hook
    • `挿入-時の手続き!
    • `除去-時の手続き!
    • `受入-時の手続き!
  • 要素の`属性~list! の概念
  • `~text~nodeの~data!
  • `Event!I ~interface, および その:
    • `type!m 属性
    • `target!m 属性
    • `currentTarget!m 属性
    • `bubbles!m 属性
    • `cancelable!m 属性
    • `isTrusted!m 属性
    • `initEvent()!m ~method
    • `preventDefault()!m ~method
  • `EventTarget!I ~interface, および その:
    • `addEventListener()!m ~method
  • `EventListener!I ~callback~interface
  • `作動化の挙動! ~hook
  • `旧来の作動化~前の挙動! ~hook
  • `旧来の作動化~取消~時の挙動! ~hook
  • `~eventを作成する!~algo
  • `~eventを発火する!~algo
  • `取消ed~flag!
  • `~eventを配送する!~algo
  • `EventInit!I 辞書~型
  • `~eventの型!
  • `~event~listener!, および `EventTarget$I の~event~listener~listの概念
  • `文書の符号化方式!
  • `文書の内容~型!
  • `~XML文書!
  • `~HTML文書!, および XML 文書との区別
  • `過去互換~mode!
  • `限定的互換~mode!
  • `非過去互換~mode!
  • `Node$I を`~cloneする~algo!
  • `~cloneする~algo$から利用される,`~clone時の手続き!
  • `基底~URL変更~手続き@ の概念
  • `要素が基底~URLの変更に影響される@ときに何が起きるかの定義
  • `要素の一意~識別子!( ID )の概念
  • `被support~token!
  • `~DOM範囲~obj! ( `Range^I )の概念, およびその:
    • `始端!
    • `終端!
    • `境界点!
  • `要素を作成する~algo!
  • `要素~interface!の概念
  • `~custom要素~状態!, `定義済み要素!, `~custom要素! の概念
  • 要素の`~custom要素~定義!
  • 要素の`~is0値!
  • `MutationObserver!I ~interface
  • `変異~observer! in general
◎ In particular, the following features are defined in the WHATWG DOM standard: [DOM] • Attr interface • Comment interface • DOMImplementation interface • Document interface • DocumentFragment interface • DocumentType interface • ChildNode interface • Element interface • Node interface • NodeList interface • ProcessingInstruction interface • Text interface • node document concept • host concept • shadow root concept • HTMLCollection interface • HTMLCollection.length attribute • HTMLCollection.item() method • HTMLCollection.namedItem() method • The terms collection and represented by the collection • DOMTokenList interface • DOMTokenList.value attribute • createDocument() method • createHTMLDocument() method • createElement() method • createElementNS() method • getElementById() method • getElementsByClassName() method • appendChild() method • cloneNode() method • importNode() method • preventDefault() method • id attribute • textContent attribute • The tree and shadow tree concepts • The tree order and shadow-including tree order concepts • The child concept • The root and shadow-including root concepts • The inclusive ancestor and shadow-including descendant concepts • The first child and next sibling concepts • The document element concept • The in a document tree, in a document (legacy), and connected concepts • The in a shadow-including document concept • The slot concept, and its name and assigned nodes • The find flattened slotables algorithm • The pre-insert, insert, append, replace, replace all, remove, and adopt algorithms for nodes • The change, append, remove, replace, and set value algorithms for attributes • The insertion steps, removing steps, and adopting steps hooks • The attribute list concept • The data of a text node • Event interface • EventTarget interface • The activation behavior hook • The legacy-pre-activation behavior hook • The legacy-canceled-activation behavior hook • The create an event algorithm • The fire an event algorithm • The canceled flag • The dispatch algorithm • EventInit dictionary type • type attribute • target attribute • currentTarget attribute • bubbles attribute • cancelable attribute • isTrusted attribute • initEvent() method • addEventListener() method • EventListener callback interface • The type of an event • The concept of an event listener and the event listeners associated with an EventTarget • The encoding (herein the character encoding) and content type of a Document • The distinction between XML documents and HTML documents • The terms quirks mode, limited-quirks mode, and no-quirks mode • The algorithm to clone a Node, and the concept of cloning steps used by that algorithm • The concept of base URL change steps and the definition of what happens when an element is affected by a base URL change • The concept of an element's unique identifier (ID) • The term supported tokens • The concept of a DOM range, and the terms start, end, and boundary point as applied to ranges. • The create an element algorithm • The element interface concept • The concepts of custom element state, and of defined and custom elements • An element's custom element definition • An element's is value • MutationObserver interface and mutation observers in general
UI Events `UIEVENTS$r

次の各種~特色機能は、 UI Events 仕様にて定義される:

  • `MouseEvent!I ~interface, および その
    • `relatedTarget@m 属性
  • `MouseEventInit!I 辞書~型
  • `FocusEvent!I ~interface, および その
    • `relatedTarget@m 属性
  • `UIEvent!I ~interface, および その
    • `view!m 属性
  • 次に挙げる各種~event:
    • `click!et
    • `dblclick!et
    • `mousedown!et
    • `mouseenter!et
    • `mouseleave!et
    • `mousemove!et
    • `mouseout!et
    • `mouseover!et
    • `mouseup!et
    • `wheel!et
    • `keydown!et
    • `keyup!et
    • `keypress!et
◎ The following features are defined in the UI Events specification: [UIEVENTS] • The MouseEvent interface • The MouseEvent interface's relatedTarget attribute • MouseEventInit dictionary type • The FocusEvent interface • The FocusEvent interface's relatedTarget attribute • The UIEvent interface • The UIEvent interface's view attribute • click event • dblclick event • mousedown event • mouseenter event • mouseleave event • mousemove event • mouseout event • mouseover event • mouseup event • wheel event • keydown event • keyup event • keypress event
Touch Events `TOUCH$r

次の各種~特色機能は、 Touch Events 仕様にて定義される:

  • `Touch!I ~interface
  • `~touch点!
  • `touchend!et ~event
◎ The following features are defined in the Touch Events specification: [TOUCH] • Touch interface • Touch point concept • touchend event
Pointer Events `POINTEREVENTS$r

次の各種~特色機能は、 Pointer Events 仕様にて定義される:

  • `pointerup!et ~event
◎ The following features are defined in the Pointer Events specification: [POINTEREVENTS] • pointerup event
auxclick `AUXCLICK$r

次の各種~特色機能は、 auxclick 仕様にて定義される:

  • `auxclick!et ~event
◎ The following features are defined in the auxclick specification: [AUXCLICK] • auxclick event
この仕様は、`~eventの型$を指して,次のように 名前 と称することもある: “名前 `click^et の~event”, “~event名は `keypress^et ならば…”, 等々。 ~eventに対する用語 "名前 と “型” は、同義である。 ◎ This specification sometimes uses the term name to refer to the event's type; as in, "an event named click" or "if the event name is keypress". The terms "name" and "type" for events are synonymous.
DOM Parsing and Serialization `DOMPARSING$r

次の特色機能は、 DOM Parsing and Serialization 仕様にて定義される: ◎ The following features are defined in the DOM Parsing and Serialization specification: [DOMPARSING]

  • `DOMParser!I
  • `innerHTML!m
  • `outerHTML!m
Selection API `SELECTION$r

次の~interfaceが定義される:

  • `Selection!I
◎ The Selection interface is defined in the Selection API specification. [SELECTION]
注記: ~UAには、 `EXECCOMMAND$r 仕様にて記述される各種~特色機能を実装することが奨励される ◎ User agents are encouraged to implement the features described in the execCommand specification. [EXECCOMMAND]
WHATWG Fullscreen ~API `FULLSCREEN$r

この仕様は、 `dialog$e 要素の具現化を定義する所, および Fullscreen ~APIが~HTMLとどうやりとりするかを定義する所にて, Fullscreen ~API標準の次の部分を参照する:

  • `top layer! の概念
  • top layer を`追加する!fs / `除去する!fs ~algo
  • `requestFullscreen()!m
◎ The following parts of the WHATWG Fullscreen API standard are referenced from this specification, in part to define the rendering of dialog elements, and also to define how the Fullscreen API interacts with HTML: [FULLSCREEN] • top layer and its add and remove algorithms • requestFullscreen()
`High Resolution Time^cite `HRT$r

`HRT$r は、次を提供する:

  • `DOMHighResTimeStamp!I ~typedef
  • `Performance!I ~obj, および その:
    • `now()!m ~method
◎ The High Resolution Time specification provides the DOMHighResTimeStamp typedef and the Performance object's now() method. [HRT]
File API `FILEAPI$r

この仕様が利用する次の各種~特色機能は、 File API 仕様にて定義される:

  • `Blob!I ~interface, および その:
    • `~type0!m 属性
  • `File!I ~interface, および その:
    • `name!m 属性
    • `lastModified!m 属性
  • `FileList!I ~interface
  • `Blob$I の`~snapshot状態! の概念
  • `読取-~error@の概念
  • `Blob URL Store!
◎ This specification uses the following features defined in the File API specification: [FILEAPI] • The Blob interface and its type attribute • The File interface and its name and lastModified attributes • The FileList interface • The concept of a Blob's snapshot state • The concept of read errors • Blob URL Store
Indexed Database API `INDEXEDDB$r

この仕様は次の用語を参照する:

  • `Indexed Database ~transactionを片付ける!
◎ This specification uses cleanup Indexed Database transactions defined by the Indexed Database API specification. [INDEXEDDB]
Media Source Extensions `MEDIASOURCE$r

この仕様は次の~interface/用語を参照する:

  • `MediaSource!I ~interface
  • `媒体~要素から切り離す!
◎ The following terms are defined in the Media Source Extensions specification: [MEDIASOURCE] • MediaSource interface • detaching from a media element
Media Capture and Streams `MEDIASTREAM$r

次の用語が定義される:

  • `MediaStream!I ~interface
  • `getUserMedia()!m ~method
◎ The following terms are defined in the Media Capture and Streams specification: [MEDIASTREAM] • MediaStream interface • getUserMedia() method
XMLHttpRequest `XHR$r

この仕様は XMLHttpRequest 仕様を参照し、その仕様との相互作用を述べ,その `ProgressEvent$I 特色機能を利用する。 次の各種~特色機能, 用語は、 XMLHttpRequest 仕様にて定義される:

  • `XMLHttpRequest!I ~interface, および その
    • `responseXML!m 属性
  • `ProgressEvent!I ~interface, および その
    • `lengthComputable!m 属性
    • `loaded!m 属性
    • `total!m 属性
  • 名前 %e の`進捗~eventを発火する!
◎ This specification references the XMLHttpRequest specification to describe how the two specifications interact and to use its ProgressEvent features. The following features and terms are defined in the XMLHttpRequest specification: [XHR] • XMLHttpRequest interface • XMLHttpRequest.responseXML attribute • ProgressEvent interface • ProgressEvent.lengthComputable attribute • ProgressEvent.loaded attribute • ProgressEvent.total attribute • Fire a progress event named e
`Battery Status API^cite `BATTERY$r

次の特色機能が定義される:

  • `getBattery()!m ~method
◎ The following features are defined in the Battery Status API specification: [BATTERY] • getBattery() method
`Media Queries^cite `MQ$r
実装は、 Media Queries を~supportし~MUST。 `media-condition!t 特色機能は、そこにて定義される。 ◎ Implementations must support Media Queries. The <media-condition> features is defined therein. [MQ]
~CSSの各種~module
この仕様の実装には,~CSS全体に対する~supportは要求されないが(~Web~browserに対しては少なくとも奨励されるが)、一部の特色機能は,特定の~CSS要件による用語を通して定義される。 ◎ CSS modules ◎ While support for CSS as a whole is not required of implementations of this specification (though it is encouraged, at least for Web browsers), some features are defined in terms of specific CSS requirements.
この仕様が何かを `特定0の~CSS文法に則って構文解析する! ことを要求する所では、 CSS Syntax 仕様における関連の~algoに従わ~MUST。 `CSSSYNTAX$r ◎ When this specification requires that something be parsed according to a particular CSS grammar, the relevant algorithm in the CSS Syntax specification must be followed. [CSSSYNTAX]
特に,一部の特色機能は、文字列を `~CSS色~値として構文解析する@ ことを要求する。 ~CSS値を構文解析するときは、~CSS仕様による~error取扱い規則を適用することが~UAに要求され、この仕様にも適用される。 `CSSCOLOR$r `CSS$r ◎ In particular, some features require that a string be parsed as a CSS <color> value. When parsing a CSS value, user agents are required by the CSS specifications to apply some error handling rules. These apply to this specification also. [CSSCOLOR] [CSS]
例えば~UAには、~stylesheetが予期せず終端することを見出したときは,すべての開き括弧を閉じることが要求される。 したがって色~値に対する文字列 `rgb(0,0,0^l (閉じ丸括弧がない)を構文解析するときは、この~error取扱い規則により,閉じ丸括弧も含意され、値(黒色)が得られることになる。 一方で,似た構成子 `rgb(0,0,^l (丸括弧と ~blue成分~値がない)は、開き括弧を閉じたときの結果が~~適正な値にならないので,構文解析できない。 ◎ For example, user agents are required to close all open constructs upon finding the end of a style sheet unexpectedly. Thus, when parsing the string "rgb(0,0,0" (with a missing close-parenthesis) for a color value, the close parenthesis is implied by this error handling rule, and a value is obtained (the color 'black'). However, the similar construct "rgb(0,0," (with both a missing parenthesis and a missing "blue" value) cannot be parsed, as closing the open construct does not result in a viable value.
CSS2 `CSS$r

次の用語が定義される:

  • `表示域!
  • `行box!
  • `~flow外!
  • `~flow内!
  • `置換~要素!
  • `内在的~寸法!, および その
    • `内在的~横幅@
    • `内在的~縦幅@
  • `内容~区画!
  • `内容~box!
  • `~border~box!
  • `~margin~box!
  • `~border辺!
  • `~margin辺!
  • `~marginの相殺!
  • `包含塊!
  • `行内~box!
  • `塊~box!
◎ The following terms are defined in the CSS specification: [CSS] • viewport • line box • out-of-flow • in-flow • replaced element • intrinsic dimensions • content area • content box • border box • margin box • border edge • margin edge • collapsing margins • containing block • inline box • block box

次の各種~propが定義される:

  • 各種~margin~prop:
    • `margin-top!p
    • `margin-bottom!p
    • `margin-left!p
    • `margin-right!p
  • 各種~padding~prop:
    • `padding-top!p
    • `padding-bottom!p
    • `padding-left!p
    • `padding-right!p
  • 各種~offset~prop:
    • `top!p
    • `bottom!p
    • `left!p
    • `right!p
  • `float!p ~prop
  • `clear!p ~prop
  • `width!p ~prop
  • `height!p ~prop
  • `line-height!p ~prop
  • `vertical-align!p ~prop
  • `content!p ~prop
  • `visibility!p ~prop
  • `display!p ~prop, およびその `inline-block!v 値。 他の~CSS~module `CSSRUBY$r `CSSTABLE$r も `display$p を拡張する。
◎ • The 'margin-top', 'margin-bottom', 'margin-left', and 'margin-right' properties • The 'padding-top', 'padding-bottom', 'padding-left', and 'padding-right' properties • The 'top', 'bottom', 'left', and 'right' properties • The 'float' property • The 'clear' property • The 'width' property • The 'height' property • The 'line-height' property • The 'vertical-align' property • The 'content' property • The 'inline-block' value of the 'display' property • The 'visibility' property ◎ The CSS specification also defines the following border properties: [CSS] Border properties Top Bottom Left Right Width 'border-top-width' 'border-bottom-width' 'border-left-width' 'border-right-width' Style 'border-top-style' 'border-bottom-style' 'border-left-style' 'border-right-style' Color 'border-top-color' 'border-bottom-color' 'border-left-color' 'border-right-color' ◎ The terms intrinsic width and intrinsic height refer to the width dimension and the height dimension, respectively, of intrinsic dimensions. ◎ The basic version of the 'display' property is defined in the CSS specification, and the property is extended by other CSS modules. [CSS] [CSSRUBY] [CSSTABLE]

次の各種~border~propも定義される(上端, 下端, 左端, 右端の順に挙げる):

  • 線幅:
    • `border-top-width!p
    • `border-bottom-width!p
    • `border-left-width!p
    • `border-right-width!p
  • ~style:
    • `border-top-style!p
    • `border-bottom-style!p
    • `border-left-style!p
    • `border-right-style!p
  • 色:
    • `border-top-color!p
    • `border-bottom-color!p
    • `border-left-color!p
    • `border-right-color!p
◎ ↑
`CSS Logical Properties^cite `CSSLOGICAL$r

次の特色機能が定義される:

  • 各種 論理~margin~prop:
    • `margin-block-start!p
    • `margin-block-end!p
    • `margin-inline-start!p
    • `margin-inline-end!p
  • 各種 論理~padding~prop:
    • `padding-block-start!p
    • `padding-block-end!p
    • `padding-inline-start!p
    • `padding-inline-end!p
◎ The following terms and features are defined in the CSS Logical Properties specification: [CSSLOGICAL] • The 'margin-block-start', 'margin-block-end', 'margin-inline-start', and 'margin-inline-end' properties • The 'padding-block-start', 'padding-block-end', 'padding-inline-start', and 'padding-inline-end' properties
CSS Color `CSSCOLOR$r

次の用語と特色機能が定義される:

  • `有名~色!
  • `color!t
  • `color!p ~prop
◎ The following terms and features are defined in the CSS Color specification: [CSSCOLOR] • named color • <color> • The 'color' property
CSS Image Values and Replaced Content `CSSIMAGES$r

次の用語と特色機能が定義される:

  • `塗り~source! — これは、一定の~HTML要素による ~CSS 'element()' 関数との相互作用を定義する
  • `既定の~obj~size! `CSSIMAGES$r
  • `object-fit!p
◎ The term paint source is used as defined in the CSS Image Values and Replaced Content specification to define the interaction of certain HTML elements with the CSS 'element()' function. [CSSIMAGES] ◎ The term default object size and the 'object-fit' property are also defined in the CSS Image Values and Replaced Content specification. [CSSIMAGES]
CSS Backgrounds and Borders `CSSBG$r

次の特色機能が定義される:

  • `background-color!p ~prop
  • `background-image!p ~prop
  • `bg-position!t ~CSS~data型
◎ The following features are defined in the CSS Backgrounds and Borders specification: [CSSBG] • The 'background-color' property • The 'background-image' property • The <position> CSS data type
CSS Display `CSSDISPLAY$r

次の特色機能が定義される:

  • `塊level!
◎ The term block-level is defined in the CSS Display specification. [CSSDISPLAY]
CSS Fonts `CSSFONTS$r

次の特色機能が定義される:

  • `font-family!p ~prop
  • `font-weight!p ~prop
  • `font-size!p ~prop
  • `font!p ~prop
◎ The following features are defined in the CSS Fonts specification: [CSSFONTS] • The 'font-family' property • The 'font-weight' property • The 'font-size' property • The 'font' property
CSS Lists and Counters `CSSLISTS$r

次の特色機能が定義される:

  • `list-style-type!p ~prop
◎ The 'list-style-type' property is defined in the CSS Lists and Counters specification. [CSSLISTS]
CSS Overflow `CSSOVERFLOW$r

次の特色機能が定義される:

  • `overflow!p ~propと,その `hidden!v 値
◎ The 'overflow' property and its 'hidden' value are defined in the CSS Overflow specification. [CSSOVERFLOW]
CSS Positioned Layout `CSSPOSITION$r

次の特色機能が定義される:

  • `position!p ~propと,その `static!v 値
◎ The following features are defined in the CSS Positioned Layout specification: [CSSPOSITION] •The 'position' property and its 'static' value
CSS Ruby Layout `CSSRUBY$r

次の特色機能が定義される:

  • `display$p ~propの `ruby-base@v 値
◎ The 'ruby-base' value of the 'display' property is defined in the CSS Ruby Layout specification. [CSSRUBY]
CSS Table `CSSTABLE$r

次の特色機能が定義される:

  • `border-spacing!p ~prop
  • `border-collapse!p ~prop
  • `display$p ~propの `table-cell!v, `table-row!v, `table-caption!v, `table!v 値
◎ The following features are defined in the CSS Table specification: [CSSTABLE] • The 'border-spacing' property • The 'border-collapse' property • The 'table-cell', 'table-row', 'table-caption', and 'table' values of the 'display' property
CSS Text `CSSTEXT$r

次の特色機能が定義される:

  • `text-transform!p ~prop
  • `white-space!p ~prop
  • `text-align!p ~prop
  • `letter-spacing!p ~prop
◎ The following features are defined in the CSS Text specification: [CSSTEXT] • The 'text-transform' property • The 'white-space' property • The 'text-align' property • The 'letter-spacing' property
CSS Writing Modes `CSSWM$r

次の特色機能が定義される:

  • `direction!p ~prop
  • `unicode-bidi!p ~prop
  • 次の各種 概念
    • `塊~flow方向!
    • `塊~size!
    • `行内~size!
    • `塊始端!
    • `塊終端!
    • `行内始端!
    • `行内終端!
    • `行左端!
    • `行右端!
◎ The following features are defined in the CSS Writing Modes specification: [CSSWM] • The 'direction' property • The 'unicode-bidi' property • The block flow direction, block size, inline size, block-start, block-end, inline-start, inline-end, line-left, and line-right concepts
CSS Basic User Interface `CSSUI$r

次の特色機能が定義される:

  • `outline!p ~prop
  • `cursor!p ~prop
  • `appearance!p ~prop
◎ The following features are defined in the CSS Basic User Interface specification: [CSSUI] • The 'outline' property • The 'cursor' property • The 'appearance' property
CSS Object Model `CSSOM$r, `CSSOMVIEW$r

~scriptingを~supportする実装は、 CSSOM ( CSS Object Model )を~supportし~MUST。 次の各種 特色機能, 用語は CSSOM の各~仕様にて定義される:

  • `Screen!I ~interface
  • `LinkStyle!I ~interface
  • `CSSStyleDeclaration!I ~interface, および その:
    • `cssText!m 属性
  • `StyleSheet!I ~interface
  • `~CSS~stylesheetを作成する!
  • `~CSS~stylesheetを除去する!
  • `結付けられている~CSS~stylesheet!
  • `~CSS~stylesheet!, および その各種~prop:
    • `種別!ss
    • `所在!ss
    • `親~CSS~stylesheet!ss
    • `所有者~node!ss
    • `所有者~CSS規則!ss
    • `媒体!ss
    • `~title!ss
    • `代替~flag!ss
    • `不能化~flag!ss
    • `~CSS規則!ss
    • `origin-clean ~flag!ss
  • `~CSS~stylesheet集合!
  • `~CSS~stylesheet集合~名!
  • `選好~CSS~stylesheet集合~名!
  • `選好~CSS~stylesheet集合~名を変更する!
  • `~CSS値の直列化法!
  • `~resize手続き!
  • `~scroll手続き!
  • `媒体~queryを評価して変化を報告する!
  • `要素を~view内に~scrollする!
  • `文書の開始位置に~scrollする!
  • `resize!et ~event
  • `scroll!et ~event
  • `閲覧文脈の特色機能を設定しておく!
◎ Implementations that support scripting must support the CSS Object Model. The following features and terms are defined in the CSSOM specifications: [CSSOM] [CSSOMVIEW] • Screen interface • LinkStyle interface • CSSStyleDeclaration interface • cssText attribute of CSSStyleDeclaration • StyleSheet interface • The terms create a CSS style sheet, remove a CSS style sheet, and associated CSS style sheet • CSS style sheets and their properties: type, location, parent CSS style sheet, owner node, owner CSS rule, media, title, alternate flag, disabled flag, CSS rules, origin-clean flag • CSS style sheet set • CSS style sheet set name • preferred CSS style sheet set name • change the preferred CSS style sheet set name • Serializing a CSS value • run the resize steps • run the scroll steps • evaluate media queries and report changes • Scroll an element into view • Scroll to the beginning of the document • The resize event • The scroll event • set up browsing context features
CSS Syntax `CSSSYNTAX$r

次の各種 特色機能, 用語が定義される:

  • `成分~値の~comma区切りの~listを構文解析する!
  • `成分~値!
  • `環境~符号化方式!
  • `whitespace-token!t
◎ The following features and terms are defined in the CSS Syntax specifications: [CSSSYNTAX] • Parse a comma-separated list of component values • component value • environment encoding • <whitespace-token>
Selectors `SELECTORS$r

次の用語が定義される:

  • `型~選択子!
  • `属性~選択子!
  • `疑似類!
◎ The following terms are defined in the Selectors specification: [SELECTORS] • type selector • attribute selector • pseudo-class
CSS Values and Units `CSSVALUES$r

次の用語が定義される:

  • `length!t
  • `em!css 単位
  • `ex!css 単位
  • `vw!css 単位
  • `in!css 単位
  • `px!css 単位
  • `attr()!css 関数
  • `calc()!css 関数
◎ The following features are defined in the CSS Values and Units specification: [CSSVALUES] • <length> • The 'em' unit • The 'ex' unit • The 'vw' unit • The 'in' unit • The 'px' unit • The 'attr()' function • The 'calc()' function
CSS Style Attributes `CSSATTR$r

次の用語が定義される:

  • `~CSS~styling属性! `CSSATTR$r
◎ The term CSS styling attribute is defined in the CSS Style Attributes specification. [CSSATTR]
CSS Cascading and Inheritance `CSSCASCADE$r

次の用語が定義される:

  • `指定値!
  • `算出値!
  • `使用値!
◎ The following terms are defined in the CSS Cascading and Inheritance specification: [CSSCASCADE] • specified value • computed value • used value

`CanvasRenderingContext2D$I ~objによる~fontの利用は、特に次の特色機能に依存する:

  • `FontFace@I `CSSFONTS$r
  • `~font~source! `CSSFONTLOAD$r
◎ The CanvasRenderingContext2D object's use of fonts depends on the features described in the CSS Fonts and Font Loading specifications, including in particular FontFace objects and the font source concept. [CSSFONTS] [CSSFONTLOAD]
Geometry Interfaces Module `GEOMETRY$r

次の各種~interface, 用語が定義される:

  • `DOMMatrix!I ~interface
  • `DOMMatrixInit!I ~interface
  • `DOMMatrix^I を `DOMMatrixInit^I `辞書から作成する~algo!
◎ The following interfaces and terms are defined in the Geometry Interfaces Module specification: [GEOMETRY] • DOMMatrix interface • DOMMatrixInit interface • The create a DOMMatrix from a dictionary algorithm for DOMMatrixInit
Intersection Observer `INTERSECTIONOBSERVER$r

次の用語は、 Intersection Observer 仕様にて定義される: ◎ The following term is defined in the Intersection Observer specification: [INTERSECTIONOBSERVER]

  • `intersection observations 手続き! ◎ run the update intersection observations steps
WebGL `WEBGL$r

次の~interfaceは、 WebGL 仕様にて定義される: ◎ The following interface is defined in the WebGL specification: [WEBGL]

  • `WebGLRenderingContext!I ~interface
WebVTT `WEBVTT$r
実装は、媒体~資源に対する[ ~subtitle, ~caption, ~chapter~title, ~metadata, 等々 ]に対する~text~track形式として,~WebVTTを~supportしてよい。 ◎ Implementations may support WebVTT as a text track format for subtitles, captions, chapter titles, metadata, etc, for media resources. [WEBVTT]

次の各種~用語は、~WebVTT仕様にて定義され,この仕様にて利用される:

  • `~WebVTT~file!
  • `~cue~textを利用する~WebVTT~file!
  • `~chapter~title~textを利用する~WebVTT~file!
  • `入子の~cueのみを利用する~WebVTT~file!
  • `~WebVTT構文解析器!
  • `~WebVTT~text~trackの表示を更新する規則!
  • `~WebVTT~text~track~cueの書字方向!
  • `VTTCue!I ~interface
◎ The following terms, used in this specification, are defined in the WebVTT specification: • WebVTT file • WebVTT file using cue text • WebVTT file using chapter title text • WebVTT file using only nested cues • WebVTT parser • The rules for updating the display of WebVTT text tracks • The WebVTT text track cue writing direction • VTTCue interface
WebSocket ~protocol `WSP$r

次の用語は、WHATWG Fetch 標準 `FETCH$r にて定義される:

  • `~WebSocket接続を確立する!
◎ The following terms are defined in the WHATWG Fetch standard: [FETCH] • establish a WebSocket connection

次の各種~用語は、 WebSocket ~protocol仕様にて定義される:

  • `~WebSocket接続は確立された@
  • `利用-中の拡張@
  • `利用-中の下位protocol@
  • `~WebSocket~messageは受信された@
  • `~WebSocket~messageを送信する@
  • `~WebSocket接続に失敗した@
  • `~WebSocket接続を~closeする@
  • `~WebSocket~closing~handshakeを開始する@
  • `~WebSocket~closing~handshakeは開始された@
  • `~WebSocket接続は~closeされた(場合によっては clean に )@
  • `~WebSocket接続~close~code@
  • `~WebSocket接続~close事由@
  • `Sec-WebSocket-Protocol@h ~header
◎ The following terms are defined in the WebSocket protocol specification: [WSP] • the WebSocket connection is established • extensions in use • subprotocol in use • a WebSocket message has been received • send a WebSocket Message • fail the WebSocket connection • close the WebSocket connection • start the WebSocket closing handshake • the WebSocket closing handshake is started • the WebSocket connection is closed (possibly cleanly) • the WebSocket connection close code • the WebSocket connection close reason • Sec-WebSocket-Protocol field
ARIA `ARIA$r

`role@a 属性は ARIA 仕様にて定義される。 次の~roleがある:

  • `button!v
  • `presentation!v
◎ The role attribute is defined in the ARIA specification, as are the following roles: [ARIA] • button • presentation

加えて、次の `aria-*@a 内容~属性も ARIA 仕様にて定義される:

  • `aria-describedby!a
  • `aria-disabled!a
  • `aria-label!a
◎ In addition, the following aria-* content attributes are defined in the ARIA specification: [ARIA] • aria-describedby • aria-disabled • aria-label

最後に,次の用語も ARIA 仕様にて定義される:

  • `~access可能な名前!
◎ Finally, the following terms are defined in the ARIA specification: [ARIA] • accessible name
~CSP( Content Security Policy ) `CSP$r
  • `~CSP!( Content Security Policy )
  • `~CSP指令!
  • `~CSP構文!
  • `施策を施行する!
  • `直列形の~CSPを構文解析する! ~algo
  • `大域~objの~CSP~listを初期化する! ~algo
  • `文書の~CSP~listを初期化する! ~algo
  • `要素の~inlineによる挙動は~CSPにより阻止されるべきか?! ~algo
  • `~sourceから~targetを~navigateするある種別の要請は~CSPにより阻止されるべきか?! ~algo
  • `~sourceから~targetを~navigateするある種別の要請に対する応答は~CSPにより阻止されるべきか?! ~algo
  • `report-uri!dir 指令
  • `EnsureCSPDoesNotBlockStringCompilation!jA 抽象演算
  • `文書に対する基底~URLは許容されるか?! ~algo
  • `frame-ancestors!dir 指令
  • `sandbox!dir 指令
  • `要素は~CSPにより先天的に阻止されるべきか?! ~algo
◎ The following terms are defined in Content Security Policy: [CSP] • Content Security Policy • Content Security Policy directive • The Content Security Policy syntax • enforce the policy • The parse a serialized Content Security Policy algorithm • The Initialize a global object's CSP list algorithm • The Initialize a Document's CSP list algorithm • The Should element's inline behavior be blocked by Content Security Policy? algorithm • The Should navigation request of type from source in target be blocked by Content Security Policy? algorithm • The Should navigation response to navigation request of type from source in target be blocked by Content Security Policy? algorithm • The report-uri directive • The EnsureCSPDoesNotBlockStringCompilation abstract operation • The Is base allowed for Document? algorithm • The frame-ancestors directive • The sandbox directive • The Should element be blocked a priori by Content Security Policy? algorithm
Service Workers `SW$r

次の各種~用語は、 Service Workers にて定義される:

  • `作動中の~worker!
  • `~client~message待行列!
  • `制御-!
  • `~fetchを取扱う!
  • `~sw登録に合致-!
  • `~scope~url!
  • `~script~url!
  • `~sw!
  • `~sw~client!
  • `~sw登録!
  • `~sw種別!
  • `~serviceworker~link!
  • `ServiceWorker!I ~interface
  • `ServiceWorkerContainer!I ~interface
  • `~cacheを利用!
◎ The following terms are defined in Service Workers: [SW] • active worker • client message queue • control • handle fetch • match service worker registration • scope url • script url • service worker • service worker client • service worker registration • service worker type • serviceworker link • ServiceWorker interface • ServiceWorkerContainer interface • use cache
Secure Contexts `SECURE-CONTEXTS$r

次の各種~用語は、Secure Contexts にて定義される:

  • `環境~設定群~objは保安的~文脈か?!
  • `非保安的~文脈!
  • `保安的~文脈!
◎ The following term is defined in Secure Contexts: [SECURE-CONTEXTS] • Is environment settings object a secure context? • non-secure context • secure context
Payment Request API `PAYMENTREQUEST$r

次の特色機能は、 Payment Request API 仕様にて定義される:

  • `PaymentRequest!I ~interface
◎ The following feature is defined in the Payment Request API specification: [PAYMENTREQUEST] • PaymentRequest interface
MathML `MathML$r
この仕様では MathML 全体の~supportは要求されないが(少なくとも~Web~browserには奨励されるが)、ある種の特色機能は, MathML のいくつかの部分が実装されることに依存する。 ◎ While support for MathML as a whole is not required by this specification (though it is encouraged, at least for Web browsers), certain features depend upon small parts of MathML being implemented. [MATHML]

次の各種~要素は MathML 仕様にて定義される:

  • `annotation-xml!e
  • `math!e
  • `merror!e
  • `mi!e
  • `mn!e
  • `mo!e
  • `ms!e
  • `mtext!e
◎ The following features are defined in the MathML specification: • MathML annotation-xml element • MathML math element • MathML merror element • MathML mi element • MathML mn element • MathML mo element • MathML ms element • MathML mtext element
SVG `SVG$r `SVGTINY12$r `SVG2$r
この仕様では SVG 全体の~supportは要求されないが(少なくとも~Web~browserには奨励されるが)、ある種の特色機能は, SVG のいくつかの部分が実装されることに依存する。 ◎ While support for SVG as a whole is not required by this specification (though it is encouraged, at least for Web browsers), certain features depend upon parts of SVG being implemented.
また, SVG 仕様には現実の実装を反映していない部分があり、現実には SVG 1.1, SVG Tiny 1.2 のある部分が実装されている。 実装にとっては,進捗中の SVG 2 仕様が より現実に近い~~目標になるものと~~期待されているが、その仕様が熟するまでは, SVG を実装する~UAは、以下に挙げる`故意的な違反$, および追加に従わ~MUST: ◎ Also, the SVG specifications do not reflect implementation reality. Implementations implement subsets of SVG 1.1 and SVG Tiny 1.2. Although it is hoped that the in-progress SVG 2 specification is a more realistic target for implementations, until that specification is ready, user agents that implement SVG must do so with the following willful violations and additions. [SVG] [SVGTINY12] [SVG2]

SVG を実装する~UAは、次の SVG 1.1 特色機能を実装しては~MUST_NOT:

  • `tref^e 要素
  • `cursor^e 要素(代わりに~CSSの `cursor^p ~propを利用すること)
  • 次に挙げる,~fontを定義する各種 SVG 要素(代わりに~CSSの `font-face^at を利用すること):
    • `font^e
    • `glyph^e
    • `missing-glyph^e
    • `hkern^e
    • `vkern^e
    • `font-face^e
    • `font-face-src^e
    • `font-face-uri^e
    • `font-face-format^e
    • `font-face-name^e
  • `externalResourcesRequired^a 属性
  • `enable-background^p ~prop
  • `contentScriptType^a 属性(代わりに SVG `~script0^e 要素~上の `type^a 属性を利用すること)
  • `contentStyleType^a 属性(代わりに SVG `style^e 要素~上の `type^a 属性を利用すること)
◎ User agents that implement SVG must not implement the following features from SVG 1.1: • The tref element • The cursor element (use CSS's cursor property instead) • The font-defining SVG elements: font, glyph, missing-glyph, hkern, vkern, font-face, font-face-src, font-face-uri, font-face-format, and font-face-name (use CSS's @font-face instead) • The externalResourcesRequired attribute • The enable-background property • The contentScriptType and contentStyleType attributes (use the type attribute on the SVG script and style elements instead)

SVG を実装する~UAは、次の SVG Tiny 1.2 特色機能を実装し~MUST:

  • `vector-effect^p ~propに対する `non-scaling-stroke^v 値
  • `class^a 属性は、すべての SVG 要素~上に許容される。
  • `tabindex^a 属性は、可視の SVG 要素~上に許容される。
  • ARIA による~accessibilityのための各種~属性は、すべての SVG 要素~上に許容される。
◎ User agents that implement SVG must implement the following features from SVG Tiny 1.2: • The non-scaling-stroke value for the vector-effect property • The class attribute is allowed on all SVG elements • The tabindex attribute is allowed on visible SVG elements • The ARIA accessibility attributes are allowed on all SVG elements

次の各種~特色機能は、 SVG 仕様にて定義される:

  • `SVGImageElement!I ~interface
  • `SVGScriptElement!I ~interface
  • `SVGSVGElement!I ~interface
  • `desc!e 要素
  • `foreignObject!e 要素
  • `image!e 要素
  • `~script0!e 要素
  • `svg!e 要素
  • `title!e 要素
  • `use!e 要素
◎ The following features are defined in the SVG specifications: • SVGImageElement interface • SVGScriptElement interface • SVGSVGElement interface • SVG desc element • SVG foreignObject element • SVG image element • SVG script element • SVG svg element • SVG title element • SVG use element
Filter Effects `FILTERS$r

次の用語は、 Filter Effects にて定義される:

  • `filter-function-list!t
◎ The following feature is defined in the Filter Effects specification: • <filter-function-list>

この仕様は、特定0の[ ~network~protocol, ~stylesheet言語, ~scripting言語 ], あるいは ~DOM仕様において上に挙げたものから要求されていない部分に対する~supportは、要求しない。 しかしながら,この仕様にて記述される言語は、[ ~styling言語として ~CSS, ~scripting言語として ~JS, ~network~protocolとして~HTTP ]に偏向している。 いくつかの特色機能は、それらの言語や~protocolが利用-中にあるものと見做している。 ◎ This specification does not require support of any particular network protocol, style sheet language, scripting language, or any of the DOM specifications beyond those required in the list above. However, the language described by this specification is biased towards CSS as the styling language, JavaScript as the scripting language, and HTTP as the network protocol, and several features assume that those languages and protocols are in use.

~HTTP~protocolを実装する~UAは、 `HTTP State Management Mechanism^cite ( Cookies ) も実装し~MUST。 `HTTP$r `COOKIES$r ◎ A user agent that implements the HTTP protocol must implement HTTP State Management Mechanism (Cookies) as well. [HTTP] [COOKIES]

注記: この仕様は、[ `文字~符号化方式$, 画像~形式, 音声~形式, 動画~形式 ]に対し,対応する節にて一定の要件を追加することもある。 ◎ This specification might have certain additional requirements on character encodings, image formats, audio formats, and video formats in the respective sections.

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に中立的な拡張が必要されるときは、それに則って,この仕様が更新されるか,この仕様の要件を上書きするような拡張~仕様が記され得る。 自身の活動にこの仕様を適用している誰かが、そのような拡張~仕様の要件を認めるものと決めたとき、それは,この仕様に対する適合性~要件の目的0において `適用し得る仕様@ になる。 ◎ 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が皆の目的0に適合であることを実際に意味するものではない。 他の誰かが,その仕様を自身の仕事に適用しないものと決めたなら、その誰かは,全く正当に[ 前述の~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:

  • ~DOM処理器においては、それらを~DOM内に残すこと。
  • ~CSS処理器においては、~CSSに則ってそれらに~styleをあてがうこと。
  • それらから いかなる意味も推定しないこと。
◎ User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and 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名前空間を[ 要素に対する既定の名前空間 ]として利用することに等価である。 それは、次が欲されることが動機にある:

  • 実装が旧来の~HTML内容と互換であり続けること。
  • この仕様により~HTMLに導入される,~HTML要素に利用される名前空間に関する変更点を~supportすること。
  • XPath 2.0 ではなく XPath 1.0 を利用すること。
◎ 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 have implementations be compatible with legacy HTML content while still supporting the changes that this specification introduces to HTML regarding the namespace used for HTML elements, and 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:

  • 要素の名前空間を`~HTML名前空間$に変更する
  • 要素の局所~名を`~ASCII小文字~化$する
  • 要素~上のどの属性 %A に対しても、 %A が名前空間に属さないならば, %A の名前を`~ASCII小文字~化$する。
◎ If the transformation program outputs an element in no namespace, the processor must, prior to constructing the corresponding DOM element node, change the namespace of the element to the HTML namespace, ASCII-lowercase the element's local name, and 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処理器は:

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

この仕様は、次については指定しない:

  • ~XSLTと`~navi$~algoとが,どう相互作用するか。
  • ~XSLTが`~event~loop$内にどう収まるか。
  • ~error頁がどう取扱われることになるか(例:~XSLT~errorは,~XSLTによる増分的~出力を置換するのか, ~inlineに具現化されるのか, 等々)。
◎ This specification does not specify how XSLT interacts with the navigation algorithm, how it fits in with the event loop, nor 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 the interaction of XSLT and HTML in the script element section, and of XSLT, XPath, and HTML in the template element section.