1. 2 共通インフラ
    1. 2.1 用語
      1. 2.1.1 Parallelism
      2. 2.1.2 リソース
      3. 2.1.3 XML互換性
      4. 2.1.4 DOMツリー
      5. 2.1.5 スクリプティング
      6. 2.1.6 プラグイン
      7. 2.1.7 文字エンコーディング
      8. 2.1.8 Conformance classes
      9. 2.1.9 依存関係
      10. 2.1.10 拡張性
      11. 2.1.11 Interactions with XPath and XSLT
    2. 2.2 ポリシー制御機能

2 共通インフラ

この仕様は、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のような用語が時に使用されるかもしれない。これらの用語は、視覚メディアを意味するものではない。同等の方法で、他のメディアに適用されると考えなければならない。

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.

For guidance on writing specifications that leverage parallelism, see Dealing with the event loop from other specifications.

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 リソース

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

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

MPEG-4ビデオファイルは、使用される圧縮形式がサポートされなかったならば、たとえ実装がファイルのメタデータからムービーの寸法を決定することができたとしても、サポートされるフォーマットであると見なされないだろう。

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

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

CSSスタイルシートの場合、そのクリティカルサブリソースは、他のインポートされたスタイルシートによって間接的にインポートされたものも含む、@import規則を通してインポートされた他のスタイルシートであることをここで暫定的に定義する。

この定義は完全に相互運用可能ではない。さらに、一部のユーザーエージェントは、背景画像やウェブフォントなどのリソースをクリティカルサブリソースと見なしているようである。理想的には、CSS Working Groupがこれを定義するだろう。その方面での進捗状況を追跡するには、w3c/csswg-drafts issue #1088を参照のこと。

2.1.3 XML互換性

To ease migration from HTML to XML, user agents conforming to this specification will place elements in HTML in the http://www.w3.org/1999/xhtml namespace, at least for the purposes of the DOM and CSS. 用語"HTML要素"は、XML文書でさえも、その名前空間内の任意の要素を参照する。

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

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

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

2.1.4 DOMツリー

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

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

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

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

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

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

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

2.1.5 スクリプティング

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

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

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

2.1.6 プラグイン

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

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

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

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

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

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.

(This is a tracking vector.) Since different users having different sets of plugins provides a tracking vector that increases the chances of users being uniquely identified, user agents are encouraged to support the exact same set of plugins for each user.

2.1.7 文字エンコーディング

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

2.1.8 Conformance classes

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

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 Web IDL. [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 its nearest article or body element ancestor. However, since an authoring tool is likely unable to determine the difference, an authoring tool is exempt from that requirement. This does not mean, though, that authoring tools can use address elements for any block of italics text (for instance); it just means that the authoring tool doesn't have to verify that when the user uses a tool for inserting contact information for an article element, that the user really is doing that and not inserting something else instead.

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.

(This is a tracking vector.) User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g., to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

For compatibility with existing content and prior specifications, this specification describes two authoring formats: 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 依存関係

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

Infra

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

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

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

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

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

XMLおよび関連仕様

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

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

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


XML名前空間における名前spaceをもつ属性は、Extensible Markup Language (XML)で定義されている。[XML]

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

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

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

URL

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

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

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

HTTPおよび関連仕様

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

次の用語はHTTP State Management Mechanism [COOKIES]で定義される:

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

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

次の用語はStructured Field Values for HTTP [STRUCTURED-FIELDS]で定義される:

次の用語はMIME Sniffing [MIMESNIFF]で定義される:

Fetch

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

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

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

Paint Timing

次の用語はPaint Timing [PAINTTIMING]で定義される:

Navigation Timing

The following terms are defined in Navigation Timing: [NAVIGATIONTIMING]

Long Tasks

次の用語はLong Tasks [LONGTASKS]で定義される:

Web IDL

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

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

Web IDL also defines the following types that are used in Web IDL fragments in this specification:

この仕様における用語投げるは、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]

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

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

JavaScriptをサポートするユーザーエージェントは、ECMAScript Internationalization APIも実装しなければならない。[JSINTL]

User agents that support JavaScript must also implement the Import Assertions proposal. The following terms are defined there, and used in this specification: [JSIMPORTASSERTIONS]

User agents that support JavaScript must also implement the JSON modules proposal. The following terms are defined there, and used in this specification: [JSJSONMODULES]

WebAssembly

次の用語はWebAssembly JavaScript Interface [WASMJS]で定義される:

DOM

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

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

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

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

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

次の機能は、Pointer Events [POINTEREVENTS]で定義される:

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

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

次の機能は、Selection API [SELECTION]で定義される:

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

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

High Resolution Timeは、現在の高解像度の時刻DOMHighResTimeStampのtypedefを提供する。[HRT]

File API

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

Indexed Database API

この仕様は、Indexed Database APIで定義されたインデックス付きデータベーストランザクションを整理するを使用する。[INDEXEDDB]

Media Source Extensions

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

Media Capture and Streams

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

Reporting

次の用語はReporting [REPORTING]で定義される:

XMLHttpRequest

次の機能は、XMLHttpRequest [XHR]で定義される:

Battery Status

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

Media Queries

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

CSSモジュール

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

この仕様が何かを特定のCSS 文法に従って解析することが要求される場合、エラー処理規則を含め、CSS Syntaxの関連するアルゴリズムに従わなければならない。[CSSSYNTAX]

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

To parse a CSS <color> value, given a string input with an optional element element, run these steps:

  1. Let color be the result of parsing input as a CSS <color>. [CSSCOLOR]

  2. If color is failure, then return failure.

  3. If color is 'currentcolor', then:

    1. If element is not given, then set color to opaque black.

    2. Otherwise, set color to the computed value of the 'color' property of element.

  4. Return color.

次の用語および機能は、Cascading Style Sheets (CSS) [CSS]で定義される:

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

次の用語および機能はCSS Box Model [CSSBOX]で定義される:

次の機能はCSS Logical Properties [CSSLOGICAL]で定義される:

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

次の用語はCSS Images [CSSIMAGES]で定義される:

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

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

CSS Backgrounds and Borders [CSSBG]はまた、次のボーダープロパティを定義する:

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

次の機能は、CSS Box Alignment [CSSALIGN]で定義される:

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

次の機能は、CSS Flexible Box Layout [CSSFLEXBOX]で定義される:

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

次の機能は、CSS Grid Layout [CSSGRID]で定義される:

次の用語および機能はCSS Inline Layout [CSSINLINE]で定義される:

次の用語および機能はCSS Intrinsic & Extrinsic Sizing [CSSSIZING]で定義される:

次の機能はCSS Lists and Countersで定義される。[CSSLISTS]

次の機能はCSS Overflowで定義される。[CSSOVERFLOW]

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

次の機能は、CSS Multi-column Layoutで定義される。[CSSMULTICOL]

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

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

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

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

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

アニメーションを更新してイベントを送信するアルゴリズムは、Web Animationsで定義される。[WEBANIMATIONS].

スクリプトをサポートする実装は、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 [GEOMETRY]で定義される:

次の用語はCSS Scoping [CSSSCOPING]で定義される:

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

次の用語はCSS Pseudo-Elements [CSSPSEUDO]で定義される:

The following term is defined in CSS Containment: [CSSCONTAIN]

Intersection Observer

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

WebGL

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

WebGPU

The following interfaces are defined in WebGPU: [WEBGPU]

WebVTT

実装は、メディアリソースの字幕、キャプション、メタデータなどのテキストトラックフォーマットとしてWebVTTをサポートしてもよい。[WEBVTT]

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

WebSocket protocol

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

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

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

role属性は、Accessible Rich Internet Applications (ARIA) [ARIA]で定義されており、次のようなロールがある:

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

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

Content Security Policy

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

Service Workers

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

Secure Contexts

次の用語はSecure Contexts [SECURE-CONTEXTS]で定義される:

Permissions Policy

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

Payment Request API

次の機能は、Payment Request API [PAYMENTREQUEST]で定義される:

MathML

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

次の機能は、Mathematical Markup Language (MathML)で定義される:

SVG

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

SVGを実装するユーザーエージェントは、以前のリビジョンではなく、SVG 2仕様を実装しなければならない。

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

Filter Effects

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

Cooperative Scheduling of Background Tasks

次の機能は、Cooperative Scheduling of Background Tasks [REQUESTIDLECALLBACK]で定義される:

Storage

次の用語は、Storage [STORAGE]で定義される:

Web App Manifest

次の機能は、Web App Manifest [MANIFEST]で定義される:

WebCodecs

The following features are defined in WebCodecs: [WEBCODECS]

WebDriver BiDi

The following terms are defined in WebDriver BiDi: [WEBDRIVERBIDI]

UUID

The following terms are defined in uuid: [UUID]


この仕様は、特定のネットワークプロトコル、スタイルシート言語、スクリプト言語、または上記のリストで要求されているもの以外のあらゆるDOM仕様のサポートを要求しない。しかし、この仕様で記載される言語は、スタイル言語としてCSS、スクリプト言語としてJavaScript、およびネットワークプロトコルとしてHTTPに偏っており、そして複数の機能は、これらの言語およびプロトコルが使用されることを前提とする。

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

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

2.1.10 拡張性

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

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

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 update 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.2 ポリシー制御機能

この文書では、次のポリシー制御機能を定義している:

Headers/Feature-Policy/autoplay

Firefox🔰 65+SafariNoChrome64+
Opera51+Edge79+
Edge (Legacy)NoInternet ExplorerNo
Firefox Android🔰 65+Safari iOSNoChrome Android64+WebView Android64+Samsung Internet9.0+Opera Android47+

Headers/Feature-Policy/document-domain

Firefox🔰 65+SafariNoChrome77+
Opera64+Edge79+
Edge (Legacy)NoInternet ExplorerNo
Firefox Android🔰 65+Safari iOSNoChrome AndroidNoWebView AndroidNoSamsung InternetNoOpera AndroidNo