HTML5日本語訳
HTMLとXHTMLのための語彙と関連API
HTMLとXHTMLのための語彙と関連API
この節は非規範的である。
ワールドワイドウェブのマークアップ言語は、常にHTMLであった。長年にわたるHTMLの普遍的な設計と改良は、多岐にわたる文書形式を記述するために使用するHTMLを可能にしたが、HTMLは本来セマンティックに科学的な文書を記述するための言語として設計されたものであった。
HTMLによって適切に処理されてない主な領域は、ウェブアプリケーションと呼ばれる曖昧な問題である。この仕様は、過去数年間で提起された問題に対処するためにHTML仕様を更新しつつ、同時にこれを修正しようと試みる。
この節は非規範的である。
この仕様は、この仕様で定義された機能を使用する文書およびスクリプトの著者を対象としている, 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の理解も随所で役立つだろうが、必須ではない。
この節は非規範的である。
この仕様は、静的な文書から動的なアプリケーションに至るまで、ウェブ上でアクセシブルなページにセマンティックレベルのマークアップ言語と関連付けられた、セマンティックレベルのスクリプトAPIを提供することに限定される。
この仕様の範囲は、外観のメディア固有なカスタマイズに対するメカニズムの提供を含まない（ただし、ウェブブラウザデフォルトのレンダリング規則はこの仕様の末尾に含まれ、またCSSに結びつけるための複数のメカニズムが言語の一部として提供される）。
この仕様の範囲は、オペレーティングシステム全体を記述することではない。具体的には、ハードウェア設定ソフトウェア、画像処理ツール、ユーザーが毎日のようにハイエンドなワークステーションで使用することが予想されるアプリケーションが範囲外である。アプリケーションの観点から、この仕様は、不定期にユーザーによって、または定期的だが低いCPU要件とともに異なる場所からの使用が予想されるアプリケーションを特に対象とする。そのようなアプリケーションの例は、オンライン購買システム、検索システム、ゲーム（特に多人数参加型オンラインゲーム）、公衆電話帳やアドレス帳、通信ソフトウェア（電子メールクライアント、インスタントメッセージクライアント、ディスカッションソフトウェア）、文書編集ソフトなどを含む。
この節は非規範的である。
最初の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]
この節は非規範的である。
一見しただけでは、HTMLの多くの特徴がでたらめであり一貫性のないように見えることを認めなければならない。
HTML、HTMLのDOM APIのサポート、およびHTMLのサポートする技術の多くは、多くの場合、互いの存在を知らない、異なる優先順位をもつ多数の人々により数十年にわたって開発されてきた。
このように機能は多くの出典から生じており、とりわけ一貫性のある方法で設計されていない。さらに、ウェブの特有な特性により、バグが修正される前にバグに依存する方法でコンテンツがしばしば意図せず書かれるため、実装バグはたびたびデファクトスタンダードになっており、今ではデジュールスタンダードになっている。
そのような状況にもかかわらず、一定の設計目標に執着する試みがなされている。これらは、次節で説明する。
この節は非規範的である。
ウェブ著者をマルチスレッド処理の複雑さに触れさせることを回避するために、HTMLとDOM APIは、スクリプトが他のスクリプトの同時実行を検出しないように設計されている。ワーカーと等しい、実装の動作がすべてのブラウジングコンテキスト内におけるすべてのスクリプトの実行を完全に逐次化すると考えることができるのが意図するところである。
このモデルにおいて、navigator.yieldForStorageUpdates()メソッドは、呼び出し元のスクリプトがブロックされている間に、他のスクリプトが実行できるようにすることと等価である。
この節は非規範的である。
この仕様は、多種多様な他の仕様と互いに影響しあい、依存する。残念ながら特定の状況において、矛盾する要求は、これら他の仕様に属する要件の違反をこの仕様に導く。この違反が発生した時はいつでも、違反はそれぞれ"故意の違反"として言及され、違反の理由が指摘される。
この節は非規範的である。
HTMLは、安全な方法でセマンティックを追加するために使用できる拡張性メカニズムを多数持つ：
class属性を使用できる。そのため拡張を知らないブラウザおよび他のツールは多少でも適切にサポートできる。たとえば、これはマイクロフォーマットで使用される方針である。data-*=""属性を使用して処理するための、インラインのクライアントサイドスクリプトまたはサイト全体のサーバーサイドスクリプトのデータを含むことができる。これらは決してブラウザによって触れられないことが保証され、スクリプトが探すおよび実行できるHTML要素でデータをスクリプトに含むことを可能にする。<meta name="" content="">メカニズムを使用できる。rel=""メカニズムを使用できる。これは、マイクロフォーマットでも使用される。さらに、非ASCII文字を一切含まず、U+0041（LATIN CAPITAL LETTER A）からU+005A（LATIN CAPITAL LETTER Z）までの範囲の文字もまた含まない絶対URLは、リンクタイプとして使用してもよい。<script type="">メカニズムを用いて生データを埋め込むことができる。embed要素を用いて呼び出すことができる。これは、Flashの動作方法である。この節は非規範的である。
この仕様は、文書やアプリケーションを記述するための抽象的な言語、およびその言語を使用するリソースのメモリ内表現と情報交換するための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でのみ表すことができる。
この節は非規範的である。
この仕様は以下の主要な章で構成される：
旧式の機能およびIANA考慮のリストといった付録も存在する。
この仕様は、他の仕様同様に読むべきである。まず、表紙から終わりまで複数回読むべきである。そして、少なくとも1回は後ろから読むべきである。それからコンテンツのリストからランダムに章を選び、すべての相互参照をたどって読むべきである。
下記の適合性要件の章で説明されるように、この仕様は、適合性の様々なクラスの適合基準を記述している。具体的には、たとえば著者および著者が作成した文書といったプロデューサに適用される適合性の要件と、たとえばウェブブラウザといった、コンシューマに適用される適合性要件がある。これらは、必要としているものによって区別することができる。プロデューサに対する要件は許可されるものを記載し、一方でコンシューマに対する要件はどのようにソフトウェアが動作するかを記載する。
たとえば、許可された値をレイアウトするとして、"foo属性の値が妥当な整数でなければならない"というのはプロデューサについての要件である。対照的に、"fooの属性の値が構文解析の整数のための規則を使用して解析しなければならない"というのはコンシューマに対する要件であり、コンテンツを処理する方法について説明する。
プロデューサについての要件は、コンシューマにまったく何の関係もない。
上記の例を続けると、特定の属性値が妥当な整数として拘束されているという要件は、コンシューマの要件について何かを意味するものではまったくない。コンシューマが実際に不明な文字列として属性を扱うことを要求し、その値が要件か否かに準拠しているかどうかにまったく影響しないかもしれない。コンシューマが、妥当な（この場合は数でない）値が処理される方法を定義する特定の規則を使用して値を解析することが（前の例のように）必要であるかもしれない。
これは、定義、要件、または説明である。
これは注である。
これは例である。
これは 未解決の問題である。
これは警告である。
interface Example {
// これはIDLの定義である
};
method( [ optionalArgument ] )これはインターフェースの使用法を著者に説明する注である。
/* これはCSS断片である */
用語の定義例はこのようにマークアップされる。その用語の使用は、このようにまたはこのようにマークアップされる。
要素、属性、またはAPIの定義例はこのようにマークアップされる。その要素、属性、またはAPIへの参照は、このようにマークアップされる。
その他のコード断片は、このようにマークアップされる。
変数は、このようにマークアップされる。
アルゴリズムにおいて、同期セクションでのステップは、⌛でマークされる。
場合によっては、要件は条件と対応する要件とともにリストの形で与えられる。このような場合、たとえ要件に対する条件の複数の集合である場合であっても、条件に適用される要件は常に、条件に従う要件の最初の集合である。次のようにこのような例が提示される：
この節は非規範的である。
HTMLの一部の機能は、ユーザーのプライバシー保護対策とユーザーの利便性を引き替えにする。
一般に、インターネットのアーキテクチャのために、ユーザーは、ユーザーのIPアドレスで区別できる。IPアドレスは、完全にユーザーと一致しない。デバイスからデバイスへ、またはネットワークからネットワークへのユーザーの移動に伴い、ユーザーのIPアドレスは変更される。同様に、NATルーティング、プロキシサーバー、共有コンピュータは、実際には複数のユーザーに対応する単一のIPアドレスからすべて来るように見えるパケットを有効にする。インターネット上の1つのノードにおけるシングルユーザーからの要求は、ネットワークの多くの異なる部分から来るように見えるので、たとえばオニオンルーティングのような技術はリクエストをさらに匿名にするために使用できる。
しかし、ユーザーのリクエストに使用されるIPアドレスは、ユーザーのリクエストが互いに関連する可能性のある唯一のメカニズムではない。たとえばクッキーは、これを有効にするために特別に設計されており、アカウントを持つサイトにログインできるようにする大部分のウェブセッション機能の基礎である。
より繊細なメカニズムが存在する。ユーザーシステムのある種の特性は、互いにユーザーのグループを区別するために使用できる。そのような情報を十分に収集することによって、個別ユーザーのブラウザの"デジタル指紋"は、より優れているとは言わないまでも同じくらいに良く、リクエストが同じユーザーからのものであるかを確かめることができるIPアドレスとして、計算できる。
特に複数のサイト間で、この方法でのグループ化のリクエストは、両者にとって有益な（かつほぼ間違いなく前向きな）目的だけでなく、悪意ある目的に対して使用できる。合理的で有益な目的の例は、特定の人が猫のイラストがあるサイトとは対照的に、犬のイラストを使ったサイトを好むように見えるかどうかを（問題のサイトを訪問する頻度に基づいて）判断し、自動的に参加サイトへのその後の訪問に優先的にイラストを使用するものである。しかし、悪意ある目的は、その人が選挙で投票することを妨害すべきかどうかを決定するために（参加フォーラムサイトを調べることによって決定される）明確な所属政党を持つ（1つサイト上で道順を取得する際に使用するアドレスから決定される）そのような自宅住所と組み合わせる政府機関を含むかもしれない。
悪意ある目的が著しく有害であるかもしれないので、ユーザーエージェントの実装は、指紋ユーザーに慣れているだろう情報の漏洩を最小限にするためのツールとともにユーザーに提供する方法を検討することを推奨する。
残念ながら、この節の最初の段落が暗示するように、単純にすべて可能性のある漏洩を遮断するのと同じくらい簡単ではないので、時として指紋採取の目的で使用できる情報でさえも公開することで得られる多数の利点がある。たとえば、特定のIDの下で投稿するサイトにログインする機能は、定義により多かれ少なかれ、ユーザーの要求がすべて同じユーザーからのものとして識別することを要求する。しかし、より微細に、どの程度広いテキストであるかのような情報は、キャンバス上にテキストを描画するのに関係する多くの効果（たとえば、テキストの周りにボーダーを描画するのに関係する任意の効果など）に対して必要であり、ユーザーのリクエストをグループ化するために使用されるだろう情報も漏洩する。（この場合において、潜在的に公開することで、力任せの検索を通して、ユーザーがインストールしているフォント、ユーザーごとにかなり変動し得る情報。）
ユーザーの指紋採取に使用されるかもしれないこの仕様の機能は、この段落のようにマークされる。
プラットフォーム内の他の機能は、以下を含むけれども限定されることなく、同じ目的に対して使用されるかもしれない：
Screenオブジェクトのような、ユーザーの環境を説明する機能。[MQ] [CSSOMVIEW]この節は非規範的である。
基本的な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ツリーに変換される：
htmlhtmlこのツリーのルート要素はhtml要素である。HTML文書のルートに見られる要素は常にhtml要素である。headとbodyの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を使用するかの詳細について、著者はチュートリアルとガイドを参考にするよう促される。この仕様に含まれている例の一部も役立つかもしれないが、やむを得ず最初は理解しにくいかもしれない詳細なレベルで言語を定義することに初心者は注意すること。
この節は非規範的である。
HTMLがインタラクティブなサイトを作成するために使用される場合、攻撃者がサイト自身またはサイトのユーザーの整合性を危険にさらすことを通して脆弱性をもたらすのを避けるような配慮が必要である。
この問題の包括的な研究は、この文書の範囲を超える。また著者は、より詳細に問題を研究することを強く促す。ただし、この節は、HTMLアプリケーション開発における一般的な落とし穴について簡単な手引きの提供を試みる。
ウェブのセキュリティモデルは"origin"の概念に基づいており、それに対応してウェブ上で潜在的な攻撃の多くは、cross-originな振る舞いを伴うとされる。[ORIGIN]
たとえばテキストコメントのようなユーザーが生成したコンテンツ、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コマースショップであれば、スクリプトによってユーザーの知らないうちに勝手に多くの不要な買い物をする可能性がある。
これは、クロスサイトスクリプティング攻撃と呼ばれている。
コードを実行させるサイトをだまそうとするために使用できる多くの構成要素がある。著者がホワイトリストのフィルタを書く場合に考慮が促されるいくつかのものがある：
imgのような無害のように思える要素を許可する場合、同様に、与えられた属性をホワイトリストに登録することが重要である。たとえば、imgがすべての属性を許可する場合、攻撃者は、任意のスクリプトを実行するためにonload属性を使用できる。javascript:"だが、ユーザーエージェントは他のものを実装することができる（そして実際、歴史的に実装している）。base要素を挿入できるようにすることは、相対的なリンクを持つページでの任意のscript要素がハイジャックされる可能性があり、同様に任意のフォームの提出が敵対サイトにリダイレクトされてしまうことを意味する。たとえば、ユーザー名でフォーラムにメッセージを投稿する、購入する、またはパスポートの申請するなど、サイトがユーザーに対してユーザー固有の副作用を伴うフォーム送信を行うことを許可する場合、他のサイトによってユーザーを無意識にリクエストするようにだますよりかはむしろ、意図的にユーザーによって行われたことを確認するのが重要である。
HTMLフォームが他の生成元に送信できるため、この問題は存在する。
サイトは、ユーザー固有な秘密のトークンを使用してフォームを生成する、またはすべての要求にOriginヘッダーをチェックしてそのような攻撃を防ぐことができる。
ユーザーが望まないだろう振る舞いを実行するインターフェースをユーザーに提供するようなページは、ユーザーがアクティブなインターフェースでだまされる可能性を回避するように設計する必要がある。
たとえば、敵対的なサイトが小さなiframeを被害者のサイトに配置し、ユーザーがリアクションゲームをプレイすることによって、クリックするようユーザーにさせる場合、ユーザーをだます一つの手段である。ひとたびユーザーがゲームをプレイすると、敵対サイトはユーザーがクリックしようとすると同時にマウスカーソルの下にiframeを配置できる。こうして被害者サイトのインターフェースをクリックするようにユーザーをだます。
これを回避するために、フレームに使用されることを予想しないサイトは、（たとえばtop属性の値にwindowオブジェクトを比較することによって）フレームにないことを検出した場合のみ、それらのインターフェースを有効にすることを促進する。
この節は非規範的である。
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>
この節は非規範的である。
著者は、よく目にする誤りを見つける適合性チェッカー（バリデータとも呼ばれる）を利用することが推奨される。W3Cは、Nu Markup Validation Serviceを含む、多くのオンライン検証サービスを提供する。
この節は非規範的である。
HTML仕様の以前のバージョンとは異なり、この仕様は、妥当な文書向け同様に、妥当でない文書の詳細な必要な処理を定義する。
しかし、妥当でないコンテンツの処理は、ほとんどの場合明確に定義されるけれども、文書のための適合要件は依然として重要である。実際には、相互運用性（すべての実装が、信頼性と同一または同等の方法で特定のコンテンツを処理している状況）は、文書適合要件の唯一の目標ではない。この節は、適合文書とエラーをもつ文書を区別するための、より一般的な理由の一部を列挙する。
この節は非規範的である。
もはや以前のHTMLバージョンからのプレゼンテーション的な機能のほとんどを使用できない。一般にプレゼンテーション的なマークアップは、多くの問題を有することが見出されている：
ユーザー支援技術（AT）に満足な体験（たとえばARIAを用いて）を提供する方法でプレゼンテーション的なマークアップを使用することは可能だが、セマンティックに適切なマークアップを用いる場合よりも著しく困難である。さらに、たとえそのような技術を用いても、テキストモードブラウザのユーザーのような、AT以外の非グラフィカルユーザー向けのページをアクセシブルにする助けにはならない。
その一方で、メディアに依存しないマークアップの使用は、多くのユーザー（たとえばテキストブラウザ）に機能するよう作成される文書向けの容易な手段を提供する。
マークアップがスタイルに依存しない方法で書かれるサイトの維持は大幅に容易である。たとえば、<font color="">を使用してサイトの色を変更すると、サイト全体にわたっての変更が必要になるのに対し、CSSに基づくサイトは同様の変更を単一のファイルの変更によって可能である。
プレゼンテーション的なマークアップは、きわめて冗長になる傾向がある。したがって、より大きな文書サイズとなる。
このためこのバージョンでは、プレゼンテーション的なマークアップはHTMLから削除された。この変化は驚くべきものではない。HTML4は何年も前にプレゼンテーション的なマークアップを非推奨とし、著者がプレゼンテーション的なマークアップからの脱却を支援するモード（HTML4 Transitional）を提供した。後に、XHTML 1.1は一段と踏み込み、完全にそれらの機能を廃止した。
HTMLで唯一残っているプレゼンテーション的なマークアップ機能は、style属性とstyle要素である。style属性の使用は本番環境で推奨されないが、ラピッドプロトタイピング（そのルールが直接後で別のスタイルシートに移動することができる）、および独立したスタイルシートが不便である他とは異なる場合での特定のスタイルを提供するのに役立つ。同様に、style要素は、配信またはページ固有のスタイルに有用であるが、一般にスタイルを複数ページに適用する場合、外部スタイルシートはより使いやすそうである。
また、以前にプレゼンテーション的であった一部の要素がメディアに依存しないよう、この仕様で再定義されていることは注目すべきである：b、i、hr、s、smallおよびu。
この節は非規範的である。
HTMLの構文は、さまざまな問題を回避するために拘束されている。
特定の妥当でない構文構造が解析されるとき、高度に直感的でないDOMツリーをもたらす。
より奇妙で複雑なエラー処理規則を実装することなく、制御された環境で使用できるようにするため、ユーザーエージェントは解析エラーに遭遇した場合に失敗が許可される。
前述した<table><hr>...のような例に対する振る舞いなど、一部のエラー処理動作は、ストリーミングのユーザーエージェント（状態を保存することなく、1回のパスでHTMLファイルを処理するユーザーエージェント）と互換性がない。そのようなユーザーエージェントとの相互運用性の問題を回避するために、そのような振る舞いに起因するいかなる構文も妥当でないと見なされる。
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©"を意図せず、実際には"?art©"となる。なぜならば最後のセミコロンがなく、"©"は"©"と同様に扱われ、したがって"©"として解釈される：
<a href="?art©">Art and Copy</a>
この問題を回避するため、すべての指定文字参照はセミコロンで終了する必要があり、セミコロンなしの指定文字参照の使用は、エラーとしてフラグ付けされる。
よって、上記の例を表現するためのふさわしい方法は、次のとおり：
<a href="?bill&ted">Bill and Ted</a> <!-- &tedは指定文字参照でないのでOK -->
<a href="?art&copy">Art and Copy</a> <!-- ©は指定文字参照なので、&はエスケープされる必要がある -->
特定の構文構造は、レガシーユーザーエージェントでは特に微妙または重大な問題を引き起こすことが知られており、したがって著者が回避するのを助けるために不適合としてマークされる。
たとえば、これは"`"（U+0060）文字が引用符なしの属性で許可されない理由となる。特定のレガシーユーザーエージェントでは、 これは時に引用符として扱われる。
一定の制限は、純粋に既知のセキュリティ問題を回避するために存在している。
たとえば、UTF-7を使用する上での制限事項は、UTF-7を用いた既知のクロスサイトスクリプティング攻撃に対して純粋に著者が犠牲になるのを避けるために存在している。[UTF7]
著者の意図が極めて不明確であるマークアップは、多くの場合不適合とされる。このエラーの早期の修正が以降のメンテナンスをより容易にする。
ユーザーが単純なタイプミスをした場合、エラーが早期に発見できれば手助けとなり、デバッグに要する時間を大幅に節約できるだろう。したがってこの仕様は、この仕様で定義される名前と一致しない要素名、属性名、およびその他の使用をエラーとみなす。
たとえば、著者が<caption>の代わりに<capton>を入力した場合、これをエラーとしてフラグ付けすれば、著者はすぐにタイプミスを修正できるだろう。
言語構文は、将来的に拡張できるようにするために、特定のその他の無害な機能を禁止している。
たとえば、終了タグの"属性"は現在無視され、むしろ妥当でなく、将来に言語が変更する場合は、既に展開された（かつ妥当な）コンテンツと競合することなく、その構文機能の利用を整える。
一部の著者は、常にすべての属性を引用符でくくる、および任意のタグを含む習慣が有益であること見いだし、HTML構文の柔軟性を利用することによって与えられる簡潔さの小さな利益を乗り越えて、そのような習慣に由来する堅牢性を好む。そうした著者を支援するため、適合性チェッカーは、このような規則が適用される動作モードを提供できる。
この節は非規範的である。
言語構文の範囲を超えて、この仕様は要素や属性を指定できる方法も制限する。この制限は、同様の理由で存在している：
定義済みの意味を持つ要素の誤用を避けるために、コンテンツモデルは、入れ子があいまいな値を持つだろう場合の、要素が入れ子にすることができる方法の制限が定義される。
たとえば、著者がセクション全体がキー入力すべきであると示すことはまずないため、この仕様は、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属性は、実際には同義なものとしてcircとcircleの値の両方を受け入れるにもかかわらず、チュートリアルやその他の学習補助を平易にするよう、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要素内に実行可能なスクリプトを不適合とする。これは、文書を検証する著者が、この種の誤りとともに時間を無駄にする可能性を低くすることを意味する。
一部の著者は、XMLとHTMLの両方で同様の結果に解釈可能なファイルを書くことを好む。この習慣は無数の微妙な困難さ（特にスクリプト、スタイル、または自動化されたシリアライゼーションの任意の種類を含む場合）のために一般的に推奨されないけれども、この仕様は、少なくとも多少の困難の軽減を意図するいくつかの制約がある。これは、著者がHTMLとXHTMLとの間で移行する場合に過渡的な段階として容易に使用できるようにする。
たとえば、langとxml:langという属性が2つの同期を維持することを目的とするやや複雑な規則がある。
もう一つの例は、適合文書中の要素が、HTMLまたはXMLとして処理したかどうか、同じ名前空間に終わることの確認を意図されるようなHTMLシリアライゼーションでxmlns属性の値を制限するだろう。
言語の今後の改正で新しい構文を可能にするために意図された構文の制限と同様に、要素や属性値の内容モデルに対する一部の制限は、HTML語彙の将来の拡張を可能にするために意図されている。
たとえば、"_"（U+005F）の文字で始まるtarget属性値を特定の事前に定義された値のみに制限することは、新たな事前定義された値を、著者が定義した値と競合することなく将来の時点で導入することができる。
一定の制約は他の仕様によって作られた制約のサポートを意図する。
たとえば、メディアクエリを取る属性が妥当なメディアクエリのみの使用を要求することは、その仕様の適合規則に従うことの重要性を強調している。
この節は非規範的である。
以下の文書は、この仕様書の読者が興味をもつかもしれない。
このアーキテクチャの仕様は、Unicode標準とISO/IEC 10646で共同定義した国際文字集合として、ウェブ上で相互運用可能なテキスト操作のための共通の基準を仕様書の著者、ソフトウェア開発者、およびコンテンツ開発者に提供する。テーマは、用語'文字'、'エンコーディング'および'文字列'の使用、参照処理モデル、文字エンコーディングの識別と選択、文字エスケープ、および文字列の索引付けを含む対処である。
Unicodeは極めて多数の文字を含み、世界の様々な書記体系を包含するため、誤った使用方法は、プログラムやシステムをセキュリティ攻撃にさらす可能性がある。次々に製品は国際化されるので、これは特に重要である。この文書は、プログラマ、システムアナリスト、規格の開発者、およびユーザーが考慮すべきセキュリティ上の考慮事項の一部について説明し、問題のリスクを軽減するために明確な推奨事項を提供する。
ウェブコンテンツ・アクセシビリティー・ガイドライン（WCAG）2.0は、ウェブコンテンツをよりアクセシブルにするための幅広い推奨事項を扱う。このガイドラインに従うことにより、失明や弱視、ろうおよび難聴、学習障害、認知制限、運動制限、言語障害、光線過敏症およびこれらの組み合わせを持つ人々の広い範囲にアクセシブルなコンテンツを提供できる。このガイドラインに従うことはまた、多くの場合一般のユーザーに対してウェブコンテンツをより使いやすくする。
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.
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.
ポリグロットマークアップを使用する文書は、HTMLとして処理およびXMLとして処理された場合に、（ルート要素のxmlns属性を除く）同一の文書ツリーに解析されたバイトストリームである文書である。定義された制約のセットを満たすポリグロットマークアップは、HTML5の仕様を通して、HTMLとしてまたはXHTMLとして処理されるかどうかにかかわらず、互換性があると解釈される。ポリグロットマークアップは、特定のDOCTYPE、名前空間宣言、および特定の活字ケース―通常は小文字だが、時折キャメルケース（先頭文字を大文字）―を要素名や属性名に用いる。ポリグロットマークアップは、特定の属性値に小文字を使用する。さらに、空要素、指定実体参照、およびスクリプトとスタイルの使用に関する制約を含む。
これは、HTML要素と属性をさまざまなプラットフォーム上でのアクセシビリティーAPIロール、ステートおよびプロパティーに割り当てたドラフト文書である。これは、HTML要素にアクセシブルな名前と説明を見いだす上での勧告を提供する。また、アクセシブルな機能の実装例を示す。