HTML: The Living Standard
Edition for Web Developers — Last Updated 19 April 2024
Edition for Web Developers — Last Updated 19 April 2024
HTMLユーザーエージェントにおいてすべてのXMLおよびHTML文書は、Documentオブジェクトによって表される。[DOM]
DocumentオブジェクトのURLは、DOMで定義される。Documentオブジェクトが作成されたときに初期に設定されるが、Documentオブジェクトの存続期間中に変更されることがある。たとえば、ユーザーがページ上のフラグメントをナビゲートするとき、およびpushState()メソッドが新しいURLとともに呼び出されるときに変更される。[DOM]
対話的なユーザーエージェントは一般にユーザーインターフェイスでDocumentオブジェクトのURLを公開する。これは、サイトが別のものを偽装しようとしているかどうかをユーザーが見分けるための基本のメカニズムである。
Documentオブジェクトのoriginは、DOMで定義される。これは、Documentオブジェクトの作成時に最初に設定され、document.domainを設定した場合にのみ、Documentの存続期間中に変更できる。 Documentの生成元は、そのURLの生成元と異なるかもしれない。たとえば、子ナビゲート可能が作成されるとき、たとえそのアクティブな文書のURLがabout:blankであったとしても、そのアクティブな文書の生成元はその親のアクティブな文書の生成元から継承される。[DOM]
DocumentがcreateDocument()またはcreateHTMLDocument()メソッドを用いたスクリプトで作成される場合、Documentは即座にready for post-load tasksとなる。
文書のリファラーは、Documentが作成されたときに設定できる（URLを表す）文字列である。文書のリファラーが明示的に設定されない場合、値は空文字列である。
DocumentオブジェクトSupport in all current engines.
DOMは、Documentインターフェイスを定義し、この仕様がこれを大幅に拡張する。
各Documentはポリシーコンテナー（ポリシーコンテナー）があり、最初は新しいポリシーコンテナーであり、これはDocumentに適用されるポリシーが含まれている。
各Documentは、パーミッションポリシーを持ち、これはパーミッションポリシーであり、最初は空である。
各Documentは、モジュールマップを持ち、これはモジュールマップであり、最初は空である。
各Documentは生成元をまたいだオープナーポリシーを持ち、これは生成元をまたいだオープナーポリシーであり、最初は新しい生成元をまたいだオープナーポリシーである。
各Documentはis initial about:blankを持ち、これは真偽値で、最初はfalseである。
Each Document has a during-loading navigation ID for WebDriver BiDi, which is a navigation ID or null, initially null.
As the name indicates, this is used for interfacing with the WebDriver BiDi specification, which needs to be informed about certain occurrences during the early parts of the Document's lifecycle, in a way that ties them to the original navigation ID used when the navigation that created this Document was the ongoing navigation. This eventually gets set back to null, after WebDriver BiDi considers the loading process to be finished. [BIDI]
Each Document has an about base URL, which is a URL or null, initially null.
This is only populated for "about:"-schemed Documents.
Each Document has a fire mutation events flag, which is a boolean, initially true.
This is intended to suppress firing of DOM Mutation Events in cases when they would normally fire. The specification describing mutation events is not actively maintained so it does not look at this flag, but implementations are expected to act as though it did. [UIEVENTS]
Each Document has a bfcache blocking details, which is a set of not restored reason details, initially empty.
DocumentOrShadowRootインターフェイスDOMは、DocumentOrShadowRootミックスインを定義し、これはこの仕様が拡張する。
document.referrerユーザーが操作したDocumentのURLを返す。ただしブロックされるあるいはそのような文書がない場合を除く。その場合空文字列を返す。
noreferrerリンク型はリファラーを遮断するために使用されうる。
document. [ = value ]Support in all current engines.
Documentに適用するHTTPクッキーを返す。クッキーが存在しないまたはクッキーがこのリソースに適用されない場合、空文字を返す。
新しいクッキーを要素のHTTPクッキーの集合に設定が可能である。
If the contents are sandboxed into an opaque origin (e.g., in an iframe with the sandbox attribute), a "SecurityError" DOMException will be thrown on getting and setting.
document.lastModifiedユーザーのローカルタイムゾーンで"MM/DD/YYYY hh:mm:ss"由来のサーバーによって報告されるような、文書の最終更新日時を返す。
最終更新日時が不明の場合、代わりに現在の時刻が返される。
Document/DOMContentLoaded_event
Support in all current engines.
document.readyStateDocumentが、いったん解析を完了したがまだサブリソースを読み込んでいる時点で"interactive"を、読み込まれた時点で"complete"を、読み込み中の間"loading"を返す。
readystatechangeイベントは、この値が変更したときにDocumentオブジェクトで発火する。
DOMContentLoadedイベントは、async script要素以外のすべてのサブリソースが読み込まれた時点で、"interactive"に遷移した後で発火するが、"complete"に遷移する前に発火する。
各Documentは、render-blocking element setを持ち、要素のセット、最初は空のセットがある。
documentのコンテンツタイプが"text/html"かつ、documentのbody要素がnullの場合、文書documentではレンダリングブロッキング要素を追加できる。
次の両方がtrueである場合、文書documentはレンダリングブロックされる。
documentのレンダリングブロッキング要素セットが空でない、またはdocumentでレンダリングブロッキング要素を追加できる。
documentの関連するグローバルオブジェクトが指定された現在の高解像度時間は、実装で定義されたタイムアウト値を超えていない。
An element el is render-blocking if el's node document document is render-blocked, and el is in document's render-blocking element set.
To block rendering on an element el:
Let document be el's node document.
If document allows adding render-blocking elements, then append el to document's render-blocking element set.
To unblock rendering on an element el:
Let document be el's node document.
Remove el from document's render-blocking element set.
Whenever a render-blocking element el becomes browsing-context disconnected, or el's blocking attribute's value is changed so that el is no longer potentially render-blocking, then unblock rendering on el.
要素がhtml要素である場合、文書のhtml要素はその文書要素である。そうでなければnullである。
document.headhead要素を返す。
存在するならば、文書のhead要素は、html要素の子である最初のhead要素である。そうでなければnullである。
document.title [ = value ]HTMLに対してtitle要素に与えられるおよびSVGに対してSVG title要素に与えられるものとして、文書のタイトルを返す。
文書のタイトルを更新する設定が可能である。更新する適切な要素が存在しない場合、新しい値は無視される。
存在するならば、文書のtitle要素は文書での（ツリー順で）最初のtitle要素である。そうでなければnullである。
document.body [ = value ]body要素を返す。
body要素を置換する設定が可能である。
新しい値がbodyまたはframeset要素でない場合、これは"HierarchyRequestError" DOMException例外を投げる。
文書のbody要素は、body要素またはframeset要素のいずれのhtml要素の最初の子である。そのような文書が存在しない場合はnullである。
document.imagesDocumentでimg要素のHTMLCollectionを返す。
document.embedsdocument.pluginsDocumentでembed要素のHTMLCollectionを返す。
document.linkshref属性を持つDocumentでaおよびarea要素のHTMLCollectionを返す。
document.formsDocumentでform要素のHTMLCollectionを返す。
document.scriptsDocumentでscript要素のHTMLCollectionを返す。
collection = document.getElementsByName(name)値nameとともにname属性を持つDocumentで要素のNodeListを返す。
document.currentScript要素がクラシックスクリプトを表す限り、現在実行している、script要素またはSVG script要素を返す。再入可能なスクリプト実行の場合には、直近でまだ実行を完了していないものの中で実行を開始しそれを返す。
（たとえば、実行中のスクリプトは、イベントハンドラー、またはタイムアウトであるため）Documentが現在scriptまたはSVG script要素を現在実行していない場合、または現在実行しているscriptまたはSVG scriptがモジュールスクリプトである場合はnullを返す。
このAPIは、APIがグローバルにscriptまたはSVG script要素を公開するので、実装者および標準コミュニティの支持から離れている。それ自身は、モジュールスクリプトを実行する場合またはシャドウツリーにおけるスクリプトを実行する場合など、新しいコンテキストで利用可能ではない。我々はそのようなコンテキストで実行するスクリプトを識別するための新しい解決法を検討している。これはグローバルに利用可能にさせるものではない。issue #1013を参照。
Documentインターフェイス上のdir属性は、dirコンテンツ属性と同様に定義される。
HTMLにおける要素、属性、および属性値は、ある意味（セマンティックス）を持つよう（この仕様によって）定義される。たとえば、ol要素は順序付きのリストを表し、lang属性はコンテンツの言語を表す。
これら定義は、ウェブブラウザーや検索エンジンなどのHTMLプロセッサに、著者が考えてないかもしれないさまざまなコンテキストで文書およびアプリケーションの提示と使用を許可する。
簡単な例として、デスクトップコンピューターのウェブブラウザーのみを考慮した著者によって書かれたウェブページを考えてみる：
<!DOCTYPE HTML>
< html lang = "en" >
< head >
< title > My Page</ title >
</ head >
< body >
< h1 > Welcome to my page</ h1 >
< p > I like cars and lorries and have a big Jeep!</ p >
< h2 > Where I live</ h2 >
< p > I live in a small hut on a mountain!</ p >
</ body >
</ html > HTMLは見栄えよりもむしろ意味を伝えるため、ページを一切変更することなく、同じページが携帯電話上のスモールブラウザーによっても使用できる。たとえば、デスクトップと同様に大きな文字である見出しの代わりに、携帯電話のブラウザーは、ページ全体で同じサイズのテキストを使用するが、太字の見出しを持つかもしれない。
しかし、画面サイズにおける当然の違いよりもさらにいうと、画面上のページを表示する代わりに、同じページが、たとえばヘッドフォンを使用してユーザーにページを読みあげるなど、同等に音声合成ベースのブラウザーを使用する目の不自由なユーザーによって使用される可能性がある。見出し用の大きなテキストの代わりに、音声ブラウザーは異なる音量または遅い音声を使用するかもしれない。
それだけではない。ブラウザーはページのどの部分が見出しであるかを知っているので、"前の見出しにジャンプ"または"次の見出しにジャンプ"キーを使用して、ユーザーが迅速に文書操作するために使用できる文書のアウトラインをブラウザーは作成できる。このような機能は、ユーザーが他の方法で素早くページを操作することが非常に困難な場合に、特に音声ブラウザーでは一般的である。
まさにブラウザーを超えて、ソフトウェアはこの情報を利用できるのである。検索エンジンは、より効果的なインデックスページへ見出しを使用する、あるいはそれらの結果からページのサブセクションへのクイックリンクを提供する。ツールは目次（実際に、まさにこの仕様の目次が生成される方法）を作成するために見出しを使用できる。
この例は見出しに焦点を当てているが、HTMLにおけるセマンティックスのすべてに同じ原理が適用される。
著者は、ソフトウェアがページを正しく処理するのを妨げるような、適切な意図されるセマンティック目的以外の要素、属性、または属性値を使用してはならない。
たとえば、企業サイトの見出しを表すことを意図した、次のスニペットは、2行目がサブセクションの見出しであることを意図しないないため、不適合であるが、単に小見出しまたは副題（同じセクションの下位の見出し）にすぎない。
< body >
< h1 > ACME Corporation</ h1 >
< h2 > The leaders in arbitrary fast delivery since 1920</ h2 >
...hgroup要素は、この種の状況で使用できる：
< body >
< hgroup >
< h1 > ACME Corporation</ h1 >
< p > The leaders in arbitrary fast delivery since 1920</ p >
</ hgroup >
...構文的に正しいにも関わらず、セル内に置かれるデータは明らかに表のデータではなく、cite要素を誤使用したため、次の例における文書は同様に不適合である：
<!DOCTYPE HTML>
< html lang = "en-GB" >
< head > < title > Demonstration </ title > </ head >
< body >
< table >
< tr > < td > My favourite animal is the cat. </ td > </ tr >
< tr >
< td >
—< a href = "https://example.org/~ernest/" >< cite > Ernest</ cite ></ a > ,
in an essay from 1992
</ td >
</ tr >
</ table >
</ body >
</ html > これは、要素のセマンティックスを信頼するソフトウェアを停止させる。たとえば、目の不自由なユーザーに文書内の表の操作を許可された音声ブラウザーは、上記の引用を表として報告し、ユーザーを混乱させる。同様に、ページから作品タイトルを抽出するツールは、実際に人の名前であってタイトルでないにもかかわらず、作品のタイトルとして"Ernest"を抽出する。
この文書の修正版は次のようになる：
<!DOCTYPE HTML>
< html lang = "en-GB" >
< head > < title > Demonstration </ title > </ head >
< body >
< blockquote >
< p > My favourite animal is the cat. </ p >
</ blockquote >
< p >
—< a href = "https://example.org/~ernest/" > Ernest</ a > ,
in an essay from 1992
</ p >
</ body >
</ html > 著者は、将来的に拡張される言語に対して拡張が著しく困難になるため、この仕様または他の適用可能な仕様で許可されない要素、属性、または属性値を使用してはならない。
次の例では、この仕様で許可されていない不適合の属性値（"carpet"）および不適合の属性（"texture"）が存在する：
< label > Carpet: < input type = "carpet" name = "c" texture = "deep pile" ></ label > 代替で正しいマークアップ方法はこうなる：
< label > Carpet: < input type = "text" class = "carpet" name = "c" data-texture = "deep pile" ></ label > ノード文書のブラウジングコンテキストがnullであるDOMノードは、HTML構文の要件およびXML構文の要件以外のすべての文書適合性要件を免除される。
具体的には、template要素のテンプレートコンテンツのノード文書のブラウジングコンテキストがnullである。たとえば、コンテンツモデルの要件と属性値microsyntaxの要件は、template要素のテンプレートコンテンツには適用されない。この例では、img要素は、template要素の外で無効になるプレースホルダーとなる属性値を持つ。
< template >
< article >
< img src = "{{src}}" alt = "{{alt}}" >
< h1 ></ h1 >
</ article >
</ template > しかし、上記のマークアップで</h1>終了タグを省略することは、HTML構文に違反するため、適合性チェッカーでエラーとしてフラグが立てられる。
ユーザーエージェントが文書を処理している間に、スクリプトやその他のメカニズムの使用を介して、属性値、テキスト、文書の全体構造は実際に動的に変更するかもしれない。ある瞬間において文書のセマンティックスは、その瞬間における文書の状態によって表されるものであり、したがって、文書のセマンティックスは、時間の経過とともに変化する。変更が発生したものとして、ユーザーエージェントは、文書の見栄えを更新する。
HTMLは、プログレスバーを表すprogress要素を持つ。その"value"属性がスクリプトによって動的に更新される場合、ユーザーエージェントは進行状況の変更を表示するためにレンダリングを更新するだろう。
DOMでHTML要素を表すノードは、この仕様の関連セクションで挙げられるインターフェイスを実装しなければならず、スクリプトに公開する。HTML要素の文書が別のコンテキスト内（たとえばXSLT変換の内側）である場合でも、これはXML文書でのHTML要素を含む。
DOM内の要素は概念を表す。これは、要素がセマンティックとして知られる固有のセマンティックスを持つ。
たとえば、ol要素は順序付きのリストを表す。
要素は、明示的にまたは暗黙的のいずれかの、何らかの方法で参照される（参照する）ことがある。DOMにおける要素を明示的に参照できる方法の1つは、要素にid属性を与えて、そのid属性の値をハイパーリンクのhref属性値のフラグメントとしてハイパーリンクを作成することである。しかし、参照にはハイパーリンクは必須ではない。問題の要素を参照する任意の方法で十分である。
< figure id = "module-script-graph" >
< img src = "module-script-graph.svg"
alt = "Module A depends on module B, which depends
on modules C and D." >
< figcaption > Figure 27: a simple module graph</ figcaption >
</ figure > ハイパーリンクベースの参照は、a要素を使用して作成することができる。このように：
As we can see in < a href = "#module-script-graph" > figure 27</ a > , ...しかし、figure要素を参照するには、次のような多くの方法がある：
"モジュールA、B、C、およびDの図に描かれているように....."
"Figure 27で..."（ハイパーリンクなしで）
"'単純なモジュールグラフ'の図の内容から..."
"下記の図で..."（しかし、これは勧められない）
すべてのHTML要素のインターフェイスが継承する基本インターフェイスは、HTMLElementインターフェイスである。
HTMLElementインターフェイスは、多数の異なる機能に関係するメソッドおよび属性を保持する。したがって、このインターフェイスのメンバーはこの仕様の異なるセクションでさまざまに説明される。
HTMLでもSVGでもない要素の例としては、次のようなものがある：
const el = document.createElementNS("some namespace", "example");
console.assert(el.constructor === Element);この仕様において各要素は以下の情報を含む定義を持つ：
要素を使用できる場所の非規範的な記述。この情報は、子として、この要素を許可する要素のコンテンツモデルとともに冗長であり、利便性のためだけに提供される。
簡単のために、最も具体的な期待のみが記載される。
たとえば、すべてのフレージングコンテンツはフローコンテンツである。したがって、フレージングコンテンツである要素は、より具体的な期待であるため、"フレージングコンテンツが期待される場所"としてのみ記載される。フローコンテンツが期待される場所はどこでもフレージングコンテンツも期待されるため、この期待も満たす。
コンテンツがその要素の子や子孫として含めなければならないものの、規範的な記述。
text/html構文で、開始タグと終了タグを省略することができるかどうかの非規範的な記述。この情報は、任意タグのセクションで与えられた規範的要件とともに冗長であり、利便性のみの要素の定義に記載される。
（許可しない場合を除く）要素で指定されてもよい属性の規範的なリスト、およびこれら属性の非規範的な説明。（ダッシュの左側のコンテンツが規範的であり、ダッシュの右側のコンテンツがそうでない。）
著者向け：ARIA roleおよびaria-*属性の使用に関する適合要件は、ARIA in HTMLで定義される。[ARIA] [ARIAHTML]
実装者向け：アクセシビリティAPIセマンティックスを実装するためのユーザーエージェント要件は、HTML Accessibility API Mappingsで定義される。[HTMLAAM]
そのような要素が実装しなければならないDOMインターフェイスの規範的な定義。
その後、著者に適用されてもよい追加の規範適合要件とともに、要素が何を表すのかの説明が続く。時に例も含まれる。
属性値は、文字列である。特に指定される場合を除き、HTML要素の属性値は、空の文字列を含み、およびそのような属性値を指定することができるテキストに制限はない、任意の文字列値であってもよい。
この仕様で定義される各要素は、要素の期待されるコンテンツの説明となる、コンテンツモデルを持つ。HTML要素は、要素のコンテンツモデルで説明される要求に一致するコンテンツを持たなければならない。要素のコンテンツは、DOMにおけるその子である。
ASCII空白文字は常に要素の間に許可される。ユーザーエージェントは、DOMでTextとしてソースマークアップにおける要素間のこれら文字を表す。空のTextノードおよびそれらの文字の単なる配列から成るTextノードは、要素間の空白文字と見なされる。
要素間の空白文字、コメントノード、および処理命令ノードは、要素の内容が要素の内容モデルと一致させるかどうかを確立するときに無視されなければならず、文書および要素のセマンティックスを定義するアルゴリズムをたどるときに無視されなければならない。
このように、AとBが同じ親ノードを持ち、それらの間に他の要素ノードまたは（要素間の空白文字以外の）Textノードが存在しない場合、要素Aに2番目の要素Bが先行または後行するという。同様に、その要素が要素間の空白文字、コメントノード、処理命令ノード以外の他のノードが含まない場合、ノードは、要素の唯一の子である。
著者は、各要素に定義された、あるいは明示的に他の仕様によって要求されたものとして明示的に許可される場所以外でHTML要素を使用してはならない。XML複合文書では、それらの要素が関連するコンテキストを提供するものとして定義される場合、これらのコンテキストは、他の名前空間に由来する要素の内部にあるかもしれない。
The Atom Syndication Formatはcontent要素を定義する。type属性の値がxhtmlの場合、Atom Syndication Formatでは、単一のHTML div要素を含む必要がある。したがって、これがこの仕様によって明白に規範的な規定でないにもかかわらず、div要素はそのコンテキストで許可される。[ATOM]
さらに、HTML要素は省略されてもよい（すなわち、親ノードをもたない）。
たとえば、td要素を作成し、スクリプト内のグローバル変数に格納することは、td要素が別の方法でのみtr要素の内部で使用されることになっているにもかかわらず、適合する。
var data = {
name: "Banana" ,
cell: document. createElement( 'td' ),
}; 要素のコンテンツモデルがnothingである場合、要素は、（要素間の空白文字以外）は、Textノードおよび要素ノードを一切含んではならない。
便宜上、ほとんどのHTML要素のコンテンツモデルはまた"nothing"であり、ボイドの要素（HTML構文には終了タグがない要素）。しかし、これらは全く別の概念である。
HTMLにおいて各要素は、0個以上の、類似の特性を持つグループ要素であるカテゴリーに分類される。次の大まかなカテゴリーがこの仕様で使用されている：
一部の要素はまた、本仕様の他の部分で定義される他のカテゴリーに分類される。
これらのカテゴリーは、次のように関連する：
セクショニングコンテンツ、ヘディングコンテンツ、フレージングコンテンツ、エンベディッドコンテンツ、およびインタラクティブコンテンツはすべてフローコンテンツ型である。メタデータは、時にフローコンテンツとなる。メタデータとインタラクティブコンテンツは時にフレージングコンテンツとなる。エンベディッドコンテンツはまた、フレージングコンテンツ型であり、時にインタラクティブコンテンツとなる。
その他のカテゴリーはまた、特定の目的のために使用される。たとえばフォームコントロールは、一般的な要件を定義するために多数のカテゴリーを用いて指定される。一部の要素は独特の要件があり、特定のカテゴリーに属さない。
メタデータコンテンツは、見栄えまたは後のコンテンツの振る舞いを設定する、または他の文書との関係を設定する、または他の"帯域外の"情報を運搬するコンテンツである。
セマンティックスが主としてメタデータに関連する他の名前空間由来の要素（たとえば、RDF）もまた、メタデータコンテンツである。
したがって、XMLシリアライゼーションにおいて、このようにRDFを使用できる：
< html xmlns = "http://www.w3.org/1999/xhtml"
xmlns:r = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang = "en" >
< head >
< title > Hedral's Home Page</ title >
< r:RDF >
< Person xmlns = "http://www.w3.org/2000/10/swap/pim/contact#"
r:about = "https://hedral.example.com/#" >
< fullName > Cat Hedral</ fullName >
< mailbox r:resource = "mailto:hedral@damowmow.com" />
< personalTitle > Sir</ personalTitle >
</ Person >
</ r:RDF >
</ head >
< body >
< h1 > My home page</ h1 >
< p > I like playing with string, I guess. Sister says squirrels are fun
too so sometimes I follow her to play with them.</ p >
</ body >
</ html > しかし、これはHTMLシリアライゼーションでは不可能である。
文書およびアプリケーションのbodyで使用される多くの要素は、フローコンテンツとして分類される。
aabbraddressarea（map要素の子孫の場合）articleasideaudiobbdibdoblockquotebrbuttoncanvascitecodedatadatalistdeldetailsdfndialogdivdlemembedfieldsetfigurefooterformh1h2h3h4h5h6headerhgrouphriiframeimginputinskbdlabellink（body内で許可される場合）main（階層的に正しいmain要素の場合）mapmarkmathmenumeta（itemprop属性が存在する場合）meternavnoscriptobjectoloutputppicturepreprogressqrubyssampscriptsearchsectionselectslotsmallspanstrongsubsupsvgtabletemplatetextareatimeuulvarvideowbrセクショニングコンテンツは、headerおよびfooter要素の範囲を定義するコンテンツである。
ヘディングコンテンツはセクションの見出しを定義する（明示的にセクショニングコンテンツ要素を用いてマークアップされようとなかろうと、またはヘディングコンテンツ自体によって暗黙であろうとなかろうと）。
フレージングコンテンツは、文書のテキストおよび段落内レベルでそのテキストをマークアップする要素である。段落からフレージングコンテンツが続く。
aabbrarea（map要素の子孫の場合）audiobbdibdobrbuttoncanvascitecodedatadatalistdeldfnemembediiframeimginputinskbdlabellink（body内で許可される場合）mapmarkmathmeta（itemprop属性が存在する場合）meternoscriptobjectoutputpictureprogressqrubyssampscriptselectslotsmallspanstrongsubsupsvgtemplatetextareatimeuvarvideowbrフレージングコンテンツとして分類されるほとんどの要素は、自身がフローコンテンツではなく、フレージングコンテンツとして分類される要素のみを含むことができる。
コンテンツモデルのコンテキストにおいてテキストは、何もないか、Textノードのいずれかを意味する。テキストは時に、そのままでコンテンツモデルとして使用されるが、フレージングコンテンツでもあり、要素間の空白文字でもあるかもしれない（Textノードが空であるか、単にASCII空白文字を含む場合）。
Textノードおよび属性値は、noncharactersおよびASCII空白文字以外の制御文字を除いて、スカラー値から構成されなければならない。この仕様は、明確なコンテキストに応じたTextノードおよび属性値の正確な値に追加の制限を含む。
エンベディッドコンテンツは、他のリソースから文書に取り込むコンテンツであるか、文書へ挿入される他の語彙由来のコンテンツである。
HTML名前空間以外の名前空間に基づく、メタデータでなくコンテンツを伝える要素は、この仕様で定義されるコンテンツモデルの目的のためのエンベディッドコンテンツである。（たとえば、MathML、またはSVG。）
一部のエンベディッドコンテンツ要素は、フォールバックコンテンツを持つこともできる。これは外部リソースが使用できない場合（たとえば、サポートされていないフォーマットであるため）に使用されるコンテンツである。もしあれば、要素の定義はどのようなフォールバックであるかを記載する。
インタラクティブコンテンツは、特にユーザーとの交流を意図するコンテンツである。
a（href属性が存在する場合）audio（controls属性が存在する場合）buttondetailsembediframeimg（usemap属性が存在する場合）input（type属性が状態でない場合）labelselecttextareavideo（controls属性が存在する場合）一般的な規則として、コンテンツモデルが任意のフローコンテンツまたはフレージングコンテンツを許可する要素は、コンテンツ内に少なくとも1つのノードを持つべきである。これがパルパブルコンテンツであり、属性が指定されていない。
パルパブルコンテンツは、子孫の空でないテキスト、またはユーザーが聞くことができるもの（audio要素）、もしくは見ることができるもの（video、img、canvas要素）、もしくは他の方法で相互作用することができるもの（たとえば、対話的なフォームコントロール）のいずれかを提供することにより、要素を空でないものにする。
しかし、この要件は厳格な要件ではない。というのは、要素が合法的に空にできる多くのケースがあるためである。たとえば、スクリプトによって後で埋められるプレースホルダーとして使用される場合、または要素がテンプレートの一部であり、ほとんどのページで埋められるが、一部のページで関係しない場合などがある。
適合性チェッカーは、オーサリングの援助として、この要件を満たせない要素を見つけるためのメカニズムを制作者に提供するよう推奨される。
次の要素はパルパブルコンテンツである：
aabbraddressarticleasideaudio（controls属性が存在する場合）bbdibdoblockquotebuttoncanvascitecodedatadeldetailsdfndivdl（要素の子が少なくとも1つの名前-値グループを含む場合）emembedfieldsetfigurefooterformh1h2h3h4h5h6headerhgroupiiframeimginput（type属性が状態でない場合）inskbdlabelmainmapmarkmathmenu（要素の子が少なくとも1つli要素を含む場合）meternavobjectol（要素の子が少なくとも1つli要素を含む場合）outputppicturepreprogressqrubyssampsearchsectionselectsmallspanstrongsubsupsvgtabletextareatimeuul（要素の子が少なくとも1つli要素を含む場合）varvideoスクリプトサポート要素は、自分自身で何も表さない（つまりこれらはレンダリングされない）が、たとえばユーザーに機能を提供するために、スクリプトをサポートするために使用される。
次の要素は、スクリプトサポート要素である：
いくつかの要素は透過的といわれる。コンテンツモデルの説明でそれらの要素は"透過的"とされる。透過的な要素のコンテンツモデルは、その親要素のコンテンツモデルを受け継ぐ。"透過的"であるコンテンツモデルの役割で要求される要素は、透過的な要素がある、透過的な親要素のコンテンツモデルの役割で要求されるものと同じ要素である。
たとえば、ins要素を許可するruby要素のコンテンツモデルの役割は、フレージングコンテンツを許可する役割であり、かつrt要素はフレージングコンテンツではないので、ruby要素の内側でins要素はrt要素を含むことはできない。
一部のケースでは、透過的な要素が相互に入れ子になる場合、プロセスを繰り返し適用する必要がある。
次のマークアップ断片を考えてみよう：
< p >< object >< param >< ins >< map >< a href = "/" > Apples</ a ></ map ></ ins ></ object ></ p > a要素の内側で"Apples"が許可されるかどうかを確かめるために、コンテンツモデルを分析する。a要素のコンテンツモデルは透過的であり、map要素もins要素も、ins要素がみられるobject要素も同様である。object要素はp要素の中にあり、このコンテンツモデルはフレージングコンテンツである。したがって、テキストはフレージングコンテンツなので、"Apples"は許可される。
透過的なコンテンツが親を持たない場合、"透過的"であるそのコンテンツモデルの役割は、代わりに任意のフローコンテンツを受け入れるものとして扱われなければならない。
この節で定義されるような用語段落は、p要素の正確な定義以上の使われ方をする。ここで定義される段落の概念は、どのように文書を解釈すべきかを説明するために使われる。p要素は、段落をマークアップするいくつかのうちの1つにすぎない。
典型的な段落は、活版印刷において見られるような、特定の主題を議論する1つ以上の文をもつテキストのブロックを形成する、フレージングコンテンツの連続であるが、より一般の主題に関する分類に対しても用いられる。たとえば、住所もまた段落であり、フォームの一部、署名、詩のスタンザも同様である。
次の例において、セクションに2つの段落がある。段落ではないフレージングコンテンツを含む見出しもある。コメントおよび要素間の空白文字は段落を形成しないことに注意する。
< section >
< h2 > Example of paragraphs</ h2 >
This is the < em > first</ em > paragraph in this example.
< p > This is the second.</ p >
<!-- This is not a paragraph. -->
</ section > フローコンテンツ内の段落は、中身を複雑にするa、ins、del、map要素なしで、文書がどのように見えるかに関連して定義される。なぜなら、以下に最初の2つの例で示すように、混成のコンテンツモデルをもつこれらの要素は、段落の境界をまたぐことができるためである。
一般に、段落の境界をまたぐ要素を持つことは避けた方がよい。このようなマークアップを維持することは困難なことがある。
次の例は、前述の例からマークアップを選び、テキストが変更されたことを示すためにそのマークアップの一部の周囲にinsとdel要素を置く（もっともこの場合、正直なところ変更にあまり意味はないが）。この例は、insとdel要素をよそに、前のものとちょうど同じ段落を持つことに注目する―ins要素は見出しと最初の段落にまたがっており、del要素は2つの段落間の境界をまたがっている。
< section >
< ins >< h2 > Example of paragraphs</ h2 >
This is the < em > first</ em > paragraph in</ ins > this example< del > .
< p > This is the second.</ p ></ del >
<!-- This is not a paragraph. -->
</ section > 段落を互いに分離するためにフレージングコンテンツ以外のコンテンツが別の方法でないだろう場合、p要素は個々の段落をワードラップするために使用できる。
次の例において、リンクは第1段落の半分、2つの段落を分離する見出しのすべて、および第2段落の半分にわたる。これは、段落と見出しをまたがっている。
< header >
Welcome!
< a href = "about.html" >
This is home of...
< h1 > The Falcons!</ h1 >
The Lockheed Martin multirole jet fighter aircraft!
</ a >
This page discusses the F-16 Fighting Falcon's innermost secrets.
</ header > 以下はマークアップのもう1つの方法である。今回は、段落を明示し、1つのリンク要素を3つに分割している：
< header >
< p > Welcome! < a href = "about.html" > This is home of...</ a ></ p >
< h1 >< a href = "about.html" > The Falcons!</ a ></ h1 >
< p >< a href = "about.html" > The Lockheed Martin multirole jet
fighter aircraft!</ a > This page discusses the F-16 Fighting
Falcon's innermost secrets.</ p >
</ header > フォールバックコンテンツを定義する特定の要素を使用する場合、段落は重複してもよい。たとえば、以下のセクションで：
< section >
< h2 > My Cats</ h2 >
You can play with my cat simulator.
< object data = "cats.sim" >
To see the cat simulator, use one of the following links:
< ul >
< li >< a href = "cats.sim" > Download simulator file</ a >
< li >< a href = "https://sims.example.com/watch?v=LYds5xY4INU" > Use online simulator</ a >
</ ul >
Alternatively, upgrade to the Mellblom Browser.
</ object >
I'm quite proud of it.
</ section > 5つの段落が存在する：
object要素である。最初の段落は他の4つの段落と重複する。"cats.sim"リソースをサポートするユーザーエージェントは、最初の段落のみを表示するが、ユーザーエージェントは、あたかも2番目の段落と同じ段落であったかのように、1段落目の最初の文を表示するという紛らわしいフォールバックを表示し、かつあたかも1段落目の2番目にある文の冒頭であるかのように、最後の段落を表示するだろう。
この混乱を避けるために、明示的にp要素を使用することができる。たとえば：
< section >
< h2 > My Cats</ h2 >
< p > You can play with my cat simulator.</ p >
< object data = "cats.sim" >
< p > To see the cat simulator, use one of the following links:</ p >
< ul >
< li >< a href = "cats.sim" > Download simulator file</ a >
< li >< a href = "https://sims.example.com/watch?v=LYds5xY4INU" > Use online simulator</ a >
</ ul >
< p > Alternatively, upgrade to the Mellblom Browser.</ p >
</ object >
< p > I'm quite proud of it.</ p >
</ section > 以下の属性は共通で、すべてのHTML要素で指定してもよいものである：
accesskeyautocapitalizeautofocuscontenteditabledirdraggableenterkeyhintinertinputmodeisitemiditempropitemrefitemscopeitemtypelangnoncepopoverspellcheckstyletabindextitletranslatewritingsuggestionsSupport in all current engines.
DOMは、すべての名前空間ですべての要素にclass、idおよびslot属性に対するユーザーエージェントの要求を定義する。[DOM]
class、idおよびslot属性は、すべてのHTML要素に指定されてもよい。
HTML要素で指定される場合、class属性は、要素が属する様々なクラスを表す空白区切りトークンの集合の値を持たなければならない。
クラスを要素に割り当てることは、クラスのCSSセレクターでのマッチング、DOMにおけるgetElementsByClassName()メソッド、および他のそのような機能に影響を与える。
著者が使用できるclass属性のトークンに追加の制限は存在しないが、著者は、コンテンツの期待するプレゼンテーションを記述する値よりもむしろ、コンテンツの性質を記述する値を使用するよう推奨される。
HTML要素で指定される場合、id属性値は、要素のツリーですべてのIDに共通して一意でなければならず、かつ少なくとも1つの文字を含まなければならない。値は一切のASCII空白文字を含んではならない。
id属性はその要素の一意な識別子（ID）を指定する。
IDを取ることができる形式に制限は存在しない。具体的に、IDは数字のみまたは句読点のみで構成することができ、数字やアンダースコアで開始できる、などである。
要素の一意な識別子は様々な目的に使用されうる。中でも注目すべきはフラグメントを用いた文書の特定部分へのリンクする方法として、およびCSS由来の特定要素へのスタイル付けする方法としての目的である。
slot属性は、要素にスロットを割り当てるために使用される：slot属性をもつ要素は、name属性の値がそのslot属性の値と一致するslot要素によって作成されたスロットに割り当てられる。ただし、そのslot要素が、ルートのホストが対応するslot属性値を持つシャドウツリー内で見つかった場合に限る。
よりきめ細かいインターフェイスを公開できるよう支援技術製品が別の方法でHTML要素と属性で可能にするために、支援技術製品への注釈の集合が指定できる（ARIA roleおよびaria-*属性）。[ARIA]
以下のイベントハンドラーコンテンツ属性は任意のHTML要素に指定されてもよい：
onauxclickonbeforeinputonbeforematchonbeforetoggleonblur*oncanceloncanplayoncanplaythroughonchangeonclickoncloseoncontextlostoncontextmenuoncontextrestoredoncopyoncuechangeoncutondblclickondragondragendondragenterondragleaveondragoverondragstartondropondurationchangeonemptiedonendedonerror*onfocus*onformdataoninputoninvalidonkeydownonkeypressonkeyuponload*onloadeddataonloadedmetadataonloadstartonmousedownonmouseenteronmouseleaveonmousemoveonmouseoutonmouseoveronmouseuponpasteonpauseonplayonplayingonprogressonratechangeonresetonresize*onscroll*onscrollend*onsecuritypolicyviolationonseekedonseekingonselectonslotchangeonstalledonsubmitonsuspendontimeupdateontoggleonvolumechangeonwaitingonwheelこれら要素が同じ名前をもつWindowオブジェクトのイベントハンドラーを公開するため、アスタリスクとともにマークされる属性は、body要素上で指定される場合、異なる意味を持つ。
これら属性がすべての要素に適用される一方で、属性はすべての要素で役立つわけでない。たとえば、メディア要素のみがユーザーエージェントによって発火されたvolumechangeイベントを受け取るだろう。
カスタムデータ属性（たとえばdata-foldernameやdata-msgid）は、任意のHTML要素に指定されてよく、ページ特有のカスタムデータ、ステート、アノテーションなどの類似のものを保存可能である。
HTML文書で、HTML名前空間での要素は指定するxmlns属性を持つかもしれない。もし存在するなら値は正確に"http://www.w3.org/1999/xhtml"のみを持つ。これはXML文書に当てはまらない。
HTMLにおいて、xmlns属性は一切影響しない。これは基本的に魔除けである。これはXMLからの移行を少し簡単にするためだけに許可される。HTMLパーサーによって解析される場合、XMLの名前空間宣言属性のように"http://www.w3.org/2000/xmlns/"名前空間ではなく、属性は名前空間なしに終わる。
XMLにおいて、xmlns属性は名前空間宣言メカニズムの一部であり、要素は実際に名前空間を指定されないxmlns属性を持つことはできない。
XMLはまた、XML文書における任意の要素上のXML名前空間でxml:space属性の使用を許可する。HTMLにおいてデフォルトの振る舞いは空白文字を維持するため、この属性はHTML要素で影響しない。[XML]
text/html構文でHTML要素上のxml:space属性をシリアル化する方法は存在しない。
title属性Support in all current engines.
title属性は、ツールチップに適するような要素に対する助言情報を表す。リンクでは、これはタイトルまたは対象リソースの記述であるかもしれない。画像では、画像のタイトルや説明であるかもしれない。段落では、テキストの脚注や解説であるかもしれない。引用では、ソースに関する詳細情報かもしれない。インタラクティブコンテンツでは、要素の用途に対する分類や指示などかもしれない、などである。値はテキストである。
title属性に依存することは、多くのユーザーエージェントがこの仕様で要求されるようなアクセス可能な方法で属性を公開しないため、現在推奨されない（たとえば、ツールチップを出現させるマウスなどのポインティングデバイスが必要になり、これはモダンな携帯端末やタブレットをもつ人のような、キーボードのみのユーザーとタッチのみのユーザーを締め出す）。
この属性が要素から省略される場合、title属性をもつ最も近い先祖HTML要素のtitle属性がその要素にとっても適切であることを意味する。属性を設定することはこれを上書きし、明示的に先祖の助言情報がこの要素に関連しないことを示す。空文字列を属性に設定すると、要素は助言情報を持たないことを示す。
title属性値がU+000A LINE FEED（LF）文字を含む場合、コンテンツは複数行に分割される。各U+000A LINE FEED（LF）文字は改行を表す。
警告は、title属性内の改行の使用について報告される。
たとえば、実際に次の断片は改行とともに省略語の拡張を定義する。
< p > My logs show that there was some interest in < abbr title = "Hypertext
Transport Protocol" > HTTP</ abbr > today.</ p > link、abbr、inputのような一部の要素は、上記で説明されるセマンティックスを越えてtitle属性に対する追加のセマンティックスを定義する。
langおよびxml:lang属性Support in all current engines.
lang属性（名前空間なし）は、要素のコンテンツに対する基本言語およびテキストを含むあらゆる要素の属性に対して指定する。その値は妥当なBCP 47言語タグまたは空文字列でなければならない。属性に空文字列を設定することは第一言語が不明であることを指す。[BCP47]
XML名前空間でのlang属性はXMLで定義されている。[XML]
If these attributes are omitted from an element, then the language of this element is the same as the language of its parent element, if any (except for slot elements in a shadow tree).
名前空間のないlang属性は任意のHTML要素で使用されてもよい。
XML名前空間でのlang属性は、XML文書でのHTML要素上で使用されてもよい。同様に、関連仕様が許可する（特に、MathMLおよびSVGがそれらの要素で指定されるXML名前空間でlang属性を許可する）場合、他の名前空間で使用されてもよい。名前空間なしのlang属性とXML名前空間でのlang属性の両方が同じ要素に指定される場合、ASCII大文字・小文字不区別で比較したときに、これらは正確に同じ値を持たなければならない。
著者は、HTML文書におけるHTML要素のXML名前空間でlang属性を使用してはならない。XMLとの移行を容易にするために、著者は、接頭辞なしで名前空間のない属性、およびHTML文書内のHTML要素にリテラルでローカル名"xml:lang"を指定してもよいが、名前空間のないlang属性も指定されている場合、そのような属性のみが指定されなければならず、ASCII大文字・小文字不区別で比較するとき、両方の属性は同じ値を持たなければならない。
接頭辞なしで名前空間のない属性およびリテラルにローカル"xml:lang"は、言語処理に影響を与えない。
translate属性Support in all current engines.
The translate attribute is used to specify whether an element's attribute values and the values of its Text node children are to be translated when the page is localized, or whether to leave them unchanged. It is an attribute is an enumerated attribute with the following keywords and states:
| キーワード | 状態 | 概要 |
|---|---|---|
yes | yes | Sets translation mode to translate-enabled. |
| （空文字列） | ||
no | no | Sets translation mode to no-translate. |
The attribute's missing value default and invalid value default are both the inherit state.
（非HTML要素でさえも）各要素は、翻訳可能状態または無翻訳状態のいずれかの翻訳モードを持つ。HTML要素のtranslate属性がyes状態である場合、その要素の翻訳モードは翻訳可能な状態となる。そうでなければ、要素のtranslate属性がno状態である場合、その要素の翻訳モードは無翻訳状態となる。そうでなければ、要素のtranslate属性はinherit状態となるか、または要素がHTML要素でないかのいずれかであり、したがってtranslate属性を持たない。いずれにせよ、もしあれば要素の翻訳モードが、その親要素と同じ状態となる、または要素が文書要素である場合、翻訳可能状態となる。
要素が翻訳可能状態にある場合、要素の翻訳可能属性とそのTextノードの子の値は、ページがローカライズされるときに翻訳される。
要素が無翻訳状態にある場合、要素の属性値とそのTextノードの子の値は、たとえば要素が人物名やコンピュータープログラム名を含むため、ページがローカライズされるときに、そのままで残される。
以下の属性は翻訳可能属性である：
th要素のabbrarea、img、input要素のaltname属性が値に翻訳可能として知られるメタデータ名を指定する場合、meta要素のcontentaおよびarea要素のdownloadoptgroup、 option、およびtrack要素のlabellang。翻訳で使用される言語と一致する"翻訳された"ものでなければならない。inputおよびtextarea要素のplaceholderiframe要素のsrcdoc。解析されかつ再帰的に処理されなければならないstyle。解析されかつ再帰的に処理されなければならない（たとえば'content'プロパティの値）titletype属性をもつinput要素のvalue他の仕様は、翻訳可能な属性でもある他の属性を定義してもよい。たとえば、ARIAは翻訳可能としてaria-label属性を定義する。
次の例で、サンプルのキーボード入力とサンプルプログラム出力を除き、ページがローカライズされるときに文書内のすべてが翻訳される：
<!DOCTYPE HTML>
< html lang = en > <!-- default on the document element is translate=yes -->
< head >
< title > The Bee Game</ title > <!-- implied translate=yes inherited from ancestors -->
</ head >
< body >
< p > The Bee Game is a text adventure game in English.</ p >
< p > When the game launches, the first thing you should do is type
< kbd translate = no > eat honey</ kbd > . The game will respond with:</ p >
< pre >< samp translate = no > Yum yum! That was some good honey!</ samp ></ pre >
</ body >
</ html > dir属性Support in all current engines.
The dir attribute is an enumerated attribute with the following keywords and states:
| キーワード | 状態 | 概要 |
|---|---|---|
ltr | ltr | The contents of the element are explicitly directionally isolated left-to-right text. |
rtl | rtl | The contents of the element are explicitly directionally isolated right-to-left text. |
auto | auto | The contents of the element are explicitly directionally isolated text, but the direction is to be determined programmatically using the contents of the element (as described below). |
The heuristic used by the auto state is very crude (it just looks at the first character with a strong directionality, in a manner analogous to the Paragraph Level determination in the bidirectional algorithm). 著者は、テキストの方向が全く未知である場合、最後の手段としてのみこの値を使用するよう要請し、同様のサーバー側のヒューリスティックを適用できる。[BIDI]
The attribute's missing value default and invalid value default are both the undefined state.
The directionality of an element (any element, not just an HTML element) is either 'ltr' or 'rtl'. To compute the directionality given an element element, switch on element's dir attribute state:
Return 'ltr'.
Return 'rtl'.
Let result be the auto directionality of element.
If result is null, then return 'ltr'.
Return result.
bdi elementLet result be the auto directionality of element.
If result is null, then return 'ltr'.
Return result.
input element whose type attribute is in the Telephone stateReturn 'ltr'.
Return the parent directionality of element.
dir属性はHTML要素に対してのみ定義されるので、他の名前空間からの要素では存在し得ない。Thus, elements from other namespaces always end up using the parent directionality.
The auto-directionality form-associated elements are:
input elements whose type attribute is in the , Text, Search, Telephone, URL, Email, Password, Submit Button, Reset Button, or Button state, and
textarea elements.
To compute the auto directionality given an element element:
If element is an auto-directionality form-associated element:
If element is a slot element whose root is a shadow root and element's assigned nodes are not empty:
For each node child of element's assigned nodes:
Let childDirection be null.
If child is a Text node, then set childDirection to the text node directionality of child.
Otherwise:
Set childDirection to the auto directionality of child.
If childDirection is not null, then return childDirection.
Return null.
For each node descendant of element's descendants, in tree order:
If descendant, or any of its ancestor elements that are descendants of element, is one of
bdi elementscript elementstyle elementtextarea elementdir attribute is not in the undefined statethen continue.
If descendant is a slot element whose root is a shadow root, then return the directionality of that shadow root's host.
Let result be the text node directionality of descendant.
If result is not null, then return result.
Return null.
To compute the text node directionality given a Text node text:
If text's data does not contain a code point whose bidirectional character type is L, AL, or R, then return null. [BIDI]
Let codePoint be the first code point in text's data whose bidirectional character type is L, AL, or R.
If codePoint is of bidirectional character type AL or R, then return 'rtl'.
If codePoint is of bidirectional character type L, then return 'ltr'.
To compute the parent directionality given an element element:
Let parentNode be element's parent node.
If parentNode is a shadow root, then return the directionality of parentNode's host.
If parentNode is an element, then return the directionality of parentNode.
Return 'ltr'.
属性の文字列が何らかの方法でレンダリングに含まれるときに使用される、HTML要素の属性の方向は、下記リストから最初の適切な一連の手順に従って決定される：
dir属性がauto状態である場合双方向性文字型L、AL、またはRのある属性値の最初の文字を（論理的な順序で）見つける。[BIDI]
以下の属性は方向可能属性である：
th要素のabbrarea、img、input要素のaltname属性が値に主に機械可読よりむしろ人間可読であることを意図するものを指定する場合、meta要素のcontentoptgroup、 option、およびtrack要素のlabelinputおよびtextarea要素のplaceholdertitledocument.dir [ = value ]Support in all current engines.
html要素のdir属性値を置換するために、"ltr"、"rtl"、"auto"が設定可能である。
html要素が存在しない場合、空文字列を返し新しい値を無視する。
著者は、CSS不在（たとえば、検索エンジンによって解釈されるような）であっても正しく文書のレンダリングが継続するよう、CSSを使用するよりもテキストの方向を示すためのdir属性を使用するよう強く推奨される。
次のマークアップ断片は、インスタントメッセージの会話である。
< p dir = auto class = "u1" >< b >< bdi > Student</ bdi > :</ b > How do you write "What's your name?" in Arabic?</ p >
< p dir = auto class = "u2" >< b >< bdi > Teacher</ bdi > :</ b > ما اسمك؟</ p >
< p dir = auto class = "u1" >< b >< bdi > Student</ bdi > :</ b > Thanks.</ p >
< p dir = auto class = "u2" >< b >< bdi > Teacher</ bdi > :</ b > That's written "شكرًا".</ p >
< p dir = auto class = "u2" >< b >< bdi > Teacher</ bdi > :</ b > Do you know how to write "Please"?</ p >
< p dir = auto class = "u1" >< b >< bdi > Student</ bdi > :</ b > "من فضلك", right?</ p > 適切なスタイルシートとp要素へのデフォルトの配置スタイルを与えられる、すなわちテキストを段落の開始端へ揃えることで、結果として生じるレンダリングは以下のようになる：
前述したように、auto値は万能薬ではない。この例の最後の段落は、アラビア文字で始まるので、右から左へのテキストであると誤って解釈されており、これは"right?"がアラビア語テキストの左側になる原因となる。
style属性Support in all current engines.
すべてのHTML要素は、指定のstyleコンテンツ属性をもってもよい。これは、CSS Style Attributesによって定義されるとおりのスタイル属性である。[CSSATTR]
要素のどこでもstyle属性を使用する文書は、属性が削除された場合、それでも理解可能でありかつ使用可能でなければならない。
特に、コンテンツを非表示および表示するstyle属性の使用、または他に文書に含まれない意味の伝達は不適合である。（コンテンツを非表示および表示するには、属性を用いる。）
element.style要素のstyle属性へCSSStyleDeclarationオブジェクトを返す。
次の例で、色を参照する単語は、単語に視覚メディアで関連色を表すようspan要素とstyle属性を用いてマークアップされている。
< p > My sweat suit is < span style = "color: green; background:
transparent" > green</ span > and my eyes are < span style = "color: blue;
background: transparent" > blue</ span > .</ p > data-*属性をもつカスタム非視覚データの埋め込みSupport in all current engines.
カスタムデータ属性は、文字列"data-"で始まる名前空間のない名前をもつ属性であり、ハイフンの後に少なくとも1文字を持ち、XML互換であり、ASCII大文字を含まない。
ASCII大文字での制約はそのような文書に影響しないので、HTML文書においてHTML要素のすべての属性名はASCII小文字を自動的に取得する。
カスタムデータ属性は、ページまたはアプリケーションへ私的なカスタムデータ、ステート、アノテーションなど類似のものを記憶することを意図する。これ以上適切な属性や要素は存在しない。
この属性は、属性を使用するサイトの管理者に知られないソフトウェアによる使用を意図しない。複数の独立したツールによって使用される一般的な拡張のために、この仕様は明示的に機能を提供するために拡張されるべきである、またはマイクロデータのような技術は（標準化された語彙で）使用されるべきかのいずれかである。
たとえば、音楽に関するサイトは、各トラックの長さを含むカスタムデータ属性でアルバム内のトラックを表すリスト項目に注釈を付けるかもしれない。その後この情報は、ユーザーがトラックの長さでリストをソートできるようにするため、または一定長さのトラックのリストをフィルターリングするために、サイト自体が使用するかもしれない。
< ol >
< li data-length = "2m11s" > Beyond The Sea</ li >
...
</ ol > しかし、このデータを見ることで一定の長さの曲を検索するために、ユーザーがその音楽サイトに関連付けられていない一般的なソフトウェアを使用することは、不適当だろう。
これは、この属性がサイトの独自スクリプトによる使用を意図し、公開で利用可能なメタデータのための一般的な拡張メカニズムでないためである。
同様に、ページ著者は、使用しようとしている翻訳ツールに対して情報を提供するマークアップを書くことができる：
< p > The third < span data-mytrans-de = "Anspruch" > claim</ span > covers the case of < span
translate = "no" > HTML</ span > markup.</ p > この例において、"data-mytrans-de"属性は、フレーズ"claim"をドイツ語に翻訳するときに使用するためのMyTrans製品に特定のテキストを提供する。しかし、標準translate属性はすべての言語で翻訳であることを伝えるために使用される。"HTML"は不変のままである。標準属性が使用可能である場合、使用されるカスタムデータ属性に対するニーズは存在しない。
この例において、カスタムデータ属性は、チェックアウトページの異なるスタイル付けをするためにCSSで使用できる、PaymentRequestの機能検出の結果を格納するために使用される。
< script >
if ( 'PaymentRequest' in window) {
document. documentElement. dataset. hasPaymentRequest = '' ;
}
</ script > ここでは、data-has-payment-request属性は事実上 真偽属性として使用されている。属性の有無を確認するだけで十分である。しかし、著者が望む場合、後で何らかの値を持つことができる、制限された機能を示すかもしれない。
各HTML要素は任意の値とともに、任意の数の指定されたカスタムデータ属性を持ってもよい。
属性が無視され、かつ関連するすべてのCSSが破棄された場合、ページがそれでも使用可能であるよう、著者はこのような拡張を慎重に設計すべきである。
JavaScriptライブラリーが使用されるページの一部であると考えられるとして、JavaScriptライブラリーはカスタムデータ属性を使用してもよい。多くの著者によって再利用されるライブラリーの著者は、衝突のリスクを軽減するために、属性名にライブラリーの名前を含むよう推奨される。理にかなっている場合には、著者が無意識のうちに同じ名前を選んだライブラリーが同じページ上で使用できるように、そしてバージョンの相互の互換性がない場合でも、特定ライブラリーの複数のバージョンが同じページ上で使用できるように、ライブラリー著者はまた、正確な名前がカスタマイズ可能な属性名に使用されることを推奨される。
たとえば、"DoQuery"と呼ばれるライブラリーはdata-doquery-rangeのような属性名を使用するかもしれないし、"jJo"と呼ばれるライブラリーはdata-jjo-rangeのような属性名を使用するかもしれない。jJoライブラリーはまた、APIに接頭辞の使用の設定を供給するかもしれない（たとえばJ.setDataPrefix('j2')が、data-j2-rangeのような名前を持つようにする）。
element.dataset要素のdata-*属性に対してDOMStringMapオブジェクトを返す。
ハイフン付き名前はキャメルケースになる。たとえば、data-foo-bar=""はelement.dataset.fooBarになる。
DOMStringMapインターフェイスは、dataset属性に使用される。各DOMStringMapは関連する要素を持つ。
たとえばゲームの一部として、ウェブページが宇宙船を表す要素を望んだ場合、data-*属性とともにclass属性を使用する必要がある：
< div class = "spaceship" data-ship-id = "92432"
data-weapons = "laser 2" data-shields = "50%"
data- x = "30" data-y = "10" data-z = "90" >
< button class = "fire"
onclick = "spaceships[this.parentNode.dataset.shipId].fire()" >
Fire
</ button >
</ div > APIにおいてハイフン付き属性名は、キャメルケースになることに注目すること。
類似の構造とともに以下の引数および要素が与えられるとする：
< img class = "tower" id = "tower5" data- x = "12" data-y = "5"
data-ai = "robotarget" data-hp = "46" data-ability = "flames"
src = "towers/rocket.png" alt = "Rocket Tower" > 1つは関数splashDamage()がいくつかの引数を取ることが考えられ、第1引数は処理する要素となる：
function splashDamage( node, x, y, damage) {
if ( node. classList. contains( 'tower' ) && // checking the 'class' attribute
node. dataset. x == x && // reading the 'data-x' attribute
node. dataset. y == y) { // reading the 'data-y' attribute
var hp = parseInt( node. dataset. hp); // reading the 'data-hp' attribute
hp = hp - damage;
if ( hp < 0 ) {
hp = 0 ;
node. dataset. ai = 'dead' ; // setting the 'data-ai' attribute
delete node. dataset. ability; // removing the 'data-ability' attribute
}
node. dataset. hp = hp; // setting the 'data-hp' attribute
}
} innerTextおよびouterTextプロパティSupport in all current engines.
element.innerText [ = value ]"レンダリングのとおりに"要素のテキストコンテンツ返す。
指定された値をもつのでなく、brに変換された改行をもつ要素の子に置換するために、設定することができる。
element.outerText [ = value ]Support in all current engines.
"レンダリングのとおりに"要素のテキストコンテンツ返す。
要素を指定された値に置き換えるように設定できるが、改行はbr要素に変換される。
HTML要素のコンテンツでTextノードをもつHTML要素におけるテキストコンテンツ、および自由形式のテキストを許可するHTML要素の属性のテキストは、U+202AからU+202EまでおよびU+2066からU+2069までの範囲（双方向アルゴリズムの書式設定文字）の文字を含んでもよい。[BIDI]
著者は、手動で双方向アルゴリズムの書式設定文字を維持するよりもむしろ、dir属性、bdo要素、およびbdi要素を使用するよう推奨される。双方向アルゴリズムの書式設定文字は、CSSと互いに不完全に影響しあう。