W3C 検証は使用が難しい場合がありますが、これを使用すると、レイアウト設計に起因するエラーを確認できます。バリデーターは、XHTML がまだ完成しておらず、異なるブラウザー間では一貫して機能しない可能性があることを示す多くのエラーと警告をスローします。次の 10 個の微妙な障害問題は、多くのプログラマーを悩ませてきました。それらを解決する方法を説明します。この記事を始める前に、W3C バリデーターを使用する際に注意する必要がある問題をいくつか紹介します。
検証者からの警告については心配する必要はありません。検証者が 12 件のエラーと 83 件の警告を見つけたと言っている場合は、無視して次のステップに進みます。
一度に 1 つのエラーを修正する - 上から下に順番に作業し、一度に 1 つのエラーを修正します。 HTML はブラウザで上から下に表示され、これらのエラーは同じ順序で表示されます。
コードを修正するたびにコードを更新して、コードを再び有効にします。多くの場合、小さな間違いがページ全体に一連のエラーを引き起こす可能性があります。したがって、「エラーの修正」を誤ると、さらに多くのエラーが発生する可能性もあります。修正を行うたびにコードを再検証することで、問題が完全に解決されたことが確認されます。
上記の基本的な例外を理解した上で、レイアウト設計が無効となるいくつかの理由を見てみましょう。
1. div タグが閉じられていない これは、レイアウト設計が失敗する最も一般的な理由の 1 つです。このせいで、どれだけ多くの繊細なレイアウト設計が失敗しているかを知ると、いつも驚かされます。調査によると、オープン div タグは最も一般的なセクション設計エラーの 1 つであり、診断が最も困難なエラーの 1 つです。バリデーターは、間違った開始 div タグを指すことがあります。これは、干し草の山から針を見つけるようなものになる可能性があります。
2. 面倒な埋め込みタグ 1990 年代初頭、Microsoft と Netscape のブラウザが標準以外の独自フォントを認識できるようになりました。残念ながら、これは、「embed」などの特定の主要な HTML タグが広く使用されているにもかかわらず、W3C バリデーターがまだそれらのタグを認識していないことを意味します。本当に厳密な DOCTYPE (文書タイプ) 検証が必要な場合は、ネストを放棄するしかありません。
効果的なレイアウトと埋め込みメディアを同時に必要とする場合は、Flash Satay 方法を試すことができます。
3. 不適切な DOCTYPE 宣言 DOCTYPE を宣言しなかったり、ファイルの先頭で誤って DOCTYPE を宣言したりすることもよくある間違いです。一般的な経験によれば、Strict DOCTYPE は誰もが追求する最高レベルの検証です。厳密な検証は、Web ページがすべてのブラウザで最適に表示されることを示します。 Strict 宣言コードは次のとおりです。
4. 末尾のスラッシュ Web サイトを検証できない場合は、コード内のどこかで末尾のスラッシュが欠落している可能性があります。特にイメージタグなどの要素では、末尾のスラッシュなどを見落としがちです。例えば：
これは厳密な DOCTYPE では効果がありません。この問題を解決するには、img タグの末尾に「/」を追加します。
5. アラインタグ DOCTYPE が Transitional に設定されている場合は、「アライン」タグを使用しますが、要求が厳しく、厳密な検証が必要な場合は、多くのエラーが表示されます。 Align もレイアウト設計には使用できないタグです。要素を変換するには、align の代わりに「float」または「text-align」を使用してみてください。
6. JavaScript
Strict DOCTYPE が宣言されている場合は、JavaScript で CDATA タグをオーバーライドする必要があります。 Web サイトは広告や追跡スクリプトに埋め込み JavaScript を使用する傾向があるため、検証プロセスのこの側面は多くのプログラマーを悩ませています。 JavaScript を使用する必要がある場合は、その前後に次のタグを追加できます。
7. 画像には「alt」属性が必要です 気づいていないかもしれませんが、画像は高度な検証の潜在的な障害にもなります。末尾のスラッシュに加えて、高度な検証では、画像を説明する alt タグも必要です (例: alt=「怖い吸血鬼の写真」)。
検索エンジンは、Web ページ上の画像を識別するために alt タグにも依存しているため、どのような場合でも、常に alt タグを追加することをお勧めします。
8. 不明なエンティティ データ エンティティ データは、検証に影響を与えるもう 1 つのよくある間違いです。 「&」などの記号を置き換えるために、適切なエンコード文字を使用することを検討できます。 XHTML セクション設計で使用できる、適切にエンコードされた文字エンティティ データの完全なリスト。
9. 悪い入れ子 入れ子とは、要素に Sweet! 要素が含まれていることを意味します。
ネストされた要素の順序は混同しやすいです。たとえば、div タグの前に強いタグを開始しますが、最初に div タグを閉じます。これによってセクションのレイアウトは変更されない可能性がありますが、セクションのデザインは無効になります。
10. "title" タグの欠落 これは明らかな間違いのように思えますが、多くのプログラマ (私も含めて) は "head" セクションの title タグをよく見逃します。 「missing a required sub-element of HEAD」（HEAD の必須サブ要素がありません）と表示されると、title タグを追加するのを忘れていることがわかります。