訳注: この文書はSuperseded Recommendationとして廃止された仕様です。この日本語訳は歴史的な意味しか持ちません。最新のW3C HTML仕様を参照ください。

また、この翻訳文書の代わりにWHATWG HTML日本語訳が存在します。


概要

この仕様は、ワールドワイドウェブのコア言語の5番目のメジャーバージョンである、ハイパーテキストマークアップ言語(HTML)を定義する。このバージョンにおいて、ウェブアプリケーションの作成者を支援するために新しい機能を導入し、優勢なオーサリング慣習の調査に基づく新しい要素を導入し、相互運用性を改善することを目指してユーザーエージェント向けの明確な適合基準を定義するために特別な注意を与える。

この文書の位置付け

この節は、公開時点におけるこの文書のステータスについて説明する。他の文書がこの文書に取って代わるかもしれない。W3Cが現在公開しているリストとテクニカルレポートの最新版は、W3C technical reports index at http://www.w3.org/TR/で見つけることができる。

This specification is a Superseded Recommendation. A newer specification exists that is recommended for new adoption in place of this specification.

W3C HTMLワーキンググループは、この仕様の進捗に責任をもつW3Cワーキンググループである。

この仕様に対する包括的なテストスイートは維持され、WebPlatform Testsプロジェクトの一環として、最新の状態に保たれている。

http://www.w3.org/TR/html/で進められるこの仕様の発展に取り組んでいる。HTML5勧告は、HTMLの開発においてマイルストーンを表すが、道筋の終わりには程遠く、すでに改良が進行中である。将来のバージョンは、もはやモノリシックの仕様としてではなく、むしろより小さなモジュールのセットとして公開される可能性がある。その可能性に関係なく、http://www.w3.org/TR/html/は、HTML技術の全体へのエントリポイントとして維持される。

この仕様を拡張する作業は通常、新しい機能が検討されているかを確認するために参照されるべき拡張仕様を通して進行する。

この仕様のテキストの大部分はまた、仕様テキストの再利用を許可するライセンスの下、WHATWG HTML Living Standardで利用可能である。

この文書はW3Cメンバー、ソフトウェア開発者、そしてその他のW3Cグループや関係者によって評価が行われ、ディレクターによってW3C勧告として承認された。

この仕様の作業はまた、WHATWGで行われる。W3C HTMLワーキンググループは、W3C HTMLワーキンググループのチャーターの範囲内で、WHATWG living standardとHTML仕様の収斂を追求する。WHATWGでこの作業をフォローするためのさまざまな方法がある:

以下の編集上の変更が勧告案以降に行われた:

For purposes of the W3C Patent Policy, this Superseded Recommendation has the same status as an active Recommendation; it retains licensing commitments and remains available as a reference for old -- and possibly still deployed -- implementations, but is not recommended for future implementation. New implementations should follow the latest version of the HTML specification.

この文書は、2005年10月14日のW3Cプロセス文書によって管理される。

目次


1 導入

1.1 背景

この節は非規範的である。

ワールドワイドウェブのマークアップ言語は、常にHTMLであった。長年にわたるHTMLの普遍的な設計と改良は、多岐にわたる文書形式を記述するために使用するHTMLを可能にしたが、HTMLは本来セマンティックに科学的な文書を記述するための言語として設計されたものであった。

HTMLによって適切に処理されてない主な領域は、ウェブアプリケーションと呼ばれる曖昧な問題である。この仕様は、過去数年間で提起された問題に対処するためにHTML仕様を更新しつつ、同時にこれを修正しようと試みる。

1.2 読者

この節は非規範的である。

この仕様は、この仕様で定義された機能を使用する文書およびスクリプトの著者を対象としている, implementors of tools that operate on pages that use the features defined in this specification, and individuals wishing to establish the correctness of documents or implementations with respect to the requirements of this specification

正確さのためのわかりやすさや、完全性のための簡潔さを犠牲にする場所において、おそらくこの文書は、少なくともウェブ技術について十分な知識を持たない読者には適さない。よりわかりやすいチュートリアルやオーサリングガイドが、より易しいHTML5入門を提供するだろう。

特に、DOMの基礎に精通することが、この仕様のより技術的な一部の要素を完全に理解するために必要である。Web IDL、HTTP、XML、Unicode、文字エンコーディング、JavaScript、およびCSSの理解も随所で役立つだろうが、必須ではない。

1.3 範囲

この節は非規範的である。

この仕様は、静的な文書から動的なアプリケーションに至るまで、ウェブ上でアクセシブルなページにセマンティックレベルのマークアップ言語と関連付けられた、セマンティックレベルのスクリプトAPIを提供することに限定される。

この仕様の範囲は、外観のメディア固有なカスタマイズに対するメカニズムの提供を含まない(ただし、ウェブブラウザデフォルトのレンダリング規則はこの仕様の末尾に含まれ、またCSSに結びつけるための複数のメカニズムが言語の一部として提供される)。

この仕様の範囲は、オペレーティングシステム全体を記述することではない。具体的には、ハードウェア設定ソフトウェア、画像処理ツール、ユーザーが毎日のようにハイエンドなワークステーションで使用することが予想されるアプリケーションが範囲外である。アプリケーションの観点から、この仕様は、不定期にユーザーによって、または定期的だが低いCPU要件とともに異なる場所からの使用が予想されるアプリケーションを特に対象とする。そのようなアプリケーションの例は、オンライン購買システム、検索システム、ゲーム(特に多人数参加型オンラインゲーム)、公衆電話帳やアドレス帳、通信ソフトウェア(電子メールクライアント、インスタントメッセージクライアント、ディスカッションソフトウェア)、文書編集ソフトなどを含む。

1.4 歴史

この節は非規範的である。

最初の5年間(1990-1995)、HTMLは多数の改訂と拡張を経験した。最初はCERNで、次にIETFでホストされた。

W3Cの発足とともに、HTMLは再び開発の場を変えた。1995年にHTML 3.0として知られる初期の不成功に終わったHTMLを拡張する試みは、HTML 3.2として知られるより実用的なアプローチとなり、これは1997年に完了した。HTML4が同年の直後に続いた。

翌年、W3C会員はHTMLの展開をやめ、代わりにXHTMLとして知られるXMLベースの同等物の開発に着手することを決定した。 この取り組みはXMLのHTML4の再定式化を開始した。これは、新たなシリアライゼーションを除く新機能を追加しないXHTML 1.0として知られ、2000年に完了した。XHTML 1.0の後に、W3Cの中心はXHTMLモジュール化の旗印の下、XHTMLを拡張する他のワーキンググループの作業をより簡単にすることに移った。これと並行して、W3CはXHTML2と呼ばれる、それまでのHTMLやXHTML言語と互換性のない新しい言語の開発に取り組んだ。

HTMLの進化が1998年に停滞したころ、ブラウザベンダーによって開発されたHTMLのためのAPIの一部がDOM Level 1(1998年)とDOM Level 2 CoreおよびDOM Level 2 HTML(2000年にはじまり2003年に最高潮になる)として規定・発行された。これらの取り組みは2004年に発行されたDOM Level 3仕様とともに次第に弱まっていき、ワーキンググループはすべてのLevel 3草案を完了する前に打ち切られてしまった。

2003年に、ウェブフォームの次世代として位置づけられた技術であるXFormsの公表は、HTMLの代替を見つけることよりも、進化するHTML自身に再び関心を巻き起こした。この関心は、XMLの展開が、実際に展開された(HTMLのような)技術の置換というよりも、むしろウェブ技術としてもっぱら(RSSや後のAtomのような)新しい技術に限られたという認識から生まれた。

既存のHTMLウェブページとの非互換なレンダリングエンジンの実装をブラウザに要求することなく、XForms 1.0で導入された多数の機能を提供するためのHTML4フォームの拡張が可能だったことを示す、というコンセプトの証明は、この新たな関心の最初の結果であった。草案がすでに公然と利用可能であり、すべての資源に投入を要請されていた一方で、初期段階において、仕様はOpera Softwareの著作権下にあった。

HTMLの進化が再開されるべきであるという考えは2004年のW3Cワークショップで試された。ここでHTML5の作業(後述)の基礎となる原則の一部、前述のフォームに関連した機能をカバーする初期草案の計画と同じく、MozillaとOperaの共同でW3Cに提案された。この提案は以前に選択したウェブの進化の方向性と矛盾するものであるとして却下された。代わりに、W3C幹部と会員はXMLベースの代替品の開発を継続することを決議した。

その後まもなく、WHATWGと呼ばれる新しい舞台のもとでApple、Mozilla、Operaは共同で作業を継続する意向を発表した。公開メーリングリストが作成され、草案はWHATWGのサイトに移された。その後著作権は3ベンダー共同で所有するよう修正され、仕様の再利用を可能にした。

WHATWGは複数の中核となる原則に基づく。特に技術は下位互換性を持つ必要があり、たとえこれが実装よりむしろ仕様が変わることを意味しても仕様と実装は一致する必要があり、仕様は実装が相互にリバースエンジニアリングすることなしに完全な相互運用性を達成可能であることが必要だというものである。

特に後者の要件は、以前にHTML4、XHTML1、DOM2 HTMLという3つの異なる文書で規定されたものを含むようHTML5仕様の範囲として要求した。このことはまた、これまで慣例と考えられていたよりも多くの必要事項を含むことを意味した。

2006年、結局W3CはHTML5の開発に参加することに興味を示し、2007年にHTML5仕様の開発にWHATWGと協力するためのワーキンググループを設立した。Apple、Mozilla、およびOperaは、W3CにW3Cライセンスの下で仕様を公開することを許可し、WHATWGサイトのバージョンでは制限の少ないライセンスを維持した。

長年にわたり、両グループは、Ian Hicksonの下で一緒に働いてきた。2011年、グループは、異なる目標を持っているという結論に達した。WHATWGは継続的に仕様を維持し、新機能を追加し、HTML Living Standardの作業を続行したいとする一方で、W3CはHTML5勧告の機能に対して、一区切りつけたいというものである。2012年中旬、新しいエディタチームはHTML5勧告の作成を引き受け、次のHTMLバージョンへのワーキングドラフトを準備することをW3Cで始めた。

それ以来、W3C HTML仕様で登録されたバグを解決された、またはより正確にユーザーエージェントで実際に実装されて表現されたWHATWGからのパッチをW3C HTMLワーキンググループは選定している。この文書の公開時点において、WHATWG HTML仕様からのパッチはリビジョン8152までマージされている。W3C HTMLエディタはまた、WHATWGによって共有されないバグの修正をW3C HTMLワーキンググループによって作成された議論や決定の結果としてのパッチを追加している。

この文書で指定されるHTMLとHTML4仕様で説明される言語との相違点を提供するための別の文書が発行される。[HTMLDIFF]

1.5 設計ノート

この節は非規範的である。

一見しただけでは、HTMLの多くの特徴がでたらめであり一貫性のないように見えることを認めなければならない。

HTML、HTMLのDOM APIのサポート、およびHTMLのサポートする技術の多くは、多くの場合、互いの存在を知らない、異なる優先順位をもつ多数の人々により数十年にわたって開発されてきた。

このように機能は多くの出典から生じており、とりわけ一貫性のある方法で設計されていない。さらに、ウェブの特有な特性により、バグが修正される前にバグに依存する方法でコンテンツがしばしば意図せず書かれるため、実装バグはたびたびデファクトスタンダードになっており、今ではデジュールスタンダードになっている。

そのような状況にもかかわらず、一定の設計目標に執着する試みがなされている。これらは、次節で説明する。

1.5.1 スクリプト実行の逐次性

この節は非規範的である。

ウェブ著者をマルチスレッド処理の複雑さに触れさせることを回避するために、HTMLとDOM APIは、スクリプトが他のスクリプトの同時実行を検出しないように設計されている。ワーカーと等しい、実装の動作がすべてのブラウジングコンテキスト内におけるすべてのスクリプトの実行を完全に逐次化すると考えることができるのが意図するところである。

このモデルにおいて、navigator.yieldForStorageUpdates()メソッドは、呼び出し元のスクリプトがブロックされている間に、他のスクリプトが実行できるようにすることと等価である。

1.5.2 他の仕様の順守

この節は非規範的である。

この仕様は、多種多様な他の仕様と互いに影響しあい、依存する。残念ながら特定の状況において、矛盾する要求は、これら他の仕様に属する要件の違反をこの仕様に導く。この違反が発生した時はいつでも、違反はそれぞれ"故意の違反"として言及され、違反の理由が指摘される。

1.5.3 拡張性

この節は非規範的である。

HTMLは、安全な方法でセマンティックを追加するために使用できる拡張性メカニズムを多数持つ:

1.6 HTML vs XHTML

この節は非規範的である。

この仕様は、文書やアプリケーションを記述するための抽象的な言語、およびその言語を使用するリソースのメモリ内表現と情報交換するためのAPIを定義する。

メモリ内表現は略して"DOM HTML"、または"DOM"として知られている。

この抽象的な言語を使用するリソースを送信するために使用できる種々の具体的な構文が存在し、この仕様で定義されるものが2つ存在する。

1つ目のそのような具体的な構文は、HTML構文である。これは、ほとんどの著者のための推奨される形式であり、ほとんどのレガシーウェブブラウザと互換性がある。文書がtext/html MIMEタイプで送信される場合、ウェブブラウザによってHTML文書として処理される。この仕様は"HTML5.0"として知られるHTML構文のバージョン5.0を定義する。

2つ目の具体的な構文は、XML応用となるXHTML構文である。文書がapplication/xhtml+xmlのようなXML MIMEタイプで送信される場合、ウェブブラウザによりXML文書として処理され、XMLプロセッサにより解析される。著者は、XMLとHTMLの処理が異なることに注意する。とりわけ、些細な構文エラーが、XMLとしてラベル付けされた文書を完全にレンダリングするのを中止させることに注意する。一方、HTML構文では無視される。この仕様は"XHTML 5"として知られるXHTML構文のバージョン5.0を定義する。

DOM、HTML構文、およびXHTML構文は、すべて同じ内容を表すことはできない。たとえば、名前空間はHTML構文を使用して表現できないが、DOMとXHTML構文でサポートされる。同様に、noscriptの機能を使用する文書は、HTML構文を使って表すことができるが、DOMまたはXHTML構文で表すことができない。文字列"-->"が含まれるコメントは、HTMLとXHTML構文では表せず、DOMでのみ表すことができる。

1.7 この文書の構成

この節は非規範的である。

この仕様は以下の主要な章で構成される:

導入
HTML標準のためのコンテキストを提供する非標準の資料。
共通インフラ
適合クラス、アルゴリズム、定義、および仕様の残り部分の共通土台。
セマンティック、構造、およびHTML文書のAPI群
文書は要素から構築されている。これらの要素は、DOMを使用するツリーを形成する。この章は、このDOMの機能だけでなく、すべての要素に共通な機能を紹介し、要素を定義するのに使用される概念を定義する。
HTMLの要素
各要素は、この章で説明される事前に定義された意味を持つ。Rules for authors on how to use the element, along with user agent requirements for how to handle each element, are also given. これは、ビデオの再生や字幕、フォーム制御やフォーム送信、HTMLキャンバスとして知られる2次元のグラフィックAPIのようなHTMLの大きな署名機能を含む。
ウェブページの読み込み
HTML文書は、孤立して存在しない―この章は、環境に影響を与える機能の多くを定義し、ウェブブラウザやウェブアプリケーションのオフラインキャッシュのような、複数のページに対処する。
ウェブアプリケーションAPI
この章は、HTMLにおけるアプリケーションのスクリプトのための基本的な機能を紹介する。
ユーザーとの対話処理
HTML文書は、この章で説明されている、ユーザーが対話し、フォーカスがどのように機能するかなど、コンテンツを変更するための多数のメカニズムを提供することができる。
HTML構文
XHTML構文
これら構文の機能がシリーズ形式で表現されず、かつ他人に送信できなかった場合、機能のすべてが無駄になるだろう。そしてこれら構文の章では、構文を使用したコンテンツを解析方法の規則に沿って、HTMLとXHTMLの構文を定義する。
レンダリング
この章は、ウェブブラウザのためのデフォルトの処理規則を定義する。

旧式の機能およびIANA考慮のリストといった付録も存在する。

1.7.1 この仕様の読み方

この仕様は、他の仕様同様に読むべきである。まず、表紙から終わりまで複数回読むべきである。そして、少なくとも1回は後ろから読むべきである。それからコンテンツのリストからランダムに章を選び、すべての相互参照をたどって読むべきである。

下記の適合性要件の章で説明されるように、この仕様は、適合性の様々なクラスの適合基準を記述している。具体的には、たとえば著者および著者が作成した文書といったプロデューサに適用される適合性の要件と、たとえばウェブブラウザといった、コンシューマに適用される適合性要件がある。これらは、必要としているものによって区別することができる。プロデューサに対する要件は許可されるものを記載し、一方でコンシューマに対する要件はどのようにソフトウェアが動作するかを記載する。

たとえば、許可された値をレイアウトするとして、"foo属性の値が妥当な整数でなければならない"というのはプロデューサについての要件である。対照的に、"fooの属性の値が構文解析の整数のための規則を使用して解析しなければならない"というのはコンシューマに対する要件であり、コンテンツを処理する方法について説明する。

プロデューサについての要件は、コンシューマにまったく何の関係もない。

上記の例を続けると、特定の属性値が妥当な整数として拘束されているという要件は、コンシューマの要件について何かを意味するものではまったくない。コンシューマが実際に不明な文字列として属性を扱うことを要求し、その値が要件か否かに準拠しているかどうかにまったく影響しないかもしれない。コンシューマが、妥当な(この場合は数でない)値が処理される方法を定義する特定の規則を使用して値を解析することが(前の例のように)必要であるかもしれない。

1.7.2 表現規則

これは、定義、要件、または説明である。

これは注である。

これは例である。

これは 未解決の問題である。

これは警告である。

interface Example {
  // これはIDLの定義である
};
variable = object . method( [ optionalArgument ] )

これはインターフェースの使用法を著者に説明する注である。

/* これはCSS断片である */

用語の定義例はこのようにマークアップされる。その用語の使用は、このようにまたはこのようにマークアップされる。

要素、属性、またはAPIの定義例はこのようにマークアップされる。その要素、属性、またはAPIへの参照は、このようにマークアップされる。

その他のコード断片は、このようにマークアップされる。

変数は、このようにマークアップされる。

アルゴリズムにおいて、同期セクションでのステップは、⌛でマークされる。

場合によっては、要件は条件と対応する要件とともにリストの形で与えられる。このような場合、たとえ要件に対する条件の複数の集合である場合であっても、条件に適用される要件は常に、条件に従う要件の最初の集合である。次のようにこのような例が提示される:

これは条件である
これは別の条件である
これは上記の条件に当てはまる要件である。
これは3番目の条件である
これは3番目の条件に当てはまる要件である。

1.8 プライバシーに対する懸念

この節は非規範的である。

HTMLの一部の機能は、ユーザーのプライバシー保護対策とユーザーの利便性を引き替えにする。

一般に、インターネットのアーキテクチャのために、ユーザーは、ユーザーのIPアドレスで区別できる。IPアドレスは、完全にユーザーと一致しない。デバイスからデバイスへ、またはネットワークからネットワークへのユーザーの移動に伴い、ユーザーのIPアドレスは変更される。同様に、NATルーティング、プロキシサーバー、共有コンピュータは、実際には複数のユーザーに対応する単一のIPアドレスからすべて来るように見えるパケットを有効にする。インターネット上の1つのノードにおけるシングルユーザーからの要求は、ネットワークの多くの異なる部分から来るように見えるので、たとえばオニオンルーティングのような技術はリクエストをさらに匿名にするために使用できる。

しかし、ユーザーのリクエストに使用されるIPアドレスは、ユーザーのリクエストが互いに関連する可能性のある唯一のメカニズムではない。たとえばクッキーは、これを有効にするために特別に設計されており、アカウントを持つサイトにログインできるようにする大部分のウェブセッション機能の基礎である。

より繊細なメカニズムが存在する。ユーザーシステムのある種の特性は、互いにユーザーのグループを区別するために使用できる。そのような情報を十分に収集することによって、個別ユーザーのブラウザの"デジタル指紋"は、より優れているとは言わないまでも同じくらいに良く、リクエストが同じユーザーからのものであるかを確かめることができるIPアドレスとして、計算できる。

特に複数のサイト間で、この方法でのグループ化のリクエストは、両者にとって有益な(かつほぼ間違いなく前向きな)目的だけでなく、悪意ある目的に対して使用できる。合理的で有益な目的の例は、特定の人が猫のイラストがあるサイトとは対照的に、犬のイラストを使ったサイトを好むように見えるかどうかを(問題のサイトを訪問する頻度に基づいて)判断し、自動的に参加サイトへのその後の訪問に優先的にイラストを使用するものである。しかし、悪意ある目的は、その人が選挙で投票することを妨害すべきかどうかを決定するために(参加フォーラムサイトを調べることによって決定される)明確な所属政党を持つ(1つサイト上で道順を取得する際に使用するアドレスから決定される)そのような自宅住所と組み合わせる政府機関を含むかもしれない。

悪意ある目的が著しく有害であるかもしれないので、ユーザーエージェントの実装は、指紋ユーザーに慣れているだろう情報の漏洩を最小限にするためのツールとともにユーザーに提供する方法を検討することを推奨する。

残念ながら、この節の最初の段落が暗示するように、単純にすべて可能性のある漏洩を遮断するのと同じくらい簡単ではないので、時として指紋採取の目的で使用できる情報でさえも公開することで得られる多数の利点がある。たとえば、特定のIDの下で投稿するサイトにログインする機能は、定義により多かれ少なかれ、ユーザーの要求がすべて同じユーザーからのものとして識別することを要求する。しかし、より微細に、どの程度広いテキストであるかのような情報は、キャンバス上にテキストを描画するのに関係する多くの効果(たとえば、テキストの周りにボーダーを描画するのに関係する任意の効果など)に対して必要であり、ユーザーのリクエストをグループ化するために使用されるだろう情報も漏洩する。(この場合において、潜在的に公開することで、力任せの検索を通して、ユーザーがインストールしているフォント、ユーザーごとにかなり変動し得る情報。)

ユーザーの指紋採取に使用されるかもしれないこの仕様の機能は、この段落のようにマークされる。 (This is a fingerprinting vector.)

プラットフォーム内の他の機能は、以下を含むけれども限定されることなく、同じ目的に対して使用されるかもしれない:

1.9 HTMLの簡単な手引き

この節は非規範的である。

基本的なHTML文書は次のようになる:

<!DOCTYPE html>
<html>
 <head>
  <title>Sample page</title>
 </head>
 <body>
  <h1>Sample page</h1>
  <p>This is a <a href="demo.html">simple</a> sample.</p>
  <!-- this is a comment -->
 </body>
</html>

HTML文書は、要素とテキストツリーで構成される。各要素は、"<body>"のような開始タグと"</body>"のような終了タグでソース内に表示される。(場合によって、特定の開始タグと終了タグは省略および別のタグで暗示されるかもしれない。)

タグは、重複することなく、その要素が互いの中に完全にネストされなければならない:

<p>This is <em>very <strong>wrong</em>!</strong></p>
<p>This <em>is <strong>correct</strong>.</em></p>

この仕様は、要素がどのようにネストできるかに関する規則に沿って、HTMLで使用できる要素の集合を定義する。

要素は、要素が動作する方法を制御する属性を持つことができる。以下の例では、a要素とhref属性を使用して形成される、ハイパーリンクが存在する:

<a href="demo.html">simple</a>

属性は開始タグの内部に置かれ、"="文字で区切られた名前で構成される。属性値が空白文字または任意の" ' ` = < >を含まない場合、属性値は引用符で囲まないままにできる。そうでなければ、単一引用符または二重引用符のいずれかを使用して、引用符で囲む必要がある。値が空文字列の場合、"="文字とともに値を完全に省略できる。

<!-- empty attributes -->
<input name=address disabled>
<input name=address disabled="">

<!-- attributes with a value -->
<input name=address maxlength=200>
<input name=address maxlength='200'>
<input name=address maxlength="200">

HTMLユーザーエージェント(たとえばウェブブラウザ)はこのマークアップを解析し、マークアップをDOM(Document Object Model)ツリーに変化させる。DOMツリーは文書のメモリ内表現である。

DOMツリーは数種類のノードを含む。具体的には、DocumentTypeノード、Elementノード、Textノード、Commentノード、場合によってはProcessingInstructionノードである。

この節の一番上にあるマークアップ断片は以下のDOMツリーに変換される:

このツリーのルート要素html要素である。HTML文書のルートに見られる要素は常にhtml要素である。headbodyの2つの要素だけでなく、間にTextノードを含む。

ソースはDOMで多数のスペース(ここでは"␣"で表す)およびTextノードの終わる改行("⏎")を含むため、最初に期待したよりもDOMツリーに多数のTextノードがある。しかし、歴史的な理由から、元のマークアップ内のスペースや改行のすべて、特に、head開始タグが暗黙に省略されて終了する前のすべての空白、およびbody終了タグがbodyの終端で終了する後のすべての空白は、DOMには表示されない。

head要素は、テキスト"サンプルページ"を持つTextノードを含むtitle要素を含む。同様に、body要素はh1要素、p要素、およびコメントを含む。


このDOMツリーはページ内のスクリプトから操作できる。(一般的にJavaScriptで)スクリプトは、script要素を使用して、またはイベントハンドラコンテンツ属性を使用して埋め込むことができる小さなプログラムである。たとえば、"Hello World"を表示するために、output要素の値を設定するスクリプトを持つフォームはこのようになる:

<form name="main">
 Result: <output name="result"></output>
 <script>
  document.forms.main.elements.result.value = 'Hello World';
 </script>
</form>

DOMツリー内の各要素はオブジェクトによって表され、これらオブジェクトは、オブジェクトを操作できるようにするためのAPIを持つ。たとえば、リンク(たとえば上記ツリーのa要素)は、"href"属性を複数の方法で変更できる:

var a = document.links[0]; // 文書内の最初のリンクを取得
a.href = 'sample.html'; // リンク先URLを変更
a.protocol = 'https'; // URLのスキーム部分のみを変更する
a.setAttribute('href', 'http://example.com/'); // 属性内容を直接変更

HTML文書が実装(特にウェブブラウザのようなインタラクティブな実装)によって処理および表示されるときに、HTML文書を表現するための手段としてDOMツリーは使用されるので、この仕様では、大部分が上記のマークアップの代わりにDOMツリーの用語で記述される。


HTML文書は、メディアに依存しないインタラクティブなコンテンツの記述を表す。HTML文書は、画面で、音声シンセサイザーを通して、または点字ディスプレイでレンダリングされるかもしれない。そのようなレンダリングが行われる方法に影響を与えるために、著者はCSSなどのスタイル言語を使用できる。

次の例において、CSSを使用するページは、背景が青色で文字色が黄色となっている。

<!DOCTYPE html>
<html>
 <head>
  <title>Sample styled page</title>
  <style>
   body { background: navy; color: yellow; }
  </style>
 </head>
 <body>
  <h1>Sample styled page</h1>
  <p>This page is just a demo.</p>
 </body>
</html>

どのようにHTMLを使用するかの詳細について、著者はチュートリアルとガイドを参考にするよう促される。この仕様に含まれている例の一部も役立つかもしれないが、やむを得ず最初は理解しにくいかもしれない詳細なレベルで言語を定義することに初心者は注意すること。

1.9.1 HTMLで安全なアプリケーションを作成する

この節は非規範的である。

HTMLがインタラクティブなサイトを作成するために使用される場合、攻撃者がサイト自身またはサイトのユーザーの整合性を危険にさらすことを通して脆弱性をもたらすのを避けるような配慮が必要である。

この問題の包括的な研究は、この文書の範囲を超える。また著者は、より詳細に問題を研究することを強く促す。ただし、この節は、HTMLアプリケーション開発における一般的な落とし穴について簡単な手引きの提供を試みる。

ウェブのセキュリティモデルは"origin"の概念に基づいており、それに対応してウェブ上で潜在的な攻撃の多くは、cross-originな振る舞いを伴うとされる。[ORIGIN]

ユーザー入力の非検証
クロスサイトスクリプティング(XSS)
SQLインジェクション

たとえばテキストコメントのようなユーザーが生成したコンテンツ、URLパラメータの値、サードパーティサイトからのメッセージなどの信頼できない入力を受け入れるとき、データは使用する前に検証され、表示される場合に適切にエスケープすることが不可欠である。これを行わないと、敵対的なユーザーが負の年齢のように偽のユーザー情報を提供するなどの潜在的に安全なものから、ユーザーが情報を含むページを見て毎回スクリプトを実行するまたは潜在的にプロセスへの攻撃を伝播するなどの深刻なもの、サーバー内のすべてのデータを削除するなどの壊滅的なものまで、さまざまな攻撃の実行を許してしまう。

ユーザー入力を検証するためのフィルタを作成する場合、フィルタは常に既知の安全な構造物を許可し、他のすべての入力を許可しないような、ホワイトリストベースであることが不可欠である。(たとえば、将来的に発明されるかもしれないなどの理由で)すべての危険が既知ではないとして、既知の危険な入力を許さずその他を許すブラックリストベースのフィルタは安全ではない。

たとえば、ページが何を表示するかを決定するために、ページのURLのクエリ文字列を見て、次に、サイトがメッセージを表示することで、そのページにユーザーをリダイレクトするとしよう:

<ul>
 <li><a href="message.cgi?say=Hello">Say Hello</a>
 <li><a href="message.cgi?say=Welcome">Say Welcome</a>
 <li><a href="message.cgi?say=Kittens">Say Kittens</a>
</ul>

メッセージがエスケープせずに単にユーザーに表示された場合、敵対的な攻撃者は、script要素が含まれるURLを作成する可能性がある:

http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E

攻撃者は被害者のユーザーがこのページにアクセスすることを確信しているならば、攻撃者が選択したスクリプトは、ページ上で実行されるだろう。そのようなスクリプトは、サイトが提供するものによってのみ制限され、好きなだけ敵対行為を起こすことができる。たとえば、サイトがeコマースショップであれば、スクリプトによってユーザーの知らないうちに勝手に多くの不要な買い物をする可能性がある。

これは、クロスサイトスクリプティング攻撃と呼ばれている。

コードを実行させるサイトをだまそうとするために使用できる多くの構成要素がある。著者がホワイトリストのフィルタを書く場合に考慮が促されるいくつかのものがある:

クロスサイト・リクエスト・フォージェリ(CSRF)

たとえば、ユーザー名でフォーラムにメッセージを投稿する、購入する、またはパスポートの申請するなど、サイトがユーザーに対してユーザー固有の副作用を伴うフォーム送信を行うことを許可する場合、他のサイトによってユーザーを無意識にリクエストするようにだますよりかはむしろ、意図的にユーザーによって行われたことを確認するのが重要である。

HTMLフォームが他の生成元に送信できるため、この問題は存在する。

サイトは、ユーザー固有な秘密のトークンを使用してフォームを生成する、またはすべての要求にOriginヘッダーをチェックしてそのような攻撃を防ぐことができる。

クリックジャッキング

ユーザーが望まないだろう振る舞いを実行するインターフェースをユーザーに提供するようなページは、ユーザーがアクティブなインターフェースでだまされる可能性を回避するように設計する必要がある。

たとえば、敵対的なサイトが小さなiframeを被害者のサイトに配置し、ユーザーがリアクションゲームをプレイすることによって、クリックするようユーザーにさせる場合、ユーザーをだます一つの手段である。ひとたびユーザーがゲームをプレイすると、敵対サイトはユーザーがクリックしようとすると同時にマウスカーソルの下にiframeを配置できる。こうして被害者サイトのインターフェースをクリックするようにユーザーをだます。

これを回避するために、フレームに使用されることを予想しないサイトは、(たとえばtop属性の値にwindowオブジェクトを比較することによって)フレームにないことを検出した場合のみ、それらのインターフェースを有効にすることを促進する。

1.9.2 スクリプトAPIの使用時に回避すべき共通の落とし穴

この節は非規範的である。

HTML内のスクリプトは"実行から完了まで"のセマンティックがある。これは、イベントを発火または文書を解析し続けるなど、ほかに何かを実行する前に、一般にブラウザは途切れずスクリプトを実行することを意味する。

一方、HTMLファイルの解析は非同期かつ増加的に発生する。これは、パーサがスクリプトが実行できるよう任意の時点で一時停止可能であることを意味する。これは一般に良いことであるが、イベントが発火する可能性ができた後に、著者はイベントハンドラをフックするのを避けるよう注意する必要があることを意味する。

これを確実に行う、イベントハンドラのコンテンツ属性を使用する、または要素を作成して同じスクリプト内でイベントハンドラを追加するという2つの方法がある。前述のように、追加のイベントが発動する前に、スクリプトが完了するまで実行されているため、後者は安全である。

これが明示することができる一つの方法は、img要素とloadイベントである。特に画像がすでに(共通の)キャッシュされている場合は、要素が解析されると同時にイベントは発火することができる。

これは、著者はloadイベントを捕まえるためにimg要素にonloadハンドラを使用している:

<img src="games.png" alt="Games" onload="gamesLogoHasLoaded(event)">

要素がスクリプトによって追加されている場合、イベントハンドラは同じスクリプトで追加され、イベントが見落とされることはないだろう:

<script>
 var img = new Image();
 img.src = 'games.png';
 img.alt = 'Games';
 img.onload = gamesLogoHasLoaded;
 // img.addEventListener('load', gamesLogoHasLoaded, false); // would work also
</script>

しかし、著者が最初にimg要素を作成し、別のスクリプトでイベントリスナーを追加した場合、loadイベントが発火している間に、見逃す機会がある:

<!-- Do not use this style, it has a race condition!-->
 <img id="games" src="games.png" alt="Games">
 <!-- the 'load' event might fire here while the parser is taking a
      break, in which case you will not see it!-->
 <script>
  var img = document.getElementById('games');
  img.onload = gamesLogoHasLoaded; // might never fire!
 </script>

1.9.3 HTMLを記述する際に誤りを見つける方法:バリデータと適合性チェッカー

この節は非規範的である。

著者は、よく目にする誤りを見つける適合性チェッカー(バリデータとも呼ばれる)を利用することが推奨される。W3Cは、Nu Markup Validation Serviceを含む、多くのオンライン検証サービスを提供する。

1.10 著者に対する適合性と必要条件

この節は非規範的である。

HTML仕様の以前のバージョンとは異なり、この仕様は、妥当な文書向け同様に、妥当でない文書の詳細な必要な処理を定義する。

しかし、妥当でないコンテンツの処理は、ほとんどの場合明確に定義されるけれども、文書のための適合要件は依然として重要である。実際には、相互運用性(すべての実装が、信頼性と同一または同等の方法で特定のコンテンツを処理している状況)は、文書適合要件の唯一の目標ではない。この節は、適合文書とエラーをもつ文書を区別するための、より一般的な理由の一部を列挙する。

1.10.1 プレゼンテーション的なマークアップ

この節は非規範的である。

もはや以前のHTMLバージョンからのプレゼンテーション的な機能のほとんどを使用できない。一般にプレゼンテーション的なマークアップは、多くの問題を有することが見出されている:

プレゼンテーション的な要素の使用は、より乏しいアクセシビリティーにつながる

ユーザー支援技術(AT)に満足な体験(たとえばARIAを用いて)を提供する方法でプレゼンテーション的なマークアップを使用することは可能だが、セマンティックに適切なマークアップを用いる場合よりも著しく困難である。さらに、たとえそのような技術を用いても、テキストモードブラウザのユーザーのような、AT以外の非グラフィカルユーザー向けのページをアクセシブルにする助けにはならない。

その一方で、メディアに依存しないマークアップの使用は、多くのユーザー(たとえばテキストブラウザ)に機能するよう作成される文書向けの容易な手段を提供する。

メンテナンスのより高いコスト

マークアップがスタイルに依存しない方法で書かれるサイトの維持は大幅に容易である。たとえば、<font color="">を使用してサイトの色を変更すると、サイト全体にわたっての変更が必要になるのに対し、CSSに基づくサイトは同様の変更を単一のファイルの変更によって可能である。

より大きな文書サイズ

プレゼンテーション的なマークアップは、きわめて冗長になる傾向がある。したがって、より大きな文書サイズとなる。

このためこのバージョンでは、プレゼンテーション的なマークアップはHTMLから削除された。この変化は驚くべきものではない。HTML4は何年も前にプレゼンテーション的なマークアップを非推奨とし、著者がプレゼンテーション的なマークアップからの脱却を支援するモード(HTML4 Transitional)を提供した。後に、XHTML 1.1は一段と踏み込み、完全にそれらの機能を廃止した。

HTMLで唯一残っているプレゼンテーション的なマークアップ機能は、style属性とstyle要素である。style属性の使用は本番環境で推奨されないが、ラピッドプロトタイピング(そのルールが直接後で別のスタイルシートに移動することができる)、および独立したスタイルシートが不便である他とは異なる場合での特定のスタイルを提供するのに役立つ。同様に、style要素は、配信またはページ固有のスタイルに有用であるが、一般にスタイルを複数ページに適用する場合、外部スタイルシートはより使いやすそうである。

また、以前にプレゼンテーション的であった一部の要素がメディアに依存しないよう、この仕様で再定義されていることは注目すべきである:bihrssmallおよびu

1.10.2 構文エラー

この節は非規範的である。

HTMLの構文は、さまざまな問題を回避するために拘束されている。

直感的でないエラー処理の動作

特定の妥当でない構文構造が解析されるとき、高度に直感的でないDOMツリーをもたらす。

たとえば、次のマークアップ断片は、hr要素が、対応するtable要素の前の兄弟となるDOMをもたらす:

<table><hr>...
オプションのエラー回復を持つエラー

より奇妙で複雑なエラー処理規則を実装することなく、制御された環境で使用できるようにするため、ユーザーエージェントは解析エラーに遭遇した場合に失敗が許可される。

エラー処理の動作がストリーミングのユーザーエージェントとの互換性がないエラー

前述した<table><hr>...のような例に対する振る舞いなど、一部のエラー処理動作は、ストリーミングのユーザーエージェント(状態を保存することなく、1回のパスでHTMLファイルを処理するユーザーエージェント)と互換性がない。そのようなユーザーエージェントとの相互運用性の問題を回避するために、そのような振る舞いに起因するいかなる構文も妥当でないと見なされる。

infoset強制をもたらす可能性のあるエラー

XMLに基づくユーザーエージェントがHTMLパーサに接続される場合、コメントで2つの連続するハイフンを含むことがないというような、XMLが強制する特定の不変条件は、HTMLファイルによって侵害される可能性がある。これを処理すると、パーサがXML互換のinfosetにHTML DOMを強要することを要求できる。このような処理を要求するほとんどの構文構造は妥当でないとみなされる。

不均衡なパフォーマンスの低下につながるエラー

特定の構文構造は不均衡なパフォーマンスの低下につながることがある。このような構造の使用を思いとどまらせるために、典型的な不適合とする。

たとえば、すべての閉じられていないi要素が各段落で再構成されなければならないために、次のマークアップはパフォーマンスの低下をもたらし、各段落で次第により多くの要素をもたらす:

<p><i>He dreamt.
<p><i>He dreamt that he ate breakfast.
<p><i>Then lunch.
<p><i>And finally dinner.

The resulting DOM for this fragment would be:

壊れやすい構文構造に関係したエラー

歴史的な理由により、比較的壊れやすい構文構造が存在する。そのような問題に偶発的に陥るユーザーの数を減らすために、これらを適合しないようにする。

たとえば、属性における指定文字参照の特定の構文解析は、閉じセミコロンが省略されても起こる。指定文字参照を形成しない文字が続くアンパサンドを含むのは安全であるが、その文字が指定文字参照を形成する文字列に変更された場合、その文字列は代わりに文字として解釈されるだろう。

次の断片で、属性値は"?bill&ted"となる:

<a href="?bill&ted">Bill and Ted</a>

しかし、次の断片では、属性値は"?art&copy"を意図せず、実際には"?art©"となる。なぜならば最後のセミコロンがなく、"&copy"は"&copy;"と同様に扱われ、したがって"©"として解釈される:

<a href="?art&copy">Art and Copy</a>

この問題を回避するため、すべての指定文字参照はセミコロンで終了する必要があり、セミコロンなしの指定文字参照の使用は、エラーとしてフラグ付けされる。

よって、上記の例を表現するためのふさわしい方法は、次のとおり:

<a href="?bill&ted">Bill and Ted</a> <!-- &tedは指定文字参照でないのでOK -->
<a href="?art&amp;copy">Art and Copy</a> <!-- &copyは指定文字参照なので、&はエスケープされる必要がある -->
レガシーユーザーエージェントにおける既知の相互運用性の問題に関係したエラー

特定の構文構造は、レガシーユーザーエージェントでは特に微妙または重大な問題を引き起こすことが知られており、したがって著者が回避するのを助けるために不適合としてマークされる。

たとえば、これは"`"(U+0060)文字が引用符なしの属性で許可されない理由となる。特定のレガシーユーザーエージェントでは、 これは時に引用符として扱われる。

もう一つの例は、非互換モードのトリガーに必要なDOCTYPEである。なぜなら互換モードでのレガシーユーザーエージェントの動作は文書化されていないことが多いためである。

著者をセキュリティ攻撃にさらす危険のあるエラー

一定の制限は、純粋に既知のセキュリティ問題を回避するために存在している。

たとえば、UTF-7を使用する上での制限事項は、UTF-7を用いた既知のクロスサイトスクリプティング攻撃に対して純粋に著者が犠牲になるのを避けるために存在している。[UTF7]

著者の意図が不明であるケース

著者の意図が極めて不明確であるマークアップは、多くの場合不適合とされる。このエラーの早期の修正が以降のメンテナンスをより容易にする。

たとえば、次の著者の意図はh1見出しかh2見出しなのか不明瞭である:

<h1>Contact details</h2>
タイプミスである可能性が高いケース

ユーザーが単純なタイプミスをした場合、エラーが早期に発見できれば手助けとなり、デバッグに要する時間を大幅に節約できるだろう。したがってこの仕様は、この仕様で定義される名前と一致しない要素名、属性名、およびその他の使用をエラーとみなす。

たとえば、著者が<caption>の代わりに<capton>を入力した場合、これをエラーとしてフラグ付けすれば、著者はすぐにタイプミスを修正できるだろう。

将来的に新しい構文を妨害する可能性のあるエラー

言語構文は、将来的に拡張できるようにするために、特定のその他の無害な機能を禁止している。

たとえば、終了タグの"属性"は現在無視され、むしろ妥当でなく、将来に言語が変更する場合は、既に展開された(かつ妥当な)コンテンツと競合することなく、その構文機能の利用を整える。

一部の著者は、常にすべての属性を引用符でくくる、および任意のタグを含む習慣が有益であること見いだし、HTML構文の柔軟性を利用することによって与えられる簡潔さの小さな利益を乗り越えて、そのような習慣に由来する堅牢性を好む。そうした著者を支援するため、適合性チェッカーは、このような規則が適用される動作モードを提供できる。

1.10.3 コンテンツモデルと属性値の制約

この節は非規範的である。

言語構文の範囲を超えて、この仕様は要素や属性を指定できる方法も制限する。この制限は、同様の理由で存在している:

あいまいなセマンティックを持つコンテンツに関係したエラー

定義済みの意味を持つ要素の誤用を避けるために、コンテンツモデルは、入れ子があいまいな値を持つだろう場合の、要素が入れ子にすることができる方法の制限が定義される。

たとえば、著者がセクション全体がキー入力すべきであると示すことはまずないため、この仕様は、kbd要素の内側にsection要素を入れ子にするのを禁止する。

表明セマンティックにおける矛盾を伴うエラー

同様に、要素の誤用に著者の注意を引くため、セマンティックにおいて明らかな矛盾がある表現も適合性エラーと見なされる。

たとえば以下の断片では、セマンティックは無意味となる:水平線とセルは両立することはできず、ラジオボタンとプログレスバーも両立し得ない。

<hr role="cell">
<input type=radio role=progressbar>

別の例では、li要素のみを子にできるul要素の内容モデルには制約がある。定義によりリストは0個以上のリスト項目のみからなり、ul要素はli要素以外のものが含まれる場合、意図するものが明らかでない。

デフォルトのスタイルが混乱を招く可能性があるケース

特定の要素は、混乱につながる可能性が高い組み合わせとなるデフォルトのスタイルや振る舞いがある。この問題がなく同等の選択肢を持つ場所では、混乱する組み合わせは許可されない。

たとえば、div要素はブロックボックスとして、span要素はインラインボックスとしてレンダリングされる。インラインボックスの内側にブロックボックスを置くことは不必要な混乱を招く。div要素のみをネストにする、またはspan要素のみをネストする、またはdivの内側にspan要素をネストすることのいずれも、すべてspan要素でdiv要素をネストするのと同じ目的を果たすが、後者はインラインボックスにブロックボックスを含み、この組み合わせは許可されない。

もう一つの例は、インタラクティブコンテンツは入れ子にできないことだろう。たとえば、button要素はtextarea要素を含めることはできない。これは、そのような入れ子となるインタラクティブな要素のデフォルトの動作がユーザーに極度の混乱をもたらすことがあるためである。これらの要素を入れ子にする代わりに、並置することができる。

仕様の誤解する可能性を示すエラー

ときに、著者の混乱を起こす可能性のために認められないものがある。

たとえば、値"false"をdisabled属性に設定することは許可されない。これは、要素が見かけ上enabledになることを意味するにもかかわらず、実際には要素がdisabledを意味する(実装のために重要なものはその値ではなく、属性の存在である)ためである。

単に言語に簡素化を強制する制限を含むエラー

一部の適合性エラーは、著者が学ぶ必要のある言語を平易にする。

たとえば、area要素のshape属性は、実際には同義なものとしてcirccircleの値の両方を受け入れるにもかかわらず、チュートリアルやその他の学習補助を平易にするよう、circ値の使用を許可しない。両者を許可しても利益はないだろうが、言語を教える際に余計な混乱を引き起こすだろう。

パーサの特殊性を伴うエラー

特定の要素はやや風変わりな方法(一般には歴史的な理由)で解析され、その要素の内容モデルの制約は、これらの問題に著者がさらされることの回避を意図する。

たとえば、form要素はフレージングコンテンツの内側で許可されない。なぜならHTMLとして解析される場合、form要素の開始タグは、p要素の終了タグを意味するのである。したがって、1つではなく2つの段落をもたらす:

<p>Welcome. <form><label>Name:</label> <input></form>

It is parsed exactly like the following:

<p>Welcome. </p><form><label>Name:</label> <input></form>
スクリプトにデバッグ困難な手段に失敗をもたらすエラー

一部のエラーは、デバッグ困難だろうスクリプトの問題を防ぐ手助けを意図している。

例えば、同じ値を持つ2つのid属性を持つことは不適合である理由となる。二重のIDは、時には悲惨な結果とその原因を究明するのを困難にするとともに、間違った要素の選択をもたらす。

オーサリング時間を浪費するエラー

一部の構造は許可されない。なぜなら、そのような構造は歴史的に無駄なオーサリング時間の多くの原因であり、その構造を避けるよう著者に推奨することで、著者は将来の取り組みに時間を節約できるためである。

たとえば、script要素のsrc属性は、要素の内容を無視する。しかし、これは明らかでなく、特に要素の内容が実行可能なスクリプトのように見える場合。スクリプトが実行されないことに気づくことなく、著者がインラインスクリプトをデバッグしようする多くの時間を費やすことにつながるだろう。この問題を軽減するため、この仕様はsrc属性が存在する場合、script要素内に実行可能なスクリプトを不適合とする。これは、文書を検証する著者が、この種の誤りとともに時間を無駄にする可能性を低くすることを意味する。

XHTMLからの移行する著者に影響する範囲を伴うエラー

一部の著者は、XMLとHTMLの両方で同様の結果に解釈可能なファイルを書くことを好む。この習慣は無数の微妙な困難さ(特にスクリプト、スタイル、または自動化されたシリアライゼーションの任意の種類を含む場合)のために一般的に推奨されないけれども、この仕様は、少なくとも多少の困難の軽減を意図するいくつかの制約がある。これは、著者がHTMLとXHTMLとの間で移行する場合に過渡的な段階として容易に使用できるようにする。

たとえば、langxml:langという属性が2つの同期を維持することを目的とするやや複雑な規則がある。

もう一つの例は、適合文書中の要素が、HTMLまたはXMLとして処理したかどうか、同じ名前空間に終わることの確認を意図されるようなHTMLシリアライゼーションでxmlns属性の値を制限するだろう。

将来の拡張のために予約される範囲を伴うエラー

言語の今後の改正で新しい構文を可能にするために意図された構文の制限と同様に、要素や属性値の内容モデルに対する一部の制限は、HTML語彙の将来の拡張を可能にするために意図されている。

たとえば、"_"(U+005F)の文字で始まるtarget属性値を特定の事前に定義された値のみに制限することは、新たな事前定義された値を、著者が定義した値と競合することなく将来の時点で導入することができる。

他の仕様の誤使用を示すエラー

一定の制約は他の仕様によって作られた制約のサポートを意図する。

たとえば、メディアクエリを取る属性が妥当なメディアクエリのみの使用を要求することは、その仕様の適合規則に従うことの重要性を強調している。

1.11 推奨される読み物

この節は非規範的である。

以下の文書は、この仕様書の読者が興味をもつかもしれない。

Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]

このアーキテクチャの仕様は、Unicode標準とISO/IEC 10646で共同定義した国際文字集合として、ウェブ上で相互運用可能なテキスト操作のための共通の基準を仕様書の著者、ソフトウェア開発者、およびコンテンツ開発者に提供する。テーマは、用語'文字'、'エンコーディング'および'文字列'の使用、参照処理モデル、文字エンコーディングの識別と選択、文字エスケープ、および文字列の索引付けを含む対処である。

Unicode Security Considerations [UTR36]

Unicodeは極めて多数の文字を含み、世界の様々な書記体系を包含するため、誤った使用方法は、プログラムやシステムをセキュリティ攻撃にさらす可能性がある。次々に製品は国際化されるので、これは特に重要である。この文書は、プログラマ、システムアナリスト、規格の開発者、およびユーザーが考慮すべきセキュリティ上の考慮事項の一部について説明し、問題のリスクを軽減するために明確な推奨事項を提供する。

Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG]

ウェブコンテンツ・アクセシビリティー・ガイドライン(WCAG)2.0は、ウェブコンテンツをよりアクセシブルにするための幅広い推奨事項を扱う。このガイドラインに従うことにより、失明や弱視、ろうおよび難聴、学習障害、認知制限、運動制限、言語障害、光線過敏症およびこれらの組み合わせを持つ人々の広い範囲にアクセシブルなコンテンツを提供できる。このガイドラインに従うことはまた、多くの場合一般のユーザーに対してウェブコンテンツをより使いやすくする。

Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG]

This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as by enabling, supporting, and promoting the production of accessible Web content by all authors.

User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG]

This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities. User agents include browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable.

Polyglot Markup: HTML-Compatible XHTML Documents [POLYGLOT]

ポリグロットマークアップを使用する文書は、HTMLとして処理およびXMLとして処理された場合に、(ルート要素のxmlns属性を除く)同一の文書ツリーに解析されたバイトストリームである文書である。定義された制約のセットを満たすポリグロットマークアップは、HTML5の仕様を通して、HTMLとしてまたはXHTMLとして処理されるかどうかにかかわらず、互換性があると解釈される。ポリグロットマークアップは、特定のDOCTYPE、名前空間宣言、および特定の活字ケース―通常は小文字だが、時折キャメルケース(先頭文字を大文字)―を要素名や属性名に用いる。ポリグロットマークアップは、特定の属性値に小文字を使用する。さらに、空要素、指定実体参照、およびスクリプトとスタイルの使用に関する制約を含む。

HTML to Platform Accessibility APIs Implementation Guide [HPAAIG]

これは、HTML要素と属性をさまざまなプラットフォーム上でのアクセシビリティーAPIロール、ステートおよびプロパティーに割り当てたドラフト文書である。これは、HTML要素にアクセシブルな名前と説明を見いだす上での勧告を提供する。また、アクセシブルな機能の実装例を示す。

2 共通インフラ

2.1 用語

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

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

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

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

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

用語XHTML文書は、文脈に応じて、HTML名前空間内の要素ノードを含むXML文書モードでのDocument、およびHTML名前空間由来の要素を含むXML MIMEタイプに分類されたバイトストリームの両方を示すために使用される。


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

When an algorithm B says to return to another algorithm A, it implies that A called B. Upon returning to A, the implementation must continue from where it left off in calling B.

用語"透明な黒"は、赤、緑、青、およびアルファチャンネルをすべて0に設定した色を指す。

2.1.1 リソース

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

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

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

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

用語MIMEタイプは、プロトコルの文献で時折インターネットメディアタイプと呼ばれるものを指すのに使用される。この仕様において、用語メディアタイプは、CSS仕様により用いられるように、プレゼンテーションのために意図されるメディアの種類を指示するために使用される。[RFC2046] [MQ]

メディアタイプがRFC 7231の3.1.1.1節"Media Types"で定義されるmedia-type規則に一致する場合、文字列は妥当なMIMEタイプとなる。具体的には、妥当なMIMEタイプはMIMEタイプのパラメータを含んでもよい。[HTTP]

";"(U+003B)文字を含まないが、RFC 7231の3.1.1.1節"Media Types"で定義されるmedia-type規則に一致した場合、文字列はパラメータなしの妥当なMIMEタイプとなる。言い換えれば、MIMEタイプのパラメータがない、タイプおよびサブタイプのみから構成される場合である。[HTTP]

用語HTML MIMEタイプは、MIMEタイプtext/htmlを表すために使用される。

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

用語data: URLは、data:スキームを用いるURLを指す。[RFC2397]

2.1.2 XML

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

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

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

属性名がXMLで定義されたName生成物と一致し、":"(U+003A)文字を含まず、かつ最初の3文字の文字列がASCII大文字・小文字不区別で文字列"xml"に一致しない場合、属性名はXML互換であると言われる。[XML]

用語XML MIMEタイプは、MIMEタイプtext/xmlapplication/xml、subtypeが4文字"+xml"で終わる任意のMIMEタイプを参照するために使用される。[RFC7303]

2.1.3 DOMツリー

Documentオブジェクトのルート要素は、もしあれば、そのDocumentが持つ最初の要素の子である。もしないならば、Documentはルート要素を持たない。

Documentオブジェクトのルート要素を示さない場合、用語ルート要素は、議論されるノードでの最も遠い先祖要素ノード、または先祖を持たないノード自身を意味する。ノードが文書の一部である場合、ノードのルート要素は文書のルート要素そのものである。しかし、一般にノードが文書ツリーの一部でないならば、ルート要素は孤立したノードだろう。

要素のルート要素Documentオブジェクトのルート要素である場合、ノードはDocumentにあると言われる。ノードのルート要素が変化してかつ現在の文書のルート要素である場合、ノードは挿入された文書であると言われる。同様に、文書のルート要素から別の要素にルート要素が変わる場合、ノードは削除された文書であると言われる。

ノードのホームサブツリーは、そのノードのルート要素をルートとするサブツリーである。ノードがDocument内にある場合、ノードのホームサブツリーは、ノードのDocumentツリーである。

(要素のような)あるNodeDocumentは、NodeownerDocumentIDL属性が返すDocumentである。あるNodeDocument内にある場合、そのDocumentは常にNodeDocumentであり、したがってNodeownerDocumentIDL属性は常にそのDocumentを返す。

コンテンツ属性のDocumentは、属性の要素のDocumentである。

用語ツリー順は先行順を意味し、(parentNode/childNodesの関係を通して)DOMノードの縦型走査に関係する。

When it is stated that some element or attribute is ignored, or treated as some other value, or handled as if it was something else, this refers only to the processing of the node after it is in the DOM. A user agent must not mutate the DOM in such situations.

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

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

2.1.4 スクリプティング

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

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

If a DOM object is said to be live, then the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data.

イベントのコンテキストにおいて、用語発火送出は、DOM仕様で定義されるとおりに使用される。イベントの発火は、イベントを作成し送出することを意味し、イベントの送出は、ツリーを介してイベントを伝播する手順を実行することを意味する。用語信頼済みイベントは、isTrusted属性がtrueに初期化されたイベントを参照するために使用される。[DOM]

2.1.5 プラグイン

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

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

A user agent must not consider the types text/plain and application/octet-stream as having a registered plugin.

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

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

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

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

Browsers should take extreme care when interacting with external content intended for plugins. When third-party software is run with the same privileges as the user agent itself, vulnerabilities in the third-party software become as dangerous as those in the user agent.

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

2.1.6 文字エンコーディング

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

ASCII互換文字エンコーディングは、バイト0x09、0x0A、0x0C、0x0D、0x20-0x22、0x26、0x27、0x2C-0x3F、0x41-0x5Aおよび0x61-0x7A, ignoring bytes that are the second and later bytes of multibyte sequences, all correspond to single-byte sequences that map to the same Unicode characters as those bytes in Windows-1252 [ENCODING]

たとえエンコーディングで0x70のようなバイトにとってASCIIとしての解釈とは無関係な、より長いシーケンスの一部である可能性があるとしても、これは、Shift_JIS、HZ-GB-2312およびISO-2022の亜種などのエンコーディングを含む。これは、UTF-7、GSM03.38、およびEBCDICの亜種のような旧式のレガシーエンコーディングを除外する。

用語UTF-16エンコーディングはUTF-16の任意の変種、BOMのあるなしに関わらず、UTF-16LEまたはUTF-16BEを指す。[ENCODING]

用語コード単位はWeb IDL仕様で定義されるとおり、16ビット符号なし整数、DOMStringの最小の基本コンポーネントとして使用される。(これは、Unicodeで使用されるものより狭い定義であり、コードポイントと同一ではない。)[WEBIDL]

用語Unicodeコードポイントは、可能であればUnicodeスカラー値を、そうでないならば孤立サロゲートコードポイントを意味する。適合要件が文字またはUnicodeコードポイントの用語で定義される場合、下位サロゲートに続く上位サロゲートから成るコード単位のペアは、サロゲートペアで表される単一のコードポイントとして扱われなければならないが、孤立したサロゲートは、サロゲートの値を持つ単一のコードポイントとしてそれぞれ扱われなければならない。[UNICODE]

この仕様において、用語文字は、Unicode文字として修飾されてい場合、用語Unicodeコードポイントと同義である。

用語Unicode文字は、Unicodeスカラー値(すなわち、サロゲートコードポイントでない任意のUnicodeコードポイント)を意味するために使用される。[UNICODE]

文字列のコード単位長さは、その文字列のコード単位の数である。

この複雑さは、Unicode文字の観点よりむしろ、16ビット(UTF-16)コード単位の観点でDOM APIを定義するための歴史的な決定に由来する。

2.2 適合性要件

この仕様において、すべての図、例、注は非規範的であり、非規範的と明示された節も同様である。この仕様におけるその他すべては規範的である。

この文書での規範部分においてキーワード"MUST"、"MUST NOT"、"REQUIRED"、 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. この文書の規範部分でのキーワード"OPTIONALLY"は、"MAY"または"OPTIONAL"としての意味と同一に解釈される。読みやすさのために、これらの単語は本仕様において大文字のみで出現しない。[RFC2119]

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

For example, were the spec to say:

To eat an orange, the user must:
1. Peel the orange.
2. Separate each slice of the orange.
3. Eat the orange slices.

...it would be equivalent to the following:

To eat an orange:
1. The user must peel the orange.
2. The user must separate each slice of the orange.
3. The user must eat the orange slices.

Here the key word is "must".

The former (imperative) style is generally preferred in this specification for stylistic reasons.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

2.2.1 Conformance classes

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

Conforming documents are those that comply with all the conformance criteria for documents. For readability, some of these conformance requirements are phrased as conformance requirements on authors; such requirements are implicitly requirements on documents: by definition, all documents are assumed to have had an author. (In some cases, that author may itself be a user agent — such user agents are subject to additional rules, as explained below.)

For example, if a requirement states that "authors must not use the foobar element", it would imply that documents are not allowed to contain elements named foobar.

There is no implied relationship between document conformance requirements and implementation conformance requirements. User agents are not free to handle non-conformant documents as they please; the processing model described in this specification applies to implementations regardless of the conformity of the input documents.

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

Web browsers and other interactive user agents

Web browsers that support the XHTML 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 XHTML processor would, upon finding an XHTML 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.

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 XHTML 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 in the rendering section that that 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 XHTML documents for reasons other than to either render the documents or check them for conformance should act in accordance with the semantics of the documents that they process.

A tool that generates document outlines but increases the nesting level for each paragraph and does not increase the nesting level for each section would not be conforming.

Authoring tools and markup generators

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

Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, but only to the extent that authoring tools are not yet able to determine author intent. However, authoring tools must not automatically misuse elements or encourage their users to do so.

For example, it is not conforming to use an address element for arbitrary contact information; that element can only be used for marking up contact information for the author of the document or section. However, since an authoring tool is likely unable to determine the difference, an authoring tool is exempt from that requirement. This does not mean, though, that authoring tools can use address elements for any block of italics text (for instance); it just means that the authoring tool doesn't have to verify that when the user uses a tool for inserting contact information for a section, that the user really is doing that and not inserting something else instead.

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

When an authoring tool is used to edit a non-conforming document, it may preserve the conformance errors in sections of the document that were not edited during the editing session (i.e. an editing tool is allowed to round-trip erroneous content). However, an authoring tool must not claim that the output is conformant if errors have been so preserved.

Authoring tools are expected to come in two broad varieties: tools that work from structure or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG).

The former is the preferred mechanism for tools that author HTML, since the structure in the source information can be used to make informed choices regarding which HTML elements and attributes are most appropriate.

However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are appropriate, and should not use elements that they do not know to be appropriate. This might in certain extreme cases mean limiting the use of flow elements to just a few elements, like div, b, i, and span and making liberal use of the style attribute.

All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling users to create well-structured, semantically rich, media-independent content.

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

For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML (referred to as the XHTML syntax), 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.2.2 Dependencies

This specification relies on several other underlying specifications.

Unicode and Encoding

The Unicode character set is used to represent textual data, and the Encoding standard defines requirements around character encodings. [UNICODE]

This specification introduces terminology based on the terms defined in those specifications, as described earlier.

The following terms are used as defined in the Encoding specification: [ENCODING]

  • Getting an encoding
  • The encoder and decoder algorithms for various encodings, including the UTF-8 encoder and UTF-8 decoder
  • The generic decode algorithm which takes a byte stream and an encoding and returns a character stream
  • The UTF-8 decode algorithm which takes a byte stream and returns a character stream, additionally stripping one leading UTF-8 Byte Order Mark (BOM), if any

The UTF-8 decoder is distinct from the UTF-8 decode algorithm. The latter first strips a Byte Order Mark (BOM), if any, and then invokes the former.

The decoder algorithm may produce an error, referred to in this specification as a decoder error.

For readability, character encodings are sometimes referenced in this specification with a case that differs from the canonical case given in the encoding standard. (For example, "UTF-16LE" instead of "utf-16le".)

XML

Implementations that support the XHTML syntax must support some version of XML, as well as its corresponding namespaces specification, because that syntax uses an XML serialization with namespaces. [XML] [XMLNS]

URLs

The following terms are defined in the URL standard: [URL]

  • URL
  • Absolute URL
  • Relative URL
  • Relative schemes
  • The URL parser
  • Parsed URL, which is the result of processing a URL through the URL parser
  • The scheme component of a parsed URL
  • The scheme data component of a parsed URL
  • The username component of a parsed URL
  • The password component of a parsed URL
  • The host component of a parsed URL
  • The port component of a parsed URL
  • The path component of a parsed URL
  • The query component of a parsed URL
  • The fragment component of a parsed URL
  • Parse errors from the URL parser
  • The URL serializer
  • Default encode set
  • Percent encode
  • UTF-8 percent encode
  • Percent decode
  • URLUtils interface
  • href attribute
  • protocol attribute
  • The get the base hook for URLUtils
  • The update steps hook for URLUtils
  • The set the input algorithm for URLUtils
  • The query encoding of an URLUtils object
  • The input of an URLUtils object
  • The url of an URLUtils object
Cookies

The following terms are defined in the Cookie specification: [COOKIES]

  • cookie-string
  • receives a set-cookie-string
CORS

The following terms are defined in the CORS specification: [CORS]

  • cross-origin request
  • cross-origin request status
  • custom request headers
  • simple cross-origin request
  • redirect steps
  • omit credentials flag
  • resource sharing check
Web IDL

The IDL blocks in this specification are conforming IDL fragments as defined by the WebIDL specification. [WEBIDL]

The terms supported property indices, determine the value of an indexed property, support named properties, supported property names, determine the value of a named property, platform array objects, and read only (when applied to arrays) are used as defined in the Web IDL specification. The algorithm to convert a DOMString to a sequence of Unicode characters is similarly that defined in the Web IDL specification.

When this specification requires a user agent to create a Date object representing a particular time (which could be the special value Not-a-Number), the milliseconds component of that time, if any, must be truncated to an integer, and the time value of the newly created Date object must represent the resulting truncated time.

For instance, given the time 23045 millionths of a second after 01:00 UTC on January 1st 2000, i.e. the time 2000-01-01T00:00:00.023045Z, then the Date object created representing that time would represent the same time as that created representing the time 2000-01-01T00:00:00.023Z, 45 millionths earlier. If the given time is NaN, then the result is a Date object that represents a time value NaN (indicating that the object does not represent a specific instant of time).

JavaScript

Some parts of the language described by this specification only support JavaScript as the underlying scripting language. [ECMA262]

The term "JavaScript" is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known. Similarly, the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC 4329. [RFC4329]

The term JavaScript global environment refers to the global environment concept defined in the ECMAScript specification.

The ECMAScript SyntaxError exception is also defined in the ECMAScript specification. [ECMA262]

DOM

The Document Object Model (DOM) is a representation — a model — of a document and its content. The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM. [DOM]

Implementations must support DOM and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [DOMEVENTS]

In particular, the following features are defined in the DOM specification: [DOM]

  • Attr interface
  • Comment interface
  • DOMImplementation interface
  • Document interface
  • DocumentFragment interface
  • DocumentType interface
  • DOMException interface
  • ChildNode interface
  • Element interface
  • Node interface
  • NodeList interface
  • ProcessingInstruction interface
  • Text interface
  • HTMLCollection interface
  • item() method
  • The terms collections and represented by the collection
  • DOMTokenList interface
  • DOMSettableTokenList interface
  • createDocument() method
  • createHTMLDocument() method
  • createElement() method
  • createElementNS() method
  • getElementById() method
  • insertBefore() method
  • ownerDocument attribute
  • childNodes attribute
  • localName attribute
  • parentNode attribute
  • namespaceURI attribute
  • tagName attribute
  • id attribute
  • textContent attribute
  • The insert, append, remove, replace, and adopt algorithms for nodes
  • The nodes are inserted and nodes are removed concepts
  • The attribute list concept.
  • The data of a text node.
  • Event interface
  • EventTarget interface
  • EventInit dictionary type
  • target attribute
  • isTrusted attribute
  • The type of an event
  • The concept of an event listener and the event listeners associated with an EventTarget
  • The concept of a regular event parent and a cross-boundary event parent
  • The encoding (herein the character encoding) and content type of a Document
  • The distinction between XML documents and HTML documents
  • The terms quirks mode, limited-quirks mode, and no-quirks mode
  • The algorithm to clone a Node, and the concept of cloning steps used by that algorithm
  • The concept of base URL change steps and the definition of what happens when an element is affected by a base URL change
  • The concept of an element's unique identifier (ID)
  • The concept of a DOM range, and the terms start, end, and boundary point as applied to ranges.
  • MutationObserver interface
  • The MutationObserver scripting environment concept
  • The invoke MutationObserver objects algorithm
  • Promise interface
  • The resolver concept
  • The fulfill and reject algorithms

The term throw in this specification is used as defined in the DOM specification. The following DOMException types are defined in the DOM specification: [DOM]

  1. IndexSizeError
  2. HierarchyRequestError
  3. WrongDocumentError
  4. InvalidCharacterError
  5. NoModificationAllowedError
  6. NotFoundError
  7. NotSupportedError
  8. InvalidStateError
  9. SyntaxError
  10. InvalidModificationError
  11. NamespaceError
  12. InvalidAccessError
  13. SecurityError
  14. NetworkError
  15. AbortError
  16. URLMismatchError
  17. QuotaExceededError
  18. TimeoutError
  19. InvalidNodeTypeError
  20. DataCloneError

For example, to throw a TimeoutError exception, a user agent would construct a DOMException object whose type was the string "TimeoutError" (and whose code was the number 23, for legacy reasons) and actually throw that object as an exception.

The URL associated with a Document, as defined in the DOM specification, is referred to in this specification as the document's address.

The following features are defined in the DOM Events specification: [DOMEVENTS]

  • MouseEvent interface
  • MouseEventInit dictionary type
  • The UIEvent interface's detail attribute
  • click event

This specification sometimes uses the term name to refer to the event's type; as in, "an event named click" or "if the event name is keypress". The terms "name" and "type" for events are synonymous.

The following features are defined in the DOM Parsing and Serialization specification: [DOMPARSING]

  • innerHTML
  • outerHTML

User agents are also encouraged to implement the features described in the HTML Editing APIs and UndoManager and DOM Transaction specifications. [EDITING] [UNDO]

The following parts of the Fullscreen specification are referenced from this specification to define how the Fullscreen API interacts with the sandboxing features in HTML: [FULLSCREEN]

  • The top layer concept
  • requestFullscreen()
  • The fullscreen enabled flag
  • The fully exit fullscreen algorithm
Typed Arrays

The ArrayBuffer and ArrayBufferView interfaces and underlying concepts from the Typed Array Specification are used for several features in this specification. The Uint8ClampedArray interface type is specifically used in the definition of the canvas element's 2D API. [TYPEDARRAY]

File API

This specification uses the following features defined in the File API specification: [FILEAPI]

  • Blob
  • File
  • FileList
  • Blob.close()
  • Blob.type
  • The concept of read errors
XMLHttpRequest

This specification references the XMLHttpRequest specification in some non-normative notes and examples. The following features and terms are defined in the XMLHttpRequest specification: [XHR]

  • XMLHttpRequest
Progress Events

This specification references the Progress Events specification to describe how the two specifications interact and to use its ProgressEvent features. The following features and terms are defined in the Progress Events specification: [PROGRESS-EVENTS]

  • ProgressEvent
  • Fire a progress event named e
Server-Sent Events

The following terms are defined in Server-Sent Events: [EVENTSOURCE]

  • EventSource
  • forcibly close
Media Queries

Implementations must support the Media Queries language. [MQ]

CSS modules

While support for CSS as a whole is not required of implementations of this specification (though it is encouraged, at least for Web browsers), some features are defined in terms of specific CSS requirements.

In particular, some features require that a string be parsed as a CSS <color> value. When parsing a CSS value, user agents are required by the CSS specifications to apply some error handling rules. These apply to this specification also. [CSSCOLOR] [CSS]

For example, user agents are required to close all open constructs upon finding the end of a style sheet unexpectedly. Thus, when parsing the string "rgb(0,0,0" (with a missing close-parenthesis) for a color value, the close parenthesis is implied by this error handling rule, and a value is obtained (the color 'black'). However, the similar construct "rgb(0,0," (with both a missing parenthesis and a missing "blue" value) cannot be parsed, as closing the open construct does not result in a viable value.

The term CSS element reference identifier is used as defined in the CSS Image Values and Replaced Content specification to define the API that declares identifiers for use with the CSS 'element()' function. [CSSIMAGES]

Similarly, the term provides a paint source is used as defined in the CSS Image Values and Replaced Content specification to define the interaction of certain HTML elements with the CSS 'element()' function. [CSSIMAGES]

The term default object size is also defined in the CSS Image Values and Replaced Content specification. [CSSIMAGES]

Support for the CSS Object Model is required for implementations that support scripting. The following features and terms are defined in the CSSOM specifications: [CSSOM] [CSSOMVIEW]

  • Screen
  • LinkStyle
  • CSSStyleDeclaration
  • cssText attribute of CSSStyleDeclaration
  • StyleSheet
  • sheet
  • disabled
  • Alternative style sheet sets and the preferred style sheet set
  • Serializing a CSS value
  • Scroll an element into view
  • Scroll to the beginning of the document

The term CSS styling attribute is defined in the CSS Style Attributes specification. [CSSATTR]

The CanvasRenderingContext2D object's use of fonts depends on the features described in the CSS Fonts and Font Load Events specifications, including in particular FontLoader. [CSSFONTS] [CSSFONTLOAD]

SVG

The following interface is defined in the SVG specification: [SVG]

  • SVGMatrix
WebGL

The following interface is defined in the WebGL specification: [WEBGL]

  • WebGLRenderingContext
WebVTT

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

The following terms, used in this specification, are defined in the WebVTT specification:

  • WebVTT file
  • WebVTT file using cue text
  • WebVTT file using chapter title text
  • WebVTT file using only nested cues
  • WebVTT parser
  • The rules for updating the display of WebVTT text tracks
  • The rules for interpreting WebVTT cue text
  • The WebVTT text track cue writing direction
The WebSocket protocol

The following terms are defined in the WebSocket protocol specification: [WSP]

  • establish a WebSocket connection
  • the WebSocket connection is established
  • validate the server's response
  • extensions in use
  • subprotocol in use
  • headers to send appropriate cookies
  • cookies set during the server's opening handshake
  • a WebSocket message has been received
  • fail the WebSocket connection
  • close the WebSocket connection
  • start the WebSocket closing handshake
  • the WebSocket closing handshake is started
  • the WebSocket connection is closed (possibly cleanly)
  • the WebSocket connection close code
  • the WebSocket connection close reason
Web Workers

The following terms are defined in Web Workers: [WEBWORKERS]

  • Worker
  • closing
2D Context

The following terms are defined in 2D Context: [CANVAS2D]

  • Set bitmap dimensions
Web Messaging

The following terms are defined in Web Messaging: [WEBMSG]

  • MessagePort
ARIA

The terms strong native semantics is used as defined in the ARIA specification. The term default implicit ARIA semantics has the same meaning as the term implicit WAI-ARIA semantics as used in the ARIA specification. [ARIA]

The role and aria-* attributes are defined in the ARIA specification. [ARIA]

This specification does not require support of any particular network protocol, style sheet language, scripting language, or any of the DOM specifications beyond those required in the list above. However, the language described by this specification is biased towards CSS as the styling language, JavaScript as the scripting language, and HTTP as the network protocol, and several features assume that those languages and protocols are in use.

A user agent that implements the HTTP protocol must implement the Web Origin Concept specification and the HTTP State Management Mechanism specification (Cookies) as well. [HTTP] [ORIGIN] [COOKIES]

This specification might have certain additional requirements on character encodings, image formats, audio formats, and video formats in the respective sections.

2.2.3 拡張性

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

If such extensions are nonetheless needed, e.g. for experimental purposes, then vendors are strongly urged to use one of the following extension mechanisms:

Attribute names beginning with the two characters "x-" are reserved for user agent use and are guaranteed to never be formally added to the HTML language. For flexibility, attributes names containing underscores (the U+005F LOW LINE character) are also reserved for experimental purposes and are guaranteed to never be formally added to the HTML language.

Pages that use such attributes are by definition non-conforming.

For DOM extensions, e.g. new methods and IDL attributes, the new members should be prefixed by vendor-specific strings to prevent clashes with future versions of this specification.

For events, experimental event types should be prefixed with vendor-specific strings.

For example, if a user agent called "Pleasold" were to add an event to indicate when the user is going up in an elevator, it could use the prefix "pleasold" and thus name the event "pleasoldgoingup", possibly with an event handler attribute named "onpleasoldgoingup".

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 "Foo Browser" could add a new IDL attribute "fooTypeTime" to a control's DOM interface 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.

When adding new reflecting IDL attributes corresponding to content attributes of the form "x-vendor-feature", the IDL attribute should be named "vendorFeature" (i.e. the "x" is dropped from the IDL attribute's name).


この仕様にベンダー中立の拡張が必要になった場合、この仕様が状況に応じて更新されうる、または拡張仕様がこの仕様の要求を上書きされうるかのいずれかである。When someone applying this specification to their activities decides that they will recognize the requirements of such an extension specification, it becomes an applicable specification.

文書に対する適合用語は、そのような適用可能な仕様によって導入される変更の性質、およびコンテンツと意図される文書の解釈に依存する。適用可能な仕様は、新しい文書コンテンツ(たとえばfoobar要素)を定義してもよく、特定のほかの適合コンテンツを禁止してもよく(たとえば<TABLE>の使用を禁止する)、この仕様で定義されるコンテンツに対するセマンティック、DOMの変換、または処理規則を変更してもよい。文書が、適用可能な仕様の用途に依存しない適合HTML5文書であるかどうか:与えられた適合HTML5文書の構文およびセマンティックが、適用可能な仕様の使用によって変更されない場合、その文書は適合HTML5文書のままである。与えられた(ほかの適合)文書のセマンティックまたは処理が、適用可能な仕様の使用によって変更される場合、それは適合HTML5文書ではない。このような場合、その適用可能な仕様は、適合用語を定義すべきである。

As a suggested but not required convention, such specifications might define conformance terminology such as: "Conforming HTML5+XXX document", where XXX is a short name for the applicable specification. (例:"適合HTML5+自動拡張文書")。

上に与えられる規則の結果は、特定の文法的に正しいHTML5文書が適用可能な仕様の存在下で適合HTML5文書でないかもしれない。(例:適用可能な仕様がひとまとまりの付属品のように<table>を定義する―たとえ要素がHTML5の構文的に正しく生じても、その仕様書に書かれてかつ<table>要素を含む文書は、適合HTML5文書ではない。)


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.2.4 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 set the current document readiness first to "interactive" and then to "complete" if they are aborted.


This specification does not specify how XSLT interacts with the navigation algorithm, how it fits in with the event loop, nor how error pages are to be handled (e.g. whether XSLT errors are to replace an incremental XSLT output, or are rendered inline, etc).

There are also additional non-normative comments regarding the interaction of XSLT and HTML in the script element section, and of XSLT, XPath, and HTML in the template element section.

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

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

ASCII大文字・小文字区別において2つの文字列を比較する方法は、コードポイントごとに正確に比較することを意味し、U+0041からU+005Aまでの範囲(すなわちLATIN CAPITAL LETTER AからLATIN CAPITAL LETTER Zまで)を除いて、U+0061からU+007Aまでの範囲(すなわちLATIN SMALL LETTER AからLATIN SMALL LETTER Zまで)において一致する文字も一致するとみなされる。

互換性大文字・小文字不区別で2つの文字列を比較する方法は、言語固有の手直し(tailoring)なしで、2つの文字列を比較するためにUnicode互換性大文字・小文字不区別一致操作を使用することを意味する。[UNICODE]

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

Converting a string to ASCII uppercase means replacing all characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z) with the corresponding characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z).

Converting a string to ASCII lowercase means replacing all characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) with the corresponding characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z).

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

2.4 共通マイクロ構文

日付や数字など、HTMLには特定のデータ型を受け入れるさまざまな箇所がある。この節では、これら形式の内容の適合基準が何か、そしてどのように解析するかを説明する。

Implementors are strongly urged to carefully examine any third-party libraries they might consider using to implement the parsing of syntaxes described below. For example, date libraries are likely to implement error handling behavior that differs from what is required in this specification, since error-handling behavior is often not defined in specifications that describe date syntaxes similar to those used in this specification, and thus implementations tend to vary greatly in how they handle errors.

2.4.1 Common parser idioms

この仕様の用途において、空白文字は、U+0020 SPACE、"tab"(U+0009)、"LF"(U+000A)、"FF"(U+000C)、"CR"(U+000D)である。

空白類文字は、UnicodeのPropList.txtデータファイルでUnicodeプロパティー"White_Space"を持つものである。[UNICODE]

これはUnicode.txtデータファイルでの"Bidi_Class"プロパティーの"White_Space"値("WS"と略される)と混同されるべきでない。

制御文字とは、UnicodeのUnicodeData.txtデータファイルでUnicodeの"White_Space"プロパティーを持つものである。[UNICODE]

大文字のASCII文字は、範囲大文字のASCII文字における文字である。

小文字のASCII文字は、範囲小文字のASCII文字における文字である。

ASCII数字は、範囲ASCII数字における文字である。

英数字のASCII文字は、大文字のASCII文字小文字のASCII文字、またはASCII数字のいずれかである。

ASCII16進数字は、ASCII 数字、U+0041 LATIN CAPITAL LETTER AからU+0046 LATIN CAPITAL LETTERまで、およびU+0061 LATIN SMALL LETTER AからU+0066 LATIN SMALL LETTER Fまでの範囲の文字である。

大文字のASCII16進数字は、範囲ASCII数字およびU+0041 LATIN CAPITAL LETTER AからU+0046 LATIN CAPITAL LETTER Fまでのみの文字である。

小文字のASCII16進数字は、範囲ASCII数字およびU+0061 LATIN SMALL LETTER AからU+0066 LATIN SMALL LETTER Fまでのみの文字である。

Some of the micro-parsers described below follow the pattern of having an input variable that holds the string being parsed, and having a position variable pointing at the next character to parse in input.

For parsers based on this pattern, a step that requires the user agent to collect a sequence of characters means that the following algorithm must be run, with characters being the set of characters that can be collected:

  1. Let input and position be the same variables as those of the same name in the algorithm that invoked these steps.

  2. Let result be the empty string.

  3. While position doesn't point past the end of input and the character at position is one of the characters, append that character to the end of result and advance position to the next character in input.

  4. Return result.

The step skip whitespace means that the user agent must collect a sequence of characters that are space characters. The collected characters are not used.

When a user agent is to strip line breaks from a string, the user agent must remove any "LF" (U+000A) and "CR" (U+000D) characters from that string.

When a user agent is to strip leading and trailing whitespace from a string, the user agent must remove all space characters that are at the start or end of the string.

When a user agent is to strip and collapse whitespace in a string, it must replace any sequence of one or more consecutive space characters in that string with a single U+0020 SPACE character, and then strip leading and trailing whitespace from that string.

When a user agent has to strictly split a string on a particular delimiter character delimiter, it must use the following algorithm:

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Let tokens be an ordered list of tokens, initially empty.

  4. While position is not past the end of input:

    1. Collect a sequence of characters that are not the delimiter character.

    2. Append the string collected in the previous step to tokens.

    3. Advance position to the next character in input.

  5. Return tokens.

For the special cases of splitting a string on spaces and on commas, this algorithm does not apply (those algorithms also perform whitespace trimming).

2.4.2 真偽属性

いくつかの属性は真偽属性である。要素での真偽属性の存在は真の値を表し、属性の不在は偽の値を表す。

属性が存在する場合、その値は先頭または末尾の空白なしで、空の文字列または属性の正規名にASCII大文字・小文字不区別でマッチする値でなければならない。

値"true"および"false"は真偽属性で許可されない。偽の値を表すため、属性は完全に省略される必要がある。

checkedおよびdisabledとなるチェックボックスの例を示す。checkedおよびdisabled属性は真偽属性である。

<label><input type=checkbox checked name=cheese disabled> Cheese</label>

これは次に書かれるものと等価であるべきである:

<label><input type=checkbox checked=checked name=cheese disabled=disabled> Cheese</label>

スタイルを混在させることもできる。以下は依然として等価である:

<label><input type='checkbox' checked name=cheese disabled=""> Cheese</label>

2.4.3 キーワードおよび列挙属性

一部の属性は、有限集合のキーワードのいずれかを取るように定義されている。このような属性は列挙属性と呼ばれる。キーワードは、特定の状態にそれぞれ対応付けて定義される(キーワードの一部が互いに同義語となる場合、複数のキーワードは同じ状態に対応づけられる。加えて、一部のキーワードは不適合であると言うことができる。これは、歴史的な理由のためだけの仕様である)。さらに、2つのデフォルト状態を挙げることができる。1つは妥当でない値のデフォルトであり、もう1つは欠落した値のデフォルトである。

列挙属性が指定される場合、属性値は、先行または後続の空白なしで、不適合でないとされる与えられたキーワードのいずれかとASCII大文字・小文字不区別で一致しなければならない。

属性が指定される際に、その値が与えられたキーワードのいずれかとASCII大文字・小文字不区別で一致する場合、属性のキーワードの状態は、属性が表す状態である。属性値が与えられたキーワードのいずれにも一致しないが、属性が妥当でない値のデフォルトを持つ場合、その属性はその状態を表す。そうでなければ、属性値がキーワードのいずれにも一致しないが欠落値のデフォルト状態定義が存在する場合、それは属性によって表される状態である。そうでなければ、デフォルトは存在せず、何も表さない状態を意味する妥当でない値である。

属性が指定されない際に、欠落値のデフォルト定義状態がある場合、それは(欠落)属性によって表される状態である。そうでなければ、属性の不在は何も状態を表さないことを意味する。

空文字列は妥当なキーワードとなりうる。

2.4.4 数字

2.4.4.1 符号付き整数

文字列が1つ以上のASCII 数字、任意で接頭辞"-"(U+002D)文字を持つ場合、文字列は妥当な整数である。

"-"(U+002D)接頭辞なしの妥当な整数は、10進数を表す。"-"(U+002D)接頭辞あり妥当な整数は、U+002D HYPHEN-MINUSに続く10進数を表し、ゼロから減算される。

The rules for parsing integers are as given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will return either an integer or an error.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Let sign have the value "positive".

  4. Skip whitespace.

  5. If position is past the end of input, return an error.

  6. If the character indicated by position (the first character) is a "-" (U+002D) character:

    1. Let sign be "negative".
    2. Advance position to the next character.
    3. If position is past the end of input, return an error.

    Otherwise, if the character indicated by position (the first character) is a "+" (U+002B) character:

    1. Advance position to the next character. (The "+" is ignored, but it is not conforming.)
    2. If position is past the end of input, return an error.
  7. If the character indicated by position is not an ASCII digit, then return an error.

  8. Collect a sequence of characters that are ASCII digits, and interpret the resulting sequence as a base-ten integer. Let value be that integer.

  9. If sign is "positive", return value, otherwise return the result of subtracting value from zero.

2.4.4.2 非負整数

1つ以上のASCII数字からなる場合、文字列は妥当な非負整数である。

妥当な非負整数は、10進数である数を表す。

The rules for parsing non-negative integers are as given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will return either zero, a positive integer, or an error.

  1. Let input be the string being parsed.

  2. Let value be the result of parsing input using the rules for parsing integers.

  3. If value is an error, return an error.

  4. If value is less than zero, return an error.

  5. Return value.

2.4.4.3 浮動小数点数

次の場合、文字列は妥当な浮動小数点数である:

  1. 任意で、"-"(U+002D)文字。
  2. 次のいずれかまたは両方の、与えられた順:
    1. ひと続きの1つ以上のASCII数字
      1. 1つの"."(U+002E)文字。
      2. ひと続きの1つ以上のASCII数字
  3. 任意で:
    1. "e"(U+0065)文字または"E"(U+0045)文字のいずれか。
    2. 任意で、"-"(U+002D)文字または"+"(U+002B)文字。
    3. ひと続きの1つ以上のASCII数字

妥当な浮動小数点数は、10の累乗による仮数部の乗算によって得られる。ここで乗算は最初の数であり、10進数として解釈される(もしあれば、小数点および小数点の後の数を含み、文字列全体が"-"(U+002D)文字で始まるおよび数値がゼロでない場合、負数として仮数部を解釈する)。またここで、もしあれば、指数はEの後の数字である(Eと数字と数字の間に"-"(U+002D)文字がある場合、負数として解釈され、数字がゼロでない、またはその他Eと数字の間に"+"(U+002B)文字が存在する場合無視できる)。Eが存在しない場合、指数はゼロとして扱われる。

無限大および非数(NaN)値は妥当な浮動小数点数ではない。

The best representation of the number n as a floating-point number is the string obtained from applying the JavaScript operator ToString to n. The JavaScript operator ToString is not uniquely determined. When there are multiple possible strings that could be obtained from the JavaScript operator ToString for a particular value, the user agent must always return the same string for that value (though it may differ from the value used by other user agents).

The rules for parsing floating-point number values are as given in the following algorithm. This algorithm must be aborted at the first step that returns something. This algorithm will return either a number or an error.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Let value have the value 1.

  4. Let divisor have the value 1.

  5. Let exponent have the value 1.

  6. Skip whitespace.

  7. If position is past the end of input, return an error.

  8. If the character indicated by position is a U+002D HYPHEN-MINUS character (-):

    1. Change value and divisor to −1.
    2. Advance position to the next character.
    3. If position is past the end of input, return an error.

    Otherwise, if the character indicated by position (the first character) is a "+" (U+002B) character:

    1. Advance position to the next character. (The "+" is ignored, but it is not conforming.)
    2. If position is past the end of input, return an error.
  9. If the character indicated by position is a "." (U+002E), and that is not the last character in input, and the character after the character indicated by position is an ASCII digit, then set value to zero and jump to the step labeled fraction.

  10. If the character indicated by position is not an ASCII digit, then return an error.

  11. Collect a sequence of characters that are ASCII digits, and interpret the resulting sequence as a base-ten integer. Multiply value by that integer.

  12. If position is past the end of input, jump to the step labeled conversion.
  13. Fraction: If the character indicated by position is a "." (U+002E), run these substeps:

    1. Advance position to the next character.

    2. If position is past the end of input, or if the character indicated by position is not an ASCII digit, "e" (U+0065), or "E" (U+0045), then jump to the step labeled conversion.

    3. If the character indicated by position is a "e" (U+0065) character or a "E" (U+0045) character, skip the remainder of these substeps.

    4. Fraction loop: Multiply divisor by ten.

    5. Add the value of the character indicated by position, interpreted as a base-ten digit (0..9) and divided by divisor, to value.
    6. Advance position to the next character.

    7. If position is past the end of input, then jump to the step labeled conversion.

    8. If the character indicated by position is an ASCII digit, jump back to the step labeled fraction loop in these substeps.

  14. If the character indicated by position is a "e" (U+0065) character or a "E" (U+0045) character, run these substeps:

    1. Advance position to the next character.

    2. If position is past the end of input, then jump to the step labeled conversion.

    3. If the character indicated by position is a "-" (U+002D) character:

      1. Change exponent to −1.
      2. Advance position to the next character.
      3. If position is past the end of input, then jump to the step labeled conversion.

      Otherwise, if the character indicated by position is a "+" (U+002B) character:

      1. Advance position to the next character.
      2. If position is past the end of input, then jump to the step labeled conversion.

    4. If the character indicated by position is not an ASCII digit, then jump to the step labeled conversion.

    5. Collect a sequence of characters that are ASCII digits, and interpret the resulting sequence as a base-ten integer. Multiply exponent by that integer.

    6. Multiply value by ten raised to the exponentth power.

  15. Conversion: Let S be the set of finite IEEE 754 double-precision floating-point values except −0, but with two special values added: 21024 and −21024.

  16. Let rounded-value be the number in S that is closest to value, selecting the number with an even significand if there are two equally close values. (The two special values 21024 and −21024 are considered to have even significands for this purpose.)

  17. If rounded-value is 21024 or −21024, return an error.

  18. Return rounded-value.

2.4.4.4 Percentages and lengths

The rules for parsing dimension values are as given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will return either a number greater than or equal to 1.0, or an error; if a number is returned, then it is further categorized as either a percentage or a length.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Skip whitespace.

  4. If position is past the end of input, return an error.

  5. If the character indicated by position is a U+002B PLUS SIGN character (+), advance position to the next character.

  6. Collect a sequence of characters that are "0" (U+0030) characters, and discard them.

  7. If position is past the end of input, return an error.

  8. If the character indicated by position is not one of "1" (U+0031) to "9" (U+0039), then return an error.

  9. Collect a sequence of characters that are ASCII digits, and interpret the resulting sequence as a base-ten integer. Let value be that number.

  10. If position is past the end of input, return value as a length.

  11. If the character indicated by position is a U+002E FULL STOP character (.):

    1. Advance position to the next character.

    2. If position is past the end of input, or if the character indicated by position is not an ASCII digit, then return value as a length.

    3. Let divisor have the value 1.

    4. Fraction loop: Multiply divisor by ten.

    5. Add the value of the character indicated by position, interpreted as a base-ten digit (0..9) and divided by divisor, to value.
    6. Advance position to the next character.

    7. If position is past the end of input, then return value as a length.

    8. If the character indicated by position is an ASCII digit, return to the step labeled fraction loop in these substeps.

  12. If position is past the end of input, return value as a length.

  13. If the character indicated by position is a "%" (U+0025) character, return value as a percentage.

  14. Return value as a length.

2.4.4.5 整数リスト

妥当な整数リストは、U+002C COMMA文字によって区切られる多数の妥当な整数であり、他の文字を持たない(たとえば空白文字のない)。さらに、与えられる整数の数、または許可される値の範囲には制限があるかもしれない。

The rules for parsing a list of integers are as follows:

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Let numbers be an initially empty list of integers. This list will be the result of this algorithm.

  4. If there is a character in the string input at position position, and it is either a U+0020 SPACE, U+002C COMMA, or U+003B SEMICOLON character, then advance position to the next character in input, or to beyond the end of the string if there are no more characters.

  5. If position points to beyond the end of input, return numbers and abort.

  6. If the character in the string input at position position is a U+0020 SPACE, U+002C COMMA, or U+003B SEMICOLON character, then return to step 4.

  7. Let negated be false.

  8. Let value be 0.

  9. Let started be false. This variable is set to true when the parser sees a number or a "-" (U+002D) character.

  10. Let got number be false. This variable is set to true when the parser sees a number.

  11. Let finished be false. This variable is set to true to switch parser into a mode where it ignores characters until the next separator.

  12. Let bogus be false.

  13. Parser: If the character in the string input at position position is:

    A U+002D HYPHEN-MINUS character

    Follow these substeps:

    1. If got number is true, let finished be true.
    2. If finished is true, skip to the next step in the overall set of steps.
    3. If started is true, let negated be false.
    4. Otherwise, if started is false and if bogus is false, let negated be true.
    5. Let started be true.
    An ASCII digit

    Follow these substeps:

    1. If finished is true, skip to the next step in the overall set of steps.
    2. Multiply value by ten.
    3. Add the value of the digit, interpreted in base ten, to value.
    4. Let started be true.
    5. Let got number be true.
    A U+0020 SPACE character
    A U+002C COMMA character
    A U+003B SEMICOLON character

    Follow these substeps:

    1. If got number is false, return the numbers list and abort. This happens if an entry in the list has no digits, as in "1,2,x,4".
    2. If negated is true, then negate value.
    3. Append value to the numbers list.
    4. Jump to step 4 in the overall set of steps.
    A character in the range U+0001 to U+001F, U+0021 to U+002B, U+002D to U+002F, U+003A, U+003C to U+0040, U+005B to U+0060, U+007b to U+007F (i.e. any other non-alphabetic ASCII character)

    Follow these substeps:

    1. If got number is true, let finished be true.
    2. If finished is true, skip to the next step in the overall set of steps.
    3. Let negated be false.
    Any other character

    Follow these substeps:

    1. If finished is true, skip to the next step in the overall set of steps.
    2. Let negated be false.
    3. Let bogus be true.
    4. If started is true, then return the numbers list, and abort. (The value in value is not appended to the list first; it is dropped.)
  14. Advance position to the next character in input, or to beyond the end of the string if there are no more characters.

  15. If position points to a character (and not to beyond the end of input), jump to the big Parser step above.

  16. If negated is true, then negate value.

  17. If got number is true, then append value to the numbers list.

  18. Return the numbers list and abort.

2.4.4.6 Lists of dimensions

The rules for parsing a list of dimensions are as follows. These rules return a list of zero or more pairs consisting of a number and a unit, the unit being one of percentage, relative, and absolute.

  1. Let raw input be the string being parsed.

  2. If the last character in raw input is a "," (U+002C) character, then remove that character from raw input.

  3. Split the string raw input on commas. Let raw tokens be the resulting list of tokens.

  4. Let result be an empty list of number/unit pairs.

  5. For each token in raw tokens, run the following substeps:

    1. Let input be the token.

    2. Let position be a pointer into input, initially pointing at the start of the string.

    3. Let value be the number 0.

    4. Let unit be absolute.

    5. If position is past the end of input, set unit to relative and jump to the last substep.

    6. If the character at position is an ASCII digit, collect a sequence of characters that are ASCII digits, interpret the resulting sequence as an integer in base ten, and increment value by that integer.

    7. If the character at position is a "." (U+002E) character, run these substeps:

      1. Collect a sequence of characters consisting of space characters and ASCII digits. Let s be the resulting sequence.

      2. Remove all space characters in s.

      3. If s is not the empty string, run these subsubsteps:

        1. Let length be the number of characters in s (after the spaces were removed).

        2. Let fraction be the result of interpreting s as a base-ten integer, and then dividing that number by 10length.

        3. Increment value by fraction.

    8. Skip whitespace.

    9. If the character at position is a "%" (U+0025) character, then set unit to percentage.

      Otherwise, if the character at position is a U+002A ASTERISK character (*), then set unit to relative.

    10. Add an entry to result consisting of the number given by value and the unit given by unit.

  6. Return the list result.

2.4.5 日付および時刻

下記のアルゴリズムにおいて、yearの月monthの日数は:monthが1、3、5、7、8、10、12ならば31である。monthが4、6、9、11ならば30である。monthが2かつyearが400で割り切れる数、またはyearが4で割り切れるが100で割り切れないならば29であり、そうでなければ28である。これは、グレゴリオ暦の閏年を考慮に入れている。[GREGORIAN]

ASCII数字がこの節で定義される日付および時刻の構文で使用される場合、これらは10進数で表現される。

While the formats described here are intended to be subsets of the corresponding ISO8601 formats, this specification defines parsing rules in much more detail than ISO8601. Implementors are therefore encouraged to carefully examine any date parsing libraries before using them to implement the parsing rules described below; ISO8601 libraries might not parse dates and times in exactly the same manner. [ISO8601]

この仕様が先発グレゴリオ暦を参照する場合、これは、1年に遡って挿入された現代のグレゴリオ暦を意味する。先発グレゴリオ日付として明示的に参照される先発グレゴリオ暦での日付は、たとえ暦が問題の時刻(または場所)で使用されていないとしても、その暦を使用して説明される。[GREGORIAN]

この仕様においてワイヤ形式としてのグレゴリオ暦の使用は、決定に関わる人々の文化的なバイアスに起因する恣意的な選択肢である。See also the section discussing date, time, and number formats in forms (for authors), implemention notes regarding localization of form controls, and the time element.

2.4.5.1

は、タイムゾーン情報および年と月を超えた日付を持たない、特定の先発グレゴリオ暦から成る。[GREGORIAN]

与えられた順で以下のコンポーネントからなる場合、文字列は、年yearおよび月monthで表される妥当な月文字列である:

  1. 4以上で表されるyear。ここでyear > 0である。
  2. "-"(U+002D)文字
  3. 1 ≤ month ≤ 12の範囲で、月monthを表す2つのASCII数字

The rules to parse a month string are as follows. This will return either a year and month, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Parse a month component to obtain year and month. If this returns nothing, then fail.

  4. If position is not beyond the end of input, then fail.

  5. Return year and month.

The rules to parse a month component, given an input string and a position, are as follows. This will return either a year and a month, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Collect a sequence of characters that are ASCII digits. If the collected sequence is not at least four characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the year.

  2. If year is not a number greater than zero, then fail.

  3. If position is beyond the end of input or if the character at position is not a U+002D HYPHEN-MINUS character, then fail. Otherwise, move position forwards one character.

  4. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the month.

  5. If month is not a number in the range 1 ≤ month ≤ 12, then fail.

  6. Return year and month.

2.4.5.2 日付

日付は、年月日からなりタイムゾーン情報を持たない、特定の先発グレゴリオ暦からなる。[GREGORIAN]

与えられた順で以下のコンポーネントからなる場合、文字列は年year、月month、日dayで表される妥当な日付文字列である:

  1. yearおよびmonthで表される、妥当な月文字列
  2. "-"(U+002D)文字
  3. 1 ≤ day ≤ maxdayの範囲でのdayで表される2つのASCII数字。ここでmaxdayyearおよび月monthでの日の数である。

The rules to parse a date string are as follows. This will return either a date, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Parse a date component to obtain year, month, and day. If this returns nothing, then fail.

  4. If position is not beyond the end of input, then fail.

  5. Let date be the date with year year, month month, and day day.

  6. Return date.

The rules to parse a date component, given an input string and a position, are as follows. This will return either a year, a month, and a day, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Parse a month component to obtain year and month. If this returns nothing, then fail.

  2. Let maxday be the number of days in month month of year year.

  3. If position is beyond the end of input or if the character at position is not a U+002D HYPHEN-MINUS character, then fail. Otherwise, move position forwards one character.

  4. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the day.

  5. If day is not a number in the range 1 ≤ day ≤ maxday, then fail.

  6. Return year, month, and day.

2.4.5.3 年なし日付

年なし日付はグレコリオ月とその月の日からなるが、年を伴わない。[GREGORIAN]

与えられた順で以下のコンポーネントからなる場合、文字列は月monthおよび日dayで表される妥当な年なし日付文字列である:

  1. 任意で、2つの"-"(U+002D)文字
  2. 1 ≤ month ≤ 12の範囲で、月monthを表す2つのASCII数字
  3. "-"(U+002D)文字
  4. 1 ≤ day ≤ maxdayの範囲でのdayで表される2つのASCII数字。ここでmaxdayは月monthかつ任意の閏年(たとえば4または2000)における日数である。

言い換えると、2月を意味するmonthが"02"である場合、あたかもその年は閏年かのように、日は29であってもよい。

The rules to parse a yearless date string are as follows. This will return either a month and a day, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Parse a yearless date component to obtain month and day. If this returns nothing, then fail.

  4. If position is not beyond the end of input, then fail.

  5. Return month and day.

The rules to parse a yearless date component, given an input string and a position, are as follows. This will return either a month and a day, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Collect a sequence of characters that are "-" (U+002D) characters. If the collected sequence is not exactly zero or two characters long, then fail.

  2. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the month.

  3. If month is not a number in the range 1 ≤ month ≤ 12, then fail.

  4. Let maxday be the number of days in month month of any arbitrary leap year (e.g. 4 or 2000).

  5. If position is beyond the end of input or if the character at position is not a U+002D HYPHEN-MINUS character, then fail. Otherwise, move position forwards one character.

  6. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the day.

  7. If day is not a number in the range 1 ≤ day ≤ maxday, then fail.

  8. Return month and day.

2.4.5.4 時刻

時刻は、時、分、秒、秒以下からなりタイムゾーン情報を持たない、特定の時刻からなる。

与えられた順で以下のコンポーネントからなる場合、文字列は、時hour、分minute、秒secondで表される妥当な時刻文字列である:

  1. 0 ≤ hour ≤ 23の範囲で、hourを表す2つのASCII数字
  2. ":"(U+003A)文字
  3. 0 ≤ minute ≤ 59の範囲でminuteを表す2つのASCII数字
  4. 任意で(secondが非ゼロの場合必要):
    1. ":"(U+003A)文字
    2. 0 ≤ s ≤ 59の範囲で、second整数部を表す2つのASCII数字
    3. 任意で(secondが整数でない場合必要):
      1. U+002E FULL STOP文字(.)
      2. second分数部で表される、1、2、また3

secondコンポーネントは60または61にはなり得ない。閏秒を表すことはできない。

The rules to parse a time string are as follows. This will return either a time, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Parse a time component to obtain hour, minute, and second. If this returns nothing, then fail.

  4. If position is not beyond the end of input, then fail.

  5. Let time be the time with hour hour, minute minute, and second second.

  6. Return time.

The rules to parse a time component, given an input string and a position, are as follows. This will return either an hour, a minute, and a second, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the hour.

  2. If hour is not a number in the range 0 ≤ hour ≤ 23, then fail.
  3. If position is beyond the end of input or if the character at position is not a U+003A COLON character, then fail. Otherwise, move position forwards one character.

  4. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the minute.

  5. If minute is not a number in the range 0 ≤ minute ≤ 59, then fail.
  6. Let second be a string with the value "0".

  7. If position is not beyond the end of input and the character at position is a U+003A COLON, then run these substeps:

    1. Advance position to the next character in input.

    2. If position is beyond the end of input, or at the last character in input, or if the next two characters in input starting at position are not both ASCII digits, then fail.

    3. Collect a sequence of characters that are either ASCII digits or U+002E FULL STOP characters. If the collected sequence is three characters long, or if it is longer than three characters long and the third character is not a U+002E FULL STOP character, or if it has more than one U+002E FULL STOP character, then fail. Otherwise, let the collected string be second instead of its previous value.

  8. Interpret second as a base-ten number (possibly with a fractional part). Let second be that number instead of the string version.

  9. If second is not a number in the range 0 ≤ second < 60, then fail.

  10. Return hour, minute, and second.

2.4.5.5 浮動日付および時刻

浮動日付および時刻は、年、月、日、時、分、秒、秒以下からなる特定の先発グレコリオ暦からなるが、タイムゾーン情報を持たない。[GREGORIAN]

与えられた順で以下のコンポーネントからなる場合、文字列は妥当な浮動日付および時刻文字列である:

  1. 日付を表す妥当な日付文字列
  2. "T"(U+0054)文字またはU+0020 SPACE文字
  3. 時刻を表す妥当な時刻文字列

与えられた順で以下のコンポーネントからなる場合、文字列は妥当な規格化浮動日付および時刻文字列である:

  1. 日付を表す妥当な日付文字列
  2. "T"(U+0054)文字
  3. 時刻を表す妥当な時間文字列は、与えられた時刻に対して可能な限り最短の文字列として表現される(たとえば、与えられた時刻がゼロ秒分を過ぎている場合、完全に秒のコンポーネントを省略する)

The rules to parse a floating date and time string are as follows. This will return either a date and time, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Parse a date component to obtain year, month, and day. If this returns nothing, then fail.

  4. If position is beyond the end of input or if the character at position is neither a U+0054 LATIN CAPITAL LETTER T character (T) nor a U+0020 SPACE character, then fail. Otherwise, move position forwards one character.

  5. Parse a time component to obtain hour, minute, and second. If this returns nothing, then fail.

  6. If position is not beyond the end of input, then fail.

  7. Let date be the date with year year, month month, and day day.

  8. Let time be the time with hour hour, minute minute, and second second.

  9. Return date and time.

2.4.5.6 タイムゾーン

タイムゾーンオフセットは符号付きの時と分の数字からなる。

次のいずれかからなる場合、文字列は、タイムゾーンオフセットを表す妥当なタイムゾーンオフセット文字列である:

この形式は、-23:59から+23:59までのタイムゾーンオフセットを許可する。しかし、特に、実際のタイムゾーンオフセットの範囲は-12:00から+14:00までであり、実際のタイムゾーンオフセットの分コンポーネントは常に00、30または45のいずれかである。とはいえ、永遠に保持される保証はない。タイムゾーンは国によって思いのままに変更され、標準に従わない。

正式なタイムゾーンの形成以前に遡る歴史的な時代でのタイムゾーンのオフセットを使用についての詳細は、下記のグローバル日付および時刻の節にある使用上の注意と例を参照のこと。

The rules to parse a time-zone offset string are as follows. This will return either a time-zone offset, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Parse a time-zone offset component to obtain timezonehours and timezoneminutes. If this returns nothing, then fail.

  4. If position is not beyond the end of input, then fail.

  5. Return the time-zone offset that is timezonehours hours and timezoneminutes minutes from UTC.

The rules to parse a time-zone offset component, given an input string and a position, are as follows. This will return either time-zone hours and time-zone minutes, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. If the character at position is a U+005A LATIN CAPITAL LETTER Z character (Z), then:

    1. Let timezonehours be 0.

    2. Let timezoneminutes be 0.

    3. Advance position to the next character in input.

    Otherwise, if the character at position is either a "+" (U+002B) or a "-" (U+002D), then:

    1. If the character at position is a "+" (U+002B), let sign be "positive". Otherwise, it's a "-" (U+002D); let sign be "negative".

    2. Advance position to the next character in input.

    3. Collect a sequence of characters that are ASCII digits. Let s be the collected sequence.

    4. If s is exactly two characters long, then run these substeps:

      1. Interpret s as a base-ten integer. Let that number be the timezonehours.

      2. If position is beyond the end of input or if the character at position is not a U+003A COLON character, then fail. Otherwise, move position forwards one character.

      3. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the timezoneminutes.

      If s is exactly four characters long, then run these substeps:

      1. Interpret the first two characters of s as a base-ten integer. Let that number be the timezonehours.

      2. Interpret the last two characters of s as a base-ten integer. Let that number be the timezoneminutes.

      Otherwise, fail.

    5. If timezonehours is not a number in the range 0 ≤ timezonehours ≤ 23, then fail.
    6. If sign is "negative", then negate timezonehours.
    7. If timezoneminutes is not a number in the range 0 ≤ timezoneminutes ≤ 59, then fail.
    8. If sign is "negative", then negate timezoneminutes.

    Otherwise, fail.

  2. Return timezonehours and timezoneminutes.

2.4.5.7 グローバル日付および時刻

グローバル日付および時刻は、符号付き時分からなるタイムゾーンオフセットとともに年、月、日、時、分、秒、秒以下からなる特定先発グレコリオ暦で構成する。[GREGORIAN]

与えられた順で以下のコンポーネントからなる場合、日付、時刻、タイムゾーンオフセットを表す文字列は妥当なグローバル日付および時刻である:

  1. 日付を表す妥当な日付文字列
  2. "T"(U+0054)文字またはU+0020 SPACE文字
  3. 時刻を表す妥当な時刻文字列
  4. タイムゾーンオフセットを表す妥当なタイムゾーンオフセット文字列

20世紀半ばにUTCを形成する前の日付の時刻は、UTC(UT1の近似がSI秒を刻む)ではなく、UT1(0°経度での現代の地球太陽時)の見地から表現および解釈されなければならない。タイムゾーンを形成する前の時刻は、適切なローカル時刻とロンドンのグリニッジで観測された時間との間のおおよその現代的な違いのある明示的なタイムゾーンとともにUT1の時間として表現および解釈されなければならない。

以下は妥当なグローバル日付および時刻として記述される例の一部である。

"0037-12-13 00:00Z"
ネロ(ローマ皇帝)の誕生日にロンドン時間を用いた地域での真夜中。これが実際に対応している日付のさらなる議論については下記を参照のこと。
"1979-10-14T12:00:00.001-04:00"
夏時間の間にアメリカ東海岸で使用されるタイムゾーンで、1979年10月14日の正午1ミリ秒後。
"8592-01-01T02:09+02:09"
8592年1月1日のUTCで夜中。現在の実際のタイムゾーンではない、UTCより早く時刻が2時9分であるタイムゾーンに関連づけられるが、それでもなお、許可される。

数点の以下の日付に関して顕著である:

ゾーンオフセットは、完全なタイムゾーンの仕様ではない。現実の日付と時刻の値を操作する場合、できればIANAのタイムゾーンIDを使用して、タイムゾーンごとに個別のフィールドの使用を検討すること。[TIMEZONES]

与えられた順で以下のコンポーネントから構成される場合、日付、時刻、タイムゾーンオフセットを表す文字列は妥当なUTCに正規化されたグローバル日付および時刻である:

  1. UTCタイムゾーンに変換された日付を表す妥当な日付文字列
  2. "T"(U+0054)文字
  3. UTCタイムゾーンに変換されるおよび与えられた時刻に対して可能な限り最短として表現される時刻(たとえば、与えられた時刻が時間を過ぎたゼロ秒である場合、完全に秒のコンポーネントを省略する)を表す妥当な時刻文字列
  4. "Z"(U+005A)文字

The rules to parse a global date and time string are as follows. This will return either a time in UTC, with associated time-zone offset information for round-tripping or display purposes, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Parse a date component to obtain year, month, and day. If this returns nothing, then fail.

  4. If position is beyond the end of input or if the character at position is neither a U+0054 LATIN CAPITAL LETTER T character (T) nor a U+0020 SPACE character, then fail. Otherwise, move position forwards one character.

  5. Parse a time component to obtain hour, minute, and second. If this returns nothing, then fail.

  6. If position is beyond the end of input, then fail.

  7. Parse a time-zone offset component to obtain timezonehours and timezoneminutes. If this returns nothing, then fail.

  8. If position is not beyond the end of input, then fail.

  9. Let time be the moment in time at year year, month month, day day, hours hour, minute minute, second second, subtracting timezonehours hours and timezoneminutes minutes. That moment in time is a moment in the UTC time zone.

  10. Let timezone be timezonehours hours and timezoneminutes minutes from UTC.

  11. Return time and timezone.

2.4.5.8

は、週番号年と週番号からなる。週番号は、月曜日から始まる7日間を示す。以下の定義に従って、このカレンダーシステムにおける週番号年は52または53の7日間を持つ。グレゴリオ暦の日付で1969年12月29日(1969-12-29)月曜日で始まる7日間は、1970週番号年で週番号1として定義される。連続した週は連番が付けられる。週番号年で1週目の前の週は、前の週番号年の最終週である。逆もまた同様である。[GREGORIAN]

最初の日(1月1日)が木曜である先発グレコリオ暦の年year、または最初の日(1月1日)が木曜である先発グレコリオ暦の年yearのいずれかに対応する場合、数字yearとともに週番号年は53週を持つ。ここで、yearは400で割り切れる数字、または4で割り切れるが100で割り切れない数字である。他のすべての週番号年は52週である。

53週をもつ週番号年の最終日の週番号は53であり、52週をもつ週番号年の最終日の週番号は52である。

特定の日の週番号年の数は、先発グレゴリオ暦で、その日を含む年の数と異なる場合がある。週番号年yでの最初の週は、グレコリオ年yの最初の木曜を含む週である。

現代の用途に対して、ここで定義されるは、ISO 8601で定義されるようなISO週に相当する。[ISO8601]

与えられた順で以下のコンポーネントからなる場合、文字列は、週番号年yearおよび週weekを表す妥当な週文字列である:

  1. 4以上で表されるyear。ここでyear > 0である。
  2. "-"(U+002D)文字
  3. "W"(U+0057)文字
  4. 1 ≤ week ≤ maxweekの範囲で、週weekを表す2つのASCII数字。ここで maxweekは週番号年year最終日の週番号である。

The rules to parse a week string are as follows. This will return either a week-year number and week number, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Collect a sequence of characters that are ASCII digits. If the collected sequence is not at least four characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the year.

  4. If year is not a number greater than zero, then fail.

  5. If position is beyond the end of input or if the character at position is not a U+002D HYPHEN-MINUS character, then fail. Otherwise, move position forwards one character.

  6. If position is beyond the end of input or if the character at position is not a "W" (U+0057) character, then fail. Otherwise, move position forwards one character.

  7. Collect a sequence of characters that are ASCII digits. If the collected sequence is not exactly two characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the week.

  8. Let maxweek be the week number of the last day of year year.

  9. If week is not a number in the range 1 ≤ week ≤ maxweek, then fail.

  10. If position is not beyond the end of input, then fail.

  11. Return the week-year number year and the week number week.

2.4.5.9 継続時間

継続時間 複数秒からなる。

月と秒は同等ではない(1か月は正確な秒数ではなく、その正確な長さは、測定された正確な1日に依存する期間である)ので、この仕様で定義される継続時間は月を含めることはできない (すなわち年は12ヶ月と等価である)。特定の秒数を記述する継続時間のみが記述可能である。

以下のいずれかからなる場合、文字列は、継続時間tで表す妥当な継続時間文字列である:

The rules to parse a duration string are as follows. This will return either a duration or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Let months, seconds, and component count all be zero.

  4. Let M-disambiguator be minutes.

    This flag's other value is months. It is used to disambiguate the "M" unit in ISO8601 durations, which use the same unit for months and minutes. Months are not allowed, but are parsed for future compatibility and to avoid misinterpreting ISO8601 durations that would be valid in other contexts.

  5. Skip whitespace.

  6. If position is past the end of input, then fail.

  7. If the character in input pointed to by position is a U+0050 LATIN CAPITAL LETTER P character, then advance position to the next character, set M-disambiguator to months, and skip whitespace.

  8. Run the following substeps in a loop, until a step requiring the loop to be broken or the entire algorithm to fail is reached:

    1. Let units be undefined. It will be assigned one of the following values: years, months, weeks, days, hours, minutes, and seconds.

    2. Let next character be undefined. It is used to process characters from the input.

    3. If position is past the end of input, then break the loop.

    4. If the character in input pointed to by position is a U+0054 LATIN CAPITAL LETTER T character, then advance position to the next character, set M-disambiguator to minutes, skip whitespace, and return to the top of the loop.

    5. Set next character to the character in input pointed to by position.

    6. If next character is a "." (U+002E) character, then let N equal zero. (Do not advance position. That is taken care of below.)

      Otherwise, if next character is an ASCII digit, then collect a sequence of characters that are ASCII digits, interpret the resulting sequence as a base-ten integer, and let N be that number.

      Otherwise next character is not part of a number; fail.

    7. If position is past the end of input, then fail.

    8. Set next character to the character in input pointed to by position, and this time advance position to the next character. (If next character was a U+002E FULL STOP character (.) before, it will still be that character this time.)

    9. If next character is a "." (U+002E) character, then run these substeps:

      1. Collect a sequence of characters that are ASCII digits. Let s be the resulting sequence.

      2. If s is the empty string, then fail.

      3. Let length be the number of characters in s.

      4. Let fraction be the result of interpreting s as a base-ten integer, and then dividing that number by 10length.

      5. Increment N by fraction.

      6. Skip whitespace.

      7. If position is past the end of input, then fail.

      8. Set next character to the character in input pointed to by position, and advance position to the next character.

      9. If next character is neither a U+0053 LATIN CAPITAL LETTER S character nor a U+0073 LATIN SMALL LETTER S character, then fail.

      10. Set units to seconds.

      Otherwise, run these substeps:

      1. If next character is a space character, then skip whitespace, set next character to the character in input pointed to by position, and advance position to the next character.

      2. If next character is a U+0059 LATIN CAPITAL LETTER Y character, or a U+0079 LATIN SMALL LETTER Y character, set units to years and set M-disambiguator to months.

        If next character is a U+004D LATIN CAPITAL LETTER M character or a U+006D LATIN SMALL LETTER M character, and M-disambiguator is months, then set units to months.

        If next character is a U+0057 LATIN CAPITAL LETTER W character or a U+0077 LATIN SMALL LETTER W character, set units to weeks and set M-disambiguator to minutes.

        If next character is a U+0044 LATIN CAPITAL LETTER D character or a U+0064 LATIN SMALL LETTER D character, set units to days and set M-disambiguator to minutes.

        If next character is a U+0048 LATIN CAPITAL LETTER H character or a U+0068 LATIN SMALL LETTER H character, set units to hours and set M-disambiguator to minutes.

        If next character is a U+004D LATIN CAPITAL LETTER M character or a U+006D LATIN SMALL LETTER M character, and M-disambiguator is minutes, then set units to minutes.

        If next character is a U+0053 LATIN CAPITAL LETTER S character or a U+0073 LATIN SMALL LETTER S character, set units to seconds and set M-disambiguator to minutes.

        Otherwise if next character is none of the above characters, then fail.

    10. Increment component count.

    11. Let multiplier be 1.

    12. If units is years, multiply multiplier by 12 and set units to months.

    13. If units is months, add the product of N and multiplier to months.

      Otherwise, run these substeps:

      1. If units is weeks, multiply multiplier by 7 and set units to days.

      2. If units is days, multiply multiplier by 24 and set units to hours.

      3. If units is hours, multiply multiplier by 60 and set units to minutes.

      4. If units is minutes, multiply multiplier by 60 and set units to seconds.

      5. Forcibly, units is now seconds. Add the product of N and multiplier to seconds.

    14. Skip whitespace.

  9. If component count is zero, fail.

  10. If months is not zero, fail.

  11. Return the duration consisting of seconds seconds.

2.4.5.10 時刻における曖昧な瞬間

以下のいずれかである場合、文字列は任意の時刻を持つ妥当な日付文字列である:


The rules to parse a date or time string are as follows. The algorithm will return either a date, a time, a global date and time, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that point and returns nothing.

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Set start position to the same position as position.

  4. Set the date present and time present flags to true.

  5. Parse a date component to obtain year, month, and day. If this fails, then set the date present flag to false.

  6. If date present is true, and position is not beyond the end of input, and the character at position is either a "T" (U+0054) character or a U+0020 SPACE character, then advance position to the next character in input.

    Otherwise, if date present is true, and either position is beyond the end of input or the character at position is neither a "T" (U+0054) character nor a U+0020 SPACE character, then set time present to false.

    Otherwise, if date present is false, set position back to the same position as start position.

  7. If the time present flag is true, then parse a time component to obtain hour, minute, and second. If this returns nothing, then fail.

  8. If the date present and time present flags are both true, but position is beyond the end of input, then fail.

  9. If the date present and time present flags are both true, parse a time-zone offset component to obtain timezonehours and timezoneminutes. If this returns nothing, then fail.

  10. If position is not beyond the end of input, then fail.

  11. If the date present flag is true and the time present flag is false, then let date be the date with year year, month month, and day day, and return date.

    Otherwise, if the time present flag is true and the date present flag is false, then let time be the time with hour hour, minute minute, and second second, and return time.

    Otherwise, let time be the moment in time at year year, month month, day day, hours hour, minute minute, second second, subtracting timezonehours hours and timezoneminutes minutes, that moment in time being a moment in the UTC time zone; let timezone be timezonehours hours and timezoneminutes minutes from UTC; and return time and timezone.

2.4.6

単純色は、sRGB色空間の中で各色のコンポーネント赤、緑、青を表す、0から255までの範囲の8ビット数字3つからなる。[SRGB]

正確に7文字長である、最初の文字が"#"(U+0023)文字であり、残りの6文字がすべてASCII16進数字である、最初の2桁は赤コンポーネントを表し、中の2桁は緑コンポーネントを表し、最後の2桁は青コンポーネントを表す16進数である場合、文字列は妥当な単純色である。

妥当な単純色でかつU+0041 LATIN CAPITAL LETTER AからU+0046 LATIN CAPITAL LETTER Fまでの範囲の文字を一切使用しない場合、文字列は妥当な小文字の単純色である。

The rules for parsing simple color values are as given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will return either a simple color or an error.

  1. Let input be the string being parsed.

  2. If input is not exactly seven characters long, then return an error.

  3. If the first character in input is not a U+0023 NUMBER SIGN character (#), then return an error.

  4. If the last six characters of input are not all ASCII hex digits, then return an error.

  5. Let result be a simple color.

  6. Interpret the second and third characters as a hexadecimal number and let the result be the red component of result.

  7. Interpret the fourth and fifth characters as a hexadecimal number and let the result be the green component of result.

  8. Interpret the sixth and seventh characters as a hexadecimal number and let the result be the blue component of result.

  9. Return result.

The rules for serializing simple color values given a simple color are as given in the following algorithm:

  1. Let result be a string consisting of a single "#" (U+0023) character.

  2. Convert the red, green, and blue components in turn to two-digit hexadecimal numbers using lowercase ASCII hex digits, zero-padding if necessary, and append these numbers to result, in the order red, green, blue.

  3. Return result, which will be a valid lowercase simple color.


Some obsolete legacy attributes parse colors in a more complicated manner, using the rules for parsing a legacy color value, which are given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will return either a simple color or an error.

  1. Let input be the string being parsed.

  2. If input is the empty string, then return an error.

  3. Strip leading and trailing whitespace from input.

  4. If input is an ASCII case-insensitive match for the string "transparent", then return an error.

  5. If input is an ASCII case-insensitive match for one of the keywords listed in the SVG color keywords section of the CSS3 Color specification, then return the simple color corresponding to that keyword. [CSSCOLOR]

    CSS2 System Colors are not recognised.

  6. If input is four characters long, and the first character in input is a "#" (U+0023) character, and the last three characters of input are all ASCII hex digits, then run these substeps:

    1. Let result be a simple color.

    2. Interpret the second character of input as a hexadecimal digit; let the red component of result be the resulting number multiplied by 17.

    3. Interpret the third character of input as a hexadecimal digit; let the green component of result be the resulting number multiplied by 17.

    4. Interpret the fourth character of input as a hexadecimal digit; let the blue component of result be the resulting number multiplied by 17.

    5. Return result.

  7. Replace any characters in input that have a Unicode code point greater than U+FFFF (i.e. any characters that are not in the basic multilingual plane) with the two-character string "00".

  8. If input is longer than 128 characters, truncate input, leaving only the first 128 characters.

  9. If the first character in input is a "#" (U+0023) character, remove it.

  10. Replace any character in input that is not an ASCII hex digit with the character "0" (U+0030).

  11. While input's length is zero or not a multiple of three, append a "0" (U+0030) character to input.

  12. Split input into three strings of equal length, to obtain three components. Let length be the length of those components (one third the length of input).

  13. If length is greater than 8, then remove the leading length-8 characters in each component, and let length be 8.

  14. While length is greater than two and the first character in each component is a "0" (U+0030) character, remove that character and reduce length by one.

  15. If length is still greater than two, truncate each component, leaving only the first two characters in each.

  16. Let result be a simple color.

  17. Interpret the first component as a hexadecimal number; let the red component of result be the resulting number.

  18. Interpret the second component as a hexadecimal number; let the green component of result be the resulting number.

  19. Interpret the third component as a hexadecimal number; let the blue component of result be the resulting number.

  20. Return result.


2.4.7 空白区切りトークン

空白区切りトークンの組は、1つ以上の空白文字によって区切られた0個以上の単語(トークンとして知られる)を含む文字列である。ここで、単語は1つ以上の文字を含み、空白文字を含まない。

空白区切りトークンの組を構成する文字列は、先頭または末尾に空白文字を持ってもよい。

順序なし固有空白区切りトークンの組は、繰り返しトークンのない空白区切りトークンの組である。

順序あり固有空白区切りトークンの組は、繰り返しトークンはないが、トークンの順序が意味のある空白区切りトークンの組である。

空白区切りトークンの組は時折定義された許可される値の組を持つ。許可された値の組が定義される場合、トークンはすべて許可される値のリストでなければならない。その他の値は不適合である。そのような許可される値の組が用意されない場合、すべての値は適合である。

空白区切りトークンの組のトークンがどのように比較されるか(たとえば、大文字小文字を区別するかどうか)は、セットごとに定義される。

When a user agent has to split a string on spaces, it must use the following algorithm:

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Let tokens be an ordered list of tokens, initially empty.

  4. Skip whitespace

  5. While position is not past the end of input:

    1. Collect a sequence of characters that are not space characters.

    2. Append the string collected in the previous step to tokens.

    3. Skip whitespace

  6. Return tokens.

2.4.8 コンマ区切りトークン

コンマ区切りトークンの組は、それぞれ単一の","(U+002C)文字で区切られる0個以上のトークンを含む文字列である。ここでトークンは0個以上の任意の文字列からなり、先頭も末尾も空白文字でなく、","(U+002C)文字を含まず、任意で空白文字に囲まれるものである。

たとえば、文字列" a ,b,,d d "は4つのトークンからなる。"a"、"b"、空文字列および"d d"。各トークンの周りの先頭と末尾の空白はトークンの一部としてカウントされず、空文字列はトークンであるかもしれない。

コンマ区切りトークンの組は時に妥当なトークンを構成するさらなる制約を持つ。そのような制限が定義される場合、トークンはすべてその制限に収まるようにしなければならない。その他の値は不適合である。そのような制限が指定されない場合、すべての値は適合である。

When a user agent has to split a string on commas, it must use the following algorithm:

  1. Let input be the string being parsed.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Let tokens be an ordered list of tokens, initially empty.

  4. Token: If position is past the end of input, jump to the last step.

  5. Collect a sequence of characters that are not "," (U+002C) characters. Let s be the resulting sequence (which might be the empty string).

  6. Strip leading and trailing whitespace from s.

  7. Append s to tokens.

  8. If position is not past the end of input, then the character at position is a "," (U+002C) character; advance position past that character.

  9. Jump back to the step labeled token.

  10. Return tokens.

2.4.9 参照

タイプtype要素に対して妥当なハッシュ名参照は、"#"(U+0023)文字の後に文書でタイプtypeをもつ要素のname属性値に正確に一致する文字列からなる文字列である。

The rules for parsing a hash-name reference to an element of type type are as follows:

  1. If the string being parsed does not contain a U+0023 NUMBER SIGN character, or if the first such character in the string is the last character in the string, then return null and abort these steps.

  2. Let s be the string from the character immediately after the first U+0023 NUMBER SIGN character in the string being parsed up to the end of that string.

  3. Return the first element of type type that has an id attribute whose value is a case-sensitive match for s or a name attribute whose value is a compatibility caseless match for s.

2.4.10 メディアクエリ

メディアクエリ仕様のmedia_query_list生成物に一致する場合、文字列は妥当なメディアクエリである。[MQ]

空文字列、空白文字のみからなる文字列、またはメディアクエリ仕様で与えられる定義に従ったユーザー環境にマッチするメディアクエリの場合、文字列はユーザー環境に一致する[MQ]

2.5 URL

2.5.1 用語

URL標準でオーサリング適合性要件に準拠する場合、URL妥当なURLである。[URL]

妥当なURLだが空文字列でない場合、文字列は妥当な空でないURLである。

先頭と末尾の空白文字を取り除いたあとに妥当なURLである場合、文字列は潜在的にスペースで囲まれた妥当なURLである。

先頭と末尾の空白文字を取り除いたあとに、妥当な空でないURLである場合、文字列は潜在的にスペースで囲まれた妥当な空でないURLである。

この仕様は、たとえ解決不可能でも、XMLツールの互換性のために必要な場合、HTML文書DOCTYPEで用いるためのabout: URL予約としてURL about:legacy-compatを定義する。[ABOUT]

この仕様は、たとえ解決不可能でも、iframe srcdoc文書文書のアドレスとして用いられるabout: URLを予約としてURL about:srcdocを定義する。[ABOUT]

Documentオブジェクトのフォールバック基底URLは、以下のサブステップを実行して得られる絶対URLである:

  1. Documentiframe srcdoc文書である場合、DocumentブラウジングコンテキストがもつブラウジングコンテキストコンテナDocumentに属する文書基底URLを返し、これらの手順を中止する。

  2. 文書のアドレスabout:blankであり、かつDocumentブラウジングコンテキストクリエーターブラウジングコンテキストを持つ場合、クリエーターDocument文書基底URLを返し、これらの手順を中止する。

  3. 文書のアドレスを返す。

Documentオブジェクトの文書基底URLは、以下のサブステップを実行して得られる絶対URLである:

  1. Documenthref属性を持つbase要素が存在しない場合、文書基底URLDocumentフォールバック基底URLであり、これらの手順を中止する。

  2. そうでなければ、文書基底URLツリー順で、href属性を持つDocumentで最初のbase要素の凍結基底URLである。

2.5.2 Resolving URLs

Resolving a URL is the process of taking a relative URL and obtaining the absolute URL that it implies.

To resolve a URL to an absolute URL relative to either another absolute URL or an element, the user agent must use the following steps. Resolving a URL can result in an error, in which case the URL is not resolvable.

  1. Let url be the URL being resolved.

  2. Let encoding be determined as follows:

    If the URL had a character encoding defined when the URL was created or defined or when this algorithm was invoked
    The URL character encoding is as defined.
    If the URL came from a script (e.g. as an argument to a method)
    The URL character encoding is the API URL character encoding specified by the script's settings object.
    If the URL came from a DOM node (e.g. from an element)
    The node has a Document, and the URL character encoding is the document's character encoding.
  3. If encoding is a UTF-16 encoding, then change the value of encoding to UTF-8.

  4. If the algorithm was invoked with an absolute URL to use as the base URL, let base be that absolute URL.

    Otherwise, let base be the element's base URL.

  5. Apply the URL parser to url, with base as the base URL, with encoding as the encoding.

  6. If this returns failure, then abort these steps with an error.

  7. Let parsed URL be the result of the URL parser.

  8. Let serialized URL be the result of apply the URL serializer to parsed URL.

  9. Return serialized URL as the resulting absolute URL and parsed URL as the resulting parsed URL.

Given an element, the element's base URL is the base URI of the element, as defined by the XML Base specification, with the base URI of the document entity being defined as the document base URL of the Document that owns the element. [XMLBASE]

For the purposes of the XML Base specification, user agents must act as if all Document objects represented XML documents.

It is possible for xml:base attributes to be present even in HTML fragments, as such attributes can be added dynamically using script. (Such scripts would not be conforming, however, as xml:base attributes are not allowed in HTML documents.)

2.5.3 Dynamic changes to base URLs

When an xml:base attribute is set, changed, or removed, the attribute's element, and all descendant elements, are affected by a base URL change.

When a document's document base URL changes, all elements in that document are affected by a base URL change.

The following are base URL change steps, which run when an element is affected by a base URL change (as defined by the DOM specification):

If the element creates a hyperlink

If the absolute URL identified by the hyperlink is being shown to the user, or if any data derived from that URL is affecting the display, then the href attribute should be re-resolved relative to the element and the UI updated appropriately.

For example, the CSS :link/:visited pseudo-classes might have been affected.

If the element is a q, blockquote, ins, or del element with a cite attribute

If the absolute URL identified by the cite attribute is being shown to the user, or if any data derived from that URL is affecting the display, then the URL should be re-resolved relative to the element and the UI updated appropriately.

そうでなければ

The element is not directly affected.

For instance, changing the base URL doesn't affect the image displayed by img elements, although subsequent accesses of the src IDL attribute from script will return a new absolute URL that might no longer correspond to the image being shown.

2.6 Fetching resources

2.6.1 Terminology

User agents can implement a variety of transfer protocols, but this specification mostly defines behavior in terms of HTTP. [HTTP]

The HTTP GET method is equivalent to the default retrieval action of the protocol. For example, RETR in FTP. Such actions are idempotent and safe, in HTTP terms.

The HTTP response codes are equivalent to statuses in other protocols that have the same basic meanings. For example, a "file not found" error is equivalent to a 404 code, a server error is equivalent to a 5xx code, and so on.

The HTTP headers are equivalent to fields in other protocols that have the same basic meaning. For example, the HTTP authentication headers are equivalent to the authentication aspects of the FTP protocol.

A referrer source is either a Document or a URL.

2.6.2 Processing model

When a user agent is to fetch a resource or URL, optionally from an origin origin, optionally using a specific referrer source as an override referrer source, and optionally with any of a synchronous flag, a manual redirect flag, a force same-origin flag, and a block cookies flag, the following steps must be run. (When a URL is to be fetched, the URL identifies a resource to be obtained.)

  1. If there is a specific override referrer source, and it is a URL, then let referrer be the override referrer source, and jump to the step labeled clean referrer.

  2. Let document be the appropriate Document as given by the following list:

    If there is a specific override referrer source
    The override referrer source.
    When navigating
    The active document of the source browsing context.
    When fetching resources for an element
    The element's Document.
  3. While document is an iframe srcdoc document, let document be document's browsing context's browsing context container's Document instead.

  4. If the origin of Document is not a scheme/host/port tuple, then set referrer to the empty string and jump to the step labeled clean referrer.

  5. Let referrer be the document's address of document.

  6. Clean referrer: Apply the URL parser to referrer and let parsed referrer be the resulting parsed URL.

  7. Let referrer be the result of applying the URL serializer to parsed referrer, with the exclude fragment flag set.

  8. If referrer is not the empty string, is not a data: URL, and is not the URL "about:blank", then generate the address of the resource from which Request-URIs are obtained as required by HTTP for the Referer (sic) header from referrer. [HTTP]

    Otherwise, the Referer (sic) header must be omitted, regardless of its value.

  9. If the algorithm was not invoked with the synchronous flag, perform the remaining steps asynchronously.

  10. If the Document with which any tasks queued by this algorithm would be associated doesn't have an associated browsing context, then abort these steps.

  11. This is the main step.

    If the resource is to be obtained from an application cache, then use the data from that application cache, as if it had been obtained in the manner appropriate given its URL.

    If the resource is identified by an absolute URL, and the resource is to be obtained using an idempotent action (such as an HTTP GET or equivalent), and it is already being downloaded for other reasons (e.g. another invocation of this algorithm), and this request would be identical to the previous one (e.g. same Accept and Origin headers), and the user agent is configured such that it is to reuse the data from the existing download instead of initiating a new one, then use the results of the existing download instead of starting a new one.

    Otherwise, if the resource is identified by an absolute URL with a scheme that does not define a mechanism to obtain the resource (e.g. it is a mailto: URL) or that the user agent does not support, then act as if the resource was an HTTP 204 No Content response with no other metadata.

    Otherwise, if the resource is identified by the URL about:blank, then the resource is immediately available and consists of the empty string, with no metadata.

    Otherwise, at a time convenient to the user and the user agent, download (or otherwise obtain) the resource, applying the semantics of the relevant specifications (e.g. performing an HTTP GET or POST operation, or reading the file from disk, or expanding data: URLs, etc).

    For the purposes of the Referer (sic) header, use the address of the resource from which Request-URIs are obtained generated in the earlier step.

    For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a "privacy-sensitive" context. [ORIGIN]

  12. If the algorithm was not invoked with the block cookies flag, and there are cookies to be set, then the user agent must run the following substeps:

    1. Wait until ownership of the storage mutex can be taken by this instance of the fetching algorithm.

    2. Take ownership of the storage mutex.

    3. Update the cookies. [COOKIES] (This is a fingerprinting vector.)

    4. Release the storage mutex so that it is once again free.

  13. If the fetched resource is an HTTP redirect or equivalent, then:

    If the force same-origin flag is set and the URL of the target of the redirect does not have the same origin as the URL for which the fetch algorithm was invoked

    Abort these steps and return failure from this algorithm, as if the remote host could not be contacted.

    If the manual redirect flag is set

    Continue, using the fetched resource (the redirect) as the result of the algorithm. If the calling algorithm subsequently requires the user agent to transparently follow the redirect, then the user agent must resume this algorithm from the main step, but using the target of the redirect as the resource to fetch, rather than the original resource.

    そうでなければ

    First, apply any relevant requirements for redirects (such as showing any appropriate prompts). Then, redo main step, but using the target of the redirect as the resource to fetch, rather than the original resource. For HTTP requests, the new request must include the same headers as the original request, except for headers for which other requirements are specified (such as the Host header). [HTTP]

    The HTTP specification requires that 301, 302, and 307 redirects, when applied to methods other than the safe methods, not be followed without user confirmation. That would be an appropriate prompt for the purposes of the requirement in the paragraph above. [HTTP]

  14. If the algorithm was not invoked with the synchronous flag: When the resource is available, or if there is an error of some description, queue a task that uses the resource as appropriate. If the resource can be processed incrementally, as, for instance, with a progressively interlaced JPEG or an HTML file, additional tasks may be queued to process the data as it is downloaded. The task source for these tasks is the networking task source.

    Otherwise, return the resource or error information to the calling algorithm.

If the user agent can determine the actual length of the resource being fetched for an instance of this algorithm, and if that length is finite, then that length is the file's size. Otherwise, the subject of the algorithm (that is, the resource being fetched) has no known size. (For example, the HTTP Content-Length header might provide this information.)

The user agent must also keep track of the number of bytes downloaded for each instance of this algorithm. This number must exclude any out-of-band metadata, such as HTTP headers.

The application cache processing model introduces some changes to the networking model to handle the returning of cached resources.

The navigation processing model handles redirects itself, overriding the redirection handling that would be done by the fetching algorithm.

Whether the type sniffing rules apply to the fetched resource depends on the algorithm that invokes the rules — they are not always applicable.

Anything in this specification that refers to HTTP also applies to HTTP-over-TLS, as represented by URLs representing the https scheme. [HTTP]

User agents should report certificate errors to the user and must either refuse to download resources sent with erroneous certificates or must act as if such resources were in fact served with no encryption.

User agents should warn the user that there is a potential problem whenever the user visits a page that the user has previously visited, if the page uses less secure encryption on the second visit.

Not doing so can result in users not noticing man-in-the-middle attacks.

If a user connects to a server with a self-signed certificate, the user agent could allow the connection but just act as if there had been no encryption. If the user agent instead allowed the user to override the problem and then displayed the page as if it was fully and safely encrypted, the user could be easily tricked into accepting man-in-the-middle connections.

If a user connects to a server with full encryption, but the page then refers to an external resource that has an expired certificate, then the user agent will act as if the resource was unavailable, possibly also reporting the problem to the user. If the user agent instead allowed the resource to be used, then an attacker could just look for "secure" sites that used resources from a different host and only apply man-in-the-middle attacks to that host, for example taking over scripts in the page.

If a user bookmarks a site that uses a CA-signed certificate, and then later revisits that site directly but the site has started using a self-signed certificate, the user agent could warn the user that a man-in-the-middle attack is likely underway, instead of simply acting as if the page was not encrypted.

2.6.4 Determining the type of a resource

The Content-Type metadata of a resource must be obtained and interpreted in a manner consistent with the requirements of the MIME Sniffing specification. [MIMESNIFF]

The sniffed type of a resource must be found in a manner consistent with the requirements given in the MIME Sniffing specification for finding the sniffed media type of the relevant sequence of octets. [MIMESNIFF]

The rules for sniffing images specifically and the rules for distinguishing if a resource is text or binary are also defined in the MIME Sniffing specification. Both sets of rules return a MIME type as their result. [MIMESNIFF]

It is imperative that the rules in the MIME Sniffing specification be followed exactly. When a user agent uses different heuristics for content type detection than the server expects, security problems can occur. For more details, see the MIME Sniffing specification. [MIMESNIFF]

2.6.5 Extracting character encodings from meta elements

The algorithm for extracting a character encoding from a meta element, given a string s, is as follows. It either returns a character encoding or nothing.

  1. Let position be a pointer into s, initially pointing at the start of the string.

  2. Loop: Find the first seven characters in s after position that are an ASCII case-insensitive match for the word "charset". If no such match is found, return nothing and abort these steps.

  3. Skip any space characters that immediately follow the word "charset" (there might not be any).

  4. If the next character is not a "=" (U+003D), then move position to point just before that next character, and jump back to the step labeled loop.

  5. Skip any space characters that immediately follow the equals sign (there might not be any).

  6. Process the next character as follows:

    If it is a """ (U+0022) character and there is a later """ (U+0022) character in s
    If it is a "'" (U+0027) character and there is a later "'" (U+0027) character in s
    Return the result of getting an encoding from the substring that is between this character and the next earliest occurrence of this character.
    If it is an unmatched """ (U+0022) character
    If it is an unmatched "'" (U+0027) character
    If there is no next character
    Return nothing.
    そうでなければ
    Return the result of getting an encoding from the substring that consists of this character up to but not including the first space character or ";" (U+003B) character, or the end of s, whichever comes first.

This algorithm is distinct from those in the HTTP specification (for example, HTTP doesn't allow the use of single quotes and requires supporting a backslash-escape mechanism that is not supported by this algorithm While the algorithm is used in contexts that, historically, were related to HTTP, the syntax as supported by implementations diverged some time ago. [HTTP]

2.6.6 CORS設定属性

CORS設定属性は、列挙属性である。次の表は、キーワードと属性の状態を示す。1列目のキーワードは、キーワードと同じ行で2列目のセル内の状態に対応づける。

キーワード 状態 概要
anonymous Anonymous Cross-origin CORSは、省略認証情報フラグ設定を持つ要素を要求する。
use-credentials Use Credentials Cross-origin CORSは、省略認証情報フラグ設定を持たない要素を要求する。

空文字列も妥当なキーワードであり、匿名状態に対応づける。属性の妥当でない値のデフォルトは、匿名状態である。反射のために、匿名状態の正規ケースはanonymousキーワードである。属性が省略された場合に用いられる、欠落した値のデフォルトは、No CORS状態である。

2.6.7 CORS-enabled fetch

When the user agent is required to perform a potentially CORS-enabled fetch of an absolute URL URL with a mode mode that is either "No CORS", "Anonymous", or "Use Credentials", optionally using a referrer source referrer source, with an origin origin, and with a default origin behaviour default which is either "taint" or "fail", it must run the first applicable set of steps from the following list. The default origin behaviour is only used if mode is "No CORS". This algorithm wraps the fetch algorithm above, and labels the obtained resource as either CORS-same-origin or CORS-cross-origin, or blocks the resource entirely.

If the URL has the same origin as origin
If the URL is a data: URL
If the URL is about:blank

Run these substeps:

  1. Fetch URL, using referrer source if one was specified, with the manual redirect flag set.

  2. Loop: Wait for the fetch algorithm to know if the result is a redirect or not.

  3. Follow the first appropriate steps from the following list:

    If the result of the fetch is a redirect, and the origin of the target URL of the redirect is not the same origin as origin

    Set URL to the target URL of the redirect and return to the top of the potentially CORS-enabled fetch algorithm (this time, one of the other branches below might be taken, based on the value of mode

    If the result of the fetch is a redirect

    The origin of the target URL of the redirect is the same origin as origin.

    Transparently follow the redirect and jump to the step labeled loop above.

    そうでなければ

    The resource is available, it is not a redirect, and its origin is the same origin as origin.

    The tasks from the fetch algorithm are queued normally, and for the purposes of the calling algorithm, the obtained resource is CORS-same-origin.

If mode is "No CORS" and default is taint

The URL does not have the same origin as origin.

Fetch URL, using referrer source if one was specified.

The tasks from the fetch algorithm are queued normally, but for the purposes of the calling algorithm, the obtained resource is CORS-cross-origin. The user agent may report a cross-origin resource access failure to the user (e.g. in a debugging console).

If mode is "No CORS"

The URL does not have the same origin as origin, and default is fail.

Discard any data fetched as part of this algorithm, and prevent any tasks from such invocations of the fetch algorithm from being queued. For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained. The user agent may report a cross-origin resource access failure to the user (e.g. in a debugging console).

If mode is "Anonymous" or "Use Credentials"

The URL does not have the same origin as origin.

Run these steps:

  1. Perform a cross-origin request with the request URL set to URL, with the CORS referrer source set to referrer source if one was specified, the source origin set to origin, and with the omit credentials flag set if mode is "Anonymous" and not set otherwise. [CORS]

  2. Wait for the CORS cross-origin request status to have a value.

  3. Jump to the appropriate step from the following list:

    If the CORS cross-origin request status is not success

    Discard all fetched data and prevent any tasks from the fetch algorithm from being queued. For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained. If a CORS resource sharing check failed, the user agent may report a cross-origin resource access failure to the user (e.g. in a debugging console).

    If the CORS cross-origin request status is success

    The tasks from the fetch algorithm are queued normally, and for the purposes of the calling algorithm, the obtained resource is CORS-same-origin.

2.7 共通DOMインターフェース

2.7.1 IDL属性におけるコンテンツ属性の反映

一部のIDL属性は、特定のコンテンツ属性の反映を定義する。これは、IDL属性がコンテンツ属性の現在値を返し、IDL属性が与えられた値にコンテンツ属性の値を変更することを意味する。

In general, on getting, if the content attribute is not present, the IDL attribute must act as if the content attribute's value is the empty string; and on setting, if the content attribute is not present, it must first be added.

If a reflecting IDL attribute is a DOMString attribute whose content attribute is defined to contain a URL, then on getting, the IDL attribute must resolve the value of the content attribute relative to the element and return the resulting absolute URL if that was successful, or the empty string otherwise; and on setting, must set the content attribute to the specified literal value. If the content attribute is absent, the IDL attribute must return the default value, if the content attribute has one, or else the empty string.

If a reflecting IDL attribute is a DOMString attribute whose content attribute is defined to contain one or more URLs, then on getting, the IDL attribute must split the content attribute on spaces and return the concatenation of resolving each token URL to an absolute URL relative to the element, with a single U+0020 SPACE character between each URL, ignoring any tokens that did not resolve successfully. If the content attribute is absent, the IDL attribute must return the default value, if the content attribute has one, or else the empty string. On setting, the IDL attribute must set the content attribute to the specified literal value.

If a reflecting IDL attribute is a DOMString attribute whose content attribute is an enumerated attribute, and the IDL attribute is limited to only known values, then, on getting, the IDL attribute must return the conforming value associated with the state the attribute is in (in its canonical case), if any, or the empty string if the attribute is in a state that has no associated keyword value or if the attribute is not in a defined state (e.g. the attribute is missing and there is no missing value default); and on setting, the content attribute must be set to the specified new value.

If a reflecting IDL attribute is a DOMString attribute but doesn't fall into any of the above categories, then the getting and setting must be done in a transparent, case-preserving manner.

If a reflecting IDL attribute is a boolean attribute, then on getting the IDL attribute must return true if the content attribute is set, and false if it is absent. On setting, the content attribute must be removed if the IDL attribute is set to false, and must be set to the empty string if the IDL attribute is set to true. (This corresponds to the rules for boolean content attributes.)

If a reflecting IDL attribute has a signed integer type (long) then, on getting, the content attribute must be parsed according to the rules for parsing signed integers, and if that is successful, and the value is in the range of the IDL attribute's type, the resulting value must be returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, then the default value must be returned instead, or 0 if there is no default value. On setting, the given value must be converted to the shortest possible string representing the number as a valid integer and then that string must be used as the new content attribute value.

If a reflecting IDL attribute has a signed integer type (long) that is limited to only non-negative numbers then, on getting, the content attribute must be parsed according to the rules for parsing non-negative integers, and if that is successful, and the value is in the range of the IDL attribute's type, the resulting value must be returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, the default value must be returned instead, or −1 if there is no default value. On setting, if the value is negative, the user agent must throw an IndexSizeError exception. Otherwise, the given value must be converted to the shortest possible string representing the number as a valid non-negative integer and then that string must be used as the new content attribute value.

If a reflecting IDL attribute has an unsigned integer type (unsigned long) then, on getting, the content attribute must be parsed according to the rules for parsing non-negative integers, and if that is successful, and the value is in the range 0 to 2147483647 inclusive, the resulting value must be returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, the default value must be returned instead, or 0 if there is no default value. On setting, first, if the new value is in the range 0 to 2147483647, then let n be the new value, otherwise let n be the default value, or 0 if there is no default value; then, n must be converted to the shortest possible string representing the number as a valid non-negative integer and that string must be used as the new content attribute value.

If a reflecting IDL attribute has an unsigned integer type (unsigned long) that is limited to only non-negative numbers greater than zero, then the behavior is similar to the previous case, but zero is not allowed. On getting, the content attribute must first be parsed according to the rules for parsing non-negative integers, and if that is successful, and the value is in the range 1 to 2147483647 inclusive, the resulting value must be returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, the default value must be returned instead, or 1 if there is no default value. On setting, if the value is zero, the user agent must throw an IndexSizeError exception. Otherwise, first, if the new value is in the range 1 to 2147483647, then let n be the new value, otherwise let n be the default value, or 1 if there is no default value; then, n must be converted to the shortest possible string representing the number as a valid non-negative integer and that string must be used as the new content attribute value.

If a reflecting IDL attribute has a floating-point number type (double or unrestricted double), then, on getting, the content attribute must be parsed according to the rules for parsing floating-point number values, and if that is successful, the resulting value must be returned. If, on the other hand, it fails, or if the attribute is absent, the default value must be returned instead, or 0.0 if there is no default value. On setting, the given value must be converted to the best representation of the number as a floating-point number and then that string must be used as the new content attribute value.

If a reflecting IDL attribute has a floating-point number type (double or unrestricted double) that is limited to numbers greater than zero, then the behavior is similar to the previous case, but zero and negative values are not allowed. On getting, the content attribute must be parsed according to the rules for parsing floating-point number values, and if that is successful and the value is greater than 0.0, the resulting value must be returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, the default value must be returned instead, or 0.0 if there is no default value. On setting, if the value is less than or equal to zero, then the value must be ignored. Otherwise, the given value must be converted to the best representation of the number as a floating-point number and then that string must be used as the new content attribute value.

The values Infinity and Not-a-Number (NaN) values throw an exception on setting, as defined in the Web IDL specification. [WEBIDL]

If a reflecting IDL attribute has the type DOMTokenList or DOMSettableTokenList, then on getting it must return a DOMTokenList or DOMSettableTokenList object (as appropriate) whose associated element is the element in question and whose associated attribute's local name is the name of the attribute in question. The same DOMTokenList or DOMSettableTokenList object must be returned every time for each attribute.

If a reflecting IDL attribute has the type HTMLElement, or an interface that descends from HTMLElement, then, on getting, it must run the following algorithm (stopping at the first point where a value is returned):

  1. If the corresponding content attribute is absent, then the IDL attribute must return null.
  2. Let candidate be the element that the document.getElementById() method would find when called on the content attribute's document if it were passed as its argument the current value of the corresponding content attribute.
  3. If candidate is null, or if it is not type-compatible with the IDL attribute, then the IDL attribute must return null.
  4. Otherwise, it must return candidate.

On setting, if the given element has an id attribute, and has the same home subtree as the element of the attribute being set, and the given element is the first element in that home subtree whose ID is the value of that id attribute, then the content attribute must be set to the value of that id attribute. Otherwise, the content attribute must be set to the empty string.

2.7.2 コレクション

HTMLAllCollectionHTMLFormControlsCollectionHTMLOptionsCollection インターフェースは、HTMLCollectionインターフェースから派生するコレクションである。

2.7.2.1 HTMLAllCollection

HTMLAllCollectionインターフェースは、複数の一致する要素が存在する場合、インターフェースのnamedItem()メソッドがHTMLCollectionオブジェクトを返す例外、およびインターフェースのitem()メソッドがそのnamedItem()メソッドと同義に用いられる例外とともに、ちょうどHTMLCollectionのような要素の汎用コレクションに使用される。これはレガシーdocument.all属性のみを意図する。

interface HTMLAllCollection : HTMLCollection {
  // inherits length and item(unsigned long index)
  (HTMLCollection or Element)? item(DOMString name);
  legacycaller getter (HTMLCollection or Element)? namedItem(DOMString name); // shadows inherited namedItem()
  HTMLAllCollection tags(DOMString tagName);
};
collection . length

コレクションの要素数を返す。

element = collection . item(index)
collection[index]

コレクションからのインデックスindexとともにアイテムを返す。アイテムはツリー順にソートされる。

element = collection . item(name)
collection = collection . item(name)
element = collection . namedItem(name)
collection = collection . namedItem(name)
collection[name]
collection(name)

コレクションからのIDまたは名前nameとともにアイテムを返す。

複数のマッチするアイテムが存在する場合、それらの要素すべてを含むHTMLCollectionオブジェクトが返される。

ただしaappletareaembedformframeframesetiframeimg、およびobject要素はこのメソッドのために名前を持ってもよい。それらの名前はname属性値によって与えられる。

collection = collection . tags(tagName)

指定されたタグ名を持つ要素のみを含む、現在のコレクションのフィルタリングされた表示であるコレクションを返す。

The object's supported property indices are as defined for HTMLCollection objects.

The supported property names consist of the non-empty values of all the id attributes of all the elements represented by the collection, and the non-empty values of all the name attributes of all the a, applet, area, embed, form, frame, frameset, iframe, img, and object elements represented by the collection, in tree order, ignoring later duplicates, with the id of an element preceding its name if it contributes both, they differ from each other, and neither is the duplicate of an earlier entry.

The item(name) and namedItem(name) methods must act according to the following algorithm:

  1. If name is the empty string, return null and stop the algorithm.
  2. Let collection be an HTMLCollection object rooted at the same node as the HTMLAllCollection object on which the method was invoked, whose filter matches only elements that already match the filter of the HTMLAllCollection object on which the method was invoked and that are either:

  3. If, at the time the method is called, there is exactly one node in collection, then return that node and stop the algorithm.
  4. Otherwise, if, at the time the method is called, collection is empty, return null and stop the algorithm.
  5. Otherwise, return collection.

The tags(tagName) method must return an HTMLAllCollection rooted at the same node as the HTMLAllCollection object on which the method was invoked, whose filter matches only HTML elements whose local name is the tagName argument and that already match the filter of the HTMLAllCollection object on which the method was invoked. In HTML documents, the argument must first be converted to ASCII lowercase.

2.7.2.2 HTMLFormControlsCollection

HTMLFormControlsCollectionインターフェースは、formfieldset要素で記載要素コレクションに使用される。

interface HTMLFormControlsCollection : HTMLCollection {
  // inherits length and item()
  legacycaller getter (RadioNodeList or Element)? namedItem(DOMString name); // shadows inherited namedItem()
};

interface RadioNodeList : NodeList {
          attribute DOMString value;
};
collection . length

コレクションの要素数を返す。

element = collection . item(index)
collection[index]

コレクションからのインデックスindexとともにアイテムを返す。アイテムはツリー順にソートされる。

element = collection . namedItem(name)
radioNodeList = collection . namedItem(name)
collection[name]
collection(name)

コレクションからのIDまたはname nameとともにアイテムを返す。

複数のマッチするアイテムが存在する場合、それらの要素すべてを含むRadioNodeListオブジェクトが返される。

radioNodeList . value [ = value ]

オブジェクトによって表される最初にチェックされたラジオボタンの値を返す。

設定される場合、オブジェクトによって表される与えられた値を持つ最初のラジオボタンをチェックする。

The object's supported property indices are as defined for HTMLCollection objects.

The supported property names consist of the non-empty values of all the id and name attributes of all the elements represented by the collection, in tree order, ignoring later duplicates, with the id of an element preceding its name if it contributes both, they differ from each other, and neither is the duplicate of an earlier entry.

The namedItem(name) method must act according to the following algorithm:

  1. If name is the empty string, return null and stop the algorithm.
  2. If, at the time the method is called, there is exactly one node in the collection that has either an id attribute or a name attribute equal to name, then return that node and stop the algorithm.
  3. Otherwise, if there are no nodes in the collection that have either an id attribute or a name attribute equal to name, then return null and stop the algorithm.
  4. Otherwise, create a new RadioNodeList object representing a live view of the HTMLFormControlsCollection object, further filtered so that the only nodes in the RadioNodeList object are those that have either an id attribute or a name attribute equal to name. The nodes in the RadioNodeList object must be sorted in tree order.
  5. Return that RadioNodeList object.

Members of the RadioNodeList interface inherited from the NodeList interface must behave as they would on a NodeList object.

The value IDL attribute on the RadioNodeList object, on getting, must return the value returned by running the following steps:

  1. Let element be the first element in tree order represented by the RadioNodeList object that is an input element whose type attribute is in the Radio Button state and whose checkedness is true. Otherwise, let it be null.

  2. If element is null, or if it is an element with no value attribute, return the empty string.

  3. Otherwise, return the value of element's value attribute.

On setting, the value IDL attribute must run the following steps:

  1. Let element be the first element in tree order represented by the RadioNodeList object that is an input element whose type attribute is in the Radio Button state and whose value content attribute is present and equal to the new value, if any. Otherwise, let it be null.

  2. If element is not null, then set its checkedness to true.

2.7.2.3 HTMLOptionsCollection

HTMLOptionsCollectionインターフェースは、option要素のコレクションに使用される。常にselect要素がルートであり、要素の子孫をコントロールする属性およびメソッドを持つ。

interface HTMLOptionsCollection : HTMLCollection {
  // inherits item()
           attribute unsigned long length; // shadows inherited length
  legacycaller HTMLOptionElement? (DOMString name);
  setter creator void (unsigned long index, HTMLOptionElement? option);
  void add((HTMLOptionElement or HTMLOptGroupElement) element, optional (HTMLElement or long)? before = null);
  void remove(long index);
           attribute long selectedIndex;
};
collection . length [ = value ]

コレクションの要素数を返す。

より小さい数に設定する場合、対応するコンテナ内のoption要素数は切り捨てられる。

より大きい数に設定する場合、そのコンテナに新しい空白のoption要素を追加する。

element = collection . item(index)
collection[index]

コレクションからのインデックスindexとともにアイテムを返す。アイテムはツリー順にソートされる。

element = collection . namedItem(name)
nodeList = collection . namedItem(name)
collection[name]
collection(name)

コレクションからのIDまたはname nameとともにアイテムを返す。

複数のマッチするアイテムが存在する場合、最初のものが返される。

collection . add(element [, before ] )

beforeによって与えられるノードの前の要素を挿入する。

before引数は数字でもよく、その場合elementはその数字をもつアイテムの前に挿入され、またはコレクションからの要素でもよい。その場合elementはその要素の前に挿入される。

beforeが省略された、null、または範囲外の数字の場合、elementはリストの最後に加えられるだろう。

要素に挿入された要素が親要素の場合、このメソッドはHierarchyRequestError例外を投げるだろう。

collection . selectedIndex [ = value ]

もしあるならば、最初に選ばれたアイテムのインデックスを、または選択したアイテムが存在しない場合−1を返す。

選択を変更する設定が可能である。

The object's supported property indices are as defined for HTMLCollection objects.

On getting, the length attribute must return the number of nodes represented by the collection.

On setting, the behavior depends on whether the new value is equal to, greater than, or less than the number of nodes represented by the collection at that time. If the number is the same, then setting the attribute must do nothing. If the new value is greater, then n new option elements with no attributes and no child nodes must be appended to the select element on which the HTMLOptionsCollection is rooted, where n is the difference between the two numbers (new value minus old value). Mutation events must be fired as if a DocumentFragment containing the new option elements had been inserted. If the new value is lower, then the last n nodes in the collection must be removed from their parent nodes, where n is the difference between the two numbers (old value minus new value).

Setting length never removes or adds any optgroup elements, and never adds new children to existing optgroup elements (though it can remove children from them).

The supported property names consist of the non-empty values of all the id and name attributes of all the elements represented by the collection, in tree order, ignoring later duplicates, with the id of an element preceding its name if it contributes both, they differ from each other, and neither is the duplicate of an earlier entry.

The legacy caller of the HTMLOptionsCollection interface must act like the namedItem() method on the ancestor HTMLCollection interface.

When the user agent is to set the value of a new indexed property or set the value of an existing indexed property for a given property index index to a new value value, it must run the following algorithm:

  1. If value is null, invoke the steps for the remove method with index as the argument, and abort these steps.

  2. Let length be the number of nodes represented by the collection.

  3. Let n be index minus length.

  4. If n is greater than zero, then append a DocumentFragment consisting of n-1 new option elements with no attributes and no child nodes to the select element on which the HTMLOptionsCollection is rooted.

  5. If n is greater than or equal to zero, append value to the select element. Otherwise, replace the indexth element in the collection by value.

The add(element, before) method must act according to the following algorithm:

  1. If element is an ancestor of the select element on which the HTMLOptionsCollection is rooted, then throw a HierarchyRequestError exception and abort these steps.

  2. If before is an element, but that element isn't a descendant of the select element on which the HTMLOptionsCollection is rooted, then throw a NotFoundError exception and abort these steps.

  3. If element and before are the same element, then return and abort these steps.

  4. If before is a node, then let reference be that node. Otherwise, if before is an integer, and there is a beforeth node in the collection, let reference be that node. Otherwise, let reference be null.

  5. If reference is not null, let parent be the parent node of reference. Otherwise, let parent be the select element on which the HTMLOptionsCollection is rooted.

  6. Act as if the DOM insertBefore() method was invoked on the parent node, with element as the first argument and reference as the second argument.

The remove(index) method must act according to the following algorithm:

  1. If the number of nodes represented by the collection is zero, abort these steps.

  2. If index is not a number greater than or equal to 0 and less than the number of nodes represented by the collection, abort these steps.

  3. Let element be the indexth element in the collection.

  4. Remove element from its parent node.

The selectedIndex IDL attribute must act like the identically named attribute on the select element on which the HTMLOptionsCollection is rooted

2.7.3 DOMStringMap

DOMStringMapインターフェースは、名前と値のペアの組を表す。これは、プロパティーのアクセスのためにスクリプト言語のネイティヴメカニズムを使用して、ペアの組を公開する。

When a DOMStringMap object is instantiated, it is associated with three algorithms, one for getting the list of name-value pairs, one for setting names to certain values, and one for deleting names.

[OverrideBuiltins]
interface DOMStringMap {
  getter DOMString (DOMString name);
  setter creator void (DOMString name, DOMString value);
  deleter void (DOMString name);
};

The supported property names on a DOMStringMap object at any instant are the names of each pair returned from the algorithm for getting the list of name-value pairs at that instant, in the order returned.

To determine the value of a named property name in a DOMStringMap, the user agent must return the value component of the name-value pair whose name component is name in the list returned by the algorithm for getting the list of name-value pairs.

To set the value of a new or existing named property name to value value, the algorithm for setting names to certain values must be run, passing name as the name and the result of converting value to a DOMString as the value.

To delete an existing named property name, the algorithm for deleting names must be run, passing name as the name.

The DOMStringMap interface definition here is only intended for JavaScript environments. Other language bindings will need to define how DOMStringMap is to be implemented for those languages.

要素のdataset属性は、要素のdata-*属性を公開する。

類似の構造とともに以下の引数および要素が与えられるとする:

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

2.7.4 譲渡可能オブジェクト

一部のオブジェクトは、ある操作でコピーおよびクローズされることをサポートする。これはオブジェクトを譲渡可能と呼び、特に共有不可の所有権またはワーカーの境界を越えて高価なリソースを移転することに使用される。

以下はTransferable型である:

The following IDL block formalizes this:

[NoInterfaceObject]
interface Transferable { };
ArrayBuffer implements Transferable;
MessagePort implements Transferable;

To transfer a Transferable object to a new owner, the user agent must run the steps defined for the type of object in question. The steps will return a new object of the same type, and will permanently neuter the original object. (This is an irreversible and non-idempotent operation; once an object has been transferred, it cannot be transferred, or indeed used, again.)

To transfer an ArrayBuffer object old to a new owner owner, a user agent must create a new ArrayBuffer object pointing at the same underlying data as old, thus obtaining new, must neuter the old object, and must finally return new. [TYPEDARRAY]

Rules for how to transfer a MessagePort object are given in the relevant sections of this specification.

2.7.5 Safe passing of structured data

When a user agent is required to obtain a structured clone of a value, optionally with a transfer map, it must run the following algorithm, which either returns a separate value, or throws an exception. If a transfer map is provided, it consists of an association list of Transferable objects to placeholder objects.

  1. Let input be the value being cloned.

  2. Let transfer map be the transfer map passed to the algorithm, if any, or the empty list otherwise.

  3. Let memory be an association list of pairs of objects, initially empty. This is used to handle duplicate references. In each pair of objects, one is called the source object and the other the destination object.

  4. For each mapping in transfer map, add a mapping from the Transferable object (the source object) to the placeholder object (the destination object) to memory.

  5. Let output be the value resulting from calling the internal structured cloning algorithm with input as the "input" argument, and memory as the "memory" argument.

  6. Return output.

The internal structured cloning algorithm is always called with two arguments, input and memory, and its behavior is as follows:

  1. If input is the source object of a pair of objects in memory, then return the destination object in that pair of objects and abort these steps.

  2. If input is a primitive value, then return that value and abort these steps.

  3. Let deep clone be none.

  4. The input value is an object. Jump to the appropriate step below:

    If input is a Boolean object

    Let output be a newly constructed Boolean object with the same value as input.

    If input is a Number object

    Let output be a newly constructed Number object with the same value as input.

    If input is a String object

    Let output be a newly constructed String object with the same value as input.

    If input is a Date object

    Let output be a newly constructed Date object with the same value as input.

    If input is a RegExp object

    Let output be a newly constructed RegExp object with the same pattern and flags as input.

    The value of the lastIndex property is not copied.

    If input is a Blob object

    If input has been disabled through the close() method, throw a DataCloneError exception and abort the overall structured clone algorithm. Otherwise, let output be a newly constructed object of the same class as input, corresponding to the same underlying data.

    If input is a FileList object

    Let output be a newly constructed FileList object containing a list of newly constructed File objects corresponding to the same underlying data as those in input, maintaining their relative order.

    If input is an ImageData object

    Let output be a newly constructed ImageData object whose width, height, and resolution attributes have values equal to the corresponding attributes on input, and whose data attribute has the value obtained from invoking the internal structured cloning algorithm recursively with the value of the data attribute on input as the new "input" argument and memory as the new "memory" argument.

    If input is an ArrayBuffer object

    If input has been neutered, throw a DataCloneError exception and abort the overall structured clone algorithm. Otherwise, let output be a newly constructed ArrayBuffer object whose contents are a copy of input's contents, with the same length.

    If input is an ArrayBufferView object

    Let output be a newly constructed object of the same class as input, with each IDL attribute defined for that class being set to the value obtained from invoking the internal structured cloning algorithm recursively with the value of the attribute on input as the new "input" argument and memory as the new "memory" argument.

    Only IDL attributes defined on the class (including the ArrayBufferView attributes) are cloned. Properties added by a script, for example, are not cloned.

    If input is an Array object

    Let output be a newly constructed empty Array object whose length is equal to the length of input, and set deep clone to own.

    This means that the length of sparse arrays is preserved.

    If input is an Object object

    Let output be a newly constructed empty Object object, and set deep clone to own.

    If input is a Map object

    Let output be a newly constructed empty Map object, and set deep clone to map.

    If input is a Set object

    Let output be a newly constructed empty Set object, and set deep clone to set.

    If input is an object that another specification defines how to clone

    Let output be a clone of the object as defined by the other specification.

    If input is another native object type (e.g. Error, Function)
    If input is a host object (e.g. a DOM node)

    Throw a DataCloneError exception and abort the overall structured clone algorithm.

    For the purposes of the algorithm above, an object is a particular type of object class if its [[Class]] internal property is equal to class.

    For example, "input is an Object object" if input's [[Class]] internal property is equal to the string "Object".

  5. Add a mapping from input (the source object) to output (the destination object) to memory.

  6. If deep clone is set to map, then run these substeps. These substeps use the terminology and typographic conventions used in the JavaScript specification's definition of Maps. [ECMA262]

    1. Let source be the List that is the value of input's [[MapData]] internal slot, if any. If there is no such slot, then instead throw a DataCloneError exception and abort the overall structured clone algorithm. [ECMA262]

    2. Let target be the List that is the value of output's [[MapData]] internal slot.

    3. For each Record {[[key]], [[value]]} entry that is an element of source, run the following substeps:

      1. Let key have the value obtained from invoking the internal structured cloning algorithm recursively with entry.[[key]] as the new "input" argument and memory as the new "memory" argument.

      2. Let value have the value obtained from invoking the internal structured cloning algorithm recursively with entry.[[value]] as the new "input" argument and memory as the new "memory" argument.

      3. Let new entry be the Record {[[key]]: key, [[value]]: value}.

      4. Append new entry as the last element of target.

    4. Set deep clone to own.

  7. If deep clone is set to set, then run these substeps. These substeps use the terminology and typographic conventions used in the JavaScript specification's definition of Sets. [ECMA262]

    1. Let source be the List that is the value of input's [[SetData]] internal slot, if any. If there is no such slot, then instead throw a DataCloneError exception and abort the overall structured clone algorithm. [ECMA262]

    2. Let target be the List that is the value of output's [[SetData]] internal slot.

    3. For each entry that is an element of source that is not empty, run the following substeps:

      1. Let new entry have the value obtained from invoking the internal structured cloning algorithm recursively with entry as the new "input" argument and memory as the new "memory" argument.

      2. Append new entry as the last element of target.

    4. Set deep clone to own.

  8. If deep clone is set to own, then, for each enumerable own property in input, run the following steps:

    1. Let name be the name of the property.

    2. Let source value be the result of calling the [[Get]] internal method of input with the argument name. If the [[Get]] internal method of a property involved executing script, and that script threw an uncaught exception, then abort the overall structured clone algorithm, with that exception being passed through to the caller.

    3. Let cloned value be the result of invoking the internal structured cloning algorithm recursively with source value as the "input" argument and memory as the "memory" argument. If this results in an exception, then abort the overall structured clone algorithm, with that exception being passed through to the caller.

    4. Add a new property to output having the name name, and having the value cloned value.

    The order of the properties in the input and output objects must be the same, and any properties whose [[Get]] internal method involves running script must be processed in that same order.

    This does not walk the prototype chain.

    Property descriptors, setters, getters, and analogous features are not copied in this process. For example, the property in the input could be marked as read-only, but in the output it would just have the default state (typically read-write, though that could depend on the scripting environment).

    Properties of Array objects are not treated any differently than those of other Objects. In particular, this means that non-index properties of arrays are copied as well.

  9. Return output.

This algorithm preserves cycles and preserves the identity of duplicate objects in graphs.

2.7.6 コールバック

次のコールバック関数型は、Fileオブジェクトと対話するさまざまなAPIで使用される:

callback FileCallback = void (File file);

2.7.7 Garbage collection

There is an implied strong reference from any IDL attribute that returns a pre-existing object to that object.

For example, the document.location attribute means that there is a strong reference from a Document object to its Location object. Similarly, there is always a strong reference from a Document to any descendant nodes, and from any node to its owner Document.

2.8 名前空間

HTML名前空間http://www.w3.org/1999/xhtmlである。

MathML名前空間http://www.w3.org/1998/Math/MathMLである。

SVG名前空間http://www.w3.org/2000/svgである。

XLink名前空間http://www.w3.org/1999/xlinkである。

XML名前空間http://www.w3.org/XML/1998/namespaceである。

XMLNS名前空間http://www.w3.org/2000/xmlns/である。


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


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

3 セマンティック、構造、HTML文書のAPI群

3.1 文書

HTMLユーザーエージェントにおいてすべてのXMLおよびHTML文書は、Documentオブジェクトによって表される。[DOM]

文書のアドレスは、Documentの存続期間中に変更されるものを除く、Documentが作成された際の初期設定である絶対URLである。たとえば、ユーザーがページ上のフラグメント識別子操作した場合、またはpushState()メソッドが新しいURLとともに呼ばれた場合である。

対話的なユーザーエージェントは一般にユーザーインターフェースで文書のアドレスを公開する。これは、サイトが別のものを偽装しようとしているかどうかをユーザーが見分けるための基本メカニズムである。

DocumentcreateDocument()またはcreateHTMLDocument()APIを用いたスクリプトで作成される場合、文書のアドレスはスクリプトの設定オブジェクトによって指定される信頼できる文書に属する文書のアドレスと同じであり、Documentは即座にready for post-load taskscompletely loadedの両方となる。

文書のリファラは、Documentが作成された際に設定できる絶対URLである。文書のリファラが明示的に設定されない場合、値は空文字列である。

Documentオブジェクトは、当初は設定されないリロード上書きフラグを持つ。フラグは、特定の状況でdocument.open()およびdocument.write()メソッドによって設定される。フラグが設定された場合、Documentもまたリロードされたときに文書のソースとして使用されるUnicode文字列であるリロード上書きバッファを持つ。

ユーザーエージェントが上書きされたリロードを実行することになっている場合、ソースブラウジングコンテキストを与えられ、以下のように振る舞わなければならない:

  1. sourceブラウジングコンテキストアクティブ文書がもつリロード上書きバッファの値にする。

  2. addressブラウジングコンテキストアクティブ文書アドレスにする。

  3. Navigate 置換有効かつ例外有効とともに、ブラウジングコンテキストにソースがsourceであるリソース。ソースブラウジングコンテキスト上書きリロードアルゴリズムに与えられるものである。操作アルゴリズムがこの目的のためにDocumentオブジェクトを作成する場合、Documentリロード上書きフラグを設定し、リロード上書きバッファsourceに設定する。

    ナビゲーションアルゴリズム文書のアドレスを設定する時間が来ると、上書きURLとしてaddressを使用する。

3.1.1 Documentオブジェクト

DOM仕様は、この仕様が大幅に拡大解釈するDocumentインターフェースを定義する:

enum DocumentReadyState { "loading", "interactive", "complete" };

[OverrideBuiltins]
partial /*sealed*/ interface Document {
  // resource metadata management
  [PutForwards=href, Unforgeable] readonly attribute Location? location;
           attribute DOMString domain;
  readonly attribute DOMString referrer;
           attribute DOMString cookie;
  readonly attribute DOMString lastModified;
  readonly attribute DocumentReadyState readyState;

  // DOM tree accessors
  getter object (DOMString name);
           attribute DOMString title;
           attribute DOMString dir;
           attribute HTMLElement? body;
  readonly attribute HTMLHeadElement? head;
  readonly attribute HTMLCollection images;
  readonly attribute HTMLCollection embeds;
  readonly attribute HTMLCollection plugins;
  readonly attribute HTMLCollection links;
  readonly attribute HTMLCollection forms;
  readonly attribute HTMLCollection scripts;
  NodeList getElementsByName(DOMString elementName);

  // dynamic markup insertion
  Document open(optional DOMString type = "text/html", optional DOMString replace = "");
  WindowProxy open(DOMString url, DOMString name, DOMString features, optional boolean replace = false);
  void close();
  void write(DOMString... text);
  void writeln(DOMString... text);

  // user interaction
  readonly attribute WindowProxy? defaultView;
  readonly attribute Element? activeElement;
  boolean hasFocus();
           attribute DOMString designMode;
  boolean execCommand(DOMString commandId, optional boolean showUI = false, optional DOMString value = "");
  boolean queryCommandEnabled(DOMString commandId);
  boolean queryCommandIndeterm(DOMString commandId);
  boolean queryCommandState(DOMString commandId);
  boolean queryCommandSupported(DOMString commandId);
  DOMString queryCommandValue(DOMString commandId);

  // special event handler IDL attributes that only apply to Document objects
  [LenientThis] attribute EventHandler onreadystatechange;
};
Document implements GlobalEventHandlers;

3.1.2 リソースメタデータの取り扱い

document . referrer

ユーザーが操作した文書アドレスを返す。ただしブロックされるあるいはそのような文書がない場合を除く。その場合空文字列を返す。

noreferrerリンク型はリファラを遮断するために使用されうる。

The referrer attribute must return the document's referrer.

HTTPの場合、referrerIDL属性は、カレントページを取得するときに送られるRefererヘッダーにマッチするだろう。

典型的なユーザーエージェントは、リファラが暗号化されたプロトコルを使用し、カレントページが暗号化されていない場所(たとえばhttps:ページからhttp:ページに操作するとき)の場合、リファラを報告しない設定をする。


document . cookie [ = value ]

Documentに適用するHTTPクッキーを返す。クッキーが存在しないかクッキーがこのリソースに適用されない場合、空文字を返すだろう。

新しいクッキーをHTTPクッキーの要素に設定が可能である。

コンテンツがサンドボックス化された固有生成元(たとえば、sandbox属性を持つiframeの中)である場合、SecurityError例外は取得および設定時に投げられるだろう。

The cookie attribute represents the cookies of the resource identified by the document's address.

A Document object that falls into one of the following conditions is a cookie-averse Document object:

On getting, if the document is a cookie-averse Document object, then the user agent must return the empty string. Otherwise, if the Document's origin is not a scheme/host/port tuple, the user agent must throw a SecurityError exception. Otherwise, the user agent must first obtain the storage mutex and then return the cookie-string for the document's address for a "non-HTTP" API, decoded using the UTF-8 decoder. [COOKIES] (This is a fingerprinting vector.)

On setting, if the document is a cookie-averse Document object, then the user agent must do nothing. Otherwise, if the Document's origin is not a scheme/host/port tuple, the user agent must throw a SecurityError exception. Otherwise, the user agent must obtain the storage mutex and then act as it would when receiving a set-cookie-string for the document's address via a "non-HTTP" API, consisting of the new value encoded as UTF-8. [COOKIES] [RFC3629]

Since the cookie attribute is accessible across frames, the path restrictions on cookies are only a tool to help manage which cookies are sent to which parts of the site, and are not in any way a security feature.


document . lastModified

ユーザーのローカルタイムゾーンで"MM/DD/YYYY hh:mm:ss"由来のサーバーによって報告されるような、文書の最終更新日時を返す。

最終更新日時が不明の場合、代わりに現在の時刻が返される。

The lastModified attribute, on getting, must return the date and time of the Document's source file's last modification, in the user's local time zone, in the following format:

  1. The month component of the date.
  2. A "/" (U+002F) character.
  3. The day component of the date.
  4. A "/" (U+002F) character.
  5. The year component of the date.
  6. A U+0020 SPACE character.
  7. The hours component of the time.
  8. A ":" (U+003A) character.
  9. The minutes component of the time.
  10. A ":" (U+003A) character.
  11. The seconds component of the time.

All the numeric components above, other than the year, must be given as two ASCII digits representing the number in base ten, zero-padded if necessary. The year must be given as the shortest possible string of four or more ASCII digits representing the number in base ten, zero-padded if necessary.

The Document's source file's last modification date and time must be derived from relevant features of the networking protocols used, e.g. from the value of the HTTP Last-Modified header of the document, or from metadata in the file system for local files. If the last modification date and time are not known, the attribute must return the current date and time in the above format.


document . readyState

Documentが、いったん解析を完了したがまだサブリソースを読み込んでいる時点で"interactive"を、読み込まれた時点で"complete"を、読み込み中の間"loading"を返す。

readystatechangeイベントは、この値が変更したときにDocumentオブジェクトで発火する。

Each document has a current document readiness. When a Document object is created, it must have its current document readiness set to the string "loading" if the document is associated with an HTML parser, an XML parser, or an XSLT processor, and to the string "complete" otherwise. Various algorithms during page loading affect this value. When the value is set, the user agent must fire a simple event named readystatechange at the Document object.

A Document is said to have an active parser if it is associated with an HTML parser or an XML parser that has not yet been stopped or aborted.

The readyState IDL attribute must, on getting, return the current document readiness.

3.1.3 DOMツリーアクセス機構

ルート要素が存在しhtml要素である場合、文書のhtml要素は文書のルート要素である。そうでなければnullである。


document . head

head要素を返す。

存在するならば、文書のhead要素は、html要素の子である最初のhead要素である。そうでなければnullである。

The head attribute, on getting, must return the head element of the document (a head element or null).


document . title [ = value ]

title要素に与えられるものとして、文書のタイトルを返す。

文書のタイトルを更新する設定が可能である。head要素が存在しない場合、新規の値は無視される。

SVG文書では、SVGDocumentインターフェースのtitle属性が優位となる。

存在するならば、文書のtitle要素は文書での(ツリー順で)最初のtitle要素である。そうでなければnullである。

The title attribute must, on getting, run the following algorithm:

  1. If the root element is an svg element in the "http://www.w3.org/2000/svg" namespace, and the user agent supports SVG, then return the value that would have been returned by the IDL attribute of the same name on the SVGDocument interface. [SVG]

  2. Otherwise, let value be a concatenation of the data of all the child Text nodes of the title element, in tree order, or the empty string if the title element is null.

  3. Strip and collapse whitespace in value.

  4. Return value.

On setting, the following algorithm must be run. Mutation events must be fired as appropriate.

  1. If the root element is an svg element in the "http://www.w3.org/2000/svg" namespace, and the user agent supports SVG, then the setter must act as if it was the setter for the IDL attribute of the same name on the Document interface defined by the SVG specification. Stop the algorithm here. [SVG]

  2. If the title element is null and the head element is null, then the attribute must do nothing. Stop the algorithm here.
  3. If the title element is null, then a new title element must be created and appended to the head element. Let element be that element. Otherwise, let element be the title element.
  4. The children of element (if any) must all be removed.
  5. A single Text node whose data is the new value being assigned must be appended to element.

The title IDL attribute defined above must replace the attribute of the same name on the Document interface defined by the SVG specification when the user agent supports both HTML and SVG. [SVG]


document . body [ = value ]

body要素を返す。

body要素を置換する設定が可能である。

新しい値がbodyまたはframeset要素でない場合、これはHierarchyRequestError例外を投げる。

文書のbody要素は、body要素またはframeset要素のいずれかであるhtml要素の最初の子である。そのような要素が存在しない場合、nullである。

The body attribute, on getting, must return the body element of the document (either a body element, a frameset element, or null). On setting, the following algorithm must be run:

  1. If the new value is not a body or frameset element, then throw a HierarchyRequestError exception and abort these steps.
  2. Otherwise, if the new value is the same as the body element, do nothing. Abort these steps.
  3. Otherwise, if the body element is not null, then replace that element with the new value in the DOM, as if the root element's replaceChild() method had been called with the new value and the incumbent body element as its two arguments respectively, then abort these steps.
  4. Otherwise, if there is no root element, throw a HierarchyRequestError exception and abort these steps.
  5. Otherwise, the body element is null, but there's a root element. Append the new value to the root element.

document . images

Documentimg要素のHTMLCollectionを返す。

document . embeds
document . plugins

Documentembed要素のHTMLCollectionを返す。

document . links

href属性を持つDocumentaおよびarea要素のHTMLCollectionを返す。

document . forms

Documentform要素のHTMLCollectionを返す。

document . scripts

Documentscript要素のHTMLCollectionを返す。

The images attribute must return an HTMLCollection rooted at the Document node, whose filter matches only img elements.

The embeds attribute must return an HTMLCollection rooted at the Document node, whose filter matches only embed elements.

The plugins attribute must return the same object as that returned by the embeds attribute.

The links attribute must return an HTMLCollection rooted at the Document node, whose filter matches only a elements with href attributes and area elements with href attributes.

The forms attribute must return an HTMLCollection rooted at the Document node, whose filter matches only form elements.

The scripts attribute must return an HTMLCollection rooted at the Document node, whose filter matches only script elements.


collection = document . getElementsByName(name)

nameとともにname属性を持つDocumentで要素のNodeListを返す。

The getElementsByName(name) method takes a string name, and must return a live NodeList containing all the HTML elements in that document that have a name attribute whose value is equal to the name argument (in a case-sensitive manner), in tree order. When the method is invoked on a Document object again with the same argument, the user agent may return the same as the object returned by the earlier call. In other cases, a new NodeList object must be returned.


The Document interface supports named properties. The supported property names at any moment consist of the values of the name content attributes of all the applet, exposed embed, form, iframe, img, and exposed object elements in the Document that have non-empty name content attributes, and the values of the id content attributes of all the applet and exposed object elements in the Document that have non-empty id content attributes, and the values of the id content attributes of all the img elements in the Document that have both non-empty name content attributes and non-empty id content attributes. The supported property names must be in tree order, ignoring later duplicates, with values from id attributes coming before values from name attributes when the same element contributes both.

To determine the value of a named property name when the Document object is indexed for property retrieval, the user agent must return the value obtained using the following steps:

  1. Let elements be the list of named elements with the name name in the Document.

    There will be at least one such element, by definition.

  2. If elements has only one element, and that element is an iframe element, then return the WindowProxy object of the nested browsing context represented by that iframe element, and abort these steps.

  3. Otherwise, if elements has only one element, return that element and abort these steps.

  4. Otherwise return an HTMLCollection rooted at the Document node, whose filter matches only named elements with the name name.

Named elements with the name name, for the purposes of the above algorithm, are those that are either:

An embed or object element is said to be exposed if it has no exposed object ancestor, and, for object elements, is additionally either not showing its fallback content or has no object or embed descendants.


Documentインターフェース上のdir属性は、dirコンテンツ属性と同様に定義される。

3.2 要素

3.2.1 セマンティック

HTMLでの要素、属性、および属性値は、ある意味(セマンティック)を持つよう(この仕様によって)定義される。たとえば、ol要素は順序つきリストを表し、lang属性はコンテンツの言語を表す。

これら定義は、ウェブブラウザや検索エンジンなどのHTMLプロセッサに、著者が考えてないかもしれないさまざまな文脈で文書およびアプリケーションの提示と使用を許可する。

簡単な例として、デスクトップコンピュータのウェブブラウザのみを考慮した著者によって書かれたウェブページを考えてみる:

<!DOCTYPE HTML>
<html>
 <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におけるセマンティックのすべてに同じ原理が適用される。

著者は、ソフトウェアがページを正しく処理するのを妨げるような、適切な意図されるセマンティック目的以外の要素、属性、または属性値を使用してはならない。

たとえば、以下の文書は構文的に正しいにもかかわらず、不適合である:

<!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="http://example.org/~ernest/"><cite>Ernest</cite></a>,
     in an essay from 1992
    </td>
   </tr>
  </table>
 </body>
</html>

これは、セルに配置されたデータが明らかに表形式データでないためである(そしてcite要素が誤って使われている)。これは、要素のセマンティックを信頼するソフトウェアを停止させるだろう。たとえば、目の不自由なユーザーに文書内の表の操作を許可された音声ブラウザは、上記の引用を表として報告し、ユーザーを混乱させるだろう。同様に、ページから作品タイトルを抽出するツールは、実際に人の名前であってタイトルでないにもかかわらず、作品のタイトルとして"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="http://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>

ユーザーエージェントが文書を処理している間に、スクリプトやその他のメカニズムの使用を介して、属性値、テキスト、文書の全体構造は実際に動的に変更するかもしれない。ある瞬間において文書のセマンティックは、その瞬間における文書の状態によって表されるものであり、したがって、文書のセマンティックは、時間の経過とともに変化する。User agents must update their presentation of the document as this occurs.

HTMLは、プログレスバーを表すprogress要素を持つ。その"value"属性がスクリプトによって動的に更新される場合、ユーザーエージェントは進行状況の変更を表示するためにレンダリングを更新するだろう。

3.2.2 DOMにおける要素

The nodes representing HTML elements in the DOM must implement, and expose to scripts, the interfaces listed for them in the relevant sections of this specification. This includes HTML elements in XML documents, even when those documents are in another context (e.g. inside an XSLT transform).

DOM内の要素は概念を表す。これは、要素がセマンティックとして知られる固有の意味を持つ。

たとえば、ol要素は順序つきリストを表す。

The basic interface, from which all the HTML elements' interfaces inherit, and which must be used by elements that have no additional requirements, is the HTMLElement interface.

interface HTMLElement : Element {
  // metadata attributes
           attribute DOMString title;
           attribute DOMString lang;
           attribute boolean translate;
           attribute DOMString dir;
  readonly attribute DOMStringMap dataset;


  // user interaction
           attribute boolean hidden;
  void click();
           attribute long tabIndex;
  void focus();
  void blur();
           attribute DOMString accessKey;
  readonly attribute DOMString accessKeyLabel;
           attribute DOMString contentEditable;
  readonly attribute boolean isContentEditable;
           attribute boolean spellcheck;
};
HTMLElement implements GlobalEventHandlers;

interface HTMLUnknownElement : HTMLElement { };

HTMLElementインターフェースは、多数の異なる機能に関係するメソッドおよび属性を保持する。したがって、このインターフェースのメンバーはこの仕様の異なるセクションでさまざまに説明される。

The HTMLUnknownElement interface must be used for HTML elements that are not defined by this specification (or other applicable specifications).

3.2.3 要素定義

この仕様において各要素は以下の情報を含む定義を持つ:

カテゴリ

要素が属するカテゴリのリスト。これは、各要素に対するコンテンツモデルを定義する際に使用される。

この要素を使用できるコンテキスト

要素を使用できる場所の非規範的な記述。この情報は、子として、この要素を許可する要素のコンテンツモデルとともに冗長であり、利便性のためだけに提供される。

簡単のために、最も具体的な期待のみが記載される。たとえば、要素はフローコンテンツまたはフレージングコンテンツのいずれかが予期される場所ならどこでも、フローコンテンツフレージングコンテンツの両方を使用できるが、フローコンテンツは予期される場所ならどこでも、フレージングコンテンツもまた予期されるので(すべてのフレージングコンテンツフローコンテンツであるので)、ただ"フレージングコンテンツが予期される場所"とだけ記載されるだろう。

コンテンツモデル

コンテンツがその要素の子や子孫として含めなければならないものの、規範的な記述。

text/htmlにおけるタグ省略

text/html構文で、開始タグと終了タグを省略することができるかどうかの非規範的な記述。この情報は、任意タグのセクションで与えられた規範的要件とともに冗長であり、利便性のみの要素の定義に記載される。

コンテンツ属性

(許可しない場合を除く)要素で指定されてもよい属性の規範的なリスト、およびこれら属性の非規範的な説明。(ダッシュの左側のコンテンツが規範的であり、ダッシュの右側のコンテンツがそうでない。)

DOMインターフェース

そのような要素が実装しなければならないDOMインターフェースの規範的な定義。

This is then followed by a description of what the element represents, along with any additional normative conformance criteria that may apply to authors and implementations. 時に例も含まれる。

3.2.3.1 属性

特に指定される場合を除き、HTML要素の属性は、空の文字列を含む、任意の文字列値を持ってもよい。明示的に記載される場合を除き、テキストが属性として指定できるものに制限はない。

3.2.4 コンテンツモデル

この仕様で定義される各要素は、要素の期待されるコンテンツの説明となる、コンテンツモデルを持つ。HTML要素は、要素のコンテンツモデルで説明される要求に一致するコンテンツを持たなければならない。要素のコンテンツは、子がテンプレートコンテンツである(要素が作成された際に要素に割り当てられる別々のDocumentFragmenttemplate要素を除いた、DOMにおけるその要素の子である。

空白文字は常に要素の間に許可される。ユーザーエージェントは、DOM内でTextノードとしてマークアップするソース内の要素間でこれらの文字を表す。 それらの文字の単なる配列からなる空のTextノードおよびTextノードは、要素間の空白文字と見なされる。

要素間の空白文字、コメントノード、および処理命令ノードは、要素の内容が要素の内容モデルと一致させるかどうかを確立する際に無視されなければならず、文書および要素のセマンティックを定義するアルゴリズムをたどる際に無視されなければならない。

このように、ABが同じ親ノードを持ち、それらの間に他の要素ノードまたは(要素間の空白以外の)Textノードが存在しない場合、要素Aに2番目の要素B先行または後行すると言う。同様に、その要素が要素間の空白、コメントノード、処理命令ノード以外の他のノードが含まない場合、ノードは、要素の唯一の子である。

著者は、各要素に定義された、あるいは明示的に他の仕様によって要求されたものとして明示的に許可される場所以外でHTML要素を使用してはならない。XML複合文書では、それらの要素が関連するコンテキストを提供するものとして定義される場合、これらのコンテキストは、他の名前空間に由来する要素の内部にあるかもしれない。

たとえば、Atom仕様はcontent要素を定義する。そのtype属性が値xhtmlを持つ場合、Atom仕様はcontent要素がHTML div要素を持つことを要求する。したがって、これがこの仕様によって明白に規範的な規定でないにもかかわらず、div要素はそのコンテキストで許可される。[ATOM]

さらに、HTML要素は省略されてもよい(すなわち、親ノードをもたない)。

たとえば、td要素を作成し、スクリプト内のグローバル変数に格納することは、td要素が別の方法でのみtr要素の内部で使用されることになっているにもかかわらず、適合する。

var data = {
  name: "Banana",
  cell: document.createElement('td'),
};
3.2.4.1 コンテンツの種類

HTMLにおいて各要素は、0個以上の、類似の特性を持つグループ要素であるカテゴリに分類される。次の大まかなカテゴリがこの仕様で使用されている:

一部の要素はまた、本仕様の他の部分で定義される他のカテゴリに分類される。

これらのカテゴリは、次のように関連する:

セクショニングコンテンツ、ヘディングコンテンツ、フレージングコンテンツ、エンベディッドコンテンツ、およびインタラクティブコンテンツはすべてフローコンテンツ型である。メタデータは、時にフローコンテンツとなる。メタデータとインタラクティブコンテンツは時にフレージングコンテンツとなる。エンベディッドコンテンツはまた、フレージングコンテンツ型であり、時にインタラクティブコンテンツとなる。

その他のカテゴリはまた、特定の目的のために使用される。たとえばフォームコントロールは、一般的な要件を定義するために多数のカテゴリを用いて指定される。一部の要素は固有の要件があり、特定のカテゴリに属さない。

3.2.4.1.1 メタデータコンテンツ

メタデータコンテンツは、見栄えまたは後のコンテンツの振る舞いを設定する、または他の文書との関係を設定する、または他の"帯域外の"情報を運搬するコンテンツである。

セマンティックが主としてメタデータに関連する他の名前空間由来の要素(たとえば、RDF)もまた、メタデータコンテンツである。

したがって、XMLシリアライゼーションにおいて、このようにRDFを使用できる:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 <head>
  <title>Hedral's Home Page</title>
  <r:RDF>
   <Person xmlns="http://www.w3.org/2000/10/swap/pim/contact#"
           r:about="http://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シリアライゼーションでは不可能である。

3.2.4.1.2 フローコンテンツ

文書およびアプリケーションのbodyで使用される多くの要素は、フローコンテンツとして分類される。

3.2.4.1.3 セクショニングコンテンツ

セクショニングコンテンツは、見出しおよびフッターの範囲を定義するコンテンツである。

セクショニングコンテンツ要素は潜在的に見出しとアウトラインを持つ。詳細は見出しとセクションの章を参照のこと。

ある要素はまたセクショニングルートである。セクショニングコンテンツとは異なる存在だが、アウトラインを持つ。

3.2.4.1.4 ヘディングコンテンツ

ヘディングコンテンツはセクションのヘッダーを定義する(明示的にセクショニングコンテンツ要素を用いてマークアップされようとなかろうと、またはヘディングコンテンツ自体によって暗黙であろうとなかろうと)。

3.2.4.1.5 フレージングコンテンツ

フレージングコンテンツは、文書のテキストおよび段落内レベルでそのテキストをマークアップする要素である。段落からフレージングコンテンツが続く。

フレージングコンテンツとして分類されるほとんどの要素は、自身がフローコンテンツではなく、フレージングコンテンツとして分類される要素のみを含むことができる。

コンテンツモデルのコンテキストにおいてテキストは、何もないか、Textノードのいずれかを意味する。テキストは時に、そのままでコンテンツモデルとして使用されるが、フレージングコンテンツでもあり、要素間の空白文字でもあるかもしれない(Textノードが空であるか、単に空白文字を含む場合)。

Textノードおよび属性値は、Unicode文字から構成されなければならず、U+0000文字を含んではならず、恒久的に未定義のUnicode文字(noncharacters)を含んではならず、空白文字以外の制御文字を含んではならない。 この仕様は、明確な文脈に応じたTextノードおよび属性値の正確な値に追加の制限を含む。

3.2.4.1.6 エンベディッドコンテンツ

エンベディッドコンテンツは、他のリソースから文書に取り込むコンテンツであるか、文書へ挿入される他の語彙由来のコンテンツである。

HTML名前空間以外の名前空間に基づく、メタデータでなくコンテンツを伝える要素は、この仕様で定義されるコンテンツモデルの目的のためのエンベディッドコンテンツである。(たとえば、MathML、またはSVG。)

一部のエンベディッドコンテンツ要素は、フォールバックコンテンツを持つこともできる。これは外部リソースが使用できない場合(たとえば、サポートされていないフォーマットであるため)に使用されるコンテンツである。もしあれば、要素の定義はどのようなフォールバックであるかを記載する。

3.2.4.1.7 インタラクティブコンテンツ

インタラクティブコンテンツは、特にユーザーとの交流を意図するコンテンツである。

HTMLの特定の要素は、ユーザーがアクティブにすることができることを意味する、アクティベーション動作を持つ。This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event, as described below.

The user agent should allow the user to manually trigger elements that have an activation behavior, for instance using keyboard or voice input, or through mouse clicks. When the user triggers an element with a defined activation behavior in a manner other than clicking it, the default action of the interaction event must be to run synthetic click activation steps on the element.

Each element has a click in progress flag, initially set to false.

When a user agent is to run synthetic click activation steps on an element, the user agent must run the following steps:

  1. If the element's click in progress flag is set to true, then abort these steps.

  2. Set the click in progress flag on the element to true.

  3. Run pre-click activation steps on the element.

  4. Fire a click event at the element. If the run synthetic click activation steps algorithm was invoked because the click() method was invoked, then the isTrusted attribute must be initialized to false.

  5. If this click event is not canceled, run post-click activation steps on the element.

    If the event is canceled, the user agent must run canceled activation steps on the element instead.

  6. Set the click in progress flag on the element to false.

When a pointing device is clicked, the user agent must run these steps:

  1. If the element's click in progress flag is set to true, then abort these steps.

  2. Set the click in progress flag on the element to true.

  3. Let e be the nearest activatable element of the element designated by the user (defined below), if any.

  4. If there is an element e, run pre-click activation steps on it.

  5. Dispatch the required click event.

    If there is an element e and the click event is not canceled, run post-click activation steps on element e.

    If there is an element e and the event is canceled, run canceled activation steps on element e.

  6. Set the click in progress flag on the element to false.

The algorithms above don't run for arbitrary synthetic events dispatched by author script. The click() method can be used to make the run synthetic click activation steps algorithm happen programmatically.

Click-focusing behavior (e.g. the focusing of a text field when user clicks in one) typically happens before the click, when the mouse button is first depressed, and is therefore not discussed here.

Given an element target, the nearest activatable element is the element returned by the following algorithm:

  1. If target has a defined activation behavior, then return target and abort these steps.

  2. If target has a parent element, then set target to that parent element and return to the first step.

  3. Otherwise, there is no nearest activatable element.

When a user agent is to run pre-click activation steps on an element, it must run the pre-click activation steps defined for that element, if any.

When a user agent is to run canceled activation steps on an element, it must run the canceled activation steps defined for that element, if any.

When a user agent is to run post-click activation steps on an element, it must run the activation behavior defined for that element, if any. Activation behaviors can refer to the click event that was fired by the steps above leading up to this point.

3.2.4.1.8 パルパブルコンテンツ

一般的な規則として、コンテンツモデルが任意のフローコンテンツまたはフレージングコンテンツを許可する要素は、パルパブルコンテンツであり、かつhidden属性が指定されないそのコンテンツで少なくとも1つノードを持つべきである。

しかし、要素が合法的に空にできる多くのケースがあるように、たとえば、スクリプトによって後で埋められるプレースホルダーとして使用される場合、または要素がテンプレートの一部であり、かつほとんどのページで満たされるが、一部のページで関係しない場合、この要件は厳しい要件ではない。

適合性検査は、オーサリングの援助として、この要件を満たせない要素を見つけるためのメカニズムを制作者に提供するよう推奨される。

次の要素はパルパブルコンテンツである:

3.2.4.1.9 スクリプトサポート要素

スクリプトサポート要素は、自分自身で何も表さない(つまりこれらはレンダリングされない)が、たとえばユーザーに機能を提供するために、スクリプトをサポートするために使用される。

次の要素は、スクリプトサポート要素である:

3.2.4.2 透過的なコンテンツモデル

いくつかの要素は透過的といわれる。コンテンツモデルの説明でそれらの要素は"透過的"とされる。透過的な要素のコンテンツモデルは、その親要素のコンテンツモデルを受け継ぐ。"透過的"であるコンテンツモデルの役割で要求される要素は、透過的な要素がある、透過的な親要素のコンテンツモデルの役割で要求されるものと同じ要素である。

たとえば、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"は許可される。

透過的なコンテンツが親を持たない場合、"透過的"であるそのコンテンツモデルの役割は、代わりに任意のフローコンテンツを受け入れるものとして扱われなければならない。

3.2.4.3 段落

この節で定義されるような用語段落は、p要素の正確な定義以上の使われ方をする。ここで定義される段落の概念は、どのように文書を解釈すべきかを説明するために使われる。p要素は、段落をマークアップするいくつかのうちの1つにすぎない。

典型的な段落は、活版印刷において見られるような、特定の主題を議論する1つ以上の文をもつテキストのブロックを形成する、フレージングコンテンツの連続であるが、より一般の主題に関する分類に対しても用いられる。たとえば、住所もまた段落であり、フォームの一部、署名、詩のスタンザも同様である。

次の例において、セクションに2つの段落がある。段落ではないフレージングコンテンツを含む見出しもある。コメントおよび段落内の空白文字は段落を形成しないことに注意する。

<section>
  <h1>Example of paragraphs</h1>
  This is the <em>first</em> paragraph in this example.
  <p>This is the second.</p>
  <!-- This is not a paragraph. -->
</section>

フローコンテンツ内の段落は、中身を複雑にするainsdelmap要素なしで、文書がどのように見えるかに関連して定義される。なぜなら、以下に最初の2つの例で示すように、混成のコンテンツモデルをもつこれらの要素は、段落の境界をまたぐことができるためである。

一般に、段落の境界をまたぐ要素を持つことは避けた方がよい。このようなマークアップを維持することは困難なことがある。

次の例は、前述の例からマークアップを選び、テキストが変更されたことを示すためにそのマークアップの一部の周囲にinsdel要素を置く(もっともこの場合、正直なところ変更にあまり意味はないが)。この例は、insdel要素をよそに、前のものとちょうど同じ段落を持つことに注目する―ins要素は見出しと最初の段落にまたがっており、del要素は2つの段落間の境界をまたがっている。

<section>
  <ins><h1>Example of paragraphs</h1>
  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>

Let view be a view of the DOM that replaces all a, ins, del, and map elements in the document with their contents. Then, in view, for each run of sibling phrasing content nodes uninterrupted by other types of content, in an element that accepts content other than phrasing content as well as phrasing content, let first be the first node of the run, and let last be the last node of the run. For each such run that consists of at least one node that is neither embedded content nor inter-element whitespace, a paragraph exists in the original DOM from immediately before first to immediately after last. (Paragraphs can thus span across a, ins, del, and map elements.)

Conformance checkers may warn authors of cases where they have paragraphs that overlap each other (this can happen with object, video, audio, and canvas elements, and indirectly through elements in other namespaces that allow HTML to be further embedded therein, like svg or math).

段落はまた、p要素によって明示的に構成される。

段落を互いに分離するためにフレージングコンテンツ以外のコンテンツが別の方法でないだろう場合、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>
 <h1>My Cats</h1>
 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="http://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つの段落が存在する:

  1. "You can play with my cat simulator. object I'm quite proud of it."とある段落。ここでobjectobject要素である。
  2. "To see the cat simulator, use one of the following links:"とある段落。
  3. "Download simulator file"とある段落。
  4. "Use online simulator"とある段落。
  5. "Alternatively, upgrade to the Mellblom Browser."とある段落。

最初の段落は他の4つの段落と重複する。"cats.sim"リソースをサポートするユーザーエージェントは、最初の段落のみを表示するが、ユーザーエージェントは、あたかも2番目の段落と同じ段落であったかのように、1段落目の最初の文を表示するという紛らわしいフォールバックを表示し、かつあたかも1段落目の2番目にある文の冒頭であるかのように、最後の段落を表示するだろう。

この混乱を避けるために、明示的にp要素を使用することができる。たとえば:

<section>
 <h1>My Cats</h1>
 <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="http://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>

3.2.5 グローバル属性

The following attributes are common to and may be specified on all HTML elements (even those not defined in this specification):

These attributes are only defined by this specification as attributes for HTML elements. When this specification refers to elements having these attributes, elements from namespaces that are not defined as having these attributes must not be considered as being elements with these attributes.

For example, in the following XML fragment, the "bogus" element does not have a dir attribute as defined in this specification, despite having an attribute with the literal name "dir". Thus, the directionality of the inner-most span element is 'rtl', inherited from the div element indirectly through the "bogus" element.

<div xmlns="http://www.w3.org/1999/xhtml" dir="rtl">
 <bogus xmlns="http://example.net/ns" dir="ltr">
  <span xmlns="http://www.w3.org/1999/xhtml">
  </span>
 </bogus>
</div>

よりきめ細かいインターフェースを公開できるよう支援技術製品が別の方法でHTML要素と属性で可能にするために、支援技術製品への注釈の組が指定できる(ARIA roleおよびaria-*属性)。[ARIA]


以下のイベントハンドラコンテンツ属性は任意のHTML要素に指定されてもよい:

これら要素が同じ名前をもつWindowオブジェクトのイベントハンドラを公開するため、アスタリスクとともにマークされる属性は、body要素上で指定される場合、異なる意味を持つ。

これら属性がすべての要素に適用される一方で、属性はすべての要素で役立つわけでない。たとえば、メディア要素のみがユーザーエージェントによって発火されたvolumechangeイベントを受け取るだろう。


カスタムデータ属性(たとえばdata-foldernamedata-msgid)は、任意のHTML要素に指定されてよく、ページ特有のカスタムデータを保存可能である。


HTML文書で、HTML名前空間での要素は指定するxmlns属性を持つかもしれない。もし存在するなら値は正確に"http://www.w3.org/1999/xhtml"のみを持つ。これはXML文書に当てはまらない。

HTMLにおいて、xmlns属性は一切影響しない。これは基本的に魔除けである。これはXHTMLからの移行を少し簡単にするためだけに許可される。HTMLパーサによって解析される場合、XMLの名前空間宣言属性のように"http://www.w3.org/2000/xmlns/"名前空間ではなく、属性は名前空間なしに終わる。

XMLにおいて、xmlns属性は名前空間宣言メカニズムの一部であり、要素は実際に名前空間を指定されないxmlns属性を持つことはできない。


XML仕様はまた、XML文書における任意の要素上でXML名前空間の中のxml:space属性の使用を許可する。HTMLにおいてデフォルトの振る舞いは空白文字を維持するため、この属性はHTML要素で影響しない。[XML]

text/html構文でのHTML要素上のxml:space属性をシリアル化する方法は存在しない。

3.2.5.1 id属性

id属性はその要素の固有識別子(ID)を指定する。[DOM]

値は、要素のホームサブツリーですべてのIDに共通して固有でなければならず、少なくとも1つの文字を含まなければならない。値は一切の空白文字を含んではならない。

IDを取ることができる形式に制限は存在しない。具体的に、IDは数字のみまたは句読点のみで構成することができ、数字やアンダースコアで開始できる、などである。

要素の固有識別子は様々な目的に使用されうる。中でも注目すべきはフラグメント識別子を用いた文書の特定部分へのリンクする方法として、およびCSS由来の特定要素へのスタイル付けする方法としての目的である。

Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute.

3.2.5.2 title属性

title属性は、ツールチップに適するような要素に対する助言的な情報を表す。リンクでは、これはタイトルまたは対象リソースの記述であるかもしれない。画像では、画像のタイトルや説明であるかもしれない。段落では、テキストの脚注や解説であるかもしれない。引用では、ソースに関する詳細情報かもしれない。インタラクティブコンテンツでは、要素の用途に対する分類や指示などかもしれない、などである。値はテキストである。

title属性に依存することは、多くのユーザーエージェントがこの仕様で要求されるようなアクセス可能な方法で属性を公開しないため、現在推奨されない(たとえば、ツールチップを出現させるマウスなどのポインティングデバイスが必要になり、これはモダンな携帯端末やタブレットをもつ人のような、キーボードのみのユーザーとタッチのみのユーザーを締め出す)。

この属性が要素から省略される場合、title属性をもつ最も近い先祖HTML要素title属性がその要素にとっても適切であることを意味する。属性を設定することはこれを上書きし、明示的に先祖の助言的な情報がこの要素に関連しないことを示す。空文字列を属性に設定すると、要素は助言的な情報を持たないことを示す。

title属性値が"LF"(U+000A)文字を含む場合、コンテンツは複数行に分割される。各"LF"(U+000A)文字は改行を表す。

警告は、title属性内の改行の使用について報告される。

たとえば、実際に次の断片は改行とともに省略語の拡張を定義する。

<p>My logs show that there was some interest in <abbr title="Hypertext
Transport Protocol">HTTP</abbr> today.</p>

linkabbrinputのような一部の要素は、上記で説明されるセマンティックを越えてtitle属性に対する追加のセマンティックを定義する。

The advisory information of an element is the value that the following algorithm returns, with the algorithm being aborted once a value is returned. When the algorithm returns the empty string, then there is no advisory information.

  1. If the element is a link, style, dfn, or abbr element, then: if the element has a title attribute, return the value of that attribute, otherwise, return the empty string.

  2. Otherwise, if the element has a title attribute, then return its value.

  3. Otherwise, if the element has a parent element, then return the parent element's advisory information.

  4. Otherwise, return the empty string.

User agents should inform the user when elements have advisory information, otherwise the information would not be discoverable.


The title IDL attribute must reflect the title content attribute.

3.2.5.3 langおよびxml:lang属性

lang属性(名前空間なし)は、要素のコンテンツに対する基本言語およびテキストを含むあらゆる要素の属性に対して指定する。その値は妥当なBCP 47言語タグまたは空文字列でなければならない。属性に空文字列を設定することは基本言語が不明であることを指す。 [BCP47]

XML名前空間でのlang属性はXMLで定義されている。[XML]

これらの属性が要素から省略される場合、この要素の言語がもしあれば、その親要素の言語と同じである。

名前空間のないlang属性は任意のHTML要素で使用されてもよい。

XML名前空間でのlang属性は、XML文書でのHTML要素上で使用されてもよい。同様に、関連仕様が許可する(特に、MathMLおよびSVGがそれらの要素で指定されるXML名前空間lang属性を許可する)場合、他の名前空間で使用されてもよい。名前空間なしのlang属性とXML名前空間でのlang属性の両方が同じ要素に指定される場合、ASCII大文字・小文字不区別で比較したときに、これらは正確に同じ値を持たなければならない。

著者は、HTML文書におけるHTML要素XML名前空間内でlang属性を使用してはならない。XHTMLとの移行を容易にするために、著者は、接頭辞なしで名前空間のない属性、およびHTML文書内のHTML要素にリテラルでローカル名"xml:lang"を指定してもよいが、名前空間のないlang属性も指定されている場合、そのような属性のみが指定されなければならず、ASCII大文字・小文字不区別で比較するとき、両方の属性は同じ値を持たなければならない。

接頭辞なしで名前空間のない属性およびリテラルにローカル"xml:lang"は、言語処理に影響を与えない。


To determine the language of a node, user agents must look at the nearest ancestor element (including the element itself if the node is an element) that has a lang attribute in the XML namespace set or is an HTML element and has a lang in no namespace attribute set. That attribute specifies the language of the node (regardless of its value).

If both the lang attribute in no namespace and the lang attribute in the XML namespace are set on an element, user agents must use the lang attribute in the XML namespace, and the lang attribute in no namespace must be ignored for the purposes of determining the element's language.

If neither the node nor any of the node's ancestors, including the root element, have either attribute set, but there is a pragma-set default language set, then that is the language of the node. If there is no pragma-set default language set, then language information from a higher-level protocol (such as HTTP), if any, must be used as the final fallback language instead. In the absence of any such language information, and in cases where the higher-level protocol reports multiple languages, the language of the node is unknown, and the corresponding language tag is the empty string.

If the resulting value is not a recognized language tag, then it must be treated as an unknown language having the given language tag, distinct from all other languages. For the purposes of round-tripping or communicating with other services that expect language tags, user agents should pass unknown language tags through unmodified, and tagged as being BCP 47 language tags, so that subsequent services do not interpret the data as another type of language description. [BCP47]

Thus, for instance, an element with lang="xyzzy" would be matched by the selector :lang(xyzzy) (e.g. in CSS), but it would not be matched by :lang(abcde), even though both are equally invalid. Similarly, if a Web browser and screen reader working in unison communicated about the language of the element, the browser would tell the screen reader that the language was "xyzzy", even if it knew it was invalid, just in case the screen reader actually supported a language with that tag after all. Even if the screen reader supported both BCP 47 and another syntax for encoding language names, and in that other syntax the string "xyzzy" was a way to denote the Belarusian language, it would be incorrect for the screen reader to then start treating text as Belarusian, because "xyzzy" is not how Belarusian is described in BCP 47 codes (BCP 47 uses the code "be" for Belarusian).

If the resulting value is the empty string, then it must be interpreted as meaning that the language of the node is explicitly unknown.


User agents may use the element's language to determine proper processing or rendering (e.g. in the selection of appropriate fonts or pronunciations, for dictionary selection, or for the user interfaces of form controls such as date pickers).


The lang IDL attribute must reflect the lang content attribute in no namespace.

3.2.5.4 translate属性

translate属性は、ページがローカライズされる場合に要素の属性値およびそのTextノードの子の値を翻訳するかどうか、または変更せずにそのままにするかどうかを指定するために使用される列挙属性である。

属性のキーワードは、空文字列、yesおよびnoである。空文字列およびyesキーワードはyes状態に対応する。noキーワードはno状態に対応する。さらに、inherit状態という第3の状態が存在する。これは欠落した値のデフォルト(および妥当でない値のデフォルト)である。

(非HTML要素でさえも)各要素は、翻訳可能状態または無翻訳状態のいずれかの翻訳モードを持つ。HTML要素translate属性がyes状態である場合、その要素の翻訳モード翻訳可能な状態となる。そうでなければ、要素のtranslate属性がno状態である場合、その要素の翻訳モード無翻訳状態となる。そうでなければ、要素のtranslate属性はinherit状態となるか、または要素がHTML要素でないかのいずれかであり、したがってtranslate属性を持たない。いずれにせよ、もしあれば要素の翻訳モードが、その親要素と同じ状態となる、または要素がルート要素である場合、翻訳可能状態となる。

要素が翻訳可能状態にある場合、要素の翻訳可能属性とそのTextノードの子の値は、ページがローカライズされる際に翻訳される。翻訳可能属性として挙げられない要素の属性は、翻訳されるべきでない。

要素が無翻訳状態にある場合、(翻訳可能属性値を含む)要素の属性値とそのTextノードの子の値は、たとえば要素が人物名やコンピュータプログラム名を含むため、ページがローカライズされるときに、そのままで残される。

以下の属性は翻訳可能属性である:


The translate IDL attribute must, on getting, return true if the element's translation mode is translate-enabled, and false otherwise. On setting, it must set the content attribute's value to "yes" if the new value is true, and set the content attribute's value to "no" otherwise.

次の例で、サンプルのキーボード入力とサンプルプログラム出力を除き、ページがローカライズされるときに文書内のすべてが翻訳される:

<!DOCTYPE HTML>
<html> <!-- default on the root 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>
3.2.5.5 xml:base属性(XMLのみ)

xml:base属性はXML Baseを定義する。[XMLBASE]

xml:base属性をXML文書HTML要素で使用してもよい。著者はHTML文書でのHTML要素においてxml:base属性を使用してはならない。

3.2.5.6 dir属性

dir属性は、要素のテキスト方向を指定する。属性は、次のキーワードと状態を持つ列挙属性である:

ltrキーワード。ltr状態に対応する。

要素のコンテンツは、明示的に孤立した左から右へのテキストであることを示す。

rtlキーワード。rtl状態に対応する。

要素のコンテンツは、明示的に孤立した右から左へのテキストであることを示す。

autoキーワード。auto状態に対応する。

要素のコンテンツは明示的に孤立したテキストであることを示すが、方向は、プログラムでの要素のコンテンツを用いて(後述)決定される。

この状態で用いられるヒューリスティックは非常に粗雑である(双方向アルゴリズムにおける段落レベルの決定に類似した方法で、強い指向性をもつ最初の文字のみを見る)。著者は、テキストの方向が全く未知である場合、最後の手段としてのみこの値を使用するよう要請し、同様のサーバー側のヒューリスティックを適用できる。[BIDI]

textareaおよびpre要素に対して、ヒューリスティックは段落レベルごとに適用される。

属性は妥当でない値のデフォルトおよび欠落した値のデフォルトを持たない。


HTML要素だけでなく、任意の要素で)要素の方向は、'ltr'または'rtl'のいずれかであり、次のリストから最初の適切な一連のステップごとに決定される:

要素のdir属性がltr状態の場合
要素がルート要素であり、かつdir属性が状態を定義されない場合(すなわち、存在しないか妥当でない値を持つ)
要素がtype属性がTelephone状態であるinput要素であり、かつdir属性が状態を定義されない場合(すなわち、存在しないか妥当でない値を持つ)

要素の方向は'ltr'となる。

要素のdir属性がrtl状態の場合

要素の方向は'rtl'となる。

type属性がTextSearchTelephoneURLまたはE-mail状態であるinput要素で、かつdir属性がauto状態である要素の場合
textarea要素かつdir属性がauto状態である要素の場合

要素のが双方向性文字の文字型ALまたはRを含み、かつ要素のの前に双方向性文字の文字型Lが存在しない場合、要素の方向は'rtl'となる。[BIDI]

そうでなければ、要素のが空文字列でない場合、または要素がルート要素である場合、要素の方向は'ltr'である。

そうでなければ、要素の方向は、その要素の親要素の方向と同じである。

要素のdir属性がauto状態の場合
要素がbdi要素であり、かつdir属性が状態を定義されない場合(すなわち、存在しないか妥当でない値を持つ)

ツリー順で次の基準に一致する最初の文字を見つける:

そのような文字が見つけられ、その文字が双方向性文字型ALまたはRの場合、要素の方向は'rtl'である。

そのような文字が見つけられ、その文字が双方向性文字型Lである場合、要素の方向は'ltr'である。

そうでなければ、要素が空でかつルート要素でない場合、要素の方向は、その要素の親要素の方向と同じである。

そうでなければ、要素の方向は'ltr'である。

要素が親要素を持ち、かつdir属性が状態を定義されない場合(すなわち、存在しないか妥当でない値を持つ)

要素の方向は、その要素の親要素の方向と同じである。

dir属性はHTML要素に対してのみ定義されるので、他の名前空間からの要素では存在し得ない。したがって、他の名前空間由来の要素は常に親要素からのみ方向を継承する。つまり、存在しない場合、デフォルトは'ltr'となる。

This attribute has rendering requirements involving the bidirectional algorithm.


属性の文字列が何らかの方法でレンダリングに含まれる際に使用される、HTML要素属性の方向は、下記リストからステップの最初の適切なセットに従って決定される:

属性が方向可能属性かつ要素のdir属性がauto状態である場合

双方向性文字型L、AL、またはRのある属性値の最初の文字を(論理的な順序で)見つける。[BIDI]

そのような文字が見つけられ、その文字が双方向性文字型ALまたはRの場合、属性の方向は'rtl'である。

そうでなければ、属性の方向は'ltr'である。

そうでなければ
属性の方向要素の方向と同じである。

以下の属性は方向可能属性である:


document . dir [ = value ]

もしあれば、html要素dir属性値を返す。

html要素dir属性値を置換するために、"ltr"、"rtl"、"auto"が設定可能である。

html要素が存在しない場合、空文字列を返し新しい値を無視する。

The dir IDL attribute on an element must reflect the dir content attribute of that element, limited to only known values.

The dir IDL attribute on Document objects must reflect the dir content attribute of the html element, if any, limited to only known values. If there is no such element, then the attribute must return the empty string and do nothing on setting.

著者は、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要素へのデフォルトの配置スタイルを与えられる、すなわちテキストを段落の開始端へ揃えることで、結果として生じるレンダリングは以下のようになる:

各段落は、独立したブロックとして表示され、ユーザー名(この例では'Student'と'Teacher')を右に流すとともに、コロンの左側に最初のテキストをもつ右揃えとなる、第二段落と最後段落を除いて、段落は左揃えとなる。

前述したように、auto値は万能薬ではない。"正しく?"アラビア語テキストの左側になることが起きるアラビア文字で始まるので、この例の最後の段落は、右から左へのテキストであると誤って解釈される。

3.2.5.7 class属性

それぞれのHTML要素は、特定のclass属性を持ってもよい。

属性が指定される場合、属性は、要素が属する様々なクラスを表すスペース区切りトークンの組の値を持たなければならない。

The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)

クラスを要素に割り当てることは、クラスのCSSセレクタでのマッチング、DOMでのgetElementsByClassName()メソッド、および他のそのような機能に影響を与える。

著者が使用できるclass属性のトークンに追加の制限は存在しないが、著者は、コンテンツの期待するプレゼンテーションを記述する値よりもむしろ、コンテンツの性質を記述する値を使用するよう推奨される。


The className and classList IDL attributes, defined in the DOM specification, reflect the class content attribute. [DOM]

3.2.5.8 style属性

すべてのHTML要素は、指定のstyleコンテンツ属性をもってもよい。これは、CSSスタイル属性構文仕様によって定義されるようなCSSスタイル属性である。[CSSATTR]

In user agents that support CSS, the attribute's value must be parsed when the attribute is added or has its value changed, according to the rules given for CSS styling attributes. [CSSATTR]

要素のどこでもstyle属性を使用する文書は、属性が削除された場合、それでも理解可能でありかつ使用可能でなければならない。

特に、コンテンツを非表示および表示するstyle属性の使用、または他に文書に含まれない意味の伝達は不適合である。(コンテンツを非表示および表示するには、hidden属性を用いる。)


element . style

要素のstyle属性へCSSStyleDeclarationオブジェクトを返す。

The style IDL attribute is defined in the CSS Object Model (CSSOM) specification. [CSSOM]

次の例で、色を参照する単語は、単語に視覚メディアで関連色を表すよう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>
3.2.5.9 data-*属性をもつカスタム非視覚データの埋め込み

カスタムデータ属性は、文字列"data-"で始まる名前空間のない名前をもつ属性であり、ハイフンの後に少なくとも1文字を持ち、XML互換であり、ASCII大文字を含まない。

ASCII大文字での制約はそのような文書に影響しないので、HTML文書においてHTML要素のすべての属性名はASCII小文字を自動的に取得する。

カスタムデータ属性は、ページまたはアプリケーションへ私的なカスタムデータを記憶することを意図する。これ以上適切な属性や要素は存在しない。

この属性は、属性を使用するサイトから独立したソフトウェアによる使用を意図しない。

たとえば、音楽に関するサイトは、各トラックの長さを含むカスタムデータ属性でアルバム内のトラックを表すリスト項目に注釈を付けるかもしれない。その後この情報は、ユーザーがトラックの長さでリストをソートできるようにするため、または一定長さのトラックのリストをフィルタリングするために、サイト自体が使用するかもしれない。

<ol>
 <li data-length="2m11s">Beyond The Sea</li>
 ...
</ol>

しかし、このデータを見ることで一定の長さの曲を検索するために、ユーザーがその音楽サイトに関連付けられていない一般的なソフトウェアを使用することは、不適当だろう。

これは、この属性がサイトの独自スクリプトによる使用を意図し、公開で利用可能なメタデータのための一般的な拡張メカニズムでないためである。

HTML要素は任意の値とともに、任意の数の指定されたカスタムデータ属性を持ってもよい。


element . dataset

要素のdata-*属性に対してDOMStringMapオブジェクトを返す。

ハイフン付き名前はキャメルケースになる。たとえば、data-foo-bar=""element.dataset.fooBarになる。

The dataset IDL attribute provides convenient accessors for all the data-* attributes on an element. On getting, the dataset IDL attribute must return a DOMStringMap object, associated with the following algorithms, which expose these attributes on their element:

The algorithm for getting the list of name-value pairs
  1. Let list be an empty list of name-value pairs.
  2. For each content attribute on the element whose first five characters are the string "data-" and whose remaining characters (if any) do not include any uppercase ASCII letters, in the order that those attributes are listed in the element's attribute list, add a name-value pair to list whose name is the attribute's name with the first five characters removed and whose value is the attribute's value.
  3. For each name in list, for each "-" (U+002D) character in the name that is followed by a lowercase ASCII letter, remove the "-" (U+002D) character and replace the character that followed it by the same character converted to ASCII uppercase.
  4. Return list.
The algorithm for setting names to certain values
  1. Let name be the name passed to the algorithm.
  2. Let value be the value passed to the algorithm.
  3. If name contains a "-" (U+002D) character followed by a lowercase ASCII letter, throw a SyntaxError exception and abort these steps.
  4. For each uppercase ASCII letter in name, insert a "-" (U+002D) character before the character and replace the character with the same character converted to ASCII lowercase.
  5. Insert the string data- at the front of name.
  6. Set the value of the attribute with the name name, to the value value, replacing any previous value if the attribute already existed. If setAttribute() would have thrown an exception when setting an attribute with the name name, then this must throw the same exception.
The algorithm for deleting names
  1. Let name be the name passed to the algorithm.
  2. For each uppercase ASCII letter in name, insert a "-" (U+002D) character before the character and replace the character with the same character converted to ASCII lowercase.
  3. Insert the string data- at the front of name.
  4. Remove the attribute with the name name, if such an attribute exists. Do nothing otherwise.

This algorithm will only get invoked by the WebIDL specification for names that are given by the earlier algorithm for getting the list of name-value pairs. [WEBIDL]

The same object must be returned each time.

たとえばゲームの一部として、ウェブページが宇宙船を表す要素を望んだ場合、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においてハイフン付き属性名は、キャメルケースになることに注目すること。

属性が無視され、かつ関連するすべてのCSSが破棄された場合、ページがそれでも使用可能であるよう、著者はこのような拡張を慎重に設計すべきである。

User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.

JavaScriptライブラリが使用されるページの一部であると考えられるとして、JavaScriptライブラリはカスタムデータ属性を使用してもよい。多くの著者によって再利用されるライブラリの著者は、衝突のリスクを軽減するために、属性名にライブラリの名前を含むよう推奨される。理にかなっている場合には、著者が無意識のうちに同じ名前を選んだライブラリが同じページ上で使用できるように、そしてバージョンの相互の互換性がない場合でも、特定ライブラリの複数のバージョンが同じページ上で使用できるように、ライブラリ著者はまた、正確な名前がカスタマイズ可能な属性名に使用されることを推奨される。

たとえば、"DoQuery"と呼ばれるライブラリはdata-doquery-rangeのような属性名を使用するかもしれないし、"jJo"と呼ばれるライブラリはdata-jjo-rangeのような属性名を使用するかもしれない。jJoライブラリはまた、APIに接頭辞の使用の設定を供給するかもしれない(たとえばJ.setDataPrefix('j2')が、data-j2-rangeのような名前を持つようにする)。

3.2.6 双方向アルゴリズムに関連する要求

3.2.6.1 双方向アルゴリズムの書式設定文字に対するオーサリング適合性要求

HTML要素のコンテンツTextノードをもつHTML要素におけるテキストコンテンツ、および自由形式のテキストを許可するHTML要素の属性のテキストは、U+202AからU+202Eまでの範囲(双方向アルゴリズムの書式設定文字)の文字を含んでもよい。ただし、これらの文字の使用は、これらの文字によって生成される任意の埋め込みまたは上書きが、異なる親要素で開始または終了できないよう、かつすべてのそのような埋めこみと上書きが明示的にU+202C POP DIRECTIONAL FORMATTING文字で終わるように制限される。これは、双方向アルゴリズム上の予期しない効果を持つ方法で再利用されるテキストの発生を減少させるのに役立つ。[BIDI]

上記の制限は、文書の特定の部分が双方向アルゴリズムの書式設定文字の範囲を形成することの指定によって定義され、その後そのような範囲で要求を課している。

以下のアルゴリズムをHTML要素elementに適用する結果もたらされる文字列は、双方向アルゴリズムの書式設定文字の範囲である:

  1. outputを文字列の空リストにする。

  2. stringを空文字列にする。

  3. もしあれば、nodeelementの最初の子ノードにする。そうでなければnullにする。

  4. Loop: nodeがnullの場合、endとラベル付けされるステップまで飛ぶ。

  5. 次のリストから最初に一致するステップにしたがってnodeを実行する:

    nodeTextノードである場合

    nodeのテキストデータにstringを加える。

    nodebr要素である場合
    nodeフローコンテンツであるがフレージングコンテンツでもないHTML要素の場合

    stringが空文字列でない場合、stringoutputに押しつけ、stringを空文字列にする。

    そうでなければ
    何もしない。
  6. もしあれば、nodenodeの次の兄弟にする。そうでなければnullにする。

  7. loopにラベル付けされたステップにジャンプする。

  8. End: stringが空文字列でない場合、stringoutputに押しつける。

  9. 双方向アルゴリズム書式設定文字としてoutputを返す。

HTML要素の名前空間のない属性の値は双方向アルゴリズムの書式設定文字の範囲である。

上述したように、双方向アルゴリズムの書式設定文字の範囲であるすべての文字列は、以下のABNFでstring生成物と対等でなければならず、Unicodeである文字セットとなる。[ABNF]

string        = *( plaintext ( embedding / override / isolation ) ) plaintext
embedding     = ( lre / rle ) string pdf
override      = ( lro / rlo ) string pdf
isolation     = ( lri / rli / fsi ) string pdi
lre           = %x202A ; U+202A LEFT-TO-RIGHT EMBEDDING
rle           = %x202B ; U+202B RIGHT-TO-LEFT EMBEDDING
lro           = %x202D ; U+202D LEFT-TO-RIGHT OVERRIDE
rlo           = %x202E ; U+202E RIGHT-TO-LEFT OVERRIDE
pdf           = %x202C ; U+202C POP DIRECTIONAL FORMATTING
lri           = %x2066 ; U+2066 LEFT-TO-RIGHT ISOLATE
rli           = %x2067 ; U+2067 RIGHT-TO-LEFT ISOLATE
fsi           = %x2068 ; U+2068 FIRST STRONG ISOLATE
pdi           = %x2069 ; U+2069 POP DIRECTIONAL ISOLATE
plaintext     = *( %x0000-2029 / %x202F-2065 / %x206A-10FFFF )
                ; any string with no bidirectional-algorithm formatting characters

U+2069 POP DIRECTIONAL ISOLATE文字が暗黙的にも開いた埋め込みおよび上書きを終了する一方で、この暗黙の範囲の閉鎖に依存しているテキストは、この仕様に準拠しない。埋め込み、上書き、および孤立のすべての文字列を明示的に、この項の要件に適合するように終端する必要がある。

著者は、手動で双方向アルゴリズムの書式設定文字を維持するよりもむしろ、dir属性、bdo要素、およびbdi要素を使用するよう推奨される。双方向アルゴリズムの書式設定文字は、CSSと互いに不完全に影響しあう。

3.2.6.2 User agent conformance criteria

User agents must implement the Unicode bidirectional algorithm to determine the proper ordering of characters when rendering documents and parts of documents. [BIDI]

The mapping of HTML to the Unicode bidirectional algorithm must be done in one of three ways. Either the user agent must implement CSS, including in particular the CSS 'unicode-bidi', 'direction', and 'content' properties, and must have, in its user agent style sheet, the rules using those properties given in this specification's rendering section, or, alternatively, the user agent must act as if it implemented just the aforementioned properties and had a user agent style sheet that included all the aforementioned rules, but without letting style sheets specified in documents override them, or, alternatively, the user agent must implement another styling language with equivalent semantics. [CSSWM] [CSSGC]

The following elements and attributes have requirements defined by the rendering section that, due to the requirements in this section, are requirements on all user agents (not just those that support the suggested default rendering):

3.2.7 WAI-ARIA

著者は、この節で提供されるものを超えたHTMLにおけるARIAの使用に関するガイダンスのために、以下のドキュメントの利用を推奨する:

著者は、以下に示す強いネイティヴセマンティックと衝突する場合を除いて、ARIA仕様で説明される要求に従い、HTML要素のARIA roleおよびaria-*属性を使用してもよい。 この例外は、著者が文書の実際の状態を表すことのない無意味な状態を支援技術製品に報告させることから防ぐことを意図する。[ARIA]

User agents are required to implement ARIA semantics on all HTML elements, as defined in the ARIA specifications. The default implicit ARIA semantics defined below must be recognized by implementations for the purposes of ARIA processing. [ARIAIMPL]

The ARIA attributes defined in the ARIA specifications, and the strong native semantics and default implicit ARIA semantics defined below, do not have any effect on CSS pseudo-class matching, user interface modalities that don't use assistive technologies, or the default actions of user interaction events as described in this specification.

3.2.7.1 ARIAロール属性

すべてのHTML要素は、ARIA roleが指定された属性を持ってもよい。これは、[ARIA] 5.4 ロールの定義で定義されたARIAロール属性である。

属性が指定される場合、属性は、要素が属する様々なWAI-ARIAのロールを表す、スペース区切りトークンの集合である値を持たなければならない。

The WAI-ARIA role that an HTML element has assigned to it is the first non-abstract role found in the list of values generated when the role attribute is split on spaces.

3.2.7.2 ステートおよびプロパティー属性

すべてのHTML要素は、ARIAステートおよびプロパティー属性を指定させてもよい。この属性は、[ARIA]6.6節 ステートおよびプロパティーの定義(すべてのaria-*属性)で定義される。

A subset of the ARIA State and Property attributes are defined as "Global States and Properties" in Section 6.4. Global States and Properties of the [ARIA] Specification.

指定された場合、この属性は、[ARIA]10.2節 WAI-ARIAの値型の言語へのマッピングに従ってHTML 5のマッピングを使用する適切なHTML値型に変換される、ステートまたはプロパティーの定義の"Value"フィールドで、ARIA値型となる値を持たなければならない。

ARIAステートおよびプロパティー属性は任意の要素で使用できる。しかし、これらは常に意味のあるものではなく、意味のない場合、ユーザーエージェントはDOMでそれらを含むこととは別に任意の処理を実行しないかもしれない。ステートおよびプロパティー属性は、[ARIA][ARIAIMPL]同様に、強いネイティヴセマンティックおよび暗黙のARIAセマンティックの節の要求にしたがって処理される。

3.2.7.3 強いネイティヴセマンティック

次の表は、強いネイティヴセマンティックかつHTML要素に適用する対応するデフォルトの暗黙のARIAセマンティックを定義する。1列目のセルでそれぞれの言語機能(要素または属性)は同じ行の2列目のセルで与えられるARIAセマンティック(ロール、ステート、およびプロパティー)を意味する。When multiple rows apply to an element, the role from the last row to define a role must be applied, and the states and properties from all the rows must be combined.

要素のセマンティックが"presentation" role値を用いて除去されうることを2列目が示す場合、文書は、(もしあれば)2列目にその要素に対して記載されるされるように、対応するロール値またはrole値"presentation"以外の以下の表で要素とともに一切のrole値を使用してはならない。

多くの場合、ARIAroleおよび/またはaria-*属性の設定は、デフォルトの暗黙のARIAセマンティックが不要であり、かつこれらのプロパティーが既にブラウザで設定されるように推奨されないものと一致する。

言語の機能 強いネイティヴセマンティックかつデフォルトの暗黙のARIAセマンティック
hyperlinkを作るarea要素 linkロール
base要素 ロールなし
datalist要素 "false"に設定するaria-multiselectableプロパティーをもつlistboxロール
fieldset要素 groupロール(セマンティックはpresentationロールの使用によって除去されてもよい)
articleまたはsection要素の子孫でないfooter要素 contentinfoロール(セマンティックはpresentationロールの使用によって除去されてもよい)
head要素 ロールなし
articleまたはsection要素の子孫でないheader要素 bannerロール(セマンティックはpresentationロールの使用によって除去されてもよい)
hr要素 separatorロール(セマンティックはpresentationロールの使用によって除去されてもよい)
html要素 ロールなし
alt属性値が空であるimg要素 presentationロール
Checkbox状態のtype属性をもつinput要素 要素のindeterminateIDL属性がtrueの場合、aria-checkedステートを"mixed"に設定し、または要素のcheckednessがtrueの場合"true"に、そうでなければ"false"に設定する
Color状態のtype属性をもつinput要素 ロールなし
Date状態のtype属性をもつinput要素 ロールなし。要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつ
提案ソース要素でないE-mail状態のtype属性をもつinput要素 要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつtextboxロール
File Upload状態のtype属性をもつinput要素 ロールなし
Hidden状態のtype属性をもつinput要素 ロールなし
Number状態のtype属性をもつinput要素 要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつspinbuttonロール、aria-valuemaxプロパティーを要素のmaximumに設定し、aria-valueminプロパティーを要素のminimumに設定し、かつ浮動小数値の解析規則を適用した結果得られる要素のvalueが数の場合、その数を設定したaria-valuenowプロパティーをもつ
Password状態のtype属性をもつinput要素 要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつtextboxロール
Radio Button状態のtype属性をもつinput要素 要素のcheckednessがtrueの場合aria-checkedステートを"true"に設定し、そうでなければ"false"に設定する
Range状態のtype属性をもつinput要素 sliderロール、aria-valuemaxプロパティーを要素のmaximumに設定し、aria-valueminプロパティーを要素のminimum設定し、かつaria-valuenowプロパティーを浮動小数値を解析規則に適用した結果が数の場合、その結果をに設定する。そうでなければデフォルト値となる
Reset Button状態のtype属性をもつinput要素 buttonロール
提案ソース要素でないSearch状態のtype属性をもつinput要素 要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつtextboxロール
Submit Button状態のtype属性をもつinput要素 buttonロール
提案ソース要素でないTelephone状態のtype属性をもつinput要素 要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつtextboxロール
提案ソース要素でないText状態のtype属性をもつinput要素 要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつtextboxロール
提案ソース要素でないTextSearchTelephoneURL、またはE-mail状態のtype属性をもつinput要素 list属性と同じ値を設定するaria-ownsプロパティーをもつcomboboxロール、かつ要素がreadonly属性を持つ場合、aria-readonlyプロパティーを"true"に設定する
Time状態のtype属性をもつinput要素 ロールなし。要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつ
提案ソース要素でないURL状態のtype属性をもつinput要素 要素がreadonly属性を持つ場合、"true"に設定するaria-readonlyプロパティーをもつtextboxロール
keygen要素 ロールなし
label要素 ロールなし
hyperlinkを作るlink要素 linkロール
main要素 mainロール(セマンティックはpresentationロールの使用によって除去されてもよい)
meta要素 ロールなし
meter要素 ロールなし
nav要素 navigationロール(セマンティックはpresentationロールの使用によって除去されてもよい)
noscript要素 ロールなし
optgroup要素 ロールなし
オプションリストで存在するまたはdatalist要素で提案を表すoption要素 selectednessがtrueの場合、aria-selectedプロパティーを"true"に設定し、そうでなければ"false"にするoptionロール
param要素 ロールなし
progress要素 プログレスバーが決定される場合、aria-valuemaxプロパティーをプログレスバーの最大値に設定し、aria-valueminプロパティーをゼロに設定し、aria-valuenowプロパティーをプログレスバーの現在地に設定するprogressbarロール
script要素 ロールなし
multiple属性をもつselect要素 "true"に設定するaria-multiselectableプロパティーをもつlistboxロール
multiple属性をもたないselect要素 "false"に設定するaria-multiselectableプロパティーをもつlistboxロール
source要素 ロールなし
style要素 ロールなし
template要素 ロールなし
textarea要素 "true"に設定するaria-multilineプロパティーをもつtextboxロール、かつ要素がreadonly属性を持つ場合、aria-readonlyプロパティーを"true"に設定する
title要素 ロールなし
disabledである要素 aria-disabledステートを"true"に設定する
inertである要素 aria-disabledステートを"true"に設定する
制約の検証のための候補であるが、その制約が満たさない要素 aria-invalidステートを"true"に設定する
3.2.7.4 暗黙のARIAセマンティック

一部のHTML要素は上書きされうるネイティヴセマンティックを持つ。次の表は、それら要素に適用する制限と一緒に、これらの要素とそのデフォルトの暗黙のARIAセマンティックを示す。1列目のセルでそれぞれの言語機能(要素または属性)は、上書きされる場合を除き、同じ行の2列目のセルで与えられるARIAセマンティック(ロール、ステート、またはプロパティー)を意味するが、このセマンティックはその行の3列目のセルで示される制約の下で上書きされてもよい。

言語の機能 デフォルトの暗黙ARIAセマンティック 制限
hyperlinkを作るa要素 linkロール 指定される場合、ロールは、linkbuttoncheckboxmenuitemmenuitemcheckboxmenuitemradiooptionradiotabまたはtreeitemのいずれかでなければならない
address要素 ロールなし 指定される場合、ロールはcontentinfoでなければならない
article要素 articleロール 指定される場合、ロールは、articledocumentapplication、またはmainのいずれかでなければならない
aside要素 complementaryロール 指定される場合、ロールは、notecomplementarysearchまたはpresentationのいずれかでなければならない
audio要素 ロールなし 指定される場合、ロールはapplicationでなければならない
body要素 documentロール 指定される場合、ロールは、document、またはapplicationのいずれかでなければならない
button要素 buttonロール 指定される場合、ロールは、buttonlinkmenuitemmenuitemcheckboxmenuitemradioradioのいずれかでなければならない
embed要素 ロールなし 指定される場合、ロールはapplicationdocument、またはimgのいずれかでなければならない
h1要素 ロールなし 指定される場合、ロールは、headingtabまたはpresentationのいずれかでなければならない
h2要素 ロールなし 指定される場合、ロールは、headingtabまたはpresentationのいずれかでなければならない
h3要素 ロールなし 指定される場合、ロールは、headingtabまたはpresentationのいずれかでなければならない
h4要素 ロールなし 指定される場合、ロールは、headingtabまたはpresentationのいずれかでなければならない
h5要素 ロールなし 指定される場合、ロールは、headingtabまたはpresentationのいずれかでなければならない
h6要素 ロールなし 指定される場合、ロールは、headingtabまたはpresentationのいずれかでなければならない
iframe要素 ロールなし 指定される場合、ロールはapplicationdocumentimgまたはpresentationのいずれかでなければならない
alt属性値が存在しないimg要素 imgロール 制限なし
alt属性値が存在するが空でないimg要素 imgロール 制限なし
Button状態のtype属性をもつinput要素 buttonロール 指定される場合、ロールは、buttonlinkmenuitemmenuitemcheckboxmenuitemradioradioのいずれかでなければならない
Checkbox状態のtype属性をもつinput要素 checkboxロール 指定される場合、ロールは、checkbox、またはmenuitemcheckboxのいずれかでなければならない
Image Button状態のtype属性をもつinput要素 buttonロール 指定される場合、ロールは、buttonlinkmenuitemmenuitemcheckboxmenuitemradioradioのいずれかでなければならない
Radio Button状態のtype属性をもつinput要素 radioロール 指定される場合、ロールは、radio、またはmenuitemradioのいずれかでなければならない
required属性をもつinputselectまたはtextarea要素 aria-requiredステートを"true"に設定する 指定される場合、aria-requiredステートを"true"に設定する
required属性をもたないinputselectまたはtextarea要素 aria-requiredステートを"false"に設定する 指定される場合、aria-requiredステートを"true"または"false"に設定する
親がolまたはul要素であるli要素 listitemロール 指定される場合、ロールは、listitemmenuitemmenuitemcheckboxmenuitemradiooptionradiotabtreeitemまたはpresentationのいずれかでなければならない
toolbar状態のtype属性をもつmenu要素 toolbarロール 指定される場合、ロールはdirectorylistlistboxmenumenubartablisttoolbartreeまたはpresentationのいずれかでなければならない
object要素 ロールなし 指定される場合、ロールはapplicationdocumentimgまたはpresentationのいずれかでなければならない
ol要素 listロール 指定される場合、ロールはdirectorylistlistboxmenumenubarradiogrouptablisttoolbartreeまたはpresentationのいずれかでなければならない
output要素 statusロール 制限なし
section要素 regionロール

注: section要素がアクセシブルな名前を持つ場合、スクリーンリーダーなどのユーザーエージェントのみが存在することを伝え、かつsection要素に対するナビゲーションを提供することを強く推奨する。

指定される場合、ロールはalertalertdialogapplicationcontentinfodialogdocumentlogmainmarqueeregionsearchstatusまたはpresentationのいずれかでなければならない
ul要素 listロール 指定される場合、ロールはdirectorygrouplistlistboxmenumenubarradiogrouptablisttoolbartreeまたはpresentationのいずれかでなければならない
video要素 ロールなし 指定される場合、ロールはapplicationでなければならない
hidden属性をもつ要素 aria-hiddenステートを"true"に設定する 指定される場合、aria-hiddenステートを"true"または"false"に設定する
hidden属性をもたない要素 aria-hiddenステートを"false"に設定する 指定される場合、aria-hiddenステートを"true"または"false"に設定する

強いネイティヴセマンティックとして使用される場合、項目"ロールなし"は、使用されうるロールを持たず、ユーザーエージェントがデフォルトでARIAロールに対応するものがないことを意味する。(ただし、アクセシビリティー層に対応するものを持つかもしれない。)デフォルトの暗黙のARIAセマンティックとして使用される場合、ユーザーエージェントがARIAロールに対応するデフォルトを持たないことを意味する。(ただし、アクセシビリティー層に独自のマッピングをおそらく持つだろう。)

The WAI-ARIA specification neither requires or forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI- ARIA markup. Even mainstream user agents might choose to expose metadata or navigational features directly or via user-installed extensions; for example, exposing required form fields or landmark navigation. User agents are encouraged to maximize their usefulness to users, including users without disabilities.

Conformance checkers are encouraged to phrase errors such that authors are encouraged to use more appropriate elements rather than remove accessibility annotations. For example, if an a element is marked as having the button role, a conformance checker could say "Use a more appropriate element to represent a button, for example a button element or an input element" rather than "The button role cannot be used with a elements".

アクセシビリティーツールにより便利な方法でユーザーにコンテンツをレンダリングさせるためにこれらの機能を使用できる。たとえば、実際には画像であるASCIIアートは、テキストのように見え、かつ適切な注釈が存在しない場合、非常に苦痛な多数の中断のある読み上げとして、スクリーンリーダーによって結局レンダリングされてしまっているだろう。この節で説明される機能を使用すると、支援技術にASCIIアートを飛ばさせ、代わりにキャプションのみを読むことができる:

<figure role="img" aria-labelledby="fish-caption"> 
 <pre>
 o           .'`/
     '      /  (
   O    .-'` ` `'-._      .')
      _/ (o)        '.  .' /
      )       )))     ><  <
      `\  |_\      _.'  '. \
        '-._  _ .-'       '.)
    jgs     `\__\
 </pre>
 <figcaption id="fish-caption">
  Joan G. Stark, "<cite>fish</cite>".
  October 1997. ASCII on electrons. 28×8.
 </figcaption> 
</figure> 
   
3.2.7.5 許可されるARIAロール、ステートおよびプロパティー

この節は非規範的である。

以下の表は、HTMLで使用するために認められるARIAロール、ステートおよびプロパティーに参考情報を提供する。すべてのARIAロール、ステートおよびプロパティーは[ARIA]仕様で規範的に定義されている。表におけるARIAロール、ステートおよびプロパティーへのリンクは、規範[ARIA]定義を参照する。

ARIAロール、ステートおよびプロパティー
ロール 説明 必須プロパティー サポートされるプロパティー
任意 ARIAグローバルステートおよびプロパティーは、任意のHTML要素で使用できる。 なし
alert 重要、かつ通常は時間依存な情報を伴うメッセージ。関連するalertdialogstatusを参照のこと。 なし
alertdialog 初期のフォーカスがダイアログ内の要素に移動する場合、警告メッセージを含むダイアログの種類。関連するalertdialogを参照のこと。 なし
application ウェブ文書とは対照的に、ウェブアプリケーションとして宣言される領域。 なし
article 文書、ページ、またはサイトの独立した部分を形成する構成物から成るページのセクション。 なし
banner ページ固有のコンテンツよりもむしろ、主にサイト中心のコンテンツが含まれる領域。 なし
button クリックされるまたは押される際に、ユーザートリガーアクションを可能にする入力。関連するlinkを参照のこと。 なし
checkbox true、false、またはmixedの3つの取りうる値を持つチェック可能な入力
columnheader 列のヘッダー情報を含むセル。 なし
combobox 選択のプレゼンテーション、ユーザーがオプションを選択する前に打ち込めるか、リストで新しい項目として任意のテキストを入力するために打ち込める場合、テキストボックスに通常似ている。関連するlistboxを参照のこと。
complementary 主コンテンツから分離される際、DOM階層における同等のレベルで主コンテンツに相補的であるように設計されているが、意味のある文書のサポートするセクション。 なし
contentinfo 親文書に関する情報を含む大きな認知できる領域。 なし
definition 用語または概念の定義。 なし
dialog ダイアログボックスは、情報を入力する、または応答を要求するようユーザーに促すために、アプリケーションの現在の処理を中断するように設計されるアプリケーションウィンドウである。関連するalertdialogを参照のこと。 なし
directory 静的なコンテンツの表などの、グループのメンバーへの参照リスト。 なし
document ウェブアプリケーションとは対照的に、文書コンテンツとして宣言される関連情報を含む領域。 なし
form 全体として、フォームを作成するために組み合わせる、項目およびオブジェクトのコレクションを含む目印領域。関連するsearchを参照のこと。 なし
grid 表のように、行と列に配列された表形式のデータセルを含むインタラクティブなコントロールであるグリッド。 なし
gridcell グリッドまたはツリーグリッドにおけるセル。 なし
group 支援技術によってページ概要または目次に含まれることを意図されないユーザーインターフェースオブジェクトの集合。 なし
heading ページのセクションに対する見出し。 なし
img 画像を形成する要素のコレクションに対するコンテナ。 なし
活性化された場合、ユーザーエージェントにそのリソースに移動させる、内部または外部のリソースへのインタラクティブな参照。関連するbuttonを参照のこと。 なし
list 非対話型リスト項目のグループ。関連するlistboxを参照のこと。 なし
listbox ユーザーが選択肢のリストから1つ以上の項目を選択できるウィジェット。関連するcomboboxlistを参照のこと。 なし
listitem listまたはdirectoryにおける1つの項目。 なし
log 新しい情報が意味のある順序で追加され、かつ古い情報が消滅する場合のlive regionの種類。関連するmarqueeを参照のこと。 なし
main 文書の主コンテンツ。 なし
marquee 必須でない情報が頻繁に変更されるlive regionの種類。関連するlogを参照のこと。 なし
math 数式を表すコンテンツ。 なし
menu ユーザーに選択肢のリストを提供するウィジェットの種類。 なし
menubar 一般に表示されたままでかつ水平に提示される、メニューの表示。 なし
menuitem menumenubarに含まれる選択肢のグループ内のオプション。 なし
menuitemcheckbox true、false、mixedの、3つの取りうる値を持つチェック可能メニュー項目。
menuitemradio 一度に1つのみがチェックできる、menuitemradioロールのグループにおいてチェック可能なメニュー項目。
navigation 文書または関連する文書をナビゲートするためのナビゲーション要素(通常はリンク)のコレクション 。 なし
note リソースの主コンテンツに挿入的または付随的であるコンテンツのセクション。 なし
option 選択リスト内の選択可能な項目。 なし
presentation 暗黙のネイティヴロールセマンティックがアクセシビリティーAPIにマッピングされない要素。 なし
progressbar 長時間かかるタスクの進捗状況を表示する要素。 なし
radio 一度に1つのみがチェックできる、radioロールのグループでチェック可能な入力。
radiogroup ラジオボタンのグループ。 なし
region たとえば、ライブスポーツイベントの統計情報を含むページ領域など、著者がページ概要または目次に含まれるのに十分重要であると思うウェブページまたは文書の大きな知覚可能なセクション。 なし
row グリッド内のセルの行。 なし
rowgroup グリッド内の1つ以上の行要素を含むグループ。 なし
rowheader グリッド内の行に対するヘッダー情報を含むセル。 なし
scrollbar 表示領域内でコンテンツが完全に表示されるかどうかに関わらず、表示領域内でコンテンツのスクロールを制御するグラフィカルオブジェクト。
全体として、検索機能を作成するために組み合わせる、項目およびオブジェクトのコレクションを含む目印領域。関連するformを参照のこと。 なし
separator メニュー項目のコンテンツまたはグループのセクションを分離して区別する仕切り。
  • なし
slider ユーザーが与えられた範囲内から値を選択する場合の、ユーザーの入力。
spinbutton ユーザーが個別の選択肢の中から選択するように期待する範囲のフォーム。
status ユーザーのための助言情報だが、通知を正当化するほど重要ではなく、多くの場合ステータスバーとして必ずしも表示されないコンテンツのコンテナ。関連するalertを参照のこと。 なし
tab ユーザーにレンダリングされるタブコンテンツを選択するためのメカニズムを提供するグループ化ラベル。 なし
tablist タブパネル要素への参照である、タブ要素のリスト。 なし
tabpanel tabtablistに含まれる場合、tabに関連付けられたリソースのコンテナ。 なし
textbox 入力値として自由形式のテキストを許可する入力。 なし
timer 始点からの経過時間または終点までの残り時間を示す数値カウンタを含むlive regionの種類。 なし
toolbar コンパクトな見た目で示した一般的に使用される機能ボタンのコレクション。 なし
tooltip 要素の説明を表示するコンテキストポップアップ。 なし
tree 折りたたみおよび展開することができるサブレベルのネストされたグループを含むことができるリストの種類。 なし
treegrid ツリーと同様に展開または折り畳むことができる行のグリッド。 なし
treeitem ツリーのオプション項目。ツリー項目のサブレベルグループを含む場合、これは展開または折りたたみできるツリー内の要素である。 なし

4 HTMLの要素

4.1 ルート要素

4.1.1 html要素

カテゴリ
なし。
この要素を使用できるコンテキスト
文書のルート要素として。
複合文書で、サブ文書断片が許可される場所ならどこでも。
コンテンツモデル
head要素の後に続いてbody要素。
コンテンツ属性
グローバル属性
manifestアプリケーションキャッシュマニフェスト
text/htmlにおけるタグ省略
html要素内の最初の文がコメントでない場合、html要素の開始タグは省略できる。
html要素の直後がコメントでない場合、html要素の終了タグは省略できる。
許可されるARIAロール属性値:
なし
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
DOMインターフェース
interface HTMLHtmlElement : HTMLElement {};

html要素は、HTML文書のルートを表す

著者は、文書の言語を与えるために、ルートのhtml要素にlang属性を指定することが推奨される。これは、音声合成ツールにどの発音を使用するかを決定する、翻訳ツールを使用するための規則を決定する、などの手助けを行う。

存在するならば、manifestマニフェスト属性は、文書のアプリケーションキャッシュマニフェストのアドレスを与える。属性が存在する場合、属性値は、潜在的にスペースで囲まれた妥当な空でないURLでなければならない。

manifest属性は、文書の読み込みの初期段階でのみ効果を持つ。よって、動的に属性を変更すると、効果がない(したがって、いずれのDOM APIも、この属性に提供されない)。

アプリケーションキャッシュの選択の目的に対して、それらの要素が見られる前に属性が処理されるように、base要素は、manifest属性で相対URLの解決に影響を後で与えることができない。

window.applicationCacheIDL属性は、オフラインのアプリケーションキャッシュ機構へのスクリプトアクセスを提供する。

次の例において、html要素は、文書言語が英語であることを宣言する。

<!DOCTYPE html>
<html lang="en">
<head>
<title>Swapping Songs</title>
</head>
<body>
<h1>Swapping Songs</h1>
<p>Tonight I swapped some of the songs I wrote with some friends, who
gave me some of the songs they wrote. I love sharing my music.</p>
</body>
</html>

4.2 文書メタデータ

4.2.1 head要素

カテゴリ
なし。
この要素を使用できるコンテキスト
html要素内の最初の要素として。
コンテンツモデル
文書がiframe srcdoc文書であるか、タイトル情報がより上位プロトコルから利用可能な場合、1つより多くないtitle要素および1つより多くないbase要素である、0個以上のメタデータコンテンツ
そうでなければ、厳密に1つのtitle要素が存在しかつ1つより多くないbase要素である、1つ以上のメタデータコンテンツ
コンテンツ属性
グローバル属性
text/htmlにおけるタグ省略
要素が空である場合、またはhead要素内の最初の文が要素である場合、head要素の開始タグは省略してもよい。
head要素の直前が空白文字またはコメントでない場合、head要素の終了タグは省略してもよい。
許可されるARIAロール属性値:
なし
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
DOMインターフェース
interface HTMLHeadElement : HTMLElement {};

head要素は、Documentに関するメタデータの集まりを表す

head要素でのメタデータの集まりは、大きいかもしれないし、小さいかもしれない。これは非常に簡潔な例である:

<!doctype html>
<html>
 <head>
  <title>A document with a short head</title>
 </head>
 <body>
 ...

これはより大きな例である:

<!DOCTYPE HTML>
<HTML>
 <HEAD>
  <META CHARSET="UTF-8">
  <BASE HREF="http://www.example.com/">
  <TITLE>An application with a long head</TITLE>
  <LINK REL="STYLESHEET" HREF="default.css">
  <LINK REL="STYLESHEET ALTERNATE" HREF="big.css" TITLE="Big Text">
  <SCRIPT SRC="support.js"></SCRIPT>
  <META NAME="APPLICATION-NAME" CONTENT="Long headed application">
 </HEAD>
 <BODY>
 ...

title要素は、ほとんどの状況で必須の子であるが、上位プロトコルがタイトル情報を提供する場合、たとえばHTMLが電子メールのオーサリング形式として使用されるときの電子メールの件名において、title要素は省略できる。

4.2.2 title要素

カテゴリ
メタデータコンテンツ
この要素を使用できるコンテキスト
他のtitle要素を含まないhead要素内。
コンテンツモデル
要素内の空白文字でないテキスト
コンテンツ属性
グローバル属性
text/htmlにおけるタグ省略
どちらのタグも省略不可。
許可されるARIAロール属性値:
なし
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
DOMインターフェース
interface HTMLTitleElement : HTMLElement {
           attribute DOMString text;
};

title要素は、文書のタイトルまたは名前を表す。たとえば、ユーザーの履歴やブックマークまたは検索結果などで、文脈を無視して使用される場合でも、著者は文書を識別するタイトルを使用すべきである。文脈から取り出したときに最初の見出しが独立する必要はないので、文書のタイトルは多くの場合、最初の見出しとは異なる。

文書ごとに複数のtitle要素が存在してはならない。

タイトルがないことが合理的なDocumentの場合、title要素はおそらく必要とされない。この要素が必要とされる場合の説明については、head要素のコンテンツモデルを参照のこと。

title . text [ = value ]

Textノードでない子ノードを無視して、要素の内容を返す。

与えられた値を持つ要素の子を置換するために、設定できる。

The IDL attribute text must return a concatenation of the contents of all the Text nodes that are children of the title element (ignoring any other nodes such as comments or elements), in tree order. On setting, it must act the same way as the textContent IDL attribute.

それらの同じページ上で使用されるかもしれないトップレベルの見出しと対照的に、適切なタイトルのいくつかの例を次に示す。

  <title>Introduction to The Mating Rituals of Bees</title>
    ...
  <h1>Introduction</h1>
  <p>This companion guide to the highly successful
  <cite>Introduction to Medieval Bee-Keeping</cite> book is...

次のページは、同じサイトの一部であるかもしれない。最初の見出しが、読者がどのような文脈か知っており、したがってダンスがサルサやワルツであるかどうかを知りたいと思わないだろうことを前提としつつ、タイトルが明確に主題を説明する方法に注意する:

  <title>Dances used during bee mating rituals</title>
    ...
  <h1>The Dances</h1>

文書のタイトルとして使用する文字列は、document.titleIDL属性によって与えられる。

User agents should use the document's title when referring to the document in their user interface. When the contents of a title element are used in this way, the directionality of that title element should be used to set the directionality of the document's title in the user interface.

4.2.3 base要素

カテゴリ
メタデータコンテンツ
この要素を使用できるコンテキスト
他のbase要素を含まないhead要素内。
コンテンツモデル
空。
コンテンツ属性
グローバル属性
href文書基底URL
targetハイパーリンクナビゲーションおよびフォーム送信に対するブラウジングコンテキスト
text/htmlにおけるタグ省略
終了タグなし。
許可されるARIAロール属性値:
なし
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
DOMインターフェース
interface HTMLBaseElement : HTMLElement {
           attribute DOMString href;
           attribute DOMString target;
};

base要素は、著者に相対URLを解決する目的で文書の基底URLを指定、および次に続くハイパーリンクのためにデフォルトでブラウジングコンテキストの名前の指定を許可する。この要素は、この情報を超えた任意のコンテンツを表すものでない。

文書ごとに複数のbase要素が存在してはならない。

base要素は、href属性、またはtarget属性のいずれか、あるいはその両方を持たなければならない。

hrefコンテンツ属性が指定される場合、潜在的にスペースで囲まれた妥当なURLでなければならない。

href属性を持つ場合、base要素は、html要素を除いて(manifest属性はbase要素に影響されない)、URLを取得するよう定義された属性を持つツリー内の他の要素の前に来なければならない。

If there are multiple base elements with href attributes, all but the first are ignored.

target属性が指定される場合、Documentハイパーリンクフォームナビゲーションを引き起こす際に、どのブラウジングコンテキストがデフォルトとして使用するかを指定する妥当なブラウジングコンテキストの名前またはキーワードを含まなければならない。

target属性を持つ場合、base要素は、ハイパーリンクを表すツリー内の要素の前に来なければならない。

If there are multiple base elements with target attributes, all but the first are ignored.

A base element that is the first base element with an href content attribute in a particular Document has a frozen base URL. The frozen base URL must be set, synchronously, whenever any of the following situations occur:

To set the frozen base URL, resolve the value of the element's href content attribute relative to the Document's fallback base URL; if this is successful, set the frozen base URL to the resulting absolute URL, otherwise, set the frozen base URL to the fallback base URL.

The href IDL attribute, on getting, must return the result of running the following algorithm:

  1. If the base element has no href content attribute, then return the document base URL and abort these steps.

  2. fallback base urlDocumentフォールバック基底URLにする。

  3. Let url be the value of the href attribute of the base element.

  4. Resolve url relative to fallback base url (thus, the base href attribute isn't affected by xml:base attributes or base elements).

  5. If the previous step was successful, return the resulting absolute URL and abort these steps.

  6. Otherwise, return the empty string.

The href IDL attribute, on setting, must set the href content attribute to the given new value.

The target IDL attribute must reflect the content attribute of the same name.

この例において、base要素は文書の基底URLを設定するために使用される:

<!DOCTYPE html>
<html>
    <head>
        <title>This is an example for the &lt;base&gt; element</title>
        <base href="http://www.example.com/news/index.html">
    </head>
    <body>
        <p>Visit the <a href="archives.html">archives</a>.</p>
    </body>
</html>

上記の例において、リンクは"http://www.example.com/news/archives.html"へのリンクとなる。

カテゴリ
メタデータコンテンツ
この要素を使用できるコンテキスト
メタデータコンテンツが期待される場所。
head要素の子であるnoscript要素内。
コンテンツモデル
空。
コンテンツ属性
グローバル属性
hrefハイパーリンクのアドレス
crossorigin — 要素がcrossorigin要求を処理する方法
rel — ハイパーリンクと宛先のリソースを含む文書の関係
media — 受け入れ可能なメディア
hreflang — リンクされたリソースの言語
type — 参照されるリソースタイプのヒント
sizes — アイコンのサイズ(rel="icon"に対する)
また、title属性はこの要素で特別なセマンティックを持つ:リンクのタイトル、代替スタイルシート設定名。
text/htmlにおけるタグ省略
終了タグなし。
許可されるARIAロール属性値:
link (デフォルト - 設定しない)。
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
許可されるロールで受け入れ可能な任意のaria-*属性。
role値に対して
DOMインターフェース
interface HTMLLinkElement : HTMLElement {
           attribute boolean disabled;
           attribute DOMString href;
           attribute DOMString crossOrigin;
           attribute DOMString rel;
           attribute DOMString rev;
  readonly attribute DOMTokenList relList;
           attribute DOMString media;
           attribute DOMString hreflang;
           attribute DOMString type;
  [PutForwards=value] readonly attribute DOMSettableTokenList sizes;
};
HTMLLinkElement implements LinkStyle;

link要素は、著者が文書を他のリソースとリンクするのを可能にする。

リンクの宛先はhref属性によって与えられ、これは存在しなければならず、潜在的にスペースで囲まれた妥当な空でないURLを含まなければならない。If the href attribute is absent, then the element does not define a link.

link要素はrel属性を持たなければならない。

rel属性が使用される場合、この要素はhead要素に制限される。

(関係を)示されるリンクの種類はrel属性値によって与えられ、存在する場合、スペースで区切られたトークンの集合である値を持たなければならない。許可されたキーワードとその意味は、後の節で定義される。If the rel attribute is absent, has no keywords, or if none of the keywords used are allowed according to the definitions in this specification, then the element does not create any links.

外部リソースへのリンクハイパーリンクという、2つのリンクカテゴリがlink要素を用いて作成できる。リンクタイプの節では、あるリンクタイプが外部リソースまたはハイパーリンクであるかどうかを定義する。1つのlink要素は、複数のリンク(一部は外部リソースへのリンクかもしれず、一部はハイパーリンクであるかもしれない)を作成できる。正確には、どのリンクがどれだけ作成されるかは、rel属性で与えられるキーワードに応じて異なる。ユーザーエージェントは、要素あたりの基準ではなく、リンクあたりの基準でリンクを処理しなければならない。

link要素に対して作成された各リンクは別々に処理される。たとえば、rel="stylesheet"をもつ2つのlink要素が存在する場合、これらは個別の外部リソースとして数え、およびそれぞれが独立に独自の属性によって影響される。同様に、単一のlink要素が値next stylesheetを伴うrel属性を持つ場合、それはハイパーリンクnextキーワードへの)および外部リソースリンクstylesheetキーワードへの)の両方を作成し、それらはそれぞれに(mediaまたはtitleのような)他の属性の影響を受ける。

たとえば、次のlink要素は、(同じページへ)2つのハイパーリンクを作成する。

<link rel="author license" href="/about">

この要素によって作成される2つのリンクは、1つは対象ページが現在のページの著者に関する情報を持つセマンティックであり、1つは現在のページが提供されている内部でライセンスに関する情報を対象ページが持つセマンティックである。

crossorigin属性はCORS設定属性である。これは、外部リソースリンクでの使用を意図される。

外部リソースへのリンクに対する正確な振る舞いは、関連するリンク型に対して定義されるように、正確な関係に依存する。一部の属性は、(以下に定義されるように)外部リソースが適用されるかどうかを制御する。

For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available (modulo cross-origin restrictions) even if the resource is not applied. To obtain the resource, the user agent must run the following steps:

  1. If the href attribute's value is the empty string, then abort these steps.

  2. Resolve the URL given by the href attribute, relative to the element.

  3. If the previous step fails, then abort these steps.

  4. Do a potentially CORS-enabled fetch of the resulting absolute URL, with the mode being the current state of the element's crossorigin content attribute, the origin being the origin of the link element's Document, and the default origin behaviour set to taint.

    The resource obtained in this fashion can be either CORS-same-origin or CORS-cross-origin.

User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied.

The semantics of the protocol used (e.g. HTTP) must be followed when fetching external resources. (For example, redirects will be followed and 404 responses will cause the external resource to not be applied.)

Once the attempts to obtain the resource and its critical subresources are complete, the user agent must, if the loads were successful, queue a task to fire a simple event named load at the link element, or, if the resource or one of its critical subresources failed to completely load for any reason (e.g. DNS error, HTTP 404 response, a connection being prematurely closed, unsupported Content-Type), queue a task to fire a simple event named error at the link element. Non-network errors in processing the resource or its subresources (e.g. CSS parse errors, PNG decoding errors) are not failures for the purposes of this paragraph.

The task source for these tasks is the DOM manipulation task source.

The element must delay the load event of the element's document until all the attempts to obtain the resource and its critical subresources are complete. (Resources that the user agent has not yet attempted to obtain, e.g. because it is waiting for the resource to be needed, do not delay the load event.)


Interactive user agents may provide users with a means to follow the hyperlinks created using the link element, somewhere within their user interface. The exact interface is not defined by this specification, but it could include the following information (obtained from the element's attributes, again as defined below), in some form or another (possibly simplified), for each hyperlink created with each link element in the document:

User agents could also include other information, such as the type of the resource (as given by the type attribute).

link要素とともに作成されるハイパーリンクおよびそのrel属性はページ全体に適用される。これは、コンテキストが文書内のリンク位置によって与えられるリンク型を示す、aおよびarea要素のrel属性とは対照的である。

media属性は、リソースが適用されるメディアを表す。値は妥当なメディアクエリでなければならない。

If the link is a hyperlink then the media attribute is purely advisory, and describes for which media the document in question was designed.

However, if the link is an external resource link, then the media attribute is prescriptive. The user agent must apply the external resource when the media attribute's value matches the environment and the other relevant conditions apply, and must not apply it otherwise.

The external resource might have further restrictions defined within that limit its applicability. For example, a CSS style sheet might have some @media blocks. This specification does not override such further restrictions or requirements.

media属性が省略される場合、デフォルトでは"all"であり、デフォルトのリンクにより、すべてのメディアに適用されることを意味する。

link要素のhreflang属性は、aおよびarea要素のhreflang属性と同じセマンティックを持つ。

type属性は、リンクされたリソースのMIMEタイプを提供する。これは単なる助言である。値は妥当なMIMEタイプでなければならない。

外部リソースへのリンクについて、それらがサポートしないリソースの再取得を回避できるように、type属性はユーザーエージェントへのヒントとして使用される。If the attribute is present, then the user agent must assume that the resource is of the given type (even if that is not a valid MIME type, e.g. the empty string). If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type. If the UA does not support the given MIME type for the given link relationship, then the UA should not obtain the resource; if the UA does support the given MIME type for the given link relationship, then the UA should obtain the resource at the appropriate time as specified for the external resource link's particular type. If the attribute is omitted, and the external resource link type does not have a default type defined, but the user agent would obtain the resource if the type was known and supported, then the user agent should obtain the resource under the assumption that it will be supported.

User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use the type attribute to determine its actual type. Only the actual type (as defined in the next paragraph) is used to determine whether to apply the resource, not the aforementioned assumed type.

The stylesheet link type defines rules for processing the resource's Content-Type metadata.

Once the user agent has established the type of the resource, the user agent must apply the resource if it is of a supported type and the other relevant conditions apply, and must ignore the resource otherwise.

If a document contains style sheet links labeled as follows:

<link rel="stylesheet" href="A" type="text/plain">
<link rel="stylesheet" href="B" type="text/css">
<link rel="stylesheet" href="C">

...then a compliant UA that supported only CSS style sheets would fetch the B and C files, and skip the A file (since text/plain is not the MIME type for CSS style sheets).

For files B and C, it would then check the actual types returned by the server. For those that are sent as text/css, it would apply the styles, but for those labeled as text/plain, or any other type, it would not.

If one of the two files was returned without a Content-Type metadata, or with a syntactically incorrect type like Content-Type: "null", then the default type for stylesheet links would kick in. Since that default type is text/css, the style sheet would nonetheless be applied.

title属性は、リンクのタイトルを与える。一つの例外を除いて、これは純粋に助言的である。値はテキストである。例外は、title属性が代替スタイルシートのセットを定義するスタイルシートのリンクに対するものである。

link要素のtitle属性は、タイトルをもたないリンクが親要素のタイトルを継承しない点で、他のほとんどの要素に属するグローバルtitle属性とは異なる。それは単にタイトルを持たない。

sizes属性は、iconリンクタイプとともに使用される。属性は、iconのキーワードを指定するrel属性を持たないlink要素を指定してはならない。

The activation behavior of link elements that create hyperlinks is to run the following steps:

  1. If the link element's Document is not fully active, then abort these steps.

  2. Follow the hyperlink created by the link element.

HTTP Link: headers, if supported, must be assumed to come before any links in the document, in the order that they were given in the HTTP message. These headers are to be processed according to the rules given in the relevant specifications. [HTTP] [WEBLINK]

Registration of relation types in HTTP Link: headers is distinct from HTML link types, and thus their semantics can be different from same-named HTML types.

The IDL attributes href, rel, rev, media, hreflang, type, and sizes each must reflect the respective content attributes of the same name.

The crossOrigin IDL attribute must reflect the crossorigin content attribute, limited to only known values.

The IDL attribute relList must reflect the rel content attribute.

IDL属性disabledは、スタイルシートのリンクにのみ適用する。link要素がスタイルシートのリンクを定義する場合、disabled属性は、代替スタイルシートDOMへ定義されるように振る舞う。他のすべてのlink要素に対して、これは常にfalseを返し、何も設定しない。

LinkStyleインターフェースはまた、この要素で実装される。スタイリング処理モデルが方法を定義する。[CSSOM]

ここで、link要素のセットは、スタイルシートを提供する:

<!-- a persistent style sheet -->
<link rel="stylesheet" href="default.css">

<!-- the preferred alternate style sheet -->
<link rel="stylesheet" href="green.css" title="Green styles">

<!-- some alternate style sheets -->
<link rel="alternate stylesheet" href="contrast.css" title="High contrast">
<link rel="alternate stylesheet" href="big.css" title="Big fonts">
<link rel="alternate stylesheet" href="wide.css" title="Wide screen">

次の例は、別の形式を使用する、他言語向け、他のメディアのために意図されているページのバージョンをどのように指定できるかを示す:

<link rel=alternate href="/en/html" hreflang=en type=text/html title="English HTML">
<link rel=alternate href="/fr/html" hreflang=fr type=text/html title="French HTML">
<link rel=alternate href="/en/html/print" hreflang=en type=text/html media=print title="English HTML (for printing)">
<link rel=alternate href="/fr/html/print" hreflang=fr type=text/html media=print title="French HTML (for printing)">
<link rel=alternate href="/en/pdf" hreflang=en type=application/pdf title="English PDF">
<link rel=alternate href="/fr/pdf" hreflang=fr type=application/pdf title="French PDF">

4.2.5 meta要素

カテゴリ
メタデータコンテンツ
この要素を使用できるコンテキスト
charset属性が存在する場合、または要素のhttp-equivの属性がエンコード宣言状態にある場合:head要素内。
http-equiv属性が存在するが、エンコード宣言状態でない場合:head要素内。
http-equiv属性が存在するが、エンコード宣言状態でない場合:head要素の子であるnoscript要素内。
name属性が存在する場合:メタデータコンテンツが期待される場所。
コンテンツモデル
空。
コンテンツ属性
グローバル属性
name — メタデータ名
http-equiv — プラグマディレクティブ
content — 要素の値
charset文字エンコーディング宣言
text/htmlにおけるタグ省略
終了タグなし。
許可されるARIAロール属性値:
なし
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
DOMインターフェース
interface HTMLMetaElement : HTMLElement {
           attribute DOMString name;
           attribute DOMString httpEquiv;
           attribute DOMString content;
};

meta要素は、titlebaselinkstylescript要素を用いて表現できない様々な種類のメタデータを表す

meta要素は、name属性をもつ文書レベルのメタデータ、http-equiv属性を持つプラグマ・ディレクティブ、およびcharset属性をもつHTML文書が文字列形式にシリアライズされる(たとえば、ネットワーク上の伝送、またはディスクストレージ)場合、ファイルの文字エンコーディング宣言を表すことができる。

namehttp-equiv、およびcharset属性のうちの1つを正確に指定しなければならない。

nameまたはhttp-equivのいずれかが指定される場合、content属性も指定しなければならない。そうでなければ、省略されなければならない。

charset属性は、文書で使用される文字エンコーディングを指定する。これは、文字エンコーディング宣言である。属性がXML文書内に存在する場合、その値は、文字列"UTF-8"とASCII大文字・小文字不区別で一致しなければならない(したがって、文書は、エンコーディングとしてUTF-8を使用するよう強制される)。

meta要素上のcharset属性は、XML文書では効果がなく、単にXHTMLからの移行を容易にするために許可される。

文書ごとにcharset属性をもつ複数のmeta要素があってはならない。

content属性は、文書のメタデータまたは要素がそれらの目的のために使用される場合のプラグマディレクティブの値を与える。この仕様の後続の節で説明されるように、許可される値は、正確な文脈に依存する。

meta要素がname属性を持つ場合、文書のメタデータを設定する。文書のメタデータは、名前と値のペアの観点から表される。meta要素のname属性が名前を与え、同じ要素のcontent属性が値を与える。名前はメタデータのどの側面を設定するかを指定する。妥当な名前とその値の意味は、次の節で説明する。meta要素がcontent属性を持たない場合、メタデータの名前と値のペアの値部分は、空文字列である。

The name and content IDL attributes must reflect the respective content attributes of the same name. The IDL attribute httpEquiv must reflect the content attribute http-equiv.

4.2.5.1 標準メタデータ名

この仕様は、meta要素のname属性の名前を定義する。

Names are case-insensitive, and must be compared in an ASCII case-insensitive manner.

application-name

値は、ページが表すウェブアプリケーションの名前を与える短い自由形式の文字列でなければならない。ページがウェブアプリケーションでない場合、application-nameメタデータ名を使用してはならない。それぞれの名前の言語を指定する属性を使用することで、ウェブアプリケーション名の翻訳は与えられてもよい。

与えられる言語をもち、かつ文書ごとに値application-nameを設定するname属性をもつ複数のmeta要素が存在してはならない。

User agents may use the application name in UI in preference to the page's title, since the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.

To find the application name to use given an ordered list of languages (e.g. British English, American English, and English), user agents must run the following steps:

  1. Let languages be the list of languages.

  2. Let default language be the language of the Document's root element, if any, and if that language is not unknown.

  3. If there is a default language, and if it is not the same language as any of the languages is languages, append it to languages.

  4. Let winning language be the first language in languages for which there is a meta element in the Document that has its name attribute set to the value application-name and whose language is the language in question.

    If none of the languages have such a meta element, then abort these steps; there's no given application name.

  5. Return the value of the content attribute of the first meta element in the Document in tree order that has its name attribute set to the value application-name and whose language is winning language.

author

値は、ページ著者のうちの一人の名前を与える、自由形式の文字列でなければならない。

description

値は、ページを説明する自由形式の文字列でなければならない。たとえば検索エンジン内など、値はページのディレクトリで使用するために適切なものでなければならない。文書ごとに値descriptionを設定するname属性を持つ複数のmeta要素があってはならない。

generator

値は、文書を生成するために使用されるソフトウェアパッケージの1つを識別する自由形式の文字列でなければならない。この値は、たとえばマークアップがテキストエディタでユーザーによって記述されたページのように、マークアップがソフトウェアによって生成されないページで使用してはならない。

"Frontweaver"と呼ばれるツールは、ページ生成のために使用されるツールとして自分自身を識別するために、ページのhead要素内にその出力で含むかもしれない:

<meta name=generator content="Frontweaver 8.2">
keywords

値は、それぞれがページに関連するキーワードである、コンマ区切りトークンの集合でなければならない。

イギリスの高速道路上の書体に関するこのページは、ユーザーがページを検索するために使用するかもしれないキーワードを指定するmeta要素を使用している:

<!DOCTYPE HTML>
<html>
 <head>
  <title>Typefaces on UK motorways</title>
  <meta name="keywords" content="british,type face,font,fonts,highway,highways">
 </head>
 <body>
  ...

多くの検索エンジンは、この機能が歴史的に当てにならず、さらにはユーザーにとって有益でない手段をもたらす、検索エンジンスパムとして誤解を招く方法で使用されているので、そのようなキーワードを考慮しない。

To obtain the list of keywords that the author has specified as applicable to the page, the user agent must run the following steps:

  1. Let keywords be an empty list.

  2. For each meta element with a name attribute and a content attribute and whose name attribute's value is keywords, run the following substeps:

    1. Split the value of the element's content attribute on commas.

    2. Add the resulting tokens, if any, to keywords.

  3. Remove any duplicates from keywords.

  4. Return keywords. This is the list of keywords that the author has specified as applicable to the page.

User agents should not use this information when there is insufficient confidence in the reliability of the value.

For instance, it would be reasonable for a content management system to use the keyword information of pages within the system to populate the index of a site-specific search engine, but a large-scale content aggregator that used this information would likely find that certain users would try to game its ranking mechanism through the use of inappropriate keywords.

4.2.5.2 他のメタデータ名

メタデータ名の定義済みセットに対する拡張は、WHATWG Wiki MetaExtensions pageに登録されているかもしれない。[WHATWGWIKI]

型の追加は、いつでもWHATWG Wiki MetaExtensions pageを編集することで誰もが自由にできる。これらの新しい名前は、次の情報を指定しなければならない:

キーワード

実際の名前が定義されている。名前は、他の定義済みの名前と紛らわしいものであるべきでない(たとえば、大文字と小文字だけが異なる)。

概要

メタデータ名の意味はどのようなものかの短い非標準の説明は、その値が要求する形式を含む。

Specification(仕様)
メタデータ名のセマンティックおよび要求のより詳細な説明へのリンク。それはWiki上の別のページかもしれないし、外部ページへのリンクかもしれない。
Synonyms(類義語)

全く同じ処理要求を持つ他の名前のリスト。著者は、同義語であると定義された名前を使うべきではなく、同義語はユーザーエージェントがレガシーコンテンツをサポートするためだけのものである。誰もが実際に使用されてない同義語を削除できる。レガシーコンテンツとの互換性のために同義語として処理する必要がある名前のみが、この方法で登録されているのである。

Status(状態)

以下のうちの1つをとる:

Proposed(提案)
広いレビューと承認を受けていない名前。誰かが提案済みか提案している、あるいは提案予定であり、使うことができる。
Ratified(承認)
広いレビューと承認を受けている名前。それは、明確に不正確な方法で使用する場合を含めて、名前を使用するページを処理する方法を明快に定義した仕様を持つ。
Discontinued(中止)
広いレビューを受けており、欠陥が発見されたメタデータ名。既存のページはこのメタデータ名を使用しているが、新しいページでは避けるべきである。"brief description"(簡単な説明)と"specification"(仕様書)のエントリは、どちらかといえば著者が代わりに使用すべきものの詳細を提供するだろう。

メタデータ名が既存の値とともに冗長であることが判明した場合、削除され、既存の値の同義語としてリストされているべきである。

メタデータ名が、使用するまたは指定することなく一月以上の期間"proposed"(提案)状態で登録されている場合、レジストリから削除されることがある。

メタデータ名が"proposed"(提案)状態で追加され、既存の値とともに冗長であることが判明している場合、既存の値の同義語として削除され、リストされているべきである。メタデータ名は"proposed"(提案)状態で追加され、有害だと判明している場合、"discontinued"(中止)状態に変更すべきである。

誰もがいつでも状態を変更できるが、上記の定義にしたがってのみ行うべきである。

Conformance checkers may use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as "proposed" or "ratified" must be accepted, whereas values marked as "discontinued" or not listed in either this specification or on the aforementioned page must be reported as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

When an author uses a new metadata name not defined by either this specification or the Wiki page, conformance checkers should offer to add the value to the Wiki, with the details described above, with the "proposed" status.

値がURLのようなメタデータ名は、提案または受け入れてはならない。リンクは、meta要素ではなく、link要素を用いて表現されなければならない。

4.2.5.3 プラグマディレクティブ

meta要素でhttp-equiv属性が指定された場合、要素はプラグマディレクティブである。

http-equiv属性は、列挙属性である。以下の表は、この属性に対して定義されたキーワードを列挙する。キーワードとともにその行の最初のセルに与えられた状態は、これらキーワードが対応する状態を与える。Some of the keywords are non-conforming, as noted in the last column.

状態 キーワード
Content Language content-language Non-conforming
エンコーディング宣言 content-type
デフォルトスタイル default-style
リフレッシュ refresh
Cookie setter set-cookie Non-conforming

When a meta element is inserted into the document, if its http-equiv attribute is present and represents one of the above states, then the user agent must run the algorithm appropriate for that state, as described in the following list:

Content language state (http-equiv="content-language")

This feature is non-conforming. Authors are encouraged to use the lang attribute instead.

This pragma sets the pragma-set default language. Until such a pragma is successfully processed, there is no pragma-set default language.

  1. If the meta element has no content attribute, then abort these steps.

  2. If the element's content attribute contains a "," (U+002C) character then abort these steps.

  3. Let input be the value of the element's content attribute.

  4. Let position point at the first character of input.

  5. Skip whitespace.

  6. Collect a sequence of characters that are not space characters

  7. Let candidate be the string that resulted from the previous step.

  8. If candidate is the empty string, abort these steps.

  9. Set the pragma-set default language to candidate.

This pragma is almost, but not quite, entirely unlike the HTTP Content-Language header of the same name. [HTTP]

エンコーディング宣言状態http-equiv="content-type"

エンコーディング宣言状態は、charset属性の設定の単なる代替形式である。これは文字エンコーディング宣言である。This state's user agent requirements are all handled by the parsing section of the specification.

エンコーディング宣言状態http-equiv属性をもつmeta要素に対して、content属性は、リテラルに文字列"text/html;"、その後に任意の数の空白文字が任意で続き、その後にリテラルに文字列"charset="が続き、その後に文字エンコーディング宣言文字エンコーディングラベルが続くものからなる文字列とASCII大文字・小文字不区別で一致する値を持たなければならない。

文書は、エンコーディング宣言状態http-equiv属性をもつmeta要素と、charset属性の存在するmeta要素の両方を含んではならない。

エンコーディング宣言状態は、HTML文書でおよびXML文書で使用されてもよい。エンコーディング宣言状態XML文書内で使用される場合、文字エンコーディングの名前は、文字列"UTF-8"とASCII大文字・小文字不区別で一致しなければならない(したがって、文書は、エンコーディングとしてUTF-8を使用するよう強制される)。

エンコーディング宣言状態はXML文書において効果がなく、単にXHTMLからの移行を容易にするために許可される。

デフォルトスタイル状態http-equiv="default-style"

このプラグマは、デフォルトの代替スタイルシートのセットの名前を設定する。

  1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  2. Set the preferred style sheet set to the value of the element's content attribute. [CSSOM]

リフレッシュ状態http-equiv="refresh"

このプラグマは、時限式のリダイレクトとして動作する。

  1. If another meta element with an http-equiv attribute in the Refresh state has already been successfully processed (i.e. when it was inserted the user agent processed it and reached the last step of this list of steps), then abort these steps.

  2. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  3. Let input be the value of the element's content attribute.

  4. Let position point at the first character of input.

  5. Skip whitespace.

  6. Collect a sequence of characters that are ASCII digits, and parse the resulting string using the rules for parsing non-negative integers. If the sequence of characters collected is the empty string, then no number will have been parsed; abort these steps. Otherwise, let time be the parsed number.

  7. Collect a sequence of characters that are ASCII digits and "." (U+002E) characters. Ignore any collected characters.

  8. Skip whitespace.

  9. Let url be the address of the current page.

  10. If the character in input pointed to by position is a ";" (U+003B) character or a "," (U+002C) character, then advance position to the next character. Otherwise, jump to the last step.

  11. Skip whitespace.

  12. If the character in input pointed to by position is a "U" (U+0055) character or a U+0075 LATIN SMALL LETTER U character (u), then advance position to the next character. Otherwise, jump to the last step.

  13. If the character in input pointed to by position is a "R" (U+0052) character or a U+0072 LATIN SMALL LETTER R character (r), then advance position to the next character. Otherwise, jump to the last step.

  14. If the character in input pointed to by position is s "L" (U+004C) character or a U+006C LATIN SMALL LETTER L character (l), then advance position to the next character. Otherwise, jump to the last step.

  15. Skip whitespace.

  16. If the character in input pointed to by position is a "=" (U+003D), then advance position to the next character. Otherwise, jump to the last step.

  17. Skip whitespace.

  18. If the character in input pointed to by position is either a "'" (U+0027) character or """ (U+0022) character, then let quote be that character, and advance position to the next character. Otherwise, let quote be the empty string.

  19. Let url be equal to the substring of input from the character at position to the end of the string.

  20. If quote is not the empty string, and there is a character in url equal to quote, then truncate url at that character, so that it and all subsequent characters are removed.

  21. Strip any trailing space characters from the end of url.

  22. Strip any "tab" (U+0009), "LF" (U+000A), and "CR" (U+000D) characters from url.

  23. Resolve the url value to an absolute URL, relative to the meta element. If this fails, abort these steps.

  24. Perform one or more of the following steps:

    In addition, the user agent may, as with anything, inform the user of any and all aspects of its operation, including the state of any timers, the destinations of any timed redirects, and so forth.

リフレッシュ状態http-equiv属性をもつmetaに対して、content属性はいずれかからなる値を持たなければならない:

前者の場合、整数は、そのページが再読み込みされるよりも前の秒数を表す。後者の場合、整数は、与えられたURLのページで置き換えられるよりも前の秒数を表す。

ページが5分ごとにサーバーからの自動的な再読み込みを確実にするために、報道機関のフロントページは、そのページのhead要素で次のマークアップを含むかもしれない:

<meta http-equiv="Refresh" content="300">

以下のようなマークアップを用いて、連続したページは、各ページが連続で次のページにリフレッシュさせることで、自動スライドショーとして使用されるかもしれない:

<meta http-equiv="Refresh" content="20; URL=page4.html">
Cookie setter (http-equiv="set-cookie")

This pragma sets an HTTP cookie. [COOKIES]

It is non-conforming. Real HTTP headers should be used instead.

  1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  2. Obtain the storage mutex.

  3. Act as if receiving a set-cookie-string for the document's address via a "non-HTTP" API, consisting of the value of the element's content attribute encoded as UTF-8. [COOKIES] [RFC3629]

一度に文書で特定の状態をもつ複数のmeta要素が存在してはならない。

4.2.5.4 他のプラグマディレクティブ

プラグマディレクティブの定義済みセットに対する拡張は、WHATWG Wiki PragmaExtensions pageに登録されているかもしれない。[WHATWGWIKI]

そのような拡張は、Permanent Message Header Field Registryに登録されたHTTPヘッダーと同一の名前を使用しなければならず、HTTPヘッダーに対して説明されるものと同様に振る舞わなければならない。[IANAPERMHEADERS]

メタデータを記述するヘッダー、または特定のユーザーエージェント処理を必要としないものに対応するプラグマディレクティブは、登録されてはならない。代わりにメタデータ名を使用する。結果としてHTMLを実装するユーザーエージェントとそうでないユーザーエージェントと異なるHTTPレベルの振る舞いをもたらすので、HTTP処理モデルに影響を与えるヘッダー(たとえば、キャッシュ)に相当するプラグマディレクティブは登録されてはならない。

上記の条件を満たすプラグマディレクティブの追加は、いつでもWHATWG Wiki PragmaExtensions pageを編集することで誰もが自由にできる。そのような登録は以下の情報を指定しなければならない:

キーワード

実際の名前が定義されている。名前は、同じ要求をもつ以前に登録されたHTTPの名前と一致しなければならない。

概要

プラグマディレクティブの目的の非規範的な説明。

Specification(仕様)
対応するHTTPヘッダーを定義する仕様へのリンク。

Conformance checkers must use the information given on the WHATWG Wiki PragmaExtensions page to establish if a value is allowed or not: values defined in this specification or listed on the aforementioned page must be accepted, whereas values not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

4.2.5.5 文書の文字エンコーディングを指定する

文字エンコーディング宣言は、文書の記憶または伝達に用いられる文字エンコーディングを指定するメカニズムである。

以下の制限が文字エンコーディング宣言に適用される。

さらに、meta要素には多くの制限があるため、文書ごとに1つのmetaベースの文字エンコーディング宣言のみがあるかもしれない。

HTML文書がBOMで開始せず、かつそのエンコーディングContent-Typeメタデータによって明示的に与えられず、かつ文書がiframe srcdoc文書でない場合、使用される文字エンコーディングはASCII互換文字エンコーディングでなければならず、エンコーディングはcharset属性をもつmeta要素またはエンコーディング宣言状態http-equiv属性をもつmeta要素を用いて指定されなければならない。

フォームにユーザーが入力した、スクリプトによって生成されたURLでなど、文字エンコーディングは非ASCII文字を処理するために必要とされるため、エンコーディングがUS-ASCIIである場合であっても、文字エンコーディング宣言は、(Content-Typeメタデータ内または明示的にファイル内のいずれか)が必要である。

文書がiframe srcdoc文書である場合、文書は文字エンコーディング宣言を持ってはならない。(この場合、文書の一部はiframeを含んでいるので、ソースはすでにデコードされている。)

HTML文書charset属性をもつmeta要素または文字エンコーディング宣言http-equiv属性をもつmeta要素を含む場合、使用される文字エンコーディングはASCII互換文字エンコーディングでなければならない。

著者はUTF-8を使用すべきである。適合性検査は、著者にレガシーエンコーディングを使うことに反対するよう忠告してもよい。[RFC3629]

Authoring tools should default to using UTF-8 for newly-created documents. [RFC3629]

0x20から0x7Eまでの範囲で一連のバイトがU+0020からU+007Eまでの範囲の文字を比較する以外の文字にデコードできるエンコーディングは、潜在的なセキュリティー脆弱性を表す。エンコーディングをサポートしない(またはエンコーディングを宣言するために使用されるラベルをサポートしない、または他のユーザーエージェントのようにラベル付けされないコンテンツのエンコーディングを宣言する同じメカニズムを使用しない)ユーザーエージェントは、結局はHTMLタグおよびJavaScriptとして技術的に温和なプレーンテキストの文脈で解釈することになるかもしれない。したがって、著者はこれらのエンコーディングを使用すべきではない。たとえば、ASCIIで"<script>"に対応するバイトのエンコーディングに適用すると、異なる文字列をデコードする可能性がある。Authors should not use such encodings, which are known to include JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), encodings based on ISO-2022, and encodings based on EBCDIC. さらに、著者は、CESU-8、UTF-7、BOCU-1およびSCSUエンコーディングを使用してはならない。これらのエンコーディングはウェブコンテンツへの使用に対して全く意図されていないため、このカテゴリに分類される。[RFC1345] [RFC1842] [RFC1468] [RFC2237] [RFC1554] [CP50220] [RFC1922] [RFC1557] [CESU8] [UTF7] [BOCU1] [SCSU]

この仕様で説明されるエンコーディング検出アルゴリズムはUTF-32とUTF-16を故意に区別しないため、著者はUTF-32を使用すべきではない。[UNICODE]

UTF-8でないエンコーディングの使用は、デフォルトで文書の文字エンコーディングを使うことで、フォーム提出およびURLエンコーディングで予期しない結果を招くかもしれない。

XHTMLにおいて、必要ならば、XML宣言はインライン文字エンコーディング情報に対して使用されるべきである。

HTMLにおいて、文字エンコーディングがUTF-8であることを宣言するために、著者は(head要素内で)文書のトップの近くに以下のマークアップを含むかもしれない:

<meta charset="utf-8">

XMLにおいて、マークアップのはじめでXML宣言は代わりに用いられるかもしれない:

4.2.6 style要素

カテゴリ
メタデータコンテンツ
この要素を使用できるコンテキスト
メタデータコンテンツが期待される場所。
head要素の子であるnoscript要素内。
コンテンツモデル
type属性の値に依存するが、下記の文に記述される要求に一致しなければならない。
コンテンツ属性
グローバル属性
media — 受け入れ可能なメディア
type — 埋め込みリソースタイプ
また、title属性はこの要素で特別なセマンティックを持つ:代替スタイルシート設定名。
text/htmlにおけるタグ省略
どちらのタグも省略不可。
許可されるARIAロール属性値:
なし
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
DOMインターフェース
interface HTMLStyleElement : HTMLElement {
           attribute boolean disabled;
           attribute DOMString media;
           attribute DOMString type;
};
HTMLStyleElement implements LinkStyle;

style要素は、著者が文書にスタイル情報の埋め込みを許可する。style要素は、スタイリング処理モデルへの、複数の入力の1つである。この要素は、ユーザーへのコンテンツを表すものでない。

type属性はスタイル言語を与える。属性が存在する場合、その値はスタイル言語を示す妥当なMIMEタイプでなければならない。charsetパラメータを指定してはならない。属性が存在しない場合に用いられるtype属性に対するデフォルト値は、"text/css"である。[RFC2318]

When examining types to determine if they support the language, user agents must not ignore unknown MIME parameters — types with unknown parameters must be assumed to be unsupported. The charset parameter must be treated as an unknown parameter for the purpose of comparing MIME types here.

media属性は、スタイルが適用されるメディアを言う。値は妥当なメディアクエリでなければならない。The user agent must apply the styles when the media attribute's value matches the environment and the other relevant conditions apply, and must not apply them otherwise.

The styles might be further limited in scope, e.g. in CSS with the use of @media blocks. This specification does not override such further restrictions or requirements.

media属性が省略される場合、デフォルトでは"all"であり、デフォルトのスタイルにより、すべてのメディアに適用されることを意味する。

style要素のtitle属性は代替スタイルシートのセットを定義する。style要素がtitle属性を持たない場合、タイトルを持たない。先祖のtitle属性はstyle要素に適用しない。[CSSOM]

link要素のtitle属性のような、style要素のtitle属性は、グローバルtitle属性とタイトルなしのstyleブロックが親要素のタイトルを継承しないという点で異なる。それは単にタイトルを持たない。

style要素のtextContentは以下のABNFでstyle生成物と対等でなければならず、Unicodeである文字セットとなる。[ABNF]

style         = no-c-start *( c-start no-c-end c-end no-c-start )
no-c-start    = < any string that doesn't contain a substring that matches c-start >
c-start       = "<!--"
no-c-end      = < any string that doesn't contain a substring that matches c-end >
c-end         = "-->"

All descendant elements must be processed, according to their semantics, before the style element itself is evaluated. For styling languages that consist of pure text (as opposed to XML), user agents must evaluate style elements by passing the concatenation of the contents of all the Text nodes that are children of the style element (not any other nodes such as comments or elements), in tree order, to the style system. For XML-based styling languages, user agents must pass all the child nodes of the style element to the style system.

All URLs found by the styling language's processor must be resolved, relative to the element (or as defined by the styling language), when the processor is invoked.

Once the attempts to obtain the style sheet's critical subresources, if any, are complete, or, if the style sheet has no critical subresources, once the style sheet has been parsed and processed, the user agent must, if the loads were successful or there were none, queue a task to fire a simple event named load at the style element, or, if one of the style sheet's critical subresources failed to completely load for any reason (e.g. DNS error, HTTP 404 response, a connection being prematurely closed, unsupported Content-Type), queue a task to fire a simple event named error at the style element. Non-network errors in processing the style sheet or its subresources (e.g. CSS parse errors, PNG decoding errors) are not failures for the purposes of this paragraph.

The task source for these tasks is the DOM manipulation task source.

The element must delay the load event of the element's document until all the attempts to obtain the style sheet's critical subresources, if any, are complete.

この仕様はスタイル規則を指定しないが、CSSは多くのウェブブラウザによってサポートされることが期待される。[CSS]

The media and type IDL attributes must reflect the respective content attributes of the same name.

disabledIDL属性は、代替スタイルシートDOMへ定義されるように振る舞う。

LinkStyleインターフェースはまた、この要素で実装される。スタイリング処理モデルが方法を定義する。[CSSOM]

次の文書は、デフォルトのイタリック体で作品とラテン語のタイトルを残したまま、イタリックテキストよりも明るい赤色のテキストとして強調するスタイルを持つ。適切な要素を使用した、文書のより簡単な再スタイル付けを可能にする方法を示す。

<!DOCTYPE html>
<html lang="en-US">
 <head>
  <title>My favorite book</title>
  <style>
   body { color: black; background: white; }
   em { font-style: normal; color: red; }
  </style>
 </head>
 <body>
  <p>My <em>favorite</em> book of all time has <em>got</em> to be
  <cite>A Cat's Life</cite>. It is a book by P. Rahmel that talks
  about the <i lang="la">Felis Catus</i> in modern human society.</p>
 </body>
</html>

4.2.7 スタイリング

linkおよびstyle要素は、文書をレンダリングする際に使用するユーザーエージェントに対してスタイル情報を供給できる。CSSおよびCSSOM仕様は、スタイル情報がユーザーエージェントによってどのように使用されるかおよびどの方法で使用されるかを指定する。[CSS] [CSSOM]

styleおよびlink要素は、LinkStyleインターフェースを実装する。[CSSOM]

For style elements, if the user agent does not support the specified styling language, then the sheet attribute of the element's LinkStyle interface must return null. Similarly, link elements that do not represent external resource links that contribute to the styling processing model (i.e. that do not have a stylesheet keyword in their rel attribute), for which the link is an alternative stylesheet but whose title content attribute is absent or empty, or whose resource is CORS-cross-origin, must have their LinkStyle interface's sheet attribute return null.

Otherwise, the LinkStyle interface's sheet attribute must return null if the corresponding element is not in a Document, and otherwise must return a StyleSheet object with the following properties: [CSSOM]

The style sheet type

The style sheet type must be the same as the style's specified type. For style elements, this is the same as the type content attribute's value, or text/css if that is omitted. For link elements, this is the Content-Type metadata of the specified resource.

The style sheet location

For link elements, the location must be the result of resolving the URL given by the element's href content attribute, relative to the element, or the empty string if that fails. For style elements, there is no location.

The style sheet media

The media must be the same as the value of the element's media content attribute, or the empty string, if the attribute is omitted.

The style sheet title

The title must be the same as the value of the element's title content attribute, if the attribute is present and has a non-empty value. If the attribute is absent or its value is the empty string, then the style sheet does not have a title (it is the empty string). The title is used for defining alternative style sheet sets.

The style sheet alternate flag

For link elements, true if the link is an alternative stylesheet. In all other cases, false.

The same object must be returned each time.

The disabled IDL attribute on link and style elements must return false and do nothing on setting, if the sheet attribute of their LinkStyle interface is null. Otherwise, it must return the value of the StyleSheet interface's disabled attribute on getting, and forward the new value to that same attribute on setting.

The rules for handling alternative style sheets are defined in the CSS object model specification. [CSSOM]


Style sheets, whether added by a link element, a style element, an PI, an HTTP Link: header, or some other mechanism, have a style sheet ready flag, which is initially unset.

When a style sheet is ready to be applied, its style sheet ready flag must be set. If the style sheet referenced no other resources (e.g. it was an internal style sheet given by a style element with no @import rules), then the style rules must be synchronously made available to script; otherwise, the style rules must only be made available to script once the event loop reaches its "update the rendering" step.

A style sheet in the context of the Document of an HTML parser or XML parser is said to be a style sheet that is blocking scripts if the element was created by that Document's parser, and the element is either a style element or a link element that was an external resource link that contributes to the styling processing model when the element was created by the parser, and the element's style sheet was enabled when the element was created by the parser, and the element's style sheet ready flag is not yet set, and, the last time the event loop reached step 1, the element was in that Document, and the user agent hasn't given up on that particular style sheet yet. A user agent may give up on a style sheet at any time.

Giving up on a style sheet before the style sheet loads, if the style sheet eventually does still load, means that the script might end up operating with incorrect information. For example, if a style sheet sets the color of an element to green, but a script that inspects the resulting style is executed before the sheet is loaded, the script will find that the element is black (or whatever the default color is), and might thus make poor choices (e.g. deciding to use black as the color elsewhere on the page, instead of green). Implementors have to balance the likelihood of a script using incorrect information with the performance impact of doing nothing while waiting for a slow network request to finish.

A Document has a style sheet that is blocking scripts if there is either a style sheet that is blocking scripts in the context of that Document, or if that Document is in a browsing context that has a parent browsing context, and the active document of that parent browsing context itself has a style sheet that is blocking scripts.

A Document has no style sheet that is blocking scripts if it does not have a style sheet that is blocking scripts as defined in the previous paragraph.

4.3 セクション

4.3.1 body要素

カテゴリ
セクショニングルート
この要素を使用できるコンテキスト
html要素の2番目の要素として。
コンテンツモデル
フローコンテンツ
コンテンツ属性
グローバル属性
onafterprint
onbeforeprint
onbeforeunload
onhashchange
onmessage
onoffline
ononline
onpagehide
onpageshow
onpopstate
onstorage
onunload
text/htmlにおけるタグ省略
要素が空である場合、またはbody要素内の最初のものが空白文字またはコメントでない場合、body要素の開始タグは省略してもよい。ただし、body要素内の最初のものがmetalinkscriptstyle、またはtemplateである場合を除く。
body要素の直前がコメントでない場合、body要素の終了タグは省略してもよい。
許可されるARIAロール属性値:
documentロール (デフォルト - 競設定しない)、application
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
許可されるロールで受け入れ可能な任意のaria-*属性。
DOMインターフェース
interface HTMLBodyElement : HTMLElement {
};
HTMLBodyElement implements WindowEventHandlers;

body要素は、文書のコンテンツを表す

適合文書では、1つのbody要素のみが存在する。document.bodyIDL属性は、文書のbody要素に簡単にアクセスできるスクリプトを提供する。

一部のDOM操作は、"body要素"という用語で定義される。これは用語の定義に従って、DOMにおける特定の要素を参照し、任意のbody要素を参照しない。

body要素は、Windowオブジェクトのイベントハンドラの数をイベントハンドラコンテンツ属性として公開する。また、それらのイベントハンドラIDL属性を反映する。

body要素で公開されるWindowオブジェクトのonbluronerroronfocusonloadonresizeおよびonscrollイベントハンドラは、通常HTML要素によってサポートされる同じ名前をもつ汎用イベントハンドラに取って代わる。

したがって、たとえば、Documentbody要素の子で送出されたわき出るerrorイベントは、要素のonerrorイベントハンドラコンテンツ属性を最初にもたらし、それからルートhtml要素のイベントハンドラコンテンツ属性、その後にbody要素のonerrorイベントハンドラコンテンツ属性をもたらすだろう。これは、イベントがターゲットから、bodyhtmlDocumentWindow、およびbodyでないWindowを見ているbody上のイベントハンドラへわき出るためである。しかし、イベントがbodyを通してわき出し、かつイベントがWindowオブジェクトに到達しない場合、addEventListener()を使用するbodyに属する通常のイベントリスナーが実行されるだろう。

このページは、ユーザーがオンラインであるかどうかを表示するインジケーターを更新する:

<!DOCTYPE HTML>
<html>
 <head>
  <title>Online or offline?</title>
  <script>
   function update(online) {
     document.getElementById('status').textContent =
       online ? 'Online' : 'Offline';
   }
  </script>
 </head>
 <body ononline="update(true)"
       onoffline="update(false)"
       onload="update(navigator.onLine)">
  <p>You are: <span id="status">(Unknown)</span></p>
 </body>
</html>

4.3.2 article要素

カテゴリ
フローコンテンツ、ただしmain要素を子孫にもたない。
セクショニングコンテンツ
パルパブルコンテンツ
この要素を使用できるコンテキスト
フローコンテンツが期待される場所。
コンテンツモデル
フローコンテンツ
コンテンツ属性
グローバル属性
text/htmlにおけるタグ省略
どちらのタグも省略不可
許可されるARIAロール属性値:
article (デフォルト - 設定しない)、 applicationdocumentまたはmain
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
許可されるロールで受け入れ可能な任意のaria-*属性。
DOMインターフェース
HTMLElementを使用する。

article要素は、文書、ページ、アプリケーション、またはサイトの中で完全もしくは自己完結した構造を表す。これは原則として、たとえばシンジケーションなど、独立して配布可能なまたは再利用可能なものである。これは、フォーラムの投稿、雑誌や新聞の記事、ブログのエントリ、ユーザーの投稿コメント、インタラクティブなウィジェットやガジェット、またはコンテンツの任意の独立した項目であるかもしれない。

article要素がネストされる場合、原則的に内側のarticle要素が外側の記事の内容に関連する記事を表す。たとえば、ユーザーの投稿コメントを受け付けるサイトのブログエントリは、ブログエントリのarticle要素内にネストされたarticle要素としてコメントを表すことができる。

article要素に関連付けられている著者の情報(address要素を参照のこと)は、ネストされたarticle要素には適用されない。

シンジケーションで再配布されるコンテンツとともに明確に使用された場合、article要素は、Atomでのentry要素の目的と類似性がある。[ATOM]

ページの主要コンテンツ(すなわちフッター、ヘッダー、ナビゲーションブロック、およびサイドバーを除く)が、すべて単一の自己完結型の構成物である場合、コンテンツはmain要素でマークアップされるべきであり、かつコンテンツはまたarticleでマークアップされてもよいが、(単一の文書であるように、ページが単一の構成物であることは自明なので)この場合は技術的に冗長である。

この例は、schema.org注釈をもつarticle要素を使用するブログ記事を示す。

<article itemscope itemtype="http://schema.org/BlogPosting">
 <header>
  <h1 itemprop="headline">The Very First Rule of Life</h1>
  <p><time itemprop="datePublished" datetime="2009-10-09">3 days ago</time></p>
  <link itemprop="url" href="?comments=0">
 </header>
 <p>If there's a microphone anywhere near you, assume it's hot and
 sending whatever you're saying to the world. Seriously.</p>
 <p>...</p>
 <footer>
  <a itemprop="discussionUrl" href="?comments=1">Show comments...</a>
 </footer>
</article>

これは同じブログの記事であるが、コメントの一部を示す:

<article itemscope itemtype="http://schema.org/BlogPosting">
 <header>
  <h1 itemprop="headline">The Very First Rule of Life</h1>
  <p><time itemprop="datePublished" datetime="2009-10-09">3 days ago</time></p>
  <link itemprop="url" href="?comments=0">
 </header>
 <p>If there's a microphone anywhere near you, assume it's hot and
 sending whatever you're saying to the world. Seriously.</p>
 <p>...</p>
 <section>
  <h1>Comments</h1>
  <article itemprop="comment" itemscope itemtype="http://schema.org/UserComments" id="c1">
   <link itemprop="url" href="#c1">
   <footer>
    <p>Posted by: <span itemprop="creator" itemscope itemtype="http://schema.org/Person">
     <span itemprop="name">George Washington</span>
    </span></p>
    <p><time itemprop="commentTime" datetime="2009-10-10">15 minutes ago</time></p>
   </footer>
   <p>Yeah! Especially when talking about your lobbyist friends!</p>
  </article>
  <article itemprop="comment" itemscope itemtype="http://schema.org/UserComments" id="c2">
   <link itemprop="url" href="#c2">
   <footer>
    <p>Posted by: <span itemprop="creator" itemscope itemtype="http://schema.org/Person">
     <span itemprop="name">George Hammond</span>
    </span></p>
    <p><time itemprop="commentTime" datetime="2009-10-10">5 minutes ago</time></p>
   </footer>
   <p>Hey, you have the same first name as me.</p>
  </article>
 </section>
</article>

(たとえば、誰がいつ書いたかなど)各コメントに対して情報を与えるためのfooterの用法に注意すること。たとえばこの場合のように、footer要素は、適切な場合にそのセクションの先頭に表示することができる。(この場合、headerの使用は、どちらも間違っていないだろう。これは主にオーサリングの好みの問題である。)

4.3.3 section要素

カテゴリ
フローコンテンツ
セクショニングコンテンツ
パルパブルコンテンツ
この要素を使用できるコンテキスト
フローコンテンツが期待される場所。
コンテンツモデル
フローコンテンツ
コンテンツ属性
グローバル属性
text/htmlにおけるタグ省略
どちらのタグも省略不可
許可されるARIAロール属性値:
regionロール (デフォルト - 設定しない)、 alertalertdialogapplicationcontentinfodialogdocumentlogmainmarqueepresentationsearchまたはstatus
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
許可されるロールで受け入れ可能な任意のaria-*属性。
DOMインターフェース
HTMLElementを使用する。

section要素は、文書またはアプリケーションの一般的セクションを表す。この文脈においてセクションは、主題を表すコンテンツのグループである。各sectionの主題は、section要素の子として見出し(h1-h6要素)を含むことによって一般に識別されるべきである。

セクションの例は、章、タブ付きのダイアログボックス内のさまざまなタブ付きページ、または論文の番号付きセクションであろう。ウェブサイトのホームページは、はしがき、ニュース、および連絡先情報のセクションに分けることができるだろう。

要素のコンテンツを配給することが理にかなう場合、著者はsection要素の代わりにarticle要素を使用するよう推奨される。

section要素は包括的なコンテナ要素ではない。要素がスタイル付け目的またはスクリプティングの便宜のために必要になった場合のみ、著者は、代わりにdiv要素を使用するよう推奨される。要素の内容が文書のアウトラインで明示的に記載されるだろう場合のみ、section要素が適切であるというのが一般的なルールである。

次の例において、2つの短いセクションを含む、リンゴについて(大規模なウェブページの一部)の記事を見てみる。

<article>
 <header>
  <h2>Apples</h2>
  <p>Tasty, delicious fruit!</p>
 </header>
 <p>The apple is the pomaceous fruit of the apple tree.</p>
 <section>
  <h3>Red Delicious</h3>
  <p>These bright red apples are the most common found in many
  supermarkets.</p>
 </section>
 <section>
  <h3>Granny Smith</h3>
  <p>These juicy, green apples make a great filling for
  apple pies.</p>
 </section>
</article>

これは、2つのセクションをもつ卒業式のプログラムであり、1つは卒業する人のリスト、もう1つは式の説明である。(この例においてマークアップは、要素間の空白の量を最小化するために使用される珍しいスタイルを特徴とする。)

<!DOCTYPE Html>
<Html
 ><Head
   ><Title
     >Graduation Ceremony Summer 2022</Title
   ></Head
 ><Body
   ><H1
     >Graduation</H1
   ><Section
     ><H2
       >Ceremony</H2
     ><P
       >Opening Procession</P
     ><P
       >Speech by Validactorian</P
     ><P
       >Speech by Class President</P
     ><P
       >Presentation of Diplomas</P
     ><P
       >Closing Speech by Headmaster</P
   ></Section
   ><Section
     ><H2
       >Graduates</H2
     ><Ul
       ><Li
         >Molly Carpenter</Li
       ><Li
         >Anastasia Luccio</Li
       ><Li
         >Ebenezar McCoy</Li
       ><Li
         >Karrin Murphy</Li
       ><Li
         >Thomas Raith</Li
       ><Li
         >Susan Rodriguez</Li
     ></Ul
   ></Section
 ></Body
></Html>

この例において、本の著者は、章と付録のようないくつかのセクションをマークアップし、異なるセクションの2つのクラスでヘッダーをスタイル付けするためにCSSを使用している。全体の本は、他の本を含むより大きな文書の一部としてarticle要素に包まれる。

<article class="book">
 <style>
  section { border: double medium; margin: 2em; }
  section.chapter h1 { font: 2em Roboto, Helvetica Neue, sans-serif; }
  section.appendix h1 { font: small-caps 2em Roboto, Helvetica Neue, sans-serif; }
 </style>
 <header>
   <h2>My Book</h2>
   <p>A sample with not much content</p>
  <p><small>Published by Dummy Publicorp Ltd.</small></p>
 </header>
  
 <section class="chapter">
  <h3>My First Chapter</h3>
  <p>This is the first of my chapters. It doesn't say much.</p>
  <p>But it has two paragraphs!</p>
 </section>
 <section class="chapter">
  <h3>It Continutes: The Second Chapter</h3>
  <p>Bla dee bla, dee bla dee bla. Boom.</p>
 </section>
 <section class="chapter">
  <h3>Chapter Three: A Further Example</h3>
  <p>It's not like a battle between brightness and earthtones would go
  unnoticed.</p>
  <p>But it might ruin my story.</p>
 </section>
 <section class="appendix">
  <h3>Appendix A: Overview of Examples</h3>
  <p>These are demonstrations.</p>
 </section>
 <section class="appendix">
  <h3>Appendix B: Some Closing Remarks</h3>
  <p>Hopefully this long example shows that you <em>can</em> style
  sections, so long as they are used to indicate actual sections.</p>
 </section>
</article>

4.3.4 nav要素

カテゴリ
フローコンテンツ
セクショニングコンテンツ
パルパブルコンテンツ
この要素を使用できるコンテキスト
フローコンテンツが期待される場所。
コンテンツモデル
フローコンテンツ、ただしmain要素を子孫にもたない。
コンテンツ属性
グローバル属性
text/htmlにおけるタグ省略
どちらのタグも省略不可
許可されるARIAロール属性値:
navigationロール(デフォルト - 設定しない)またはpresentation
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
許可されるロールで受け入れ可能な任意のaria-*属性。
DOMインターフェース
HTMLElementを使用する。

nav要素は、他のページへまたはページ内の一部へリンクするページのセクション、すなわちナビゲーションリンクをもつセクションを表す

nav要素のコンテンツが項目のリストを表す場合、理解とナビゲーションを支援するために、リストのマークアップを使用する。

ページ上のリンクのグループがnav要素である必要はない―この要素は、主要なナビゲーションブロックから成るセクションを主に対象としている。特に、サービスの条件、ホームページ、著作権ページのような、サイトのさまざまなページへの簡潔なリンクのリストをフッターが持つことは、一般的である。footer要素は単独で、このような場合に対して十分である。一方nav要素は、そのような場合に使用できるが、通常不要である。

初期のレンダリングで省略されているナビゲーション情報から利益を得ることができる、またはすぐに利用可能であるナビゲーション情報から利益を得ることができるユーザーを対象とする(スクリーンリーダーなどの)ユーザーエージェントは、ページ上のどのコンテンツに最初にスキップまたは要求(もしくはその両方)に応じて提供するかを決定する方法として、この要素を使用できる。

次の例において、ページはリンクが存在する複数の場所を持つが、そのうちの1つのみがナビゲーションセクションとみなされる。

<body itemscope itemtype="http://schema.org/Blog">
 <header>
  <h1>Wake up sheeple!</h1>
  <p><a href="news.html">News</a> -
     <a href="blog.html">Blog</a> -
     <a href="forums.html">Forums</a></p>
  <p>Last Modified: <span itemprop="dateModified">2009-04-01</span></p>
  <nav>
   <h1>Navigation</h1>
   <ul>
    <li><a href="articles.html">Index of all articles</a></li>
    <li><a href="today.html">Things sheeple need to wake up for today</a></li>
    <li><a href="successes.html">Sheeple we have managed to wake</a></li>
   </ul>
  </nav>
 </header>
 <main>
  <article itemprop="blogPosts" itemscope itemtype="http://schema.org/BlogPosting">
   <header>
    <h1 itemprop="headline">My Day at the Beach</h1>
   </header>
   <div itemprop="articleBody">
    <p>Today I went to the beach and had a lot of fun.</p>
    ...more content...
   </div>
   <footer>
    <p>Posted <time itemprop="datePublished" datetime="2009-10-10">Thursday</time>.</p>
   </footer>
  </article>
  ...more blog posts...
 </main>
 <footer>
  <p>Copyright ©
   <span itemprop="copyrightYear">2010</span>
   <span itemprop="copyrightHolder">The Example Company</span>
  </p>
  <p><a href="about.html">About</a> -
     <a href="policy.html">Privacy Policy</a> -
     <a href="contact.html">Contact Us</a></p>
 </footer>
</body>

ページの主要コンテンツを包むために使用されているmain要素に注目する。この場合、ページヘッダーとフッター以外の全てのコンテンツとなる。

ブログの記事について、公開日およびその他のメタデータを提供するためにschema.orgの語彙を使用する上記の例で、マイクロデータの注釈も見ることができる。

次の例において、2つのnav要素がある。1つはサイト周辺の主要なナビゲーションのため、もう1つはページ自身周辺の補助的なナビゲーション用である。

<body>
 <h1>The Wiki Center Of Exampland</h1>
 <nav>
  <ul>
   <li><a href="/">Home</a></li>
   <li><a href="/events">Current Events</a></li>
   ...more...
  </ul>
 </nav>
 <main>
  <header>
   <h1>Demos in Exampland</h1>
   <p>Written by A. N. Other.</p>
  </header>
  <nav>
   <ul>
    <li><a href="#public">Public demonstrations</a></li>
    <li><a href="#destroy">Demolitions</a></li>
    ...more...
   </ul>
  </nav>
  <div>
   <section id="public">
    <h1>Public demonstrations</h1>
    <p>...more...</p>
   </section>
   <section id="destroy">
    <h1>Demolitions</h1>
    <p>...more...</p>
   </section>
   ...more...
  </div>
  <footer>
   <p><a href="?edit">Edit</a> | <a href="?delete">Delete</a> | <a href="?Rename">Rename</a></p>
  </footer>
 </main>
 <footer>
  <p><small>© copyright 1998 Exampland Emperor</small></p>
 </footer>
</body>

nav要素はリストを含める必要はなく、同様に他の種類のコンテンツを含むことができる。このナビゲーションブロックにおいて、リンクは文で提供されている:

<nav>
 <h1>Navigation</h1>
 <p>You are on my home page. To the north lies <a href="/blog">my
 blog</a>, from whence the sounds of battle can be heard. To the east
 you can see a large mountain, upon which many <a
 href="/school">school papers</a> are littered. Far up thus mountain
 you can spy a little figure who appears to be me, desperately
 scribbling a <a href="/school/thesis">thesis</a>.</p>
 <p>To the west are several exits. One fun-looking exit is labeled <a
 href="http://games.example.com/">"games"</a>. Another more
 boring-looking exit is labeled <a
 href="http://isp.example.net/">ISP™</a>.</p>
 <p>To the south lies a dark and dank <a href="/about">contacts
 page</a>. Cobwebs cover its disused entrance, and at one point you
 see a rat run quickly out of the page.</p>
</nav>

4.3.5 aside要素

カテゴリ
フローコンテンツ
セクショニングコンテンツ
パルパブルコンテンツ
この要素を使用できるコンテキスト
フローコンテンツが期待される場所。
コンテンツモデル
フローコンテンツ、ただしmain要素を子孫にもたない。
コンテンツ属性
グローバル属性
text/htmlにおけるタグ省略
どちらのタグも省略不可
許可されるARIAロール属性値:
complementaryロール(デフォルト - 設定しない)、notesearchまたはpresentation
許可されるARIAステートおよびプロパティー
グローバルaria-* 属性
許可されるロールで受け入れ可能な任意のaria-*属性。
DOMインターフェース
HTMLElementを使用する。

aside要素は、aside要素の周りにコンテンツとわずかに関連し、かつそのコンテンツから分離すると見なすことができるコンテンツで構成されるページのセクションを表す。このようなセクションは、しばしば活版印刷でサイドバーとして表