HTML: The Living Standard
Edition for Web Developers — Last Updated 19 April 2024
Edition for Web Developers — Last Updated 19 April 2024
一口に言えば：はい。
より長くは：用語"HTML5"は、広範にモダンなウェブ技術を参照するための流行語として使用され、（決してすべてではないけれども）その多くはWHATWGで開発されている。この文書は、その1つである。他の文書は、WHATWG specification overviewから利用可能である。
HTMLは、ワールドワイドウェブの中核となるマークアップ言語である。そもそも、HTMLは本来セマンティックに科学的な文書を記述するための言語として設計されたものであった。しかし、長年にわたるHTMLの普遍的な設計は、多岐にわたる文書およびアプリケーションでさえもを記述するために適応するHTMLを可能にした。
この仕様は、この仕様で定義された機能を使用する文書およびスクリプトの著者を対象としている。
正確さのためのわかりやすさや、完全性のための簡潔さを犠牲にする場所において、おそらくこの文書は、少なくともウェブ技術について十分な知識を持たない読者には適さない。よりわかりやすいチュートリアルやオーサリングガイドが、より易しい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サイトのバージョンでは制限の少ないライセンスを維持した。
長年にわたり、両グループは一緒に働いてきた。しかし、2011年に両グループは、異なる目標を持っていたという結論に達した：WHATWGは、既知の問題とともに状態でそれを凍結するよりもむしろ連続的に仕様を維持し、プラットフォームを進化させ必要に応じて新しい機能を追加することで、HTMLに対する生きている標準の作業を続けたがっていた一方で、W3Cは"HTML5"の"完成"バージョンを公開したがっていた。
2019年にWHATWGとW3Cは、今後HTMLの単一バージョンに関して共同作業を行う協定に署名した。それがこの文書である。
一見しただけでは、HTMLの多くの特徴がでたらめであり一貫性のないように見えることを認めなければならない。
HTML、HTMLのDOM APIのサポート、およびHTMLのサポートする技術の多くは、多くの場合、互いの存在を知らない、異なる優先順位をもつ多数の人々により数十年にわたって開発されてきた。
このように機能は多くの出典から生じており、とりわけ一貫性のある方法で設計されていない。さらに、ウェブの独特の特性により、バグが修正される前にバグに依存する方法でコンテンツがしばしば意図せず書かれるため、実装バグはたびたびデファクトスタンダードになっており、今ではデジュールスタンダードになっている。
そのような状況にもかかわらず、一定の設計目標に執着する試みがなされている。これらは、次節で説明する。
この仕様は、多種多様な他の仕様と互いに影響しあい、依存する。残念ながら特定の状況において、矛盾する要求は、これら他の仕様に属する要件の違反をこの仕様に導く。この違反が発生した時はいつでも、違反はそれぞれ"故意の違反"として言及され、違反の理由が指摘される。
HTMLは、安全な方法でセマンティックスを追加するために使用できる広範な配列の拡張性メカニズムを持つ：
著者は、最も適切な既存の"本物の"HTML要素を使用しつつ、効果的に独自の要素を作成する、要素を拡張するためのclass属性を使用できる。そのため拡張を知らないブラウザーおよび他のツールは多少でも適切にサポートできる。たとえば、これはマイクロフォーマットで使用される方針である。
著者は、data-*=""属性を使用して処理するための、インラインのクライアントサイドスクリプトまたはサイト全体のサーバーサイドスクリプトのデータを含むことができる。これらは決してブラウザーによって触れられないことが保証され、スクリプトが探すおよび実行できるHTML要素でデータをスクリプトに含むことを可能にする。
著者は、ページ全体のメタデータを含む<meta name="" content="">メカニズムを使用できる。
著者は、リンクタイプの定義済み集合の拡張を登録することにより、特定の意味を持つリンクに注釈を付けるrel=""メカニズムを使用できる。これは、マイクロフォーマットでも使用される。
著者は、インラインまたはサーバーサイドスクリプトによるさらなる処理のためのカスタムタイプとともに、<script type="">メカニズムを用いて生データを埋め込むことができる。
著者は、JavaScriptプロトタイピングのメカニズムを使用してAPIを拡張することができる。たとえば、これは、広くスクリプトライブラリーによって使用される。
著者は、他のアプリケーションおよびサイトで共有するデータのネストされた名前-値ペアを埋め込むためにマイクロデータ機能（itemscope=""およびitemprop=""属性）を使用することができる。
著者は、カスタム要素を定義、共有、使用して、HTMLの語彙を拡張することができる。妥当なカスタム要素名の要件は、前方互換性を保証する（将来、ハイフンを含むローカル名を持つHTML、SVG、またはMathMLに要素が追加されなくなるため）。
この仕様は、文書やアプリケーションを記述するための抽象的な言語、およびその言語を使用するリソースのメモリー内表現と情報交換するためのAPIを定義する。
メモリー内表現は略して"DOM HTML"、または"DOM"として知られている。
この抽象的な言語を使用するリソースを送信するために使用できる種々の具体的な構文が存在し、この仕様で定義されるものが2つ存在する。
1つ目のそのような具体的な構文は、HTML構文である。これは、ほとんどの著者のための推奨される形式であり、ほとんどのレガシーウェブブラウザーと互換性がある。文書がtext/html MIMEタイプで送信される場合、ウェブブラウザーによってHTML文書として処理される。この仕様は"HTML"として知られる最新のHTML構文を定義する。
2つ目の具体的な構文は、XML構文である。文書がapplication/xhtml+xmlのようなXML MIMEタイプで送信される場合、ウェブブラウザーによりXML文書として処理され、XMLプロセッサーにより解析される。著者は、XMLとHTMLの処理が異なることに注意する。とりわけ、些細な構文エラーが、XMLとしてラベル付けされた文書を完全にレンダリングするのを中止させることに注意する。一方、HTML構文では無視される。
HTMLのためのXML構文は、以前に"XHTML"と呼ばれていたが、この仕様ではその用語を使用しない（他にも理由はあるが、MathMLやSVGのHTML構文にそのような用語は使用されないため）。
DOM、HTML構文、およびXML構文は、すべて同じコンテンツを表すことはできない。たとえば、名前空間はHTML構文を使用して表現できないが、DOMとXML構文でサポートされる。同様に、noscriptの機能を使用する文書は、HTML構文を使って表すことができるが、DOMまたはXML構文で表すことができない。文字列"-->"が含まれるコメントは、HTMLとXML構文では表せず、DOMでのみ表すことができる。
この仕様は以下の主要な章で構成される：
EventSourceとして知られるサーバープッシュなイベントストリームメカニズム、およびWeb Socketsとして知られるスクリプトに対する双方向全二重ソケットプロトコルを導入する。旧式の機能およびIANA考慮のリストといった付録も存在する。
これは、定義、要件、または説明である。
これは注である。
これは例である。
これは未解決の問題である。
これは警告である。
variable = object.method([optionalArgument])これはインターフェイスの使用法を著者に説明する注である。
/* これはCSS断片である */ 用語の定義例はこのようにマークアップされる。その用語の使用は、このようにまたはこのようにマークアップされる。
要素、属性、またはAPIの定義例はこのようにマークアップされる。その要素、属性、またはAPIへの参照は、このようにマークアップされる。
その他のコード断片は、このようにマークアップされる。
変数は、このようにマークアップされる。
場合によっては、要件は条件と対応する要件とともにリストの形で与えられる。このような場合、たとえ要件に対する条件の複数の集合である場合であっても、条件に適用される要件は常に、条件に従う要件の最初の集合である。次のようにこのような例が提示される：
基本的なHTML文書は次のようになる：
<!DOCTYPE html>
< html lang = "en" >
< 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 > 属性は開始タグの内部に置かれ、"="文字で区切られた名前と値で構成される。属性値がASCII空白文字または任意の" ' ` = < >を含まない場合、属性値は引用符で囲まないままにできる。そうでなければ、単一引用符または二重引用符のいずれかを使用して、引用符で囲む必要がある。値が空文字列の場合、"="文字とともに値を完全に省略できる。
<!-- 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要素となる。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 ]; // obtain the first link in the document
a. href = 'sample.html' ; // change the destination URL of the link
a. protocol = 'https' ; // change just the scheme part of the URL
a. setAttribute( 'href' , 'https://example.com/' ); // change the content attribute directly HTML文書が実装（特にウェブブラウザーのような対話的な実装）によって処理および表示されるときに、HTML文書を表現するための手段としてDOMツリーは使用されるので、この仕様では、大部分が上記のマークアップの代わりにDOMツリーの用語で記述される。
HTML文書は、メディアに依存しない対話的なコンテンツの記述を表す。HTML文書は、画面で、音声シンセサイザーを通して、または点字ディスプレイでレンダリングされるかもしれない。そのようなレンダリングが行われる方法に影響を与えるために、著者はCSSなどのスタイル言語を使用できる。
次の例において、CSSを使用するページは、青地に黄となっている。
<!DOCTYPE html>
< html lang = "en" >
< 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"の概念に基づいており、それに対応してウェブ上で潜在的な攻撃の多くは、生成元をまたいだ振る舞いを伴うとされる。[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を作成する可能性がある：
https://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を被害者のサイトに配置し、ユーザーがリアクションゲームをプレイすることによって、クリックするようユーザーにさせる場合、ユーザーをだます1つの手段である。ひとたびユーザーがゲームをプレイすると、敵対サイトはユーザーがクリックしようとすると同時にマウスカーソルの下にiframeを配置できる。こうして被害者サイトのインターフェイスをクリックするようにユーザーを騙す。
これを回避するために、フレームに使用されることを予想しないサイトは、（たとえばtop属性の値にwindowオブジェクトを比較することによって）フレームにないことを検出した場合のみ、それらのインターフェイスを有効にすることを促進する。
HTML内のスクリプトは"実行から完了まで"のセマンティックスがある。これは、イベントを発火または文書を解析し続けるなど、ほかに何かを実行する前に、一般にブラウザーは途切れずスクリプトを実行することを意味する。
一方、HTMLファイルの解析は増加的に発生する。これは、パーサーがスクリプトが実行できるよう任意の時点で一時停止可能であることを意味する。これは一般に良いことであるが、イベントが発火する可能性ができた後に、著者はイベントハンドラーをフックするのを避けるよう注意する必要があることを意味する。
これを確実に行う、イベントハンドラーのコンテンツ属性を使用する、または要素を作成して同じスクリプト内でイベントハンドラーを追加するという2つの方法がある。前述のように、追加のイベントが発動する前に、スクリプトが完了するまで実行されているため、後者は安全である。
これが明示することができる1つの方法は、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 > 著者は、よく目にする誤りを見つける適合性チェッカー（バリデーターとも呼ばれる）を利用することが推奨される。WHATWGはそのようなツールのリストを維持する：https://whatwg.org/validator/
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パーサーに接続される場合、たとえば要素または属性名が複数のコロンを一切含まないように、XMLがHTMLファイルにより侵害されることを強要する特定の不変条件が可能である。これを処理すると、パーサーがXML互換infosetにHTML DOMを強要することを要求できる。このような処理を要求するほとんどの構文構造は妥当でないとみなされる。（2回連続ハイフンを含む、またはハイフンで終わるコメントは、HTML構文で許可される例外である。）
特定の構文構造は不均衡なパフォーマンスの低下につながることがある。このような構造の使用を思いとどまらせるために、典型的な不適合とする。
たとえば、すべての閉じられていないi要素が各段落で再構成されなければならないために、次のマークアップはパフォーマンスの低下をもたらし、各段落で次第により多くの要素をもたらす：
< p >< i > She dreamt.
< p >< i > She dreamt that she ate breakfast.
< p >< i > Then lunch.
< p >< i > And finally dinner.この断片に対して得られるDOMは次のようになる：
歴史的な理由により、比較的壊れやすい構文構造が存在する。そのような問題に偶発的に陥るユーザーの数を減らすために、これらを適合しないようにする。
たとえば、属性における指定文字参照の特定の構文解析は、閉じセミコロンが省略されても起こる。指定文字参照を形成しない文字が続くアンパサンドを含むのは安全であるが、その文字が指定文字参照を形成する文字列に変更された場合、その文字列は代わりに文字として解釈されるだろう。
次の断片で、属性値は"?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 is ok, since it's not a named character reference --> < a href = "?art&copy" > Art and Copy</ a > <!-- the & has to be escaped, since © is a named character reference --> 特定の構文構造は、レガシーユーザーエージェントでは特に微妙または重大な問題を引き起こすことが知られており、したがって著者が回避するのを助けるために不適合としてマークされる。
たとえば、これはU+0060 GRAVE ACCENT文字（`）が引用符なしの属性で許可されない理由となる。特定のユーザーエージェントにおいて、これは時に引用符として扱われる。
一定の制限は、純粋に既知のセキュリティ問題を回避するために存在している。
たとえば、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要素をネストするのと同じ目的を果たすが、後者はインラインボックスにブロックボックスを含み、この組み合わせは許可されない。
もう1つの例は、インタラクティブコンテンツは入れ子にできないことだろう。たとえば、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 > これは、正確に次のように解析される：
< p > Welcome. </ p >< form >< label > Name:</ label > < input ></ form > 一部のエラーは、デバッグ困難だろうスクリプトの問題を防ぐ手助けを意図している。
例えば、同じ値を持つ2つのid属性を持つことは不適合である理由となる。二重のIDは、時には悲惨な結果とその原因を究明するのを困難にするとともに、間違った要素の選択をもたらす。
一部の構造は許可されない。なぜなら、そのような構造は歴史的に無駄なオーサリング時間の多くの原因であり、その構造を避けるよう著者に推奨することで、著者は将来の取り組みに時間を節約できるためである。
たとえば、script要素のsrc属性は、要素の内容を無視する。しかし、これは明らかでなく、特に要素の内容が実行可能なスクリプトのように見える場合。スクリプトが実行されないことに気づくことなく、著者がインラインスクリプトをデバッグしようする多くの時間を費やすことにつながるだろう。この問題を軽減するため、この仕様はsrc属性が存在する場合、script要素内に実行可能なスクリプトを不適合とする。これは、文書を検証する著者が、この種の誤りとともに時間を無駄にする可能性を低くすることを意味する。
一部の著者は、XMLとHTMLの両方で同様の結果に解釈可能なファイルを書くことを好む。この習慣は無数の微妙な困難さ（特にスクリプト、スタイル、または自動化されたシリアライゼーションの任意の種類を含む場合）のために一般的に推奨されないけれども、この仕様は、少なくとも多少の困難の軽減を意図するいくつかの制約がある。これは、著者がHTMLとXMLとの間で移行する場合に過渡的な段階として容易に使用できるようにする。
たとえば、langとxml:langという属性が2つの同期を維持することを目的とするやや複雑な規則がある。
もう1つの例は、適合文書中の要素が、HTMLまたはXMLとして処理したかどうか、同じ名前空間に終わることの確認を意図されるようなHTMLシリアライゼーションでxmlns属性の値を制限するだろう。
言語の今後の改正で新しい構文を可能にするために意図された構文の制限と同様に、要素や属性値の内容モデルに対する一部の制限は、HTML語彙の将来の拡張を可能にするために意図されている。
たとえば、U+005F LOW LINE文字（_）で始まるtarget属性値を特定の事前に定義された値のみに制限することは、新たな事前定義された値を、著者が定義した値と競合することなく将来の時点で導入することができる。
一定の制約は他の仕様によって作られた制約のサポートを意図する。
たとえば、メディアクエリーを取る属性が妥当なメディアクエリーのみの使用を要求することは、その仕様の適合規則に従うことの重要性を強調している。
以下の文書は、この仕様書の読者が興味をもつかもしれない。
このアーキテクチャーの仕様は、Unicode標準とISO/IEC 10646で共同定義した国際文字集合として、ウェブ上で相互運用可能なテキスト操作のための共通の基準を仕様書の著者、ソフトウェア開発者、およびコンテンツ開発者に提供する。テーマは、用語'文字'、'エンコーディング'および'文字列'の使用、参照処理モデル、文字エンコーディングの識別および選択、文字エスケープ、ならびに文字列の索引付けを含む対処である。
Unicodeは極めて多数の文字を含み、世界の様々な書記体系を包含するため、誤った使用方法は、プログラムまたはシステムをセキュリティ攻撃にさらす可能性がある。次々に製品は国際化されるので、これは特に重要である。この文書は、プログラマー、システムアナリスト、規格の開発者、およびユーザーが考慮すべきセキュリティ上の考慮事項の一部について説明し、問題のリスクを軽減するために明確な推奨事項を提供する。
ウェブコンテンツ・アクセシビリティ・ガイドライン（WCAG）は、ウェブコンテンツをよりアクセシブルにするための幅広い推奨事項を扱う。このガイドラインに従うことにより、全盲およびロービジョン、ろうおよび難聴、学習障害、認知制限、運動制限、言語障害、光過敏性発作ならびにこれらの組み合わせを持つ人々の広い範囲にアクセシブルなコンテンツを提供できる。このガイドラインに従うことはまた、多くの場合一般のユーザーに対してウェブコンテンツをより使いやすくする。