ニュースソース：コムシャープ
2008 年後半に Web デザイナーとして、コードで Table を使用していることを認めるのは恥ずかしいですか? もしそうなら、あなたは勇気のある人です。夕方に Web サイトを広告のようにデザインできるのです。ただし、ソース コード内で Table を使用していることを誰にも知らせないでください。これは、ズボンを引き上げて白い靴下を履いていることに気づいた営業マンのようなものです。
Table は非常に醜くて肥大化しています。たとえ単純なコンテンツを表示するだけであっても、<table><tr><td> という 3 つの基本タグが必要であり、<div とは異なり、乱雑な属性が各タグに追加されます。 > シンプルですっきりしていて、CSS との相性も抜群です。実際にはボックスのようなものを入れて、自由に配置できます。 1 つのレイアウトであっても構いません。CSS 定義を変更するだけで、まったく新しいレイアウトが生まれます。Table とは異なり、Table は食堂のサイドボードのようなもので、行と列があり、私たちのものと同じように、素朴で油っこいものです。両親はだらしなく、すべてを家に持ち帰り、部屋の隅に無造作に積み上げている。ディヴが小ブルジョワジーであるとすれば、テーブルはこの時代に属していない。
つまり、ここ数年、せいぜい 3 ～ 5 年ほどの間、W3C は誰もが重要だと思っていますが、その公式 Web サイトは、私がこれほど醜い Web サイトを見たことがないと断言します。しかし、彼らの Web サイトは、すべての W3C 標準検証に合格できる数少ない Web サイトの 1 つです。つまり、Web サイトは依然として非常に醜いものの、文法、構造、アクセシビリティの点で完璧です。しかし、これは冗談です。W3C は非常に重要です。そうでないと、Microsoft はすべての Web 開発エンジニアを取り返しのつかない状況に追い込むことになります。幸いなことに、Netscape の死後、Nirvana は Firefox をリリースしましたが、Opera は Firefox の誕生後に何の恩恵も受けませんでした。 Firefox さん、少なくともあなたは精神的なサポートを受けてきました。ついに兄があなたの面倒を見てくれるようになったのがわかりましたか?ジョブズが戻ってきた後、Apple はかつての栄光を取り戻しました。そのとき初めて、人々は Safari というブラウザが存在することを知りました。これらすべてが組み合わさって、W3C の存在が本当に必要になったのです。
W3C によれば、Table はテキスト、書式設定されたテキスト、画像、リンク、フォーム、その他の Table を収容するために使用できます...ただし、Table は純粋にドキュメントのコンテンツをレイアウトする手段として使用されるべきではありません ()。その理由は、Table がさらに、スクリーン リーダーや点字ブラウザなどの非視覚的なデバイスで Web をレンダリングすると、大きな表示デバイスでユーザーが左右にスクロールする必要があるため、Table の代わりに Web デザイナーの CSS を使用する必要があります。テーブルの定義については、W3C HTML 4.01 を参照してください。 W3C がこれを言ったのは 1999 年 12 月 24 日のことでした。CSS が誕生してから長い時間が経っていましたが、元の Web はドキュメントのオンライン版のようなもので、現在のようなプラットフォームにはなりませんでした。第一次インターネット バブルの形成に伴って、多くのポータル Web サイトがテーブル レイアウトの元祖となりました。そのホームページは、新聞全体のページを合わせたよりも大きいためです。 Complex, Table はこの点で非常に便利で、colspan と rollspan を組み合わせることで、ほぼすべての複雑なレイアウトを実現できます。
このレイアウト スタイルは、2000 年代初頭から 2000 年代半ばにかけて、特に中国で非常に人気がありました。Da Weimei の潜在意識の下では、人々は 1 ページに詰め込めるものをすべてホームページに詰め込みました。古い時代では、すべてを秩序正しく配置することはできませんが、少なくとも同じ順序で配置されていました。しかし、検索、RSS 購読、ブログに代表されるパーソナライズされた Web の出現により、人々はほとんど必要な少数の Web サイトにアクセスすることなく情報を入手できるチャネルが増えました。失神したポータルのホームページには、よりシンプルなレイアウト、明るい色、大きなアイコン、大きなバナー、そして読みやすい大きなフォントを使用した、新鮮で軽量な Web スタイルが同時に登場しました。 , CSS はすでに非常に成熟しており、Firefox、Opera、Safari などのブラウザは W3C 標準への準拠において IE よりもはるかに優れており、人々はついに CSS の威力に気づきました。 CSS の中核はレイアウトの点で Box モデルであるため、CSS をアタッチするコンテナ オブジェクトを見つける必要があります。
Div が幸運なのは、意味的には、Div がページの領域を表すためです。さらに重要なのは、それが <P> や < a> とは異なることです。特別なセマンティクスが事前に与えられています (ただし、ボックス モデルでも使用できます)。一方で、肥大化した時代を支配するテーブルに対する人々の憎しみから、時代の終わりには後継者が古いものを消去しようと懸命に働きます。時代の痕跡、古い時代の象徴や代表者の運命は、ほとんどがこのようなものです。人々はそれらを単に忘れるのではなく、それらの間に明確な線を引きます。
ここからテーブルに対するすべての不公平な扱いが始まります。これはなぜ不公平なのでしょうか? W3C はテーブル レイアウトを推奨しないのに、代わりに CSS を使用する必要があるとだけ述べています。これはどういう意味ですか?もちろんサポートされています。Table は古い HTML オブジェクトであり、そのステータスが非常に重要であるため、どのブラウザでも CSS サポートを含め、Table を最も完璧にサポートしています。 Div を受け入れると、Table も Box であることを忘れるようです。Table は全体として、Box モデルとその内部セルの点で、 Margin を除いて、Div と何の違いもありません。これはまだボックスであり、内側のボックスにはマージンの概念が含まれていないことを理解する必要があります。 Div が優れていることは言うまでもありませんが、Div + CSS と言うと、Table は CSS を使用できないと思われますが、これは大きな誤解です。
実際、Div が普及する前に、Div の初期導入者は、Table でできることなら Div でもできると自信を持って言っていましたが、彼らもその言葉を代償にしました。この価格については、Div で垂直方向のセンタリングを実現しようとしている人は私の意味を理解してくれるでしょうし、CSS Hack を使用せずに IE6 で 100% Div レイアウトを実現しようとしている人は私の意味をさらに理解できるでしょう。複数の Div 間の高さ 100% の問題、幅の適応の問題は、Div + CSS デザインに携わっている人なら誰でも遭遇する問題だと思います。この点での Table の利点は、それがいかに優れているかということではなく、古いものであり、それを無視するブラウザがないためでもあります。また、人々がデータをきれいに表示するためにテーブルを発明したためでもあります。それはとても簡単です。しかし、なぜテーブルは後にこれほど悪名を馳せることになったのでしょうか? Div 支持者は Table を次のような理由で非難しています。
コードは肥大化しています。実際のコンテンツを開始する前に、少なくとも 3 つのタグ <table><tr><td> を記述する必要があります。さらに、Table のさまざまなタグには複雑な属性定義も含まれていますが、Div には < div のみが必要です。 >ラベルです。
ページのレンダリングのパフォーマンスの問題: ブラウザーは、レンダリングを開始する前にテーブル全体を完全に読み取る必要があります。
SEO に悪影響: 検索エンジンはコンテンツを洗練されたものから分離することを好みます。
アクセシビリティが低い: 画面読み上げソフトウェアと点字ブラウザは、表の内容を十分に理解できません。
セマンティックが不十分: セマンティック Web が必要です。
記事 1: コードが肥大化している
まず、CSS で定義できないのは Table の属性だけです。このように、他のすべての属性は CSS を使用できます。 <td> と <div> は、サイズが軽く数十 K になる Web ページの場合、たとえ数十の Table が使用されていたとしても、余分なコードは無視できると思います。Table コードの肥大化について不満を言う人は、実際に確認する必要があります。コーディングの習慣によって、非常に肥大化した Table を書ける人でも、Div を書くほど簡潔ではない可能性があります。
記事 2: ページ レンダリングのパフォーマンスの問題。
私は 1.6G CPU と 1G メモリを搭載した 2004 年のラップトップを使用していますが、実際には、ページ レンダリングにテーブル レイアウトと Div レイアウトの速度の違いは見られません。わずかな違いであるため、ネットワーク自体に対する遅延は無視できます。
記事 3: 検索エンジンの最適化に役立たない
前述したように、Table 属性の代わりに CSS をできるだけ使用すると、検索エンジンは <table> を区別して生成するコードと Div の差が大きくなりません。タグ? 今のところこの声明の根拠は見つかりません。
第 4 条: アクセシビリティの低さ
これは Table に固有の欠陥ですが、ほとんどの Div + CSS ファンはこの理由で Table を拒否するわけではないようです。
第 5 条: セマンティクスが不十分である
セマンティック Web の意味は、Table と Div にだけ含まれているわけではありません。Table が表形式のデータのみに使用できるとは規定されていません。 Table の皆さん、HTML 5 を待ったほうがよいでしょう。これが本当のセマンティクスです。
この記事の目的は、Div を放棄して Table に参加させることではありません。逆に、Div が設計ニーズを満たすことができるのであれば、依然として Div が第一の選択肢ですが、Table を避ける必要はありません。その他の極端な。 Div を使用すると簡単に実現できないデザインの多くは、Table を使用すると実現できます。もちろん、何を使用するとしても、CSS を使用してコンテンツと装飾を分離する必要があります。 Div + CSS と Table + CSS は両方とも正当なデザインであるため、より簡単な方を使用してください。私の経験によれば、コンテンツの形式を予測でき、追加しようとしているコンテンツの表示形式を完全に制御できる場合、追加しようとしているコンテンツが固定されていない場合は、Div + CSS を使用する必要があります。予測することはできません。その形式に関して、ページを折りたたんだくない場合は、Table + CSS を使用するのが安全な方法です。
この記事のソース: COMSHARP CMS 著者: 35 キロメートル