1. 2 共通インフラ
    1. 2.1 用語
      1. 2.1.1 Parallelism
      2. 2.1.2 Resources
      3. 2.1.3 XML compatibility
      4. 2.1.4 DOM trees
      5. 2.1.5 Scripting
      6. 2.1.6 Plugins
      7. 2.1.7 Character encodings
      8. 2.1.8 Conformance classes
      9. 2.1.9 Dependencies
      10. 2.1.10 Extensibility
      11. 2.1.11 Interactions with XPath and XSLT
    2. 2.3 大文字・小文字区別と文字列の比較

2 共通インフラ

この仕様は、WHATWG Infra標準に依存する。[INFRA]

2.1 用語

この仕様は、多くの場合、同じ文脈においてHTMLおよびXMLの属性とIDL属性の両方に言及する。どの属性について言及されているかが不明瞭な場合、HTMLおよびXML属性のコンテンツ属性、およびIDLインターフェイスに定義されるIDL属性として言及される。同様に、用語"プロパティ"は、JavaScriptのオブジェクトプロパティとCSSプロパティの両方に使用される。プロパティが不明瞭の場合、それぞれオブジェクトプロパティおよびCSSプロパティとして修飾される。

一般に、ある機能がHTML構文またはXML構文の一方に当てはまると仕様が言及する場合、他方を含む。機能が2つの言語の1つのみ明確に当てはまる場合、"HTMLに対して…(これはXMLに適用されない)"のように、他方の形式に適用されないことが明示的に示される。

この仕様は、短い静的な文書からリッチなマルチメディアを伴う長いエッセイやレポートだけでなく、本格的な対話型アプリケーションにまで至る、HTMLの任意の用法を表す用語文書を使用する。この用語は、文脈に応じてDocumentオブジェクトおよびその子孫DOMツリー、HTML構文またはXML構文を用いてシリアル化されたバイトストリームの両方を表すために使用される。

DOM構造の文脈において、用語HTML文書およびXML文書は、DOM仕様で定義されるとおりに使用され、Documentオブジェクトが自分自身を見つけることができる2つの異なるモードを表す。[DOM](このような用途は常に定義にハイパーリンクされる。)

バイトストリームの文脈において、用語HTML文書は、text/htmlとして分類されたリソースを指し、用語XML文書は、XML MIMEタイプで分類されるリソースを指す。


簡潔さのために、文書がユーザーに表示される方法を参照する際、(原文でいう)showndisplayedvisibleのような用語が時に使用されるかもしれない。これらの用語は、視覚メディアを意味するものではない。同等の方法で、他のメディアに適用されると考えなければならない。

Transparent black refers to the color with red, green, blue, and alpha channels all set to zero.

2.1.1 Parallelism

To run steps in parallel means those steps are to be run, one after another, at the same time as other logic in the standard (e.g., at the same time as the event loop). This standard does not define the precise mechanism by which this is achieved, be it time-sharing cooperative multitasking, fibers, threads, processes, using different hyperthreads, cores, CPUs, machines, etc. By contrast, an operation that is to run immediately must interrupt the currently running task, run itself, and then resume the previously running task.

To avoid race conditions between different in parallel algorithms that operate on the same data, a parallel queue can be used.

A parallel queue represents a queue of algorithm steps that must be run in series.

A parallel queue has an algorithm queue (a queue), initially empty.

To enqueue steps to a parallel queue, enqueue the algorithm steps to the parallel queue's algorithm queue.

To start a new parallel queue, run the following steps:

  1. Let parallelQueue be a new parallel queue.

  2. Run the following steps in parallel:

    1. While true:

      1. Let steps be the result of dequeueing from parallelQueue's algorithm queue.

      2. If steps is not nothing, then run steps.

      3. Assert: running steps did not throw an exception, as steps running in parallel are not allowed to throw.

      Implementations are not expected to implement this as a continuously running loop. Algorithms in standards are to be easy to understand and are not necessarily great for battery life or performance.

  3. Return parallelQueue.

Steps running in parallel can themselves run other steps in in parallel. E.g., inside a parallel queue it can be useful to run a series of steps in parallel with the queue.

Imagine a standard defined nameList (a list), along with a method to add a name to nameList, unless nameList already contains name, in which case it rejects.

The following solution suffers from race conditions:

  1. Let p be a new promise.

  2. Run the following steps in parallel:

    1. If nameList contains name, reject p with a TypeError and abort these steps.

    2. Do some potentially lengthy work.

    3. Append name to nameList.

    4. Resolve p with undefined.

  3. Return p.

Two invocations of the above could run simultaneously, meaning name isn't in nameList during step 2.1, but it might be added before step 2.3 runs, meaning name ends up in nameList twice.

Parallel queues solve this. The standard would let nameListQueue be the result of starting a new parallel queue, then:

  1. Let p be a new promise.

  2. Enqueue the following steps to nameListQueue:

    1. If nameList contains name, reject p with a TypeError and abort these steps.

    2. Do some potentially lengthy work.

    3. Append name to nameList.

    4. Resolve p with undefined.

  3. Return p.

The steps would now queue and the race is avoided.

2.1.2 Resources

仕様は、ユーザーエージェントが外部リソースのセマンティックスをデコード可能な実装を持つかどうかを参照する場合に用語サポートされるを使用する。フォーマットまたはタイプは、重要なリソースの機能を無視されることなく、実装がそのフォーマットやタイプの外部リソースを処理できる場合はサポートされると言われる。特定のリソースがサポートされるかどうかは、リソースのフォーマットのどの機能が使用されるかに依存するだろう。

たとえば、たとえ実装の知らないうちに、画像がアニメーションデータを含む場合でも、画像のピクセルデータがデコードされレンダリングされるならば、PNG画像はサポートされるフォーマットであると見なされるだろう。

たとえ実装がファイルのメタデータからムービーの寸法を決定可能でも、使用される圧縮形式がサポートされていなかった場合、MPEG-4ビデオファイルはサポートされるフォーマットであるとみなされない。

特にHTTP仕様において、一部の仕様がrepresentationと表されるものは、この仕様でリソースとして表される。[HTTP]

リソースのクリティカルサブリソースは、リソースが正しく処理されるために使用できる状態にしておく必要があるものである。どのリソースがクリティカルかどうかとみなされるかは、リソースのフォーマットを定義する仕様によって定義されない。

2.1.3 XML compatibility

HTMLからXMLへの移行を容易にするため、この仕様に準拠するユーザーエージェントは、少なくともDOMとCSSのために、http://www.w3.org/1999/xhtml名前空間にHTMLで要素を配置する。用語"HTML要素"は、XML文書でさえも、その名前空間内の任意の要素を指す。

他に記載される場合を除き、この仕様で定義または記載されるすべての要素はHTML名前空間("http://www.w3.org/1999/xhtml")であり、この仕様で定義または記載されるすべての属性は名前空間を持たない。

用語要素タイプは、与えられたローカル名と名前空間を持つ要素の集合を参照するために使用される。たとえば、button要素は要素型buttonをもつ要素であり、ローカル名"button"および(上で定義されるように暗黙のうちに)HTML名前空間を持つことを意味する。

属性名がXMLで定義されたName生成物と一致しかつ、U+003A COLON文字(:)を含まない場合、属性名はXML互換であると言われる。[XML]

2.1.4 DOM trees

ノードが一部の要素または属性が無視されると言われる、または他の値として扱われる、または何か他のものであったかのように扱われる場合、これはDOMになった後の、ノードの処理のみを指す。ユーザーエージェントは、そのような状況でDOMを変化させてはならない。

新しい値が前の値と異なっている場合のみ、コンテンツ属性は値を変更すると言われる。既に持つ属性値を設定することは変更ではない。

用語は、属性値、Textノード、または文字列で使用された場合、テキストの長さがゼロであることを意味する(つまり、制御文字やU+0020 SPACEすら含まない)。

挿入手順が引数としてAで呼び出される場合かつAの新しい親がBであるので、ノードBノードAは挿入される。同様に、除去手順removedNode引数としてAにかつoldParent引数としてBに呼び出される場合に、ノードBからノードAは除去される

挿入手順が引数としてノードに呼び出されかつノードが現在文書ツリー内に存在する場合、ノードは文書内に挿入される。類似の方法で、除去手順が引数としてノードに呼び出されかつノードがもはや文書ツリー内に存在しない場合、ノードは文書から除去される

挿入手順が引数としてノードに呼び出されかつノードが現在接続される場合、ノードは接続される。類似の方法で、除去手順が引数としてノードに呼び出されかつノードがもはや接続されない場合、ノードは切断される

ノードは、ノードが接続されており、かつノードのシャドウを含むルートブラウジングコンテキストを持つ場合に、ブラウジングコンテキスト接続である。ノードは、挿入手順が引数として呼び出され、かつノードが今ブラウジングコンテキスト接続である場合に、ブラウジングコンテキスト接続になる。ノードは、除去手順が引数としてノードを呼び出され、かつノードがもはや現在ブラウジングコンテキスト接続でないか、ノードのシャドウを含むルートがもはやブラウジングコンテキストを持たないかのいずれかの場合、ブラウジングコンテキスト切断になる

2.1.5 Scripting

構造体"Fooオブジェクト"は、Fooが実際にインターフェイスである場合、時折より正確な"Fooインターフェイスを実装するオブジェクト"の代わりに使用される。

IDL属性は、その値が(著者のスクリプトなどによって)取得時に取得されると言われ、新しい値が割り当てられる際に設定されると言われる。

DOMオブジェクトがライブであると言われる場合、そのオブジェクトの属性とメソッドは、データのスナップショットではなく、実際の元となるデータを操作しなければならない。

2.1.6 Plugins

用語プラグインは、Documentオブジェクトの属するユーザーエージェントのレンダリングに関与可能な、ユーザーエージェントによって使用されるコンテンツハンドラーの組に定義されるユーザーエージェントを参照するが、Document子ブラウジングコンテキストとして振る舞うことも、任意のNodeオブジェクトをDocumentのDOMに導入することもない。

通常、そのようなコンテンツハンドラーは、第三者によって提供される。もっともユーザーエージェントもまた、プラグインとしてビルトインコンテンツのハンドラーを指定できる。

ユーザーエージェントは、タイプtext/plainおよびapplication/octet-streamを登録されたプラグインを持つものとして考慮しなければならない。

プラグインの一例は、ユーザーがPDFファイルを操作するときにブラウジングコンテキストでインスタンスを生成されたPDFビューアーであろう。これは、実装されたPDFビューアーコンポーネントがユーザーエージェント自身に実装されたものと同じメーカーかどうかにかかわらず、プラグインとしてカウントされるだろう。しかし、ユーザーエージェント(同じインターフェイスを使用するのではない)とは別に起動するPDFビューアーアプリケーションは、この定義によるプラグインではない。

プラグインはユーザーエージェント固有かつプラットフォーム固有であることが予測されるので、この仕様はプラグインと情報交換するためのメカニズムを定義しない。一部のユーザーエージェントは、NetscapeプラグインAPIのようなプラグイン機構をサポートすることを選ぶかもしれない。他のユーザーエージェントは、リモートコンテンツコンバーターを使用するか、または特定の種類のビルトインサポートを持つかもしれない。実際に、この仕様はユーザーエージェントにプラグインのサポートを一切要求しない。[NPAPI]

sandbox属性のセマンティックスを受け取る場合、プラグインは保護されるだろう。

たとえば、保護されるプラグインは、プラグインがサンドボックス化されるiframe内部でインスタンス化される際、コンテンツがポップアップウィンドウを生成することから防ぐだろう。

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.

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. (This is a fingerprinting vector.)

2.1.7 Character encodings

文字エンコーディング、すなわち曖昧でない箇所で単にエンコーディングは、WHATWGエンコーディング標準で定義されるように、バイトストリームとUnicode文字列との間の変換方法を定義する。エンコーディングは、エンコーディング仕様でエンコーディングの名前およびラベルとして参照される、エンコーディング名および1つ以上のエンコーディングラベルを持つ。[ENCODING]

UTF-16エンコーディングは、UTF-16BEまたはUTF-16LEである。[ENCODING]

ASCII互換エンコーディングは、UTF-16エンコーディングでない任意のエンコーディングである。[ENCODING]

WHATWGエンコーディング標準で定義されないエンコーディングのサポートは禁止されるため、UTF-16エンコーディングは、この仕様がASCII互換エンコーディングでないものとして処理するために必要となる唯一のエンコーディングである。

2.1.8 Conformance classes

This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).

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

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.

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.

User agents fall into several (overlapping) categories with different conformance requirements.

Web browsers and other interactive user agents

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.

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.

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.

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]

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.

Non-interactive presentation user agents

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.

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.

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.

Visual user agents that support the suggested default rendering

User agents, whether interactive or not, may be designated (possibly as a user option) as supporting the suggested default rendering defined by this specification.

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.

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.

User agents with no scripting support

Implementations that do not support scripting (or which have their scripting features disabled entirely) are exempt from supporting the events and DOM interfaces mentioned in this specification. For the parts of this specification that are defined in terms of an events model or in terms of the DOM, such user agents must still act as if events and the DOM were supported.

Scripting 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

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

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])

The term "HTML validator" can be used to refer to a conformance checker that itself conforms to the applicable requirements of this specification.

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. Criteria that can be expressed in a DTD.
  2. 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.

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 tools

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.

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.

Authoring tools and markup generators

Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate.

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.

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.

In terms of conformance checking, an editor has to output documents that conform to the same extent that a conformance checker will verify.

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.

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

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.

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.

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.

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. (This is a fingerprinting vector.)

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.

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.9 Dependencies

この仕様は、複数の基礎をなす仕様に依存する。

Infra

次の用語はWHATWG Infra標準[INFRA]で定義される:

Unicodeおよびエンコーディング

Unicode文字セットは、テキストデータを表すために使用され、WHATWG Encoding標準は、文字エンコーディングを中心とする要件を定義する。[UNICODE]

この仕様は、前述したように、その仕様で定義される用語に基づく用語を導入する

WHATWG Encoding標準[ENCODING]で定義される次の用語が使用される:

XMLおよび関連仕様

その構文が名前空間をもつXMLシリアライゼーションを使用するため、XHL構文をサポートする実装は、いくつかのXMLのバージョンと同様に、対応する名前空間の仕様をサポートしなければならない。[XML] [XMLNS]

データマイニングツールおよび、スクリプトを実行、CSSやXPathを評価、または別の方法で任意のコンテンツにDOMの結果を公開することなく、コンテンツに対する操作を実行するユーザーエージェントは、それらのDOMノードの類似体が実際に名前空間文字列を公開することなく、特定の名前空間であることを相応の主張することによって"名前空間をサポート"してもよい。

HTML構文において、名前空間接頭辞および名前空間宣言は、XMLと同一の効果を持たない。たとえば、HTML要素名においてコロンは特別な意味を持たない。


XML名前空間でタグ名xml:spaceをもつ属性は、XML仕様で定義される。[XML]

Name生成物は、XML仕様で定義される。[XML]

この仕様はまた、Associating Style Sheets with XML documents仕様で定義される、<?xml-stylesheet?>処理命令を参照する。[XMLSSPI]

この仕様はまた、XSLTProcessorインターフェイスとそのtransformToFragment()およびtransformToDocument()メソッドに非規範的に言及する。[XSLTP]

URL

次の用語はWHATWG URL標準[URL]で定義される:

多くのスキーマおよびプロトコルはまたこの仕様で参照される:

メディアフラグメント構文Media Fragments URI仕様で定義される。[MEDIAFRAG]

HTTPおよび関連仕様

次の用語はHTTP仕様[HTTP]で定義される:

次の用語はCookie仕様[COOKIES]で定義される:

  • cookie-string
  • receives a set-cookie-string
  • `Cookie`ヘッダー

次の用語はWeb Linking仕様[WEBLINK]で定義される:

The following terms are defined in the WHATWG MIME Sniffing standard: [MIMESNIFF]

Fetch

次の用語はWHATWG Fetch標準[FETCH]で定義される:

次の用語は、Referrer Policy仕様[REFERRERPOLICY]で定義される:

次の用語は、Mixed Content [MIX]で定義される:

Web IDL

Web IDL仕様に記載されるとおりに、この仕様におけるIDL断片は、適合するIDL断片に要求されるとして解釈されなければならない。[WEBIDL]

次の用語はWeb IDL仕様で定義される:

Web IDL仕様はまた、この仕様においてWeb IDL断片で使用される次の型を定義する:

この仕様における用語投げるは、Web IDL仕様で定義されるとおりに使用される。DOMException型および次の例外名はWeb IDLによって定義されかつこの仕様によって使用される:

この仕様が(特別な値Not-a-Numberであるかもしれない)特定の時間を表すDateオブジェクトを作成することをユーザーエージェントに要求する場合、もしあれば、その時刻のミリ秒コンポーネントは整数に切り捨てられなければならず、新しく作成されるDateオブジェクトの時刻値は、結果として生じる切り捨てられる時刻を表さなければならない。

たとえば、2000年1月1日1時より後の100万分の23045秒の時刻、つまり2000-01-01T00:00:00.023045Zが与えられる場合、時刻を表す作成されたDateオブジェクトは、100万分の45秒早い、時刻2000-01-01T00:00:00.023Zを表す作成されたものと同じ時刻を表す。与えられる時刻がNaNである場合、結果は(オブジェクトが特定の時間の瞬間を表さないことを示す)時刻値NaNを表すDateオブジェクトとなる。

JavaScript

この仕様によって記載される言語の一部は、基礎となるスクリプト言語としてJavaScriptのみをサポートする。[JAVASCRIPT]

Users agents that support JavaScript must also implement the ECMAScript Internationalization API Specification. [JSINTL]

用語JavaScriptはより広く知られているため、用語"JavaScript"は、公式用語ECMAScriptよりもむしろ、ECMA-262を参照するために使用される。同様に、RFC 4329によれば公式に廃止されたタイプであるにもかかわらず、最も一般的に使用されるタイプであるため、この仕様でJavaScriptを参照するために使用されるMIMEタイプは、text/javascriptである。[RFC4329]

次の用語はJavaScript仕様で定義され、この仕様で使用される:

Users agents that support JavaScript must also implement the import() proposal. The following terms are defined there, and used in this specification: [JSIMPORT]

DOM

ドキュメントオブジェクトモデル(DOM)は、文書とそのコンテンツの表現(モデル)である。DOMは単なるAPIではない。HTML実装の適合基準は、DOMに対する操作の観点から、この仕様で定義される。[DOM]

この仕様はDOMの観点で定義され、機能の一部はDOMインターフェイスの拡張機能として定義されるため、実装は、DOMおよびUI Eventsで定義されるイベントをサポートしなければならない。[DOM] [UIEVENTS]

具体的に、次の機能がWHATWG DOM標準[DOM]で定義される:

次の機能は、UI Events仕様[UIEVENTS]で定義される:

次の機能は、Touch Events仕様[TOUCH]で定義される:

The following features are defined in the Pointer Events specification: [POINTEREVENTS]

この仕様は、イベントのタイプを参照するために用語名前(name)を使用することがある。たとえば、"clickと名付けられるイベント"または"イベント名がkeypressである場合"などである。イベントのための用語"名前"と"タイプ"は同義語である。

次の機能は、DOM Parsing and Serialization仕様[DOMPARSING]で定義される:

Selectionインターフェイスは、Selection API仕様で定義される。[SELECTION]

ユーザーエージェントは、execCommand仕様で説明される機能を実装することを勧める。[EXECCOMMAND]

WHATWG Fullscreen API標準[FULLSCREEN]の次の部分は、ある程度dialog要素のレンダリングを定義するために、かつフルスクリーンAPIがHTMLと対話する方法を定義するために、この仕様から参照される:

High Resolution Time仕様は、DOMHighResTimeStampのtypedefおよびPerformanceインターフェイスのnow()メソッドを提供する。[HRT]

File API

この仕様はFile API仕様[FILEAPI]で定義される次の機能を使用する:

Indexed Database API

This specification uses cleanup Indexed Database transactions defined by the Indexed Database API specification. [INDEXEDDB]

Media Source Extensions

次の用語はMedia Source Extensions仕様[MEDIASOURCE]で定義される:

Media Capture and Streams

次の用語はMedia Capture and Streams仕様[MEDIASTREAM]で定義される:

XMLHttpRequest

この仕様は、2つの仕様がどのように相互作用するかを説明し、ProgressEvent機能を使用するためにXMLHttpRequest仕様を参照する。次の機能および用語がXMLHttpRequest仕様[XHR]で定義される:

Battery Status

次の機能は、Battery Status API仕様[BATTERY]で定義される:

Media Queries

実装は、Media Queriesをサポートしなければならない。<media-condition>機能が定義される。[MQ]

CSSモジュール

全体としてのCSSのサポー​​トはこの仕様の実装に必要とされないが(少なくともウェブブラウザー用に奨励されるが)、一部の機能は、特定のCSS要件の観点で定義される。

この仕様が特定のCSSの文法に従って解析されるものを要求する場合、CSS Syntax仕様で関連するアルゴリズムが続かなければならない。[CSSSYNTAX]

具体的に、一部の機能は、CSS <color>値として解析される文字列を要求する。CSS値を解析する際、ユーザーエージェントは、一部のエラー処理規則を適用するためにCSS仕様によって要求される。これはまた、この仕様に適用される。[CSSCOLOR] [CSS]

たとえば、ユーザーエージェントは予期せずスタイルシートの最後を見つけると、開いているすべての構成物を閉じることを要求される。したがって、色値の(閉じ丸括弧の欠損している)文字列"rgb(0,0,0"を解析する場合、閉じ丸括弧はこのエラー処理規則によって暗示され、値は(色'black')を得られる。しかし、(欠損する括弧と欠損する"青"値の両方をもつ類似の構成物"rgb(0,0,"は、開いた構成物を閉じることは実行可能な値をもたらさないため、解析することができない。

次の用語および機能は、CSS仕様[CSS]で定義される:

CSS仕様[CSS]はまた、次のボーダープロパティを定義する:

ボーダープロパティ
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'

用語内在幅および内在高さは、それぞれ、内在次元の幅次元および高さ次元を参照する。

'display'プロパティの基本バージョンはCSS仕様で定義され、プロパティは他のCSSモジュールによって拡張される。[CSS] [CSSRUBY] [CSSTABLE][CSS] [CSSRUBY] [CSSTABLE]

次の用語および機能はCSS Logical Properties仕様[CSSLOGICAL]で定義される:

次の用語および機能はCSS Color仕様[CSSCOLOR]で定義される:

用語paint sourceは、CSS 'element()'関数と特定のHTML要素との相互作用を定義するためにCSS Image Values and Replaced Content仕様で定義されるとおりに使用される。[CSSIMAGES]

用語デフォルトオブジェクトサイズおよび'object-fit'プロパティはまた、CSS Image Values and Replaced Content仕様で定義される。[CSSIMAGES]

次の機能は、CSS Backgrounds and Borders仕様[CSSBG]で定義される:

用語ブロックレベルは、CSS Display仕様で定義される。[CSSDISPLAY]

次の機能は、CSS Fonts仕様[CSSFONTS]で定義される:

'list-style-type'プロパティは、CSS Lists and Counters仕様で定義される。[CSSLISTS]

The 'overflow' property and its 'hidden' value are defined in the CSS Overflow specification. [CSSOVERFLOW]

次の機能は、CSS Positioned Layout仕様[CSSPOSITION]で定義される:

'display'プロパティの'ruby-base'値は、CSS Ruby Layout仕様で定義される。[CSSRUBY]

次の機能は、CSS Table仕様[CSSTABLE]で定義される:

次の機能は、CSS Text仕様[CSSTEXT]で定義される:

次の機能は、CSS Writing Modes仕様[CSSWM]で定義される:

次の機能は、CSS Basic User Interface仕様[CSSUI]で定義される:

スクリプトをサポートする実装は、CSS Object Modelをサポートしなければならない。次の機能は、CSSOM仕様[CSSOM] [CSSOMVIEW]で定義される:

次の機能は、CSS Syntax仕様[CSSSYNTAX]で定義される:

次の機能は、Selectors仕様[SELECTORS]で定義される:

次の機能は、CSS Values and Units仕様[CSSVALUES]で定義される:

用語スタイル属性は、CSS Style Attributes仕様で定義される。[CSSATTR]

次の機能は、CSS Cascading and Inheritance仕様[CSSCASCADE]で定義される:

フォントのCanvasRenderingContext2Dの使用は、具体的にはFontFaceオブジェクトおよびfont sourceコンセプトを含む、CSS FontsおよびFont Loading仕様で説明される機能に依存する。[CSSFONTS] [CSSFONTLOAD]

次のインターフェイスおよび用語は、Geometry Interfaces Module仕様[GEOMETRY]で定義される:

Intersection Observer

次の用語は、Intersection Observer仕様[INTERSECTIONOBSERVER]で定義される:

WebGL

次のインターフェイスは、WebGL仕様[WEBGL]で定義される:

WebVTT

Implementations may support WebVTT as a text track format for subtitles, captions, metadata, etc., for media resources. [WEBVTT]

この仕様で使用される次の用語は、WebVTT仕様で定義される:

WebSocket protocol

次の用語はWHATWG Fetch標準[FETCH]で定義される:

次の用語はWebSocket protocol仕様[WSP]で定義される:

  • WebSocket接続が確立される
  • 使用中の拡張
  • 使用中のサブプロトコル
  • WebSocketメッセージが受信した
  • WebSocketメッセージを送信する
  • WebSocket接続に失敗する
  • WebSocket接続を閉じる
  • WebSocket終了ハンドシェイクを開始する
  • WebSocket終了ハンドシェイクが開始される
  • WebSocket接続は閉じられた(おそらくクリーンに
  • WebSocket接続終了コード
  • WebSocket接続終了理由
  • Sec-WebSocket-Protocolフィールド
ARIA

次のロールのように、role属性はARIA仕様[ARIA]で定義される:

加えて、次のaria-*コンテンツ属性はARIA仕様で定義される[ARIA]

最後に、次の用語がARIA仕様で定義される[ARIA]

Content Security Policy

次の用語は、Content Security Policy仕様[CSP]で定義される:

Service Workers

次の用語はService Workers [SW]で定義される:

Secure Contexts

The following terms are defined in Secure Contexts: [SECURE-CONTEXTS]

Payment Request API

The following feature is defined in the Payment Request API specification: [PAYMENTREQUEST]

MathML

全体としてMathMLに対するサポートは、この仕様によって要求されないが(少なくともウェブブラウザーの場合に奨励されるが)、特定の機能は、実装されている一部のMathMLに依存する。[MATHML]

次の機能はMathML仕様で定義される:

SVG

全体としてSVGに対するサポートは、この仕様によって要求されないが(少なくともウェブブラウザーの場合に奨励されるが)、特定の機能は、実装されている一部のSVGに依存する。

また、SVG仕様は実装の現実を反映していない。実装は、SVG1.1とSVG Tiny 1.2のサブセットを実装している。進行中のSVG2仕様の準備ができるまで、SVG2仕様は実装のためのより現実的な目標であることが期待されるが、SVGを実装するユーザーエージェントは、次の故意の違反および追加を行わなければならない。[SVG] [SVGTINY12] [SVG2]

SVGを実装するユーザーエージェントはSVG 1.1由来の次の機能を実装してはならない:

  • tref要素
  • cursor要素(CSSのcursorプロパティを代わりに使用する)
  • フォント定義SVG要素:font, glyph, missing-glyph, hkern, vkern, font-face, font-face-src, font-face-uri, font-face-format, font-face-name(CSSの@font-faceを代わりに使用する)
  • externalResourcesRequired属性
  • enable-backgroundプロパティ
  • contentScriptTypeおよびcontentStyleType属性(SVG scriptおよびstyle要素のtype属性を代わりに使用する)

SVGを実装するユーザーエージェントはSVG Tiny 1.2由来の次の機能を実装しなければならない:

  • vector-effectプロパティのnon-scaling-stroke
  • class属性は、すべてのSVG要素で許可される
  • tabindex属性は、可視SVG要素で許可される
  • ARIAアクセシビリティー属性は、すべてのSVG要素で許可される

次の機能はSVG仕様で定義される:

Filter Effects

次の機能はFilter Effects [FILTERS]仕様で定義される:

Worklets

The following feature is defined in the Worklets specification: [WORKLETS]


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. しかし、この仕様で記載される言語は、スタイル言語としてCSS、スクリプト言語としてJavaScript、およびネットワークプロトコルとしてHTTPに偏っており、そして複数の機能は、これらの言語およびプロトコルが使用されることを前提とする。

同様に、HTTPプロトコルを実装するユーザーエージェントは、HTTP State Management Mechanism (Cookies)を実装しなければならない。[HTTP] [COOKIES]

この仕様は、それぞれの節で文字エンコーディング、画像フォーマット、オーディオフォーマット、およびビデオフォーマットの特定の追加要件があるかもしれない。

2.1.10 Extensibility

ユーザーエージェントがこの仕様を拡張するベンダー固有のプロパティを強く推奨しない。そうすることは、特定のユーザーエージェントのユーザーだけが当該のコンテンツにアクセスすることができ、相互運用性を減少させユーザーベースを分断するので、文書はそのような拡張を使用してはならない。

All extensions must be defined so that the use of extensions neither contradicts nor causes the non-conformance of functionality defined in the specification.

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.


この仕様にベンダー中立の拡張が必要になった場合、この仕様が状況に応じて更新されうる、または拡張仕様がこの仕様の要求を上書きされうるかのいずれかである。この仕様に自分の活動を適用するある人が、そのような拡張仕様の要件を承認することを決定する場合、拡張仕様はこの仕様における適合性要求の目的に適用可能な仕様になる。

誰かが適合するものとして任意のバイトストリームを定義する仕様を記述することができ、そしてランダムなジャンクが準拠していることを主張することができる。しかし、それはそのランダムなジャンクが皆の目的に実際に適合していることを意味しない。他の誰かがその仕様が自分の仕事に適用されないと判断する場合、彼らは、前述のランダムジャンクがそのもので、ジャンクであり、かつ一切適合しないものであると完全に合法的に言うことはできる。適合性に関する限り、特定のコミュニティーで重要なのは、そのコミュニティーが同意するものが適用可能なことである。


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.

When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient.

2.1.11 Interactions with XPath and XSLT

Spec bugs: 18460

Implementations of XPath 1.0 that operate on HTML documents parsed or created in the manners described in this specification (e.g. as part of the document.evaluate() API) must act as if the following edit was applied to the XPath 1.0 specification.

First, remove this paragraph:

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

Then, insert in its place the following:

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

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

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

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.

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 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:

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.

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]


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.


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

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.

2.3 大文字・小文字区別と文字列の比較

大文字・小文字区別において2つの文字列を比較することは、正確にコードポイントを比較することを意味する。

明記される場合を除き、文字列の比較は大文字・小文字区別の方法で実行されなければならない。

patterns未満でかつpatternの長さにsを切り捨てが、互いにマッチとしての2つの文字列のままにする場合、文字列のpatternは、文字列s接頭辞一致である。