私は最近、主要な Web サイトのほとんどがW3C のマークアップおよび CSS 検証テストに合格していないことを知りました。では、Web 標準に従うことは本当に重要なのでしょうか?
22 に答える
基準!
歴史のビット
答えに直行する前に、最新の標準の背景を述べることが重要だと思います。
W3CがXHTML 2標準の開発を試みていたことをご存知ですか? もしそれが出ていたら、以前のバージョンの HTML との下位互換性はありません。実際、反乱はW3C内で形成され、 WHATWGを作成する方法を単に分割するグループで終わりました。WHATWGは、 HTML5の背後にある真のマスター マインドです。
WC3から標準を取得するのになぜそんなに時間がかかるのか、自問したことがありますか? WC3 の仕組みは非常に民主的です。全員が同意するまで、彼らはすべてを話し合います。WHATWGはこれを少しひねって行います。問題が提起され、議論されますが、最終的な決定は編集者に委ねられます。Jeremy Keithの言葉を引用すると、「HTML5 がWHATWGで開発されている間、W3C は XHTML 2 の作業を続けていました。どこにも速く進んでいないと言うのは正確ではありません。非常にゆっくりとどこにも進んでいませんでした。」
結局、W3CはXHTML 2 をドロップし、ゼロから始めるのではなく、 WHATWGを使用することを決定しました。
スパゲッティ マークアップの復活?
HTML5 は XHTML のように厳密ではなくなりましたが、適切なコーディング プラクティスがなくなったわけではありません。HTML5 は機械仕掛けではありません。XHTML 2 とは異なり、既存の仕様に基づいて構築されています (既存のコンテンツをサポートします)。
何よりも、仕様の背後にある仲裁者は、さまざまなブラウザー ベンダーです。webkit
(Safari、Chrome)、moz
(Firefox)、またはo
(Opera)で独自の CSS 要素を見たことがありますか? これは、ベンダーが今後の仕様や、場合によっては仕様外の機能に取り組んでいることを意味するため、実際には通常のことです。Microsoft はしばらくの間、ブラウザー共有を独占し、独自の CSS 要素を作成したため、標準よりも優れているという考え方を持っていました。Microsoft は のような CSS 要素を作成しましたがfilter
、それでも私たちは何か奇妙なものを見つけました。仕様には、CSS で不透明度を扱う 2 つの異なる方法である 2 つの推奨事項があります。color 要素の RGBA と opacity 要素です。
標準の重要性
最後に、Web デザイナー/開発者には、技術や HTML5 などの標準に関して最新の状態を維持する大きな責任があると言えます。それはそこにあるすべての仕様を読むことを意味するものではありません. これが長くて退屈になることに同意します。実際、このテーマに関する本を読んだり、ブラウザー ベンダーの開発者ブログをフォローしたり、ときどき試してみたりして楽しんでください。常に例外があるため、すべての Web 標準に 100% 準拠することにもはや同意しません。私は、開発者に役立つ優れたコーディング プラクティスを使用することを好みますが、それは同時にブラウザー フレンドリーでもあります。HTML5 は既存の標準に基づいて構築されており、既存のコンテンツをサポートするように作られていることを理解することが重要です。
最後の意見: http://dowebsitesneedtobeexperiencedexactlythesameineverybrowser.com/
それはあなたの聴衆の規模に依存します。それがあなたのブログのためなら、あなたはかなりずさんになることができます. しかし、私は政府の Web サイトを作成したことがあります。そこでは、Web 標準とアクセシビリティ ガイドラインに従うことが非常に重要でした。
しかし、ええ、それをしてください。なぜあなたはしないのですか?
非常に重要です。アクセシビリティ、ユーザビリティ、ポータビリティ、それは法律 (場合によっては)、スケーラビリティ、さまざまなアプリケーション フレームワークや CMS との統合の容易さです。リストは続きますが、他のポスターがその点を十分にカバーしています。
平均的なビジネス オーナーは通常、OP と同じように「気にしない」と言います。これまでの私の最も効果的な応答は、「Google ボットは盲目のエンド ユーザーにすぎません。サイトを効果的にリストアップしたくありませんか?」というものでした。
標準に従えば、レイアウト エラーのデバッグがはるかに簡単になります。標準を無視すると、ブラウザはページをどのようにレンダリングしてもかまいません。また、1 文字を変更すると、ページのレンダリング方法が完全に変わる可能性があります。1 つのブラウザーをデバッグするのは難しいですが、IE 7、IE 6、Firefox、Opera、Safari などをデバッグし、標準を無視すると、生活が困難になります。
jQuery またはその他の DOM 操作ライブラリを使用している場合、マークアップが有効でない場合、予期しない一貫性のない結果が得られる可能性があります。
ですから、時間を無駄にしないでください。有効な HTML と CSS を記述していることを確認してください。とても簡単で、時間を節約できます。
あなたはhtml、css、c、java...何にでも適用される簡単なルールに従うことができます。
あなたがそれらを無視する正当な理由がない限り、標準に固執してください。あなたが標準文書に固執しないのなら、なぜそうしないのですか。
回避策を記述したり、コードを高速化したりするために、標準に違反しなければならない状況に遭遇することがあります。
標準を無視しなければならないと感じるときはいつでも、なぜそれをしたのかをメモする必要があります。そうすれば、あなたやhtml(またはCMSコード)に出くわした別の開発者は、これがバグではないことを知っています。
そして、はい、「正当な理由」が期限またはサーバーのクラッシュである場合があります。あなたが文書化する限り、それは大丈夫です。
追加の利点:標準に準拠していない非標準のhtml(またはコード)を作成することが例外である場合、クリーンなコードを作成することに慣れている可能性があります。
ブラウザーやその他の Web ベースのリーダーは、標準に従うことを開発者に依存しており、ほとんどの場合、標準に従うことは難しくありません。ですから、できる限り最善を尽くしますが、それらに従うために非生産的にならないようにしてください。
これらの大きなサイトの特徴は、サイトが機能し続けることを保証するプログラマーの軍隊を持っていることです。
あなたは?そのためにお金を使う気はありますか?
標準に従わない場合の問題は、明日のブラウザーでサイトがどのように機能するかについて保証がないことです。
次に、アクセシビリティやサイトを解析する自動ツールの有効化など、他の問題があります。これが検索エンジンのウェブ クローラーであれ、マイクロフォーマットから入手できる情報を集約するサイトであれ、目の不自由な人のためのスクリーン リーダーであれ、サイトを読むために必要なその他の数十のツールであれ、それらができるという保証はありません。ランダムなタグのスープである場合は、サイトを解析してください。
次に、あなた自身が私たちに提供するツールがあります。jQuery やその他の JavaScript ライブラリは、奇妙な非標準 DOM を見つけ出すことができますか? 多分そうでないかもしれません。来週バージョンかな?知るか?
そして最後に、費用はいくらですか?準拠した HTML/CSS を書くことはそれほど難しくありません。非推奨の HTML や非標準の HTML に依存しないようにするための CSS トリックのいくつかを理解するには、ある程度の練習が必要ですが、一度理解してしまえば、典型的なずさんな非標準コードを書くのと同じくらい簡単です。もちろん、デバッグ時に HTML バリデーターなどのツールを有意義に使用できるため、作業が簡単になることもあります。いずれにせよ、サイトに 50 個の HTML エラーが含まれている場合、それを有用なものとして使用することは困難です。解決しようとしている問題に関連するものはどれですか?
W3C検証は、サイトの機能を損なうエラー(または何かを損なう可能性のあるエラー)を探しているときに考慮すべき重要な要素です。これは、エラーが作業を中断し始める前にエラーを検出する可能性のあるレーダーのようなものです。
たとえば、サイトに問題があり、それについてSOに質問を投稿したい場合は、W3Cバリデーターを使用して、問題の原因を示さないようにすることをお勧めします。
しかし...すべてのHTMLが検証されるわけではありません。最も重要なのは、おそらくHTML5だけではありません。CSSでは、ベンダープレフィックスも検証されません。それはあなたがそれらを使うべきではないという意味ですか?全くない!
検証サービスは、誤って入力された属性名、閉じられていないタグ、セミコロンの欠落、またはXHTMLDoctypeのタグを見つけるのに最適です<br>
。<video>
バリデーターがタグの機能を知らないという理由だけで検証されない要素については心配しません。これはまだ正しいです。
要するに - 非常に。クロスプラットフォームおよびクロスブラウザの互換性のために、これは重要です。
それらを T まで追跡する必要がありますか? そうでない場合は、おそらく大丈夫です。
厳格な基準に従わないものの多くは、時間の経過とともに変更されたレガシー アプリケーションです。
私の意見では、新しいプロジェクトで厳格な基準に従わない理由はありません。
イアン
最終的に、標準は開発者に利便性を提供することを意味します。「標準」であることにより、一連の異なる要件の代理として機能するため、標準に従う場合:
- コードがさまざまなテクノロジ (ブラウザ、プラットフォーム、バージョン) で動作することを理解する
- あなたのコードがさまざまな人に機能することを知ってください (アクセシビリティ)
- クライアントはその事実に基づいてコードを受け入れます (プロジェクトには標準への準拠が必要です)
- 私が考えていない他のもの
Web 標準の「時間を節約」した実績はかなり複雑です。検証を取得するために何時間も費やして、ブラウザが標準をサポートしていないことが判明することがよくあります。私にとっては、通常、ページを検証することで時間を節約できます。
手元の問題に戻る: いつそれらを使用するか。これが私の実用的な見解です。要件をもう一度見てください (ブラウザ、プラットフォーム、バージョン、アクセシビリティに関して)。これらすべてを目指すアプローチと、標準に加えて標準に欠けているものすべてを目指すアプローチを比較してください。要件のリストに「標準」を追加すると、時間を節約できますか?それとも、プロジェクトを完了するための別の負担が増えるだけですか?
余談ですが、ウェブ標準に従うのはたいした努力ではありません。慣れてくると、そうしないとどれだけの努力が必要かすぐにわかります。Web標準を使用すると、通常、代わりに使用したい古い学校のレイアウト手法と比較して、より少ないコード(=より短い書き込み時間)、より読みやすいコード、および「将来性のある」コードが生成されます。
サポートしたいすべてのブラウザーですべてが機能する場合、HTML コードが実際に検証されることはそれほど重要ではありません。ただし、XHTML の場合は重要です。XHTML を使用するということは、コードを XML パーサーで読み取れるようにすることを意味するため、有効な XHTML ではないものをそのように宣言するべきではありません。
しかし、標準に準拠したコードを作成することは難しくありません。つまり、わざわざエラーを修正しない人は、プロ意識が欠けていることを示しています。標準を無視することもあるかもしれませんが、それは常に意識的な決定である必要があります。たとえば、Google のホームページは速度とクロス ブラウザのサポートのために最適化されており、広範囲にテストされています。そのようなテストと継続的なサポートのためのリソースがない場合は、標準に固執する必要があります。
HTML 検証は、ある程度までは便利であることがわかりました。
その時点以降 (つまりバリデーションが常識から引き継がれる場所) は障害になります。バリデーションは非常に便利な開発ツールですが、100% 準拠する必要はないと思います。たとえば、XHTML Strict 仕様ではtarget=""
セレクターが非推奨になっているため、上記のコードを使用せずに同じアクションを実行するには、有効な JavaScript コードが必要です。
jQuery(document).ready(function($) {
$('a').each(function(){
if (($(this).attr('rel')=='external') ||
($(this).attr('rel')=='nofollow'))
{
$(this).attr('target','_blank');
}
});
});
単純なロジックや適切なプログラミングに逆らうのではなく、上記を実装するためにtarget=""
、CSS は通常検証する必要がありますが、例外があります。ブラウザのハッキングとベンダー固有のタグは、現在のブラウザ環境では必要悪であり、コードを無効にしますが、ほとんどの主要なブラウザで機能するため、本当にあなた次第です。100% 準拠してジャンプすることができますあなたのサイトに「XHTML Valid」や「HTML5 Valid」などと書かれた素敵な小さなバッジを付けるか、うまく機能するきちんとした機能的でクリーンなコードのサイトを作成することができます。
PS私が炎上して偽善者と呼ばれる前に、はい、個人のブログサイトに1つ持っていますが、とにかく現時点では私のコードは有効ではありません.
さらに読む: http://net.tutsplus.com/articles/general/but-it-doesnt-validate/
Webサイトを仕様どおりに機能させ、今日最も一般的に使用されているブラウザー全体で一貫して機能させることがすべてです。実用的には、Web標準は優先されません。
これがこの質問に対する私の見解です。
まず、このビットに取り組みます。
「最近、主要なWebサイトのほとんどがW3CのマークアップとCSS検証テストに失敗していることがわかりました。したがって[...]」
大企業はしばしば麻痺に苦しむ可能性があり、小さな変更を加えることさえ非常に困難になります。ほとんどの場合、「大企業」の慣行は従うべき良い例ではありません。彼らはウェブサイトの構築が不十分であるため、「大企業」ではありません。その逆です。彼らは大きくなり、検証エラーを修正するためにWebサイトに変更を加えることは、ますます多くの費用がかかる、ますます長いプロセスになります(変更を承認する必要がある人々の長いリストがあります!)
それでは、大企業の手荷物を気にせずに、次のビットに移りましょう!
「[...]Web標準に従うことは本当に重要ですか?」
これは2つの状況で答えることができます。あなたがスタックオーバーフローについて尋ねているので、最初の段落はおそらくあなたに当てはまると思います:)
プロのWeb開発者の場合は、明示的に要求されない限り、常に標準に従う必要があります(1を参照)。これを行う理由は、マークアップ、アクセシビリティ、およびブラウザの互換性を検証できることが、プロフェッショナルなWebサイトを作成するための技術の一部であるためです。
あなたが主題愛好家(たとえば、珍しい昆虫の専門家)である場合-ひどいマークアップを含むWebページを公開することは可能であり、ブラウザはすべて同じ方法でエラーを処理する必要があります-非常に少なくとも、誰もが情報を読むことができるはずです。Webは、専門の開発者だけでなく、誰でもWebページを公開できるためです。
1)「そうしないように明示的に要求された」?いったいそれはどういう意味ですか。これは、標準に従わなくても、すべてのブラウザで機能するWebサイトを作成できることを意味します。この記事で説明されているように、Googleは検索ページで非常に意図的にいくつかの非常に奇妙なマークアップを使用しています。
http://www.stevefenton.co.uk/Content/Blog/Date/201008/Blog/Google-Deliberately-Write-Awful-HTML/
今すぐプロジェクトを提供したい場合は、必要なすべての基準を破ってください。
ただし、現在および将来(追加の作業なしで)配信する場合は、標準に厳密に準拠してください。
ええと、あなたが言ったように、ほとんどの大規模な Web サイトは標準に従っていません。したがって、大規模な Web サイトが必要な場合は、標準に従わない方がよいでしょう。:)
しかし、いいえ、標準に従うのが最善です。これにより、サイトがほとんどのブラウザーで機能し、将来のほとんどのブラウザーでも非常に長い間機能し続けるという最大の変化が得られるからです。
いくつかの例外があり、それらは主に一部のブラウザー (またはブラウザーの一部のバージョン) が標準に従っていないために発生します。そのため、サポートしたいすべてのブラウザーでサイトを機能させるには、いくつかのトリックやハックが必要になる場合があります。これらのトリックのほとんどは、標準に従っている間に適用できますが、パフォーマンスの向上や実装やメンテナンスの容易化につながるものもあります。
したがって、一般的には標準に従うのが最善ですが、常に 1 つまたは 2 つの例外が存在する可能性があります...
最初に行うことは、ターゲット環境でテストすることです。機能していて検証に失敗した場合、それはおそらく小さなポイントですが、当然調査する価値があります. 可能な限りアクセシビリティに努めたいコース。
プロジェクトの規模やご予算によって異なります。何かをすぐに終わらせる必要があり、機能がそれほど多くなく、主な目的が何かを成し遂げて先に進むことである場合、標準は重要ではありません。プロジェクトが非常に小規模な場合、標準に準拠するために 2 倍の時間を費やすことになります。
ウェブサイトの設計者が歴史的にウェブ標準に従わなかった唯一の理由は、(1) 標準をまったく認識していないか、(2) 標準に準拠していないブラウザ (*咳 IE咳) にクールなことをさせるためです。しかし、Internet Explorer は最近、標準の互換性に向けて大きな動きを見せているため、理由 (2) の関連性はますます低下しており、明らかに理由 (1) の影響を受けません。それなら、標準に準拠した Web サイトを作成してみませんか? 他の人が言ったように、さまざまなブラウザーをたくさん使うのではなく、1 つの標準で作業するだけでよいため、コードのデバッグがはるかに簡単になります。
W3C 標準は非常に便利ですが、目的を達成するための手段であり、それ自体が目的ではありません。これらの標準の最終目標は、クロス ブラウザーの互換性であり、これは非常に重要です。W3C の標準は、対象ユーザーが使用するさまざまなブラウザーすべてでアプリケーションが正しく動作することを確認するために次の役割を果たします。SEO を念頭に置くと、Web 標準にも多くの価値が生まれます。標準を遵守することで、人間以外のユーザーがサイトをより見やすくすることができます。したがって、検索エンジンの可視性に関心がある場合は、Web 標準も同様に考慮する必要があります。これは、「主要な Web サイト」 (検索エンジンで既に十分に確立されているため) にとっては大きな問題ではないかもしれませんが、あなたにとってはそうかもしれません。
そのため、Web 標準は、ブラウザー間の互換性と検索エンジンの最適化のために重要です。
ここで Hotmail を使っている人はいますか? Firefox のメジャー リリースごとに、Microsoft は、最新の Firefox リリースに取り残されないように、Hotmail Web サイトに戻って変更を加える必要があることに気づいたことがありますか?
開発者が標準を尊重していれば、そうする必要があったでしょうか? どのくらいの時間とお金を節約できますか? その時間/お金のうち、新しいテクノロジーや新機能にどれだけ投資できるでしょうか?
あなたは、主要な Web サイトのほとんどが W3C のマークアップおよび CSS 検証テストに合格していないとおっしゃっています。ほとんどのウェブサイトを見てください。彼らは現代的に見えますか?それらは検証するもののように見えますか? 彼らは最新かつ最高の機能を最初に実装したのでしょうか、それとも古くて時代遅れのテクノロジの維持に行き詰まり、熱狂的かつたゆみなくカードの家を維持しようとし、変化の風がそれを打ち負かさないことを望んでいますか?
私たちが下すすべての決定には機会費用があります。標準をスキップすることの機会費用が、収益性の高いビジネス パートナーシップを築く場合があります。また、特に無知のために標準が守られていない場合は、バグ、ランダムな動作、および推測ゲームのためにコストが取り残されています. 場合によっては、標準に従うことで、今後何年にもわたって新しい機能を追加できる拡張性のあるプラットフォームを作成できます。