私は今サイトを構築しています.これまでのところ、すべてを準拠させることを痛烈に強制しており、ブラウザ間でほとんど同じように見えます. ただし、属性の追加などを行うサードパーティ/無料の JavaScript の実装を開始しています (例: order=2)。これを回避することはできますが、それは苦痛であり、すべてが有効であることを確認するという原則を失い始めています。本当に、このような問題を回避する意味はありますか? Firefox 用の HTMLValidator プラグインを入手しましたが、ほとんどの主要なサイト (このサイト、Google などを含む) を見ると、それらは有効な XHTML または HTML ではありません。
11 に答える
検証は、おそらく同意すると思われる基準を満たしていない状況を判断するのに役立ちます。検証基準にないものを具体的に追加するツールを意図的に使用している場合、明らかに、それはあなたの個人的な基準合意を破ることにはなりません。
上記のことを説明し、単にあなたが怠け者ではないことを彼らに納得させなければならないため、すべてが青信号に戻るべきだと信じている上司またはクライアントがいる場合、この議論はさらに困難になります。
とはいえ、単に怠け者であるというだけではありません。バリデーターは、サードパーティの属性のすべてのインスタンスを絶えず表示することができますが、それによって、彼らが言及している他の検証エラーが無効になることはありません (ha)。作業を再確認する手段として、スキャンする価値があることがよくあります。
標準への準拠とは、テストしていないブラウザーでページが機能する可能性を高めることです。これには、スクリーン リーダー、テスト対象のブラウザーの次の更新、およびテスト対象であるがユーザーによって予期しない方法で構成されたブラウザーが含まれます。
ページが検証される可能性はありますが、それでも十分にあいまいで、いつかブラウザで希望どおりに動作しない可能性があるため、検証によって何も保証されるわけではありません。
ただし、ページが検証される場合は、少なくとも、XHTML 仕様がどのように動作するかを示す力があります。妥当性が確認されない場合は、ブラウザー作成者間の非公式な取り決めがたくさんあるだけです。
一方では許可されていて、他方では許可されていない何かをしたい場合は、おそらく無効な XHTML よりも有効な HTML 3 を作成する方がよいでしょう。
XHTML を XML として利用することを計画している場合は、ページを有効で整形式にすることをお勧めします。それ以外の場合は、プレーンな古いセマンティック HTML が必要になる可能性があります。いずれにせよ、オーディエンスのニーズはバリデーターのニーズを上回ります。
非標準の属性を追加すると、どのブラウザでもレンダリングの問題が発生するという事例はまだ経験していません。
これらの非標準属性を回避しようとしないでください。バリデーターは、意図しない間違いがないかコードを再確認するためのツールとして便利ですが、ご存知のとおり、完全に有効なxhtmlでさえ、ブラウザー間で常に一貫してレンダリングされるとは限りません。設計上の決定により、効果を達成するためにブラウザー固有の(および非標準の)ハックを使用する必要がある場合がよくあります。これは、検証されていないテクノロジーを推進するサイト(google、yahooなど)の数からも明らかなように、Web開発者の人生です。
XHTML タグは、ほとんどのブラウザーで、それがない場合とは異なる方法でレンダリングされることに注意してください。DOCTYPE 属性は、ブラウザーがレンダリングするモードを決定し、何が許可され、何が許可されないかを指示します。XHTML 準拠から逸脱した場合は、必ずすべてのブラウザーで再テストしてください。
個人的には、可能な限り最新の標準に固執しますが、確実にコンプライアンスと時間/お金を比較検討する必要があり、ほとんどの場合、それは個人的な好みに帰着します.
ブラウザーに関する限り、XHTML 準拠は次の点で無意味です。
ブラウザーには XHTML パーサーがありません。これらには、 http://www.w3.org/1999/xhtml名前空間の周りに DOM を構築する、バージョン固有ではない Web 互換の HTML パーサーがあります。
XML パーサーを備えた一部のブラウザーは、application/xhtml+xml として提供される XHTML マークアップを XML として処理できます。これは XML を取得し、 http://www.w3.org/1999/xhtml名前空間の要素にデフォルトの HTML スタイルと動作を与えます。しかし、構文解析に関しては、XHTML とは何の関係もありません。一部の XHTML DTD の規則ではなく、XML 解析規則に従います。
つまり、XHTML マークアップを使用すると、ブラウザーに異質なものを与えて、意図したとおりに表示されるかどうかを確認することになります。問題は、これを任意のマークアップで行うことができるということです。意図したとおりにレンダリングされ、正しい DOM が生成される場合は、かなりうまくいっています。DOCTYPE の切り替えを念頭に置いて、ブラウザーのバグに依存していないことを確認する必要があります (バグのないブラウザーで問題が発生しないようにするため)。
XHTML 準拠が適しているのは、マークアップが適切に形成されているかどうかを確認するための構文チェック (検証による) です。これにより、解析のバグを回避できます。もちろん、これは HTML でも行うことができるので、この場合 XHTML について特別なことは何もありません。いずれにせよ、ブラウザでテストする必要があり、ブラウザ ベンダーがあらゆる種類のがらくたを受け入れることができる素晴らしい HTML パーサーを作成することを願っています。
無意味ではないのは、ブラウザーが期待するものに準拠しようとすることです。HTML5 は、この重要な時期に役立ちます。そして、HTML5 といえば、カスタム属性を自由に定義できます。<p data-order="This is a valid, custom attribute.">test</p> のように、data- を前に付けるだけです。
規則に従って模範を示しているからといって、「有効なコード」を書くことは重要だと思います。すべての開発者が Fx、Safari、Opera のコードを書いていたとしたら、IE はバージョン 8 よりも早く「ルールに従い始める」必要があったと思います。
HTML Valid であることは、通常、ユーザーとブラウザー レンダリング エンジンの両方にとって役立ちます。ブラウザが対処しなければならない癖が少なければ少ないほど、ブラウザは新しい機能の追加に集中できます。厳密にすればするほど、この f@#cking 独自のタグが他のブラウザーで機能しない理由を考える時間が減ります。
一方、XHTML は、XML ドキュメント内に統合する予定がある場合を除いて、私見ですが、より無意味です。IEはまだそれを認識しないので、固執するのはかなり役に立ちません.
ほとんどの場合、1 つを除くすべてのケースで、時間/コストと対象ユーザーのニーズを比較検討して、準拠したコードを作成しようとします。コードを 503 準拠にする必要がある場合は、準拠したコードを作成することがあなたの最善の利益であり、視聴者の利益にもなります。コードがわずかでもずれていると爆発するスクリーン リーダーがたくさんあります。
ポスターの大部分が言ったように、それは本当にあなたの聴衆が何を必要としているかです.
決して無意味ではありませんが、それを破る正当な理由はたくさんあります。CSS 開発の初期段階では、マークアップが有効な場合にブラウザーの問題を診断するのに非常に役立ちます。それ以上に、何かをしたくて、検証を破るのが最も適切な方法であると感じた場合、通常はそれで問題ありません。
カスタム属性を使用する代わりに、「rel」属性を使用することもできます。例については、Litebox (およびその類) を参照してください。
もちろん、少なくとも機能することを確認しながら、いつでも先に進んで好きなように書くことができます。もちろん、私たちはすでにこの考え方に苦しんでおり、その出力であるInternet Explorer 6を目の当たりにしています。
私は、標準指向の開発に対する Mike Davidson のアプローチの大ファンです。
コードを検証できるからといって、他の誰よりも優れているとは限りません。一体、それは必ずしもあなたが他の誰よりも優れたコードを書くことを意味するわけではありません. バンキング アプリケーションを完全に Flash で作成できる人は、あなたより優れたコーダーです。サードパーティのコードを複雑なパブリッシング環境に統合できる人は、あなたより優れたコーダーです。検証は、完璧な文法を使用するものと考えてください。それはあなたのアイデアを伝えるのに役立ち、良い教育のしるしですが、あなたが考え、その後に伝えるアイデアや概念ほど重要ではありません. 私が今まで働いた中で最もカリスマ性があり、おそらく最も賢い人は南部出身で、「ain't」という言葉を頻繁に使用していました。それは彼を賢くするものではなく、実際、彼をより記憶に残るものにしました.
多くの人が、この投稿を、標準に従ってコーディングするべきではないという意味であると誤解しています。もちろんそうすべきですが、実際に考えるべきことではありません。検証軍は常に検証しないものを非難しますが、検証は有効なコード以上のものを意味します。
したがって、原則を失うことはありませんが、基準に従えば、将来問題の深刻な問題に直面する可能性がはるかに低くなることを覚えておいてください. 提供しようとしているコンテンツは、表示方法よりもはるかに重要です。