タグスープ

不正なマークアップは、ウェブオーサリングにおいて最も深刻な問題と言えるでしょう。しかし、より良い教育と情報、そしておそらくXHTMLの助けもあり、不正なマークアップの問題は少なくなりつつあります。ブラウザは、不正なマークアップに遭遇すると、作成者の意図を推測しなければなりません。期待される場所に閉じタグを推測し、他の閉じタグに一致する開始タグを推測する必要があります。解釈はブラウザによって大きく異なる場合があります。^{[ 2 ]}

多くのグラフィカルWebエディタは整形式のマークアップを生成しますが、テキストエディタでコードを手動で記述し、1つのブラウザでのみテストを行う場合、このようなエラーを見落としやすいです。そのため、各ブラウザが著者の意図を異なる方法で「修正」しようとし、その「修正」にスタイルを適用するため、ブラウザごとに表示が大きく異なる可能性があります。

ここでいう無効な文書構造とは、本来属するべきでない場所に属性や要素を使用することのみを意味します。たとえば、「cite」要素に「cite」属性を付けることは無効です。なぜなら、HTMLおよびXHTMLのDTDでは、その要素の属性に意味が与えられていないからです。同様に、「em」要素の内容の中に「p」要素を含めることも無効です。不正なマークアップと無効なマークアップを区別する動きが進むにつれて、無効なマークアップの問題は以前ほど深刻ではないと見なされるようになりました。HTML文書（HTMLでもXHTMLでも）の作成においてより柔軟性を持たせる、より緩やかなコンテンツモデルを提唱する人もいます。しかし、無効なマークアップの使用は、不正なマークアップほど深刻ではありませんが、著者の意図した意味を曖昧にする可能性があります。

多くのグラフィックWebエディタは依然として無効なマークアップを生成しています。さらに、多くのプロのWebデザイナーや著者は、マークアップの妥当性の問題にほとんど注意を払っていません。ワールドワイドウェブ上の多くのサイトで、無効なマークアップを目にするのはよくあることです。

ウェブ黎明期（1990年代の大部分）において、公式HTML仕様の設計は、視覚的に魅力的なデザインを柔軟に作成したいというデザイナーの要望に、次第に追い詰められていった。こうした圧力に対し、ブラウザメーカーは当時の標準規格から逸脱した独自の機能をHTMLに一方的に追加していった。その結果、HTMLには一部のブラウザでは動作するものの、他のブラウザでは動作しない独自の要素が存在することになった。

この問題の緩和には、W3Cが1998年に導入したCSSなどの新しい標準規格の導入が一定の効果をもたらした。CSSは、多数の追加のHTML要素や属性を必要とせずに、ウェブページの表示とレイアウトにおいてより大きな柔軟性を提供することに役立った。

さらに、HTML 4 および XHTML 1 では、多くの要素が単一の意味構造に置き換えられたり (例えば、独自のapplet 要素やembed要素をobject要素に置き換えたり)、表示目的の要素であったために非推奨になったりしました (例えば、「s」、「strike」、「u」要素)。

それにもかかわらず、ブラウザ開発者は必要性を感じた際にHTMLに新しい要素を導入し続けた。一部のブラウザは、あらゆる要素にtabindex属性を追加した。AppleのWebKitの開発者はcanvas要素を導入し、そのバージョンは後にMozillaに採用された。

2004年、Apple、Mozilla、Operaは、すべてのブラウザの動作が一致する新しいバージョンのHTML仕様を作成することを目的としてWHATWGを設立しました。これには、異なるブラウザ間の既存の合意に合わせるために必要に応じて仕様を変更することも含まれていました。^{[ 3 ]}

キャンバス^{[ 4 ]}と埋め込み^{[ 5 ]}要素はその後WHATWGによって標準化されました。以前はプレゼンテーション要素として非推奨とされていた特定の要素（b、i、smallなど）は含まれましたが、視覚的な方法ではなくメディアに依存しない方法で定義されました。^{[ 6 ]}

WHATWG仕様のバージョンは、W3CによってHTML5として公開されました。^{[ 3 ]}

Cascading Style Sheets (CSS) は、ドキュメントのマークアップ構造を変更することなく、ドキュメント内の要素の表示方法を指定する仕組みを提供します。CSS が普及する以前は、Web 開発者は特定の表示目的を達成するために、構造的に不適切なマークアップを使用することがありました。例えば、特定の効果を得るためにブロックレベル要素をインライン要素内に含めたり、場合によっては大量の<font><div> タグやその他の表示固有の HTML タグを使用したりしていました。CSS はスタイルルールを使用することで、マークアップをより簡潔かつシンプルに保ちながら、これらのタスクを実行できます。

XHTMLは、 XMLに基づいてHTML言語を再構築したものです。XHTMLは、タグの乱立に伴う多くの問題を解決するために開発されました。

XMLでは、パーサーがドキュメントの構文と構造の解釈プロセスを分離できます。HTMLやSGMLでは、パーサーは解析中に要素に関する特定のルール、例えばどの要素が他の要素の中に含まれるか、どの要素が前の要素を暗黙的に閉じるかなどを知る必要がありました。これは、HTMLやSGMLでは、一部の要素で閉じタグや開始タグさえも省略可能だったためです。XMLでは、すべての要素に明示的な開始タグと閉じタグを要求することで、ドキュメントの種類を知らなくてもドキュメントを解析し、ドキュメントツリーを生成できます。これにより、パーサーは汎用的で非常に軽量になり、ドキュメントの検証や解釈のプロセスから分離されます。

XML仕様では、準拠するユーザーエージェント（Webブラウザなど）は、構文エラーが発生した場合、ドキュメントを受け入れず、解析を続行してはならないと明確に規定されています。したがって、WebページをXHTMLとして解釈するブラウザは、形式エラーが発生した場合、ページを表示しません。これにより、作成者が準拠ブラウザでXHTMLコードをテストする際に、形式エラーがすぐに通知されるようになります。これは、Webブラウザが直面する最も深刻な問題の一つです。コードが不正な形式の場合、作成者の意図は曖昧になります。XMLの指示がない場合、HTMLブラウザは、無効な構文が検出された様々なケースにおいて、作成者の意図を推測するために複雑なアルゴリズムを使用する必要があります。

XMLとXHTMLは、名前空間の概念を導入しています。名前空間を用いることで、作成者または作成者コミュニティは、新しい意味を持つ新しい要素や属性を定義し、それらをXHTMLドキュメント内で混在させることができます。名前空間は、さまざまな名前空間の要素名が混同されないようにします。たとえば、「table」要素をHTMLの「table」要素とは異なる新しい意味を持つ新しい名前空間で定義しても、ブラウザは両者を区別できます。名前空間を提供することで、XHTMLはCSSと組み合わせることで、作成者コミュニティがドキュメントの意味語彙を容易に拡張できるようにします。これにより、完全なスタイルシート定義（音声/読み上げスタイルや触覚スタイルを含む）を通じて意図したユーザーに提示できる限り、独自の要素の使用が可能になります。

XHTML ドキュメントは、インターネット メディア タイプapplication/xhtml+xmlまたはtext/html^{[ 7 ]}を使用して Web 上で配信できます。Microsoft Internet Explorer のバージョン9より前のバージョンでは、として配信される XHTML ドキュメントは表示されませんapplication/xhtml+xml。IE9 以降のバージョンは準拠しています。この問題については、XHTML の記事の説明も参照してください。

HTML5は、可能な限り後方互換性と前方互換性を維持しながら、タグの乱立問題に対するこれまでで最も包括的な解決策となることを目指しています。後方互換性を放棄し、構文解析器が不適切な形式のマークアップに対してより厳しい姿勢を取るべきだとするXHTMLとは対照的に、HTML5は不適切な形式のHTMLコードが既に大量に存在し、今後も使用され続ける可能性が高いことを認識し、そのようなコードとの最大限の互換性を確保するために仕様を拡張すべきだと考えています。

このように、HTML 5の仕様では、現在一般的に使用されている構文に対応するため、また「不正な形式のコード」をパーサーがどのように処理すべきかを明確に記述するために、HTML構文の定義が変更されました。不正な形式のコードの処理は仕様自体に規定されるようになり、将来のHTMLパーサーが認識できないコードを処理するために、仕様外の追加的な対策を実装する必要性が軽減されることが期待されます。