HTML

Living Standard — Last Updated 17 December 2024

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タイプで分類されるリソースを示す。

簡潔さのために、文書がユーザーにレンダリングされる方法を参照するとき、（原文で）shown、displayed、visibleのような用語が時に使用されるかもしれない。これらの用語は、視覚メディアを意味するものではない。同等の方法で、他のメディアに適用されると考えなければならない。

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.

2.1.2 リソース

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

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

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

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

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

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

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

2.1.3 XML互換性

HTMLからXMLへの移行を容易にするため、この仕様に適合するユーザーエージェントは、少なくともDOMとCSSのために、HTMLにおける要素をhttp://www.w3.org/1999/xhtml名前空間に配置する。用語"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すら含まない）。

An HTML element can have specific HTML element insertion steps, HTML element post-connection steps, and HTML element removing steps, all defined for the element's local name.

The insertion steps for the HTML Standard, given insertedNode, are defined as the following:

1. If insertedNode is an element whose namespace is the HTML namespace, and this standard defines HTML element insertion steps for insertedNode's local name, then run the corresponding HTML element insertion steps given insertedNode.

2. If insertedNode is a form-associated element or the ancestor of a form-associated element, then:

   1. If the form-associated element's parser inserted flag is set, then return.

   2. Reset the form owner of the form-associated element.

3. If insertedNode is an Element that is not on the stack of open elements of an HTML parser, then process internal resource links given insertedNode's node document.

The post-connection steps for the HTML Standard, given insertedNode, are defined as the following:

1. If insertedNode is an element whose namespace is the HTML namespace, and this standard defines HTML element post-connection steps for insertedNode's local name, then run the corresponding HTML element post-connection steps given insertedNode.

The removing steps for the HTML Standard, given removedNode and oldParent, are defined as the following:

1. Let document be removedNode's node document.

2. If document's focused area is removedNode, then set document's focused area to document's viewport, and set document's relevant global object's navigation API's focus changed during ongoing navigation to false.

   This does not perform the unfocusing steps, focusing steps, or focus update steps, and thus no blur or change events are fired.

3. If removedNode is an element whose namespace is the HTML namespace, and this standard defines HTML element removing steps for removedNode's local name, then run the corresponding HTML element removing steps given removedNode and oldParent.

4. If removedNode is a form-associated element or the ancestor of a form-associated element, then:

   1. If the form-associated element has a form owner and the form-associated element and its form owner are no longer in the same tree, then reset the form owner of the form-associated element.

5. If removedNode's popover attribute is not in the no popover state, then run the hide popover algorithm given removedNode, false, false, and false.

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

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

ノードは、そのノードが接続されており、かつそのノードのシャドウを含むルートのブラウジングコンテキストが非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.

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

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 依存関係

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.

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

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

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

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

• "autoplay"。これは'self'のデフォルト許可リストを持つ。
• "cross-origin-isolated"。これは'self'のデフォルト許可リストを持つ。