HTML検証：価値があるか？

すべてのページが有効であることを確認することの利点と欠点（ある場合）は、主要なブラウザーすべてで機能する無効なHTMLと比較してどのようなものですか？

また、Javascriptの実行後に有効なHTMLを使用することも重要ですか？

私は間違いなくやりがいがあると思いますが、検証の奴隷になるべきではありません-それは愚か者のゲームです。

http://www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html

1. HTMLを検証します。有効なHTMLマークアップを持つことの意味を理解します。ツールを理解します。少ない情報よりも、多くの情報が常に優れています。なぜ盲目で飛ぶのですか？

2. HTMLが有効かどうかは誰も気にしません。あなたを除いて。あなたがしたい場合は。完全に有効なHTMLを作成することは、Webサイトを実行したり、ユーザーを喜ばせる機能を提供したり、作業を完了したりすることよりも重要だと考えないでください。

私は有効なHTMLを価値のある目標と考えていますが、良いWebサイトを構築するためのすべての目的やすべての目的とは考えていません。

秘Theは、マークアップが完全に有効であっても、セマンティックではない場合があることです。たとえば、レイアウトやナビゲーションにテーブルを使用することです。有効なコードとセマンティックコードには違いがあります。

別の注意として、広告や外部スクリプトを使用する場合、彼らは独自のマークアップを挿入する可能性があります。

検証を求めて多くのマークアップと論理エラーをキャッチしたので、それは価値があると思います。これは、「必要だが十分ではない」ものの1つです。エラー、警告、およびヒントのないコンパイル（またはJSlintを介したチェックアウト）のような有効なマークアップは、それを正しくするための良い最初のステップです。

有効なHTMLの大きな利点は、ページが「主要なブラウザ」以外のものにアクセスしやすくなることです。すべての「主要なブラウザ」には、WWWに存在するすべての無効なジャンクを処理するための無限の回避策があります。ただし、有効なHTMLに固執することは、たとえば、誰かが視覚障害者のためにブラウザーを使用している場合や、オフラインでページにアクセスしている場合などに役立ちます。

100％に準拠しているブラウザはほとんどなく、ルールの解釈方法についても仕様が100％明確ではないため、検証自体はそれほど重要ではありません。

ただし、有効なHTMLを使用することで、サイトを適合および改善するためのより良い立場になります。標準が移動するにつれて、標準は一般に前方に移行します。新しいサイトが有効な場合、最新のものをサポートするように更新する方が簡単です。

一番下に、有効であると、ゲームのトップを維持し、できるだけ多くの視聴者と互換性を保つことが容易になります。

最良のアプローチは、どの無効なHTMLが悪いか、そしてどの無効なHTMLが重要でないかを知ることです。

たとえば、<div>タグを閉じることを忘れると、レイアウトが1つまたは複数のブラウザーでほぼ確実に台無しになるため、非常に悪いです。

ただし、XHTMLの<br>代わりに使用する<br />ことは問題ではありません。すべてのブラウザは、両方とも問題なく改行として解釈します。targetリンクでの属性の使用は無効ですが、最悪のシナリオは、ブラウザーがリンクを新しいウィンドウで開かないことです。

バリデーターを実行するとき、ケースバイケースでそれが与えるエラーを調べる必要があります。検証は重要ですか？私にとって、はい、それは非常に重要です。しかし、それは要件ですか？番号。

（クラスの代わりに）同じIDを複数回使用する、インラインレベルの要素内にブロックレベルの要素を配置する（通常、これらの要素は意味的にこの方法に適合しない）、画像のalt属性が欠落する（障害者のアクセシビリティが低いなど） ）、すべてが重要です。タグの不明な属性などは重要ではありません。まったく。DojoやそのひどいMeeboソーシャルメディアバーなどのJavascriptフレームワークは、フックとしてカスタム属性を使用します。HTML仕様では、これらは許可されており、不明な属性は無視されると規定されています。バリデーターはそれらを無視しませんが、エラーをスローします。これらのエラーは無視できます。

検証するとき、エラーがある場合は間違っていると考えないでください。セマンティクスは非常に重要であり、有効なHTMLが適切なセマンティクスを持っていることの自然な結果であることが多いということはたまたま起こります。

有効なHTMLについてサイトをテストする理由の1つは、検索エンジンスパイダーがページの意味を完全にインデックス付けおよび決定できることを確認することです。不正なHTML（歴史的な理由で主要なブラウザが回避する可能性がある）が原因でそうできない場合、検索エンジンのランキングを制限する可能性があります。

また、主要な検索エンジンは不正なHTMLをうまく処理しますが、有効性のためにページ品質の「ポイント」を割り当て、コンテンツの価値に応じてランク付けする能力にさらに影響を与える可能性があるという推測もあります。

私は本当にそれがもう重要だとは思わない。以前は検証の奴隷でしたが、今ではそれをチェックすることはほとんどありません。おそらく、自分のサイトが有効であることを確認するために燃え尽きてしまったのか、あるいは誰も気にしないのでもう気にしなかったのかもしれません。私たちの訪問者の99.9％はそれが何であるかさえ知らず、彼らが知っていたとしても気にしさえしないことを保証することができます。将来のブラウザソフトウェアはそうなるかもしれませんが、その日が来たら、それについて心配します。

検証は、次のようなキャッチしにくいエラーを見つけるのに役立つため、便利です。

<input name=foo value=<?php echo htmlspecialchars($_GET['foo']); ?> />

または予期しないブラウザの動作（たとえば、ブロック要素を入れるとa、Firefoxで見苦しくなることがあります）。

誰もまだ言及していない点は、無効なHTMLがレンダリング時間を遅くする一方で、ブラウザが表示時に非標準のHTMLを理解しようとしているということです。

有効なhtmlを持っていることの欠点はありません。そもそも仕様が存在する理由と、物事の仕組みを定義するために多くの努力が仕様に費やされている理由があります。

基本的に、得られるのは仕様を満たすことだけです。つまり、htmlを読み取るように作成されたプログラム（ブラウザー、ボット）は、何か問題が発生した場合に仕様を満たしていないことであなたを責めることはできません。これらのプログラムのいくつかは、追加のポイントを提供します（ボットが「仕様に適合している」と報告した場合、検索エンジンのランキングが高くなります）。仕様を満たしていても、一部のブラウザが壊れたhtmlを想定どおりにレンダリングしない場合、驚くことはほとんどありません。

そのため、仕様を満たし、有効なhtmlを書くことはあなたにとって良いことであり、欠点はまったくありません。

一部のHTML検証エラーは、非自明なレイアウトの問題（たとえば、誤ってネストされた/閉じられていないタグ）、JavaScriptのバグ（たとえば、id複数回使用）、一部のユーザーの問題（たとえばalt、画像に意味のあるまたは空白の属性を含めない）を引き起こす可能性があります。

すべてのページが検証されると、それはエラーの原因を除外するために実行できる便利な自動チェックです。害を引き起こしていないことがわかっているために検証エラーを残した場合、チェックは自動化されなくなります。各エラーを確認し、問題がないことを忘れないでください。個人的には、コンピューターが私がしなければならない仕事の量を増やすよりも減らす方が好きです。

誰も言及していない点の1つは、将来のブラウザ開発です。今日のすべてのブラウザは無効なマークアップを比較的うまく処理しますが、常にそうであるとは限りません。

将来のブラウザメーカーは、ブラウザがHTML / XHTML標準に対応することを保証するため、Web開発者も同様にそうする必要があります。無効なマークアップの特定のビットが動作するからといって、将来のブラウザで動作することを保証するわけではありません。

妥当性は、非互換性を回避し、コードを保守可能に保つのに役立ちます。ブラウザはマークアップエラーから回復しますが、非常に直感的でない場合があります。

• DTDベース（HTML4、XHTML1 @ W3C）—価値がないかもしれません。DTDはプリミティブであり、たとえば、ほとんどの属性の有効性をチェックできません。ほとんどの場合、エンティティとネストに関するエラーを理解するのは難しくなります。

• HTML5バリデーター — はい。絶対に。HTML5はより実用的であり、以前はエラーであった無害な構成要素を許可します。OTOH Henriのバリデーターは、実際の問題を発見するのにはるかに徹底的で優れています。

ブラウザはDOM上で動作するため、作成方法に関係なく、JSで生成されたコードの有効性が重要になる場合があります。を使用する場合はdocument.write()、構文が正しくなるように注意する必要があります（ページソースと同じパーサーを通過します）。

HTMLがすべての主要なブラウザーで動作する場合でも、googlebotなどの検索エンジンクローラーで問題が発生することがあるため、実行する価値はあります。たとえば、次を参照してください。

http://www.codeproject.com/KB/server-management/Google_Indexing_Problem.aspx

GoogleとBingは、ランキング要素としてCSSまたはHTML検証を使用していません。

ほとんどのウェブサイトには数十から数百のエラーがあり、すべての検索エンジンがページのレンダリング方法に関心があるため、それらについて心配する必要はありません。ウェブサイトがすべての主要なブラウザとGoogleのFetchで正しく表示されることを確認してください。