最近は常に完全な検証に努めていますが、時間の無駄ではないかと思うことがよくあります。コードが実行され、すべてのブラウザーで同じように見える場合（browsershots.orgを使用して確認します）、さらにコードを進める必要がありますか、それとも過度に肛門的ですか？
次の目的でコードを作成するときに、コードをどのレベルに保持しますか。
a）あなた自身b）あなたのクライアント
PSジェフと会社、なぜスタックオーバーフローが検証されないのですか？:)
編集：いくつかの良い洞察、私は非常に有効であるため、私は何が問題を引き起こし、何が問題を引き起こさないかを知ってプログラムするので、最初にサイトを作成し、次にサイトを作成する人々よりも良い立場にあると思います「戻って検証の問題を修正してください」
スタックオーバーフローについて別の質問を投稿するかもしれないと思います。「進行中に検証しますか、それとも終了してから戻って検証しますか？」それがこの質問が進んでいるところのようです
a）同じように見える必要があります
b）可能な限り標準に準拠しているが、仕上げ作業を妨げるほど肛門ではない
コードに永続的にアクセスできる状況では、標準への準拠はそれほど重要ではないと思います。何かが壊れた場合はいつでもコードに変更を加えることができるからです。永続的なアクセス権がない場合（つまり、コードをサインオフして他の人の責任になる場合）、後でメンテナンスの問題を最小限に抑えるために、可能な限り標準に準拠するのが最善です...コードを再度処理すると、評判が維持され、他の潜在的なクライアントに送信される可能性があります。多くのチームは、発生した問題について前の開発者を非難することを好みます。
これは、実用的な範囲でロバストネス原則を使用するように努力する必要がある領域だと思います（これは、コーディングのあらゆる領域に適したアドバイスです）。今日何かが機能するからといって、それが明日機能することを意味するわけではありません。特定のHTML / CSSハックに依存している場合、または厳密に有効なコードの発行に少し余裕がない場合でも、ブラウザーの次の反復はうまくいく可能性があります。壊す。正しい方法で一度実行すると、この問題が最小限に抑えられます（ただし、完全に軽減されるわけではありません）。
ただし、ここで取り上げる実用主義の特定の要素があります。私は確かにクライアントのサイトが有効になるようにできる限りのことをしますが、私は自分のスペースでより多くのリスクを冒すことをいとわないでしょう。
「100％標準準拠」を本当に気にかけているのは「技術者」だけだと思います。私の通常のページの利用者（=ユーザー）は、「メニュー境界線の画像要素」にalt属性がなくてもかまいません。
私は通常、明らかなエラー（すべてのタグが閉じている、すべて小文字、引用符で囲まれた属性など）が表示されないことを確認しますが、IEとFFで見栄えがよい場合は、それだけです。HTMLタグで非標準の属性を使用してもかまわないので、意図した視覚的な結果が得られる限り、ページはDTDに対して検証されません。
検証が重要な理由を理解するには、ブラウザーがさまざまなレイヤーでどのように機能するかを理解し、Web ブラウザーの観点から Web の歴史について少し理解する必要があります。
ブラウザに与える HTML は、ページ全体をノードの階層としてマップするアプリケーション プログラミング インターフェイスである DOM に従って、ブラウザによって解釈されます。そのツリーの各部分は、 さまざまな種類のデータを含む一種のノードです。DOM (Document Object Model) が必要だったのは、初期の Web ブラウザー (Netscape、IE...) が Web ページの外観と内容をリロードせずに変更できるように実装した HTML ページの多様性のためです。Web のクロスプラットフォームの性質を維持するために、W3C はこれらのブラウザーのさまざまな実装を修正し、DOM を提案したいと考えました。
DOM のサポートは、ほとんどの Web ブラウザー ベンダーにとって大きな優先事項となり、リリースごとにサポートを改善するための努力が続けられています。それで、うまくいきました。
DOM は、Web ブラウザーを開始するための非常に基本的なステップです。その主な流れは次のとおりです。
ステップ 1 により、タグが DOM ノードに変換されたコンテンツ ツリーが得られます。ステップ 2 により、スタイリング情報を含むレンダー ツリーが得られます。
では、検証が重要な理由:コンテンツ ツリーとレンダリング ツリーは、Web ブラウザーがジョブを開始するための基盤だからです。それらが明確に定義されているほど、Web ブラウザーに適しています。
最終的に、DOM は JavaScript イベントの基礎でもあります。そのため、その検証はインタラクション レイヤーにも役立ちます。
これがあなたの質問全体に答えているわけではないことは知っていますが、完全に有効なhtmlを使用することで、まだリリースされていない将来のWebブラウザーでWebサイトが正しく機能することを確認できることを考慮する価値があります。
私のアプローチは、すべてのページで完全に検証できるようにする傾向がありますが、ページを application/xhtml+xml ではなく text/html として送信するため、何かを見逃した場合でも醜い XML エラーは発生しません。
私にとっては、自分のコードが検証されれば、良い仕事をしたと感じます。w3c のページに緑色のチェック ボックスが表示されているのを見ると、少し目がくらみます。グループbに関しては、彼らは通常、ブラウザ間で同じように見えて動作することだけを気にします. 彼らは、これが真実ではないことを私が発見した唯一の場所は政府部門です. w3c だけでなく、ADA テストに合格することも完全に検証する必要があります (基本的に、スクリーン リーダーでどのように聞こえるか)。
ps 政府部門とは、具体的にはカリフォルニア州とその中のいくつかの郡を意味します。私は彼ら以外の政府グループとの経験はありません。
検証は、問題が適切に行われたかどうかの優れたリトマス試験だと思います。小さな問題がわずかしかない場合は、それらを修正して、少なくとも将来的にブラウザがサイトを正しく理解できるようにしてください。他の理由で物事を異なってレンダリングしますか）？
OTOH、ほとんどのプロジェクトでは、検証は大きな頭痛の種のように思われます。ブラウザ間で動作させることができれば、検証だけに1日/週以上余分に費やす価値はありません。
バリデーター自体が非常に積極的に肛門である場合を除いて、-moz-、-webkit、または-o-、つまりブラウザー固有の修飾用語が使用されている場合は常に、エラーまたは警告にフラグを立てます。また、0や他の単位ではなく0pxを指定するように求められます。バリデーターがチェックしたい単位が何であれ、ゼロはゼロです。
WordPressの21のstyle.cssを検証してみてください。140の奇妙なエラーがスローされます。これは上記のすべての性質であるか、バリデーターが解析エラーから回復しています。
もみ殻から小麦を選別できない場合、バリデーターは役に立ちません!!!
ブラウザ固有の資格条件を認識するバリデーターが必要です。