HTML 5検証はろうそくに値するでしょうか？

StackOverflow https://stackoverflow.com/questions/432933

  •  10-07-2019
  •  | 
  •  

質問

HTMLを検証する最良の理由は、すべてのブラウザが一貫して予測可能にHTMLを処理することであると広く考えられています。

ただし、HTML 5ドラフトには2つの仕様が含まれています。最初に、HTML作成者が使用する要素と属性、およびそれらの相互関係を説明する作成者仕様。 HTML 5ページの検証は、この仕様に基づいています。含まれる要素と属性はHTML 4から直接描画されませんが、<！> lt; table <！> gt;、longdescのsummary属性など、一部のHTML 4機能を正当化する必要があります。 <！> lt; img <！> gt; <！> lt; head <！> gt;のプロファイル属性は、現在このドラフトには表示されていません。そのような機能は非推奨とは見なされず、単に含まれていません。 （ドラフトからの不在は論争の問題のままですが、いつかすぐにそれらが含まれる可能性は低いようです。）

第二に、ドラフトは、HTMLの形式と有効性に関係なく、与えられたバイトストリームをブラウザーのパーサーがどのように処理するかを正確に定義するブラウザー処理仕様を定義します。これは、ブラウザーがHTML 5を完全にサポートしている場合、検証に合格する入力よりもはるかに広い範囲の入力に対して、ブラウザーがどのようにHTMLを処理するかを予測できることを意味します。

特に、HTML 5は今日のWebと100％下位互換性があると定義されているため、すべての有効なHTML 4、および無効だが一般的に使用されるマークアップはすべて、今日とまったく同じように処理され続けますHTML 5が有効かどうか。

したがって、最低限、HTML 5、HTML 4、または以前のバージョンのHTMLの機能に加えて、多くの独自の拡張機能を使用している人は、HTMLがすべてのブラウザーで一貫して予測可能な扱いになると確信できます。

これを考えると、HTML 5を検証するHTML 5に制限しても意味がありますか。そうすることでどのような実用的なメリットが得られますか？

役に立ちましたか？

解決

  • まず<！>＃8217; <！>＃8220; parse errors <！>＃8221;に対応する有効層 HTML5解析アルゴリズム。この層は、XMLの整形式に似ています。このレイヤーのドキュメントでエラーが発生しないようにする一番の理由は、驚くべき解析ツリーを取得できるからです。このレイヤーでドキュメントにエラーがない場合、DOMで動作するJSまたはCSSを作成するときにデバッグするサプライズが少なくなります。
  • 上記のレイヤーの特殊なケースとして、<！>＃8217; s HTML5 doctype：<!DOCTYPE html>。ここで準拠したい理由は、可能な限り簡単な方法で標準モードを取得することです。 It <！>＃8217;は、毎回検索してコピーして貼り付ける必要があるHTML 4.01またはXHTML 1.0のdoctypeとは異なり、記憶できるものです。もちろん、あなたが<！>＃8217; dを標準モードにしたい理由は、CSSレイヤーでの驚きが少ないことです。
  • 解析アルゴリズムよりも上位のレイヤーで検証を行う主な理由は、タイプミスをキャッチすることです。これにより、ページが期待どおりに機能しない理由をデバッグする時間を短縮できます。
  • 前のポイントでは、スペルミスをしなかった特定の要素または属性がレガシーの問題としてブラウザーでサポートされているが、HTML5仕様ではそれが回避されている場合、検証を考慮する必要がある理由については説明しません。 Here <！>＃8217; s HTML5がこのような構文を廃止した理由：
    • HTML5は廃止を使用して、一部の機能が時間の浪費であることを著者に知らせます。これらには、longdesc、summary、およびprofileが含まれます。 （これらが実際に時間の無駄であるかどうかは意見が異なりますが、現在草案されているように、HTML5はそれらを廃止していることに注意してください。） =>および<font>。セマンティックな純度のためにリソースが限られている場合、リソースは<applet>で正しい呪文を持っていることを確認するよりも何かに費やしたほうがよいでしょう。
    • HTML5は、CSSで複製できるいくつかのプレゼンテーション機能を廃止し、作成者が自分の利益のためにCSSを使用するように導きます。このように、自分で保守性を考慮しない<！>＃8217;作成者は、それにもかかわらず、より保守性の高いコードに導かれることになっています。個人的には、従来のプレゼンテーション資料をより適合させ、作成者自身に任せて、どの方法を使用するかを決定することを好みます。
    • 政治的な理由で一部が廃止されています。 classid要素は廃止されました。準拠させると、アンチ<object>標準主義者がHTML5の人々が狂ったように思われ、悪いPRにつながる可能性があるためです。 nameは、特定のプラグインに特別なマークアップを与えないという原則の問題として主に廃止されました。 <a>のlanguage属性は廃止されました。これは、<！>＃8217;実際にはActiveX固有であるためです。
    • 一部のものは、言語設計の美学に基づいて廃止されています。これには、<script>の<=>属性と<=>の<=>属性が含まれます。

（W3Cバリデーターが使用するHTML5検証エンジンでもあるValidator.nu HTML5バリデーターを開発しています。）

他のヒント

  

これを考えると、HTML 5を検証するHTML 5に制限しても意味がありますか。そうすることでどのような実用的なメリットが得られますか？

はい、もちろん。あなたは未来が決まっていないことを忘れます。特に、HTML 5の仕様が変更されることはなく、機能が廃止されることもないと暗黙的に想定しています。もちろん、これは現状を固めるだけです。いくつかの機能のサポートを長期的に削除して、新しい開発がより簡単に行われるようにすることが特に望ましい（特にこれらが互いに競合する可能性がある場合）。

有効なHTML 5を作成しても、すぐにメリットが得られるとは限りません（ただし、検証と開発が容易になることを still 除いて）。しかし、ほとんどのWebサイトの品質が向上すれば、現在の技術や標準をはるかに超えて移行しやすくなるため、長期的なメリットがあるかもしれません。

検証は、HTML5が開始される前であっても、ブラウザー間で一貫した結果を取得することではありませんでした。それは、たとえ自分が何を話しているのかを理解していない人たちによって広められた神話です。

検証の本当の理由は、常に純粋に品質保証の問題です。これはエラーを検出する方法にすぎません。特定のエラーの結果がブラウザー間で一貫しているか、または間もなく一致する場合でも、結果自体が意図したとおりではない可能性があります。

特にチーム環境で作業している場合、よりクリーンでエラーのないマークアップを使用すると保守が容易になるため、作成者がコード内のエラーをキャッチできることが重要です。個々のエラーのほとんどは良性であり、大きな問題を引き起こすことはありませんが、予期しない結果をもたらす可能性のあるエラーがいくつかあります。例えば誤って、重複する要素または閉じられていない要素は、場合によっては予期しないレイアウトの問題を引き起こす可能性があり、検証ツールにエラーの場所を通知させると、問題の修正に役立ちます。しかし、結果にそれ以外の無害なエラーが多数ある場合、検出と処理が必要以上に困難になる可能性があります。

これは確かに、HTML5での私のちょっとした問題の1つです。とにかくブラウザーがすべてのストリームを同じ方法で処理する必要がある場合、ストリームのサブセットを「有効」と定義する意味はありません。 WHATWGのリストに費やされたフォールバックメカニズムの議論は、特にXMLがすべての解析の問題をすでに解決しているはずの場合、全員の時間の大きな浪費です。

従来の無効なドキュメントの解析に関するベストプラクティスドキュメントを作成することは有益なアイデアでしたが、これはWeb標準には含まれていません。既存の動作を体系化する（HTML 3.2のように）、よりクリーンなプラットフォームを再定義する（HTML 3.0で試したように）、または新しい拡張機能を少しずつ追加する。

とにかく、<！> quot;完全にHTML5 <！> quot;をサポートするブラウザは決してないので、質問は間違っているかもしれません。あまりにも多すぎます。ブラウザーの製造元は、たとえMicrosoftが明示的にそうしていない場合でも、細かさまで完全に実装することはできませんでした。代わりに、明らかに有用な機能がベンダーによって選択され、より広く受け入れられます。

HTML5は一貫性のあるHTML仕様ではなく、Webブラウザが行うべきだと思うあらゆるランダムなものに対するHixieの広大で読みにくい、未完成のレシピです。失敗します。そして、W3の代替アプローチであるXHTML2はすでに失敗しています。 Web標準の一貫した将来の方向性はありません。ボールを落としました。

良い質問です。

（少なくとも私にとって）検証の主な目的は、マークアップのエラーを見つけやすくすることと、さまざまなブラウザーでページをテストするときに構築するための適切な基盤を提供することです。マークアップが有効で、ページがIE6で中断されている場合、IE6の問題です。

テーブルサマリーやアンカーアクセスキーなどの技術的に無効なHTML5がマークアップに含まれている場合でも、ブラウザーはすべて予測可能な方法で動作する必要があるという事実は、水域をやや濁らせます。

一般的な経験則として、前述の理由により、常にページの検証を行いたいと考えています。ただし、（たとえば）明らかに適切な置換を追加せずにHTML5仕様から属性が削除された場合、廃止または廃止された属性を引き続き使用し、検証エラーを受け入れることになります。

相変わらず、それはあなたの技術を知っている場合だと思います。

自分が何をしているかを知っていて、正当な理由で検証されないページを構築するために意識的な決定を行った場合、それは問題ではありません。よくわからないので検証しないコードを書いているだけなら、それは別の問題です。

スティーブン

W3C HTML5バリデータメンテナはこちら。私は最近短い<！>＃8220; Why Validate？<！>＃8221;を書きました。 <！>＃8220; About <！>＃8221;のセクションHTML5バリデーターのセクション：

http://validator.w3.org/nu/about.html# why-validate

そのセクションのテキストのソースはこちらです：

https://github.com/validator/ validator / blob / master / site / nu-about.html＃L160

また、提案された改良/追加を伴うプルリクエストも歓迎します。

私が現在持っているものはこれです：

  

適合性を介してHTMLドキュメントを実行する主な理由   チェッカーは単純です：意図しない間違いをキャッチするには<！>＃8212;間違いがあるかもしれません   <！>＃8212;見逃しているので修正できます。

     

さらに、いくつかのドキュメント適合要件（有効性規則）   あなたとあなたのドキュメントのユーザーを助けるためにHTML仕様にあります   特定の種類の潜在的な問題を回避します。理論的根拠を説明するために   これらの要件の背後にあるHTML仕様には、次の2つのセクションが含まれています。

           

これらの2つのセクションで述べられていることを要約するには、<！>＃8217;

     
      
  • エラーとして定義されているマークアップケースがいくつかあります。   アクセシビリティ、ユーザビリティ、相互運用性に関する潜在的な問題、   セキュリティ、または保守性   パフォーマンス、またはそれが原因でスクリプトが失敗する可能性があります   トラブルシューティングが難しい。
    •   
  • それらとともに、いくつかのマークアップケースが定義されています   エラーとして、潜在的な問題が発生する可能性があるため   HTMLの解析とエラー処理の動作   DOMで直感的ではない予期しない結果が発生します。
    •   
     

ドキュメントを検証すると、これらの潜在的な問題を警告します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top