HTMLのレイアウトにテーブルを使用しないのはなぜですか。
一般的な意見 は、テーブルをHTMLのレイアウトに使用してはいけないということです。
どうして？
私はこれについて良い議論を見たことがない（あるいは正直になることはめったにない）。通常の答えは：
レイアウトからコンテンツを分離する
しかし、これは誤った議論です。 クリシェ思考 。レイアウトにtable要素を使用しても、表形式のデータとはほとんど関係がないことは事実だと思います。だから何？私の上司は気にしますか？私のユーザーは気にしますか？
Webページを維持しなければならない私または私の他の開発者...テーブルは保守性が低いのでしょうか。テーブルを使うことはdivとCSSを使うよりも 簡単 だと思います。
ところで、なぜdivやspanを使ってレイアウトやテーブルからコンテンツをうまく分離できないのでしょうか。 divだけで良いレイアウトを得るためにはしばしば入れ子になったdivがたくさん必要になります。コードの読みやすさ
それは逆だと思います。ほとんどの人はHTMLを理解しますが、CSSを理解する人はほとんどいません。SEOはテーブルを使わないほうがいい
なぜ？誰かがそれがあるという何らかの証拠を示すことができますか？それとも、テーブルはSEOの観点から推奨されていないというGoogleの声明？テーブルは遅くなります。
追加のtbody要素を挿入する必要があります。これは現代のWebブラウザの落花生です。テーブルを使用するとページが大幅に遅くなるベンチマークをいくつか表示します。レイアウトを見直すことは、テーブルがなくても簡単です。 css Zen Garden を参照してください。
アップグレードが必要なほとんどのWebサイトにも新しいコンテンツ（HTML）が必要です。 Webサイトの新しいバージョンが新しいCSSファイルしか必要としないというシナリオは、それほどありそうもありません。 Zen GardenはNiceのWebサイトですが、少し理論的なものです。 CSSの 誤用 は言うまでもありません。
私は本当にテーブルの代わりにdivs + CSSを使う良い議論に興味を持っています。
私はあなたの議論を次々に見て行き、それらの中のエラーを見せようとします。
レイアウトからコンテンツを分離するのは良いことですが、これは誤った議論です。クリシェ思考。
HTMLは意図的に設計されているので、それはまったく誤謬ではありません。要素の誤用は全く問題にならないかもしれません（結局、他の言語でも新しい慣用句が開発されました）が、否定的な影響の可能性を相殺する必要があります。さらに、今日の<table>要素の誤用に反対する意見がなかったとしても、ブラウザのベンダーがこの要素に特別な扱いをする方法のせいで、明日があるかもしれません。結局のところ、彼らは「<table>要素は表形式のデータ専用である」ことを知っていて、レンダリングエンジンを改善するためにこの事実を使用し、その過程で<table>の振る舞いを微妙に変更し、以前は誤用されていたケースを壊します。
だから何？私の上司は気にしますか？私のユーザーは気にしますか？
依存します。あなたの上司は先のとがった髪ですか？それから彼は気にしないかもしれません。彼女が有能なら、彼女は気にするでしょう、なぜならユーザーは 意志 です。
たぶん私または私の仲間の開発者がWebページを管理しなければならないのですが...テーブルの保守性は低いですか？テーブルを使うほうがdivやcssを使うよりも簡単だと思います。
プロのWeb開発者の大多数はあなたに反対しているようです[要引用]。テーブルareは実際には保守性が低いことは明らかです。レイアウトにテーブルを使用するということは、企業のレイアウトを変更すると、実際にはすべてのページを変更することになるということです。これはvery高価になる可能性があります。一方、意味的に意味のあるHTMLをCSS mayと組み合わせて慎重に使用すると、そのような変更がCSSと使用される画像に限定されます。
ちなみに...なぜdivやspanを使ってレイアウトやテーブルからコンテンツを分離するのがうまくいかないのでしょうか。 divだけで良いレイアウトを得るためにはしばしば入れ子になったdivがたくさん必要になります。
深くネストされた<div>sは、テーブルレイアウトとまったく同じアンチパターンです。良いウェブデザイナーはそれらの多くを必要としません。一方、そのような深くネストされたdivでも、テーブルレイアウトの多くの問題はありません。実際、コンテンツを論理的に部分に分割することによって、意味構造にも貢献できます。
コードの読みやすさ私はそれが逆だと思う。ほとんどの人はhtmlを理解しますが、少しはcssを理解します。もっと簡単です。
「ほとんどの人」は関係ありません。専門家が関係します。専門家にとって、テーブルレイアウトはHTML + CSSよりもはるかに多くの問題を引き起こします。これは、メモ帳がほとんどの人にとって単純なので、GVimやEmacsを使うべきではないと言うようなものです。あるいは、MS Wordはほとんどの人にとって単純なので、LaTeXを使うべきではありません。
SEOはテーブルを使わないほうがいい
これが本当かどうか、そしてこれを議論として使用しないのかどうかはわかりませんが、それは論理的なことです。検索エンジンはrelated dataを検索します。表形式のデータはもちろん関連性がありますが、ユーザーが検索するものはめったにありません。ユーザーはページタイトルまたは同様に目立つ位置で使用されている用語を検索します。したがって、表のコンテンツをフィルタ処理から除外して、処理時間（およびコスト）を大幅に削減することは理にかなっています。
テーブルは遅くなります。追加のtbody要素を挿入する必要があります。これは現代のWebブラウザの落花生です。
余分な要素はテーブルが遅くなることとは何の関係もありません。一方、テーブルのレイアウトアルゴリズムははるかに難しく、ブラウザは多くの場合、コンテンツのレイアウトを開始する前にテーブル全体がロードされるのを待たなければなりません。さらに、レイアウトのキャッシュは機能しません（CSSは簡単にキャッシュできます）。これについてはすべて前述しました。
テーブルを使用するとページが大幅に遅くなるベンチマークをいくつか表示します。
残念ながら、ベンチマークデータはありません。この議論に特定の科学的厳密性が欠けているのは当然のことであるので、私はそれに興味を持っています。
アップグレードが必要なほとんどのWebサイトにも新しいコンテンツ（html）が必要です。 Webサイトの新しいバージョンが新しいCSSファイルのみを必要とするシナリオは、あまりありません。
どういたしまして。私は、デザインの変更がコンテンツとデザインの分離によって単純化されたいくつかのケースに取り組んできました。いくつかのHTMLコードを変更することが依然として必要なことがしばしばありますが、変更は常にはるかに制限されます。加えて、設計変更は時々動的に行われなければならない。 WordPressブログシステムで使用されているようなテンプレートエンジンを検討してください。テーブルレイアウトは文字通りこのシステムを殺すでしょう。私は市販のソフトウェアについても同じようなケースで取り組んできました。 HTMLコードを変更せずにデザインを変更できることは、ビジネス要件の1つです。
別物。テーブルレイアウトにより、Webサイトの自動解析（スクリーンスクレイピング）がはるかに困難になります。結局のところ、誰がそれをするのですか？びっくりしました。問題のサービスがそのデータにアクセスするための代替のWebサービスを提供していない場合は、画面のスクレイピングが非常に役立ちます。私はこれが悲しい現実であるバイオインフォマティクスで働いています。最近のWeb技術やWebサービスは、ほとんどの開発者には届いていません。また、データを取得するプロセスを自動化する唯一の方法はスクリーンスクレイピングです。多くの生物学者がまだそのようなタスクを手動で実行しているのも不思議ではありません。何千ものデータセットに。
これが simliarスレッドからの私のプログラマーの答えです
セマンティクス101
まずこのコードを見て、ここで何が悪いのか考えてみてください。
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
問題は、もちろん、自転車は車ではないということです。車のクラスはバイクのインスタンスには不適切なクラスです。コードにエラーはありませんが、意味上は正しくありません。プログラマーにはあまり反映されていません。
セマンティクス102
これを文書のマークアップに適用しましょう。あなたの文書が表形式のデータを提示する必要がある場合、適切なタグは<table>になります。ただし、テーブルにナビゲーションを配置すると、<table>要素の意図した目的を誤用してしまいます。 2番目のケースでは、表形式のデータを提示していません - プレゼンテーションの目標を達成するために<table>要素を（誤って）使用しています。
結論
訪問者は気づくでしょうか？いいえ、あなたの上司は気にかけていますか？多分。プログラマーとして時々コーナーを切りますか？もちろんです。しかし、私たちは？いいえ。セマンティックマークアップを使用すると誰が利益を得ますか？あなた - そしてあなたの職業的評判 - 今行って正しいことを行います。
明白な答え： CSS Zen Garden をご覧ください。テーブルベースのレイアウトでも同じことが簡単にできる（HTMLは変更されていないことを覚えておいてください）と言ったら、レイアウトには必ずテーブルを使用してください。
他に2つの重要なことは、アクセシビリティとSEOです。
どちらも情報が表示される順序を気にしています。テーブルベースのレイアウトでページ上の2番目のネストしたテーブルの2行目の3番目のセルにナビゲーションを配置した場合、ナビゲーションをページの上部に簡単に表示することはできません。
だからあなたの答えは保守性、アクセシビリティとSEOです。
怠けないでください。たとえそれらが学ぶのが少し難しいとしても、物事を正しく適切な方法で行いなさい。
あなたが忘れているのは、アクセシビリティです。たとえば、スクリーンリーダーを使用する必要がある場合、テーブルベースのレイアウトも変換されません。あなたが政府のために働いているなら、スクリーンリーダーのようなアクセス可能なブラウザをサポートすることは required かもしれません。
私はまたあなたが質問で述べたことのいくつかの影響を過小評価していると思います。例えば、あなたがデザイナーでもプログラマーでもあるならば、それがプレゼンテーションとコンテンツをどの程度うまく分離しているかについて十分に理解していないかもしれません。しかし、それらが2つの異なる役割である店に入ると、その利点はより明確になり始めます。
自分のしていることを知っていて、優れたツールを持っているのであれば、CSSはレイアウトに関してテーブルよりも大きな利点があります。そして、各項目はそれ自体ではテーブルを放棄することを正当化できないかもしれませんが、まとめるとそれは一般的に価値があります。
残念ながら、CSS Zen Gardenは、優れたHTML/CSSデザインの例として使用できなくなりました。最近のほぼすべてのデザインで、セクション見出しにグラフィックが使用されています。これらのグラフィックファイルはCSSで指定されています。
そのため、コンテンツをデザインから除外することの利点を示すことを目的としているWebサイトでは、現在、コンテンツをデザインにすることをゆるぎない罪で犯しています。 （HTMLファイルのセクション見出しが変更された場合、表示されているセクション見出しは変更されません）。
これは、DIVとCSSの厳格な宗教を支持する人々でさえ、自分たちの規則に従うことができないことを示しているにすぎません。あなたはそれらをどれだけ厳密にフォローするかの指針としてそれを使うことができます。
これは絶対的な議論ではありませんが、CSSを使用すると、同じマークアップを使用してメディアに応じてレイアウトを変更できます。これは素晴らしい利点です。印刷ページの場合は、たとえば、印刷用ページを作成しなくても、静かにナビゲーションを抑制できます。
レイアウトのための一つのテーブルはそれほど悪くないでしょう。しかし、ほとんどの場合、1つのテーブルだけでは必要なレイアウトを取得できません。もうすぐ2つか3つのネストした表があります。これは非常に面倒になります。
それはIS読むのがより難しいです。それは意見次第ではありません。識別用のマークが付いていないタグがネストされているだけです。
プレゼンテーションからコンテンツを分離することは、自分がしていることに集中できるため、良いことです。 2つを混在させると、読みづらいページが肥大化します。
スタイルのCSSを使用すると、ブラウザでファイルをキャッシュすることができ、それ以降の要求ははるかに高速になります。これは巨大です。
テーブルはあなたをデザインに固定します。確かに、誰もがCSS Zen Gardenの柔軟性を必要としているわけではありませんが、デザインを少しでも変更する必要がないサイトで作業したことは一度もありません。 CSSの方がずっと簡単です。
テーブルはスタイルが難しいです。それらにはそれほど柔軟性がありません（つまり、テーブルのスタイルを完全に制御するためにHTML属性を追加する必要があります）。
私はたぶん4年の間、非表形式のデータにテーブルを使っていません。私は振り返っていません。
CSS Mastery Andy Budd著を読むことをお勧めします。すごいね。
レイアウトからコンテンツを分離するのは良いことです
しかし、これは誤った議論です。クリシェ思考
HTMLテーブルはレイアウトなので、これは誤った議論です。内容はテーブルの data であり、プレゼンテーションはテーブルそのものです。 HTMLからCSSを切り離すことが非常に難しい場合があるのはこのためです。プレゼンテーションからコンテンツを分離しているのではなく、プレゼンテーションからプレゼンテーションを分離しているのです。入れ子になったdivの山はテーブルと同じです - それはタグの異なるセットです。
HTMLをCSSから切り離すことに関するもう1つの問題は、それらがお互いの詳細な知識を必要とすることです - あなたは本当にそれらを完全に切り離すことができません。 HTMLのタグレイアウトは、何をしてもCSSファイルと密接に関連しています。
テーブル対divはあなたのアプリケーションの必要性に帰着すると思います。
私たちが仕事で開発しているアプリケーションでは、ピースのサイズがコンテンツのサイズに合わせて動的に変わるようなページレイアウトが必要でした。私はCSSやDIVとクロスブラウザで動作させるために何日も費やしましたが、それは完全な悪夢でした。私たちはテーブルに切り替えました、そしてそれはすべてちょうど 働いた です。
しかし、私たちの製品には非常に密接な関係者がいて（私たちはWebインターフェースを備えたハードウェアの一部を販売しています）、アクセシビリティの問題は私たちにとって心配の種ではありません。スクリーンリーダーがテーブルをうまく処理できない理由はわかりませんが、それがその方法であれば開発者がそれを処理しなければならないと思います。
CSS/DIV - それはデザインの男の子たちのための仕事だけですよね。私がDIV/CSSの問題をデバッグするのに費やした何百時間ものマークアップの一部をあいまいなブラウザで動作させるためにインターネットを検索する - それは私を怒らせます。あなたは1つの小さな変更を加えると、全体のレイアウトはひどく間違ってしまいます。このようにして3ピクセル移動してから2ピクセル移動して、すべてが並ぶようにします。これはどういうわけか私には明らかに間違っているようです。あなたが純粋主義者であり、何かが「するべき正しいことではない」からといって、特にあなたの人生を1000倍容易にするならば、あなたはそれをn番目の程度そしてあらゆる状況下で利用するべきではありません。
それで、私はようやく純粋に商業的な理由で決心しました、私はDIVを正しく置くために20時間の仕事が予想されるならば、私はテーブルに固執するでしょう、私は最小に慣れ続けますが。それは間違っています、それは純粋主義者を混乱させますが、ほとんどの場合それはより少ない時間がかかり、管理するのにより安いです。そうすれば、純粋主義者を喜ばせるのではなく、顧客が望むとおりにアプリケーションを機能させることに集中できます。結局のところ、彼らは請求書を払っていますし、CSS/DIVの使用を強制するマネージャーに対する私の主張は、私も顧客が彼の給料を払っていることを指摘するだけです！
これらすべてのCSS/DIV引数が発生する唯一の理由は、そもそもCSSの欠点と、ブラウザ間の互換性がないためで、世界のWebデザイナーの半数が仕事を失うことになるからです。 。
あなたがWindowsフォームをデザインするとき、あなたがそれらをレイアウトした後にあなたがコントロールを動かすことを試みないので、私はあなたがなぜあなたがWebフォームでこれをしたいのか私にとって不思議だと思います。私は単純にこの論理を理解することができません。最初からレイアウトを正しく作成し、問題は何でしょうか。アプリケーション開発者は、実際にアプリケーションを機能させること、ビジネスオブジェクトを作成すること、ビジネスルールを実装すること、顧客データのビット間の関係を明確にすること、要件 - あなたが知っている - 現実世界のもののように。
誤解しないでください、両方の議論が有効ですが、フォームを設計するためのより簡単で、より論理的なアプローチを選ぶことについて開発者を批判しないでください。 divよりもテーブルを使うという正しい意味よりも、もっと重要なことを気にする必要があります。
その好例 - この議論に基づいて、私はいくつかの既存のtdsとtrをdivに変換しました。 45分ですべてが並んで並ぶようにしようとしていて、私はあきらめました。 10秒後にTDが戻ってきました - すぐに - すべてのブラウザでうまくいきます。私に理解させるようにしてください - 私に他の方法でそれをしてほしいと思うためにあなたがどんな可能性のある正当化を持っていますか！
レイアウトは簡単なはずです。 CSSでヘッダーとフッターを使用して動的3列レイアウトを実現する方法について書かれた記事があるという事実は、それが不適切なレイアウトシステムであることを示しています。もちろん動作させることはできますが、それを実行する方法については、文字通り何百という記事がオンラインで公開されています。明らかに明白であるため、テーブルを含む同様のレイアウトに関するそのような記事はほとんどありません。あなたがテーブルに対して何を言っても、そしてCSSを支持しても、この事実はそれをすべて元に戻す：CSSの基本的な3列のレイアウトはしばしば「聖杯」と呼ばれる。
それでも "WTF"と言わない場合は、今すぐクールエイドをやめる必要があります。
私はCSSが大好きです。それは素晴らしいスタイリングオプションといくつかのクールなポジショニングツールを提供します、しかしレイアウトエンジンとしてそれは不十分です。何らかの種類の動的グリッド位置決めシステムが必要です。サイズを最初に知らなくても、ボックスを複数の軸上で整列させる簡単な方法です。 <table>や<gridlayout>などと呼んでも気にしませんが、これはCSSにはない基本的なレイアウト機能です。
より大きな問題は、欠けている機能があることを認めないことによって、CSS熱狂者たちはCSSを可能性のあるものすべてから差し控えてきたということです。 CSSが基本的に世界中の他のすべてのレイアウトエンジンのようにまともな多軸グリッドポジショニングを提供するならば、私はテーブルの使用をやめて完全に幸せです。 （この問題がW3Cを除くすべての人によってすでに多くの言語で何度も解決されていることをご存知でしょうか？そして、そのような機能が有用であることを否定する者は他にいませんでした。）
ため息十分な通気。頭を砂の中に戻してください。
508準拠（視覚障害者用スクリーンリーダーの場合）によると、テーブルはデータを保持するためにのみ使用され、スクリーンリーダーがおかしくなる原因となるためレイアウトには使用しないでください。それとも私は言われました。
各divに名前を割り当てる場合は、CSSを使用してそれらをまとめてスキンすることができます。彼らはあなたがそれらを必要とする方法で座ることを得るために得ることはもう少しの痛みです。
これは最近のプロジェクトからのhtmlのセクションです：
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<div id="header">
<h1><!-- Page title --></h1>
<ol id="navigation">
<!-- Navigation items -->
</ol>
<div class="clearfix"></div>
</div>
<div id="sidebar">
<!-- Sidebar content -->
</div>
<!-- Page content -->
<p id="footer"><!-- Footer content --></p>
</body>
</html>
そしてこれがテーブルベースのレイアウトと同じコードです。
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<table cellspacing="0">
<tr>
<td><!-- Page Title --></td>
<td>
<table>
<tr>
<td>Navitem</td>
<td>Navitem</td>
</tr>
</table>
</td>
</tr>
</table>
<table>
<tr>
<td><!-- Page content --></td>
<td><!-- Sidebar content --></td>
</tr>
<tr>
<td colspan="2">Footer</td>
</tr>
</table>
</body>
</html>
そのテーブルベースのレイアウトで私が見る唯一の清潔さは私が私の刻み目に熱心であるという事実です。コンテンツセクションにはさらに2つの埋め込みテーブルがあるはずです。
考えるべきもう一つのこと： ファイルサイズ 。私は、テーブルベースのレイアウトは、通常のCSSのレイアウトの2倍のサイズであることを発見しました。私達の高速ブロードバンドではそれは大きな問題ではありませんが、それはダイアルアップモデムを使っている人々にあります。
Divベースのレイアウトは、保守、展開、およびリファクタリングを容易にしていることを付け加えたいと思います。要素を並べ替えるためにCSSを変更するだけで完了です。私の経験からすると、テーブルを使用するレイアウトの再設計は悪夢です（ネストされたテーブルがある場合はさらに問題になります）。
あなたのコードは セマンティック の観点からも意味を持ちます。
コンテンツが自然な順序で並んでいてスタイルシートがなくても意味があるのであれば、CSSレイアウトは一般的にアクセシビリティの点ではるかに優れています。また、テーブルベースのレイアウトに苦しんでいるのはスクリーンリーダーだけではありません。モバイルブラウザでページを正しく表示することがさらに困難になります。
また、divベースのレイアウトでは、印刷ページからヘッダー、フッター、ナビゲーションを除外するなど、印刷スタイルシートを使って簡単にクールなことを行うことができます。それが不可能な、または少なくとももっと難しいと思います。テーブルベースのレイアウト。
レイアウトよりコンテンツの分離がテーブルよりdivのほうが簡単であることに疑問がある場合は、 CSS Zen Garden でdivベースのHTMLを見てください。スタイルシートを変更するとレイアウトが劇的に変わることを考えてください。 HTMLがテーブルベースの場合と同じ種類のレイアウトを実現できるかどうかについて...テーブルベースのレイアウトを使用している場合は、CSSを使用してセル内のすべての間隔と余白を制御することはほとんどありません。あなたがいた、あなたはほぼ確実に最初の場所で浮動divなどを使用する方が簡単だと思うでしょう）。 CSSを使用してこれらすべてを制御することなく、またテーブルはHTML内で左から右および上から下への順序を指定するため、テーブルはレイアウトがHTML内で非常に固定されることを意味する傾向があります。
現実的には、divを少し変更せずにdivとCSSベースのデザインのレイアウトを完全に変更するのは非常に難しいと思います。ただし、divとCSSベースのレイアウトでは、さまざまなブロック間の間隔やそれらの相対的なサイズなどを微調整するほうがはるかに簡単です。
これが熱く議論されている質問であるという事実は、試みられるであろうレイアウト設計の多様性を予想するためにW3Cが失敗したことの証です。意味的に使いやすいレイアウトにdivs + cssを使用することは素晴らしい概念ですが、実装の詳細には欠陥があるため、実際には自由度が制限されています。
私の会社のサイトの1つをテーブルからdivに切り替えようとしましたが、大変な頭痛のせいで、私がそこに注ぎ込んでいた作業時間を完全に廃止してテーブルに戻りました。垂直方向の配置を制御するために私のdivと格闘しようとすると、この議論が激しくなるまでは絶対に揺れないという大きな心理的問題に悩まされました。
単純な設計目標（垂直方向の位置合わせなど）を達成するために、人々が複雑で醜い回避策を頻繁に考え出す必要があるという事実は、規則が十分に柔軟ではないことを強く示唆しています。スペックが十分であれば、なぜ有名なサイト（SOのような）がテーブルや他の回避策を使用してルールを曲げる必要があるのでしょうか？
DIVに関する議論は私に有利ではありません。
靴が収まる場合は、それを着用してください。
2列または3列にコンテンツをレンダリングするための優れたDIV + CSS方式を見つけることは不可能ではないにしても難しいことは注目に値します。
これは私のレイアウトの大部分でテーブルに向けてバランスを取るためのヒントとなっています。私がTABLEを使うのはもっと簡単で速いです。私はその時間までには支払われていないので、テーブルは私にとっては安いです。
レイアウトにtable要素を使用しても、表形式のデータとはほとんど関係がないことは事実だと思います。だから何？私の上司は気にしますか？私のユーザーは気にしますか？
グーグルや他の自動化システム do care、そしてそれらは多くの状況で同様に重要です。セマンティックコードは、インテリジェントでないシステムにとっては解析や処理が簡単です。
あるアプリケーションによって生成された6層のネストしたテーブルを含むWebサイトで作業しなければならず、無効なHTMLを生成していたので、実際には小さな変更でそれを修正するのに3時間の仕事でした。
もちろんこれはEdgeのケースですが、テーブルベースのデザインは維持できません。あなたがCSSを使用する場合、あなたはHTMLを修正するときあなたが壊れることについて心配する必要が少ないので、スタイルを分離します。
また、JavaScriptでこれを試してください。 1つのテーブルセルを別のテーブルのある場所から別の場所に移動します。 div/spanが単にコピー＆ペースト的に機能する場所で実行するのはやや複雑です。
「私の上司は気にかけていますか」
私があなたの上司だったらあなたは気にするでしょう。あなたの人生を大切にするなら.
レイアウトの柔軟性
多数のサムネイルを含むページを作成しているとします。
DIV ：
各サムネイルを左に浮かせたDIVに入れた場合、10枚が1行に収まる可能性があります。ウィンドウを狭くしてBAMにしましょう - 6行、2行、あるいはそれ以上にぴったりです。
表：
あなたは一列に並んでいるセルの数を明確に言わなければなりません。ウィンドウが狭すぎる場合、ユーザーは水平方向にスクロールする必要があります。
保守性
上記と同じ状況です。 3行目に3つのサムネイルを追加します。
DIV：
それらを追加します。レイアウトは自動的に調整されます。
TABLE： 3番目の行に新しいセルを貼り付けます。 おっとっと！ 今そこにはたくさんのアイテムがあります。その行からいくつか切り取り、それらを4行目に置きます。今そこにはたくさんのアイテムがあります。その行からいくつか切り取ります...（etc）
（もちろん、サーバーサイドのスクリプトを使用して行とセルを生成しているのであれば、これはおそらく問題にはなりません。）
ボートが出航したと思います。業界の方向性を見れば、CSSとOpen Standardsがその議論の勝者であることに気づくでしょう。これは、フォームを除いて、ほとんどのHTML作業に意味があります。デザイナーはテーブルの代わりにdivを使用します。私はCSSの第一人者ではありませんが、それがそうであるので、私はそれで苦労します。
また、忘れないでください。テーブルはモバイルブラウザではうまく表示されません。確かに、iPhoneにはキックアスブラウザがありますが、誰もがiPhoneを持っているわけではありません。テーブルのレンダリングは現代のブラウザにとっては落花生になることがありますが、モバイルブラウザにとってはスイカの束です。
私は個人的に多くの人があまりにも多くの<div>タグを使用していることを発見しました、しかし適度に、それは非常にきれいで読みやすいことができます。皆さんは、人々はテーブルよりもCSSを読むのが難しいと言っています。 「コード」の点では本当かもしれません。しかし、コンテンツを読むという点で（ビュー>ソース）、テーブルよりもスタイルシートの方が構造を理解するのがはるかに簡単です。
あなたはただテーブルに慣れているようですが、それで終わりです。レイアウトをテーブルに入れると、そのレイアウトだけに制限されます。 CSSを使えば、ビットを動かすことができます。 http://csszengarden.com/ を見てください。いいえ、レイアウトに通常入れ子になったdivは必要ありません。
レイアウトと適切なセマンティクスのためのテーブルがないので、HTMLははるかにきれいで、したがって読みやすくなります。 CSSを理解できない人がそれを読もうとするのはなぜですか？そして誰かが自分自身をwebdeveloperであると考えるならば、CSSの十分な把握は必須です。
SEOの利点は、最も重要なコンテンツをページの上位に配置し、コンテンツとマークアップの比率を向上させることができることにあります。
セマンティックマークアップに関する全体的な考えは、マークアップとプレゼンテーションの分離です。これにはレイアウトが含まれます。
Divはテーブルを置き換えるのではなく、コンテンツを関連するコンテンツのブロックに分離する際に独自の用途を持っています（、）。スキルがなく、テーブルに頼っている場合は、目的のレイアウトにするためにコンテンツをセルに分割する必要があることがよくありますが、セマンティックマークアップを使用する場合は、マークアップに触れる必要はありません。これは、静的ページではなくマークアップが生成されているときに本当に重要です。
開発者は、コンテンツを提示するスキルを持っている人が仕事に取り組むことができるようにレイアウトを暗示するマークアップを提供することをやめる必要があります。
- 508コンプライアンス - スクリーンリーダーがあなたのマークアップを理解する能力。
- レンダリング待ち - テーブルが
</table>要素の終わりに達するまでブラウザ内でレンダリングされません。
これは本当に 'divがレイアウトのためのテーブルより優れている'かどうかについてではありません。 CSSを理解している人なら誰でも、「レイアウトテーブル」を使って簡単にデザインを複製できます。一番のメリットは、HTML要素を目的に使うことです。非タブラータデータにテーブルを使用しないのは、整数を文字列として格納しないのと同じ理由からです。設計目的で使用すると、テクノロジははるかに簡単に機能します。レイアウトにテーブルを使用する必要があったのであれば（1990年代初頭のブラウザの欠点のため）、それは確かに今ではありません。
ページレイアウトの中央のコンテンツ列がサイドバーの前に読み込まれて表示されるように、CSSとdivを理解する価値があります。ただし、ロゴをスポンサーシップテキストと垂直に揃えるために浮動divを使用するのに苦労している場合は、単に表を使用して生活を進めてください。禅の庭の宗教はただ支出に大きな衝撃を与えません。
プレゼンテーションからコンテンツを分離するという考えは、さまざまな種類の作業がさまざまなコードブロックに影響を与えるようにアプリケーションを分割することです。これは実際には変更管理についてです。しかし、コーディング標準は表面的な方法でのみコードの現在の状態を調べることができます。
「プレゼンテーションからコンテンツを分離する」ためにコーディング標準に依存するアプリケーションの変更履歴には、縦型サイロ全体で並行して変更が行われるパターンが示されます。 「内容」への変更が常に「表示」への変更を伴う場合、分割はどの程度成功しますか？
本当にコードを生産的に分割したい場合は、Subversionを使用して変更ログを確認してください。それから、最も単純なコーディングテクニック - div、テーブル、JavaScript、インクルード、関数、オブジェクト、継続など - を使用して、変更がシンプルで快適な方法で収まるようにアプリケーションを構成します。
テーブルは一般的にCSSよりも簡単ではなく、保守も容易ではありません。ただし、いくつかの固有のレイアウト問題があります。実際には、テーブルは最も単純で柔軟性の高いソリューションです。
CSSは、プレゼンテーションマークアップとCSSが同じ種類のデザインをサポートする場合に明らかに望ましいです。CSSでタイポグラフィを指定するよりもfont-タグの方が良いと主張する人は誰もいません。 font- tags、ただしはるかにクリーンな方法で。
ただし、テーブルに関する問題は、基本的に、CSSのテーブルレイアウトモデルがMicrosoft Internet Explorerでサポートされていないことです。そのため、テーブルとCSSはnotで同等です。欠落している部分は、テーブルのグリッドのような動作です。セルの端は縦と横の両方に整列しますが、セルはまだコンテンツを含むように拡大します。この動作は、一部の次元をハードコーディングせずに純粋なCSSで実現するのは容易ではありません。これにより、設計が硬く脆弱になります（Internet Explorerをサポートする必要がある限り、他のブラウザではdisplay:table-cellを使用して簡単に実現できます）。
したがって、テーブルまたはCSSのどちらが望ましいかという問題ではありませんが、テーブルを使用するとレイアウトがより柔軟になる特定のケースを認識するという問題です。
テーブルを使用するnotの最も重要な理由は、アクセシビリティです。 Webコンテンツのアクセシビリティガイドライン http://www.w3.org/TR/WCAG10/ レイアウトにテーブルを使用する場合のアドバイスアクセシビリティについて懸念がある場合（および場合によっては法的に義務付けられる場合があります）、テーブルが単純な場合でもCSSを使用する必要があります。 alwaysは、CSSを使用してテーブルと同じレイアウトを作成できることに注意してください。さらに作業が必要になる場合があります。
テーブルレイアウトを使用するツールは、レイアウトを作成するのに必要なコード量のために非常に重くなる可能性があります。 SAPのNetweaver PortalはデフォルトでTABLEを使用してページをレイアウトします。
私の現在のギグでの本番用SAPポータルには、HTMLのサイズが60Kを超えるホームページがあり、そのページ内で3回、7つのテーブルがあります。 Javascriptに、16個のiframeの誤用、それらの内部に似たような表の問題、過度に重いCSSなどを追加しました。ページのサイズは5MBを超えます。
帯域幅を使用してユーザーと一緒に魅力的なアクティビティを実行できるように、ページの重みを下げるために時間を割くことは、努力する価値があります。
DOM操作はテーブルベースのレイアウトでは困難です。
セマンティックdivの場合：
$('#myawesomediv').click(function(){
// Do awesome stuff
});
テーブル付き：
$('table tr td table tr td table tr td.......').click(function(){
// Cry self to sleep at night
});
さて、2番目の例は愚かなもので、テーブルやtd要素には常にIDやクラスを適用することができますが、それは意味論的価値を追加することになります。
私はいくつかの問題がまだカバーされていないのを見て驚いたので、ここに私の2セントがあります。
.1 CSSとSEO：
a）CSSは、コンテンツをページ内の好きな場所に配置できるようにすることで、SEOに非常に大きな影響を与えていました。数年前、検索エンジンは「ページ上」の要素に重点を置いていました。ページの上部にあるものは、下部にあるものよりもページに関連していると見なされました。クモの「ページのトップ」は「コードの先頭に」という意味です。 CSSを使用すると、コードが豊富なコンテンツをコードの先頭にまとめて、ページ内の好きな場所に配置できます。これはやや関連性がありますが、ページ上の要素はページランク付けにとってますます重要ではありません。
b）レイアウトがCSSに移動されると、HTMLページはより軽量になるため、検索エンジンのスパイダーの読み込み速度が速くなります。 （スパイダーは外部のcssファイルをダウンロードすることを煩わさない）。高速ロードページは、Googleを含むいくつかの検索エンジンにとって重要なランキングの考慮事項です。
c）SEO作業には、テストや変更が必要なことが多く、CSSベースのレイアウトでははるかに便利です。
.2。 生成されたコンテンツ：
テーブルは同等のCSSレイアウトよりもプログラム的に生成するのがかなり簡単です。
foreach ($comment as $key=>$value)
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
テーブルを生成するのは簡単で安全です。それは自己完結型であり、あらゆるテンプレート内にうまく統合されています。 CSSで同じことをするのはかなり難しく、まったく意味がありません。CSSスタイルシートを編集するのが難しく、スタイルをインラインで追加するのはテーブルを使用するのと同じです（コンテンツはレイアウトから分離されません）。
さらに、テーブルが生成されるときに、内容（変数内）はすでにレイアウト（コード内）から分離されているため、変更が容易です。
これが、非常によくデザインされたWebサイト（たとえばSO）がまだテーブルレイアウトを使用している理由の1つです。
もちろん、結果をJavaScriptで処理する必要がある場合、divは問題を解決する価値があります。
.3。 クイックコンバージョンテスト
特定のオーディエンスに何が効果があるのかを判断するとき、さまざまな方法でレイアウトを変更して、最良の結果が得られるものを見つけることができると便利です。 CSSベースのレイアウトは物事をかなり容易にします
.4。 さまざまな問題に対するさまざまな解決策
「みんながdivとCSSを知っている」というのが一番の理由です。
しかし、ほとんどのCSSレイアウトよりもテーブルの作成が速く、理解しやすく、堅牢であるという事実は変わりません。 （はい、CSSは同じくらい堅牢にすることができますが、さまざまなブラウザや画面解像度でネットを一目で見れば、そうではないことがわかります）
メンテナンス、柔軟性の欠如など、テーブルには多くの欠点があります...しかし、お風呂の水で赤ちゃんを投げないようにしましょう。迅速かつ信頼性の高いソリューションのための専門的な用途はたくさんあります。
ユーザーの大部分は古いバージョンのIEを使い、CSSのサポートは本当に悪いので、テーブルを使ってきれいでシンプルなCSSレイアウトを書き直す必要がありました。
私は、1つには、「ああ、いや、レイアウトのためのテーブル」というひざまずいた反応にうんざりしていてうんざりしています。
「それはその目的のために意図されたものではなかったので、あなたはこのようにそれを使うべきではない」群衆に関しては、その偽善ではありませんか？たいていのブラウザでうまく動かないようにするために必要なすべてのCSSトリックについてどう思いますか。彼らはその目的のためのものでしたか？
それは、テーブルを使用するサイトを維持することがHELLであり、そしてコード化に多くの時間がかかるからです。あなたが浮動divを怖がっているなら、それらのコースを受講してください。それらを理解するのは難しくありません、そして彼らはお尻の約100倍効率的で百万倍少ない痛みです（あなたがそれらを理解しない限り - しかし、ちょっと、コンピュータの世界へようこそ）。
テーブルを使ってレイアウトすることを考えている人は、私がそれを維持することを期待してはいけません。これは、Webサイトをレンダリングするための最も厄介な方法です。神に感謝します。私たちは今、はるかに良い選択肢を持っています。絶対に戻らないでください。
最新のツールを使用してサイトを作成することによる時間とエネルギーの利点に気付いていない人もいるかもしれません。
- 10/20の何か深いcolspan/rowspanをマージ/分割してみてください。私は本能を抑えて誰かとの闘いを始めなければなりませんでした。 [？！]
- 表示順序を変更せずにソースコードの順序を変更してください。 [SEO、ユーザビリティ、...]
- 私たちが見ている非常に（本当に単純な）ページは〜150Kです。私はきっとそれは適切なCSSを使ってほぼ半分にすることができます。 [SEO（はい、SEO、最新のGoogleスペックなどを読む）、perfo、...]
- 任意の幅で機能することができるイテレータテンプレートを作成してみてください。
- SOのこの表ベースの媒体での問題の議論は、 特異点を引き起こし、私たち全員を破壊することができます
プレゼンテーションとコンテンツを厳密に分離するという問題は、C++で実装ファイルからヘッダーファイルを分離するのとほぼ同じように私を襲っています。それは理にかなっていますが、それはまた痛みかもしれません。単一のソースファイルでクラスが定義されているJavaおよびC＃を確認します。新しい言語の作者は、プログラマーの頭痛の原因となっているものに気付いて、それを取り除きました。それがこの議論の要旨のようです。一方はCSSが難しすぎると言っています、他方はCSSマスターにならなければならないと言っています。
単純なレイアウトの問題については、プレゼンテーションは完全に別のものでなければならないという規則を曲げないのですか。 HTMLで直接プレゼンテーションを制御できるようにする新しいタグ（またはdivタグの何らかの拡張）についてはどうですか？結局のところ、私たちはすでにプレゼンテーションをHTMLにリークしていませんか？ h1、h2 ... h6を見てください。私たちは皆、これらの統制の提示を知っています。
コードを読む能力（そしてHTMLはコードです）は非常に重要です。 Gurusは、プログラミング環境をできるだけ大衆が利用できるようにすることがいかに重要であるかを見落としがちです。プロのプログラマーだけが重要であると考えるのは非常に近視眼的です。
私にとって大きな問題は、テーブル、特にネストしたテーブルは、正しくレイアウトされたcss実装よりもレンダリングに時間がかかることです。 （あなたは can cssを同じくらい遅くすることができます）。
各divは別々の要素であるため、すべてのブラウザでCSSが高速にレンダリングされます。そのため、ユーザーが読んでいるときに画面が読み込まれる可能性があります。 （巨大なデータセットなどに）私はそのインスタンスでテーブルの代わりにcssを使用しましたが、レイアウトも扱っていません。
ネストしたテーブル（セル内のテーブルなど）は、最後の "/ table"が見つかるまでブラウザウィンドウに表示されません。さらに悪いことに、定義が不十分なテーブルではレンダリングされないことさえあります。または、そうすると、物事が悪くなります。 （ "TD"などと適切に対応していない）
私はほとんどの場合テーブルを使用しますが、大規模なデータやエンドユーザーにすばやく画面をレンダリングさせたい場合は、CSSの機能を最大限に活用します。
私はこれらの両方の方法でサイトを作成しなければならず、さらに3つ目はテーブル、div、およびスタイルを含む「ハイブリッド」レイアウトです。
たった1つのテーブルセルのコードの重さに合わせるには、divを3深さにネストする必要があります。その効果はネストした表に応じて変わります。
私はまた私のサイトのすべてのページのための1つの変更に対して1つのレイアウトの変更をすることを好むでしょう。
私はdiv/cssを使ってプレゼンテーションのあらゆる面を完全に制御しています。特にIE、私がまだサポートしないオプションを持っていなかったブラウザでは、テーブルはめちゃくちゃな方法で混乱します。
Divs/cssウェブサイトのメンテナンスや再設計のための私の時間は、それがテーブルにあるもののほんの一部です。
最後に、CSSとほとんどすべてのスクリプト言語を使用して、切り替え可能な複数のレイアウトを革新できます。テーブルではそれは不可能です。
あなたがその決断をするときあなたのROIで頑張ってください。
一例として、ページのメインコンテンツ領域を中央に配置したいが、その中にフロートを含めるには、フローティングする必要があります。 CSSには "float：center"はありません。
それが中心の要素の中に「フロートを含む」ための唯一の方法ではありません。だから、まったく良い議論ではありません！
ある意味で、それは誤った前提、「divs vs tables」のことです。
ページを3列にすばやく分割する正直に言うと、テーブルareは簡単です。しかし、ページ要素のページ内への配置をロックするため、専門家はレイアウトのためにそれらを使用することはもうありません。
本当の議論は、「ページ内のHTMLによって行われる配置」とは対照的に、「CSSによって行われる配置（おそらくリモートファイル内での配置）」です。確かに誰もが後者とは対照的に前者の利点を見ることができますか？
- サイズ - あなたのページレイアウトがHTML、ページの中にある場合、それはキャッシュすることができず、そしてそれはすべてのページで繰り返されなければなりません。レイアウトがページ内ではなくキャッシュされたCSSファイル内にある場合は、大量の帯域幅を節約できます。
- 複数の開発者が同時に同じページに取り組むことができます - 私はHTMLに取り組んでいます、他の人はCSSに取り組んでいます。リポジトリは不要、上書き、ファイルロックなどの問題はありません。
- 変更を加えるのは簡単です - 異なるブラウザでのレイアウトに問題があるでしょう、しかしあなたはそれらを整理するために1つのファイル、CSSファイルを修正するだけでよいです。
- 前述したように、アクセシビリティ。テーブルは二次元レイアウトがすべての人のために働くと仮定しています。それは、一部のユーザーがあなたのコンテンツを見る方法ではなく、Googleがあなたのコンテンツを見る方法でもありません。
このことを考慮：
[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]
6つのセルを持つテーブルの2行を表します。 2-Dテーブルレイアウトを見ることができる人は、各写真の下にキャプションを見るでしょう。しかし、音声合成、またはPDAを使用して、そして検索エンジンスパイダーのために、それはそれです
picture picture picture caption caption caption
そして、テーブルが適切に配置されていれば、その関係は明らかになります。
DIVとCSSはできるだけ短い時間で特定のデザインを達成するためにHTMLページ上に長方形をレイアウトするだけのことですのタスクに向いていますか？} _いいえ、そうではありません。しかし、私は与えられたデザインを達成するために長方形をすばやくレイアウトすることはしていません。もっと大きな絵を考えています。
コンテンツとレイアウトを分離することで、異なるHTMLファイルを作成しなくても、印刷用のレイアウトやサイト用に異なるスキン（スタイル）を簡単に生成できます。 Firefoxなどの一部のブラウザでは、ビューメニューからスタイルシートを選択することもできます。
そして、私はそれがテーブルレスレイアウトを維持することがより簡単であると思います。行スパン、colspansなどについて心配する必要はありません。単にcontainer-divをいくつか作成し、必要な場所にコンテンツを配置するだけです。そしてそれは私もそれがもっと読みやすいと思うと言った（<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>）。
それはあなたが学ばなければならないほんの少しの「トリック」です（そして一度あなたがトリックを習得すれば、私はそれがより簡単でより理にかなっていると思います）。
「テーブルが遅い」という議論に答えるために - あなたはレンダリング時間を考えています。これは間違った測定基準です。多くの場合、開発者はページ全体のレイアウトを実行するために大きなテーブルを作成します。これは、ダウンロードされるページのサイズを大幅に増加させます。それが好きであろうとなかろうと、まだたくさんのダイヤルアップユーザーがいます。
ViewStateの使いすぎも参照してください。
過去の経験から、私はDIVのために行かなければならないでしょう。 OOPであっても、主な目的はオブジェクト間の結合を減らすことであるため、この概念はDIVSとテーブルに適用できます。テーブルはデータを保持するために使用され、ページの周囲に配置するためには使用されません。 DIVはページの周囲にアイテムを配置するように特別に設計されているので、デザインはDIVを使用し、テーブルを使用してデータを格納する必要があります。
また、テーブルで作られたウェブサイトを編集するのは、単なる難しい（私の意見では）
divとCSSの配置により、より柔軟なデザインが可能になり、Webページの変更とテンプレート化が容易になります。
そうは言っても、柔軟性に興味がなければ、CSSによってテーブルに変換されるdivではなく、テーブルを使用することは間違いなくはるかに簡単で素早く簡単に開始できます。デザインをノックアップするときは、テーブルを使用して、外観を少し速くします。
私がCSSを使ってレイアウトをデザインするとき、私は一般的にすべての主要なセクションにそれ自身のルート（ボディレベル）divを与え、それを適切な場所に入れるために相対的/絶対的なポジショニングを使います。行と列を使って表現できる配置に限定されていないので、これはテーブルより少し柔軟です。
さらに、レイアウトを並べ替える（ナビゲーションバーを今すぐ右に配置したい）と決めた場合は、単純に移動して要素（CSSファイル）の位置を変更するだけで済みます。変更する必要はありません。私がテーブルでそれをしていたならば、私は入って情報を見つけなければならず、そして同じ効果を得るために多くの属性の変更とコピーと貼り付けをしなければならないでしょう。
実際、CSSを使用して、自分のレイアウトをどのように機能させるかを自分の users に選択させることさえできます。コンテンツ領域の一般的なサイズが変わらない限り、私のCSSをユーザーの好みに基づいて出力するためにPHPスクリプトを少し使用して、サイトを次のように並べ替えることができます。自分の好み。もう一度言いますが、テーブルでは可能ですが、維持するのがずっと難しいです。
最後に、CSSはテーブルが決して提供しない1つの主要な利点、つまり表示装置に基づいてコンテンツを再フォーマットする機能を可能にします。 CSSでは、モニタに使用しているものとはまったく異なるスタイルセット（位置、フォーマットなど）をプリンタに使用できます。これは他のメディアにも拡張することができます。素晴らしい例はOpera Showです。これにより、巧妙に設計された（そして非常に標準的な）CSS拡張ページをスライドショーとして表示することができます。
したがって、結局のところ、柔軟性と管理が真の勝者です。一般的に、CSSを使用するとレイアウトをより詳細に設定できます。テーブルベースのレイアウトに関して 技術的に 標準外のものは何もありませんが、なぜあなたは自分自身を制限したいですか？
これまで、スクリーンリーダーやその他のアクセシビリティソフトウェアは、効率的な方法でテーブルを処理するのに苦労していました。ある程度までは、これはスクリーンリーダーで、テーブル内で見たものに基づいて「テーブル」モードと「レイアウト」モードを切り替えることによって処理されるようになりました。これはしばしば間違っていたので、ユーザーはテーブルをナビゲートするときに手動でモードを切り替える必要がありました。いずれにせよ、スクリーンリーダーを使用してナビゲートするのは、大規模で、頻繁にネスト化されたテーブルが多く、その大部分は依然として非常に困難です。
Divまたは他のブロックレベルの要素がテーブルの再作成に使用されており、ネストが高い場合も同様です。 divの目的は、フォーム作成要素やレイアウト要素として使用されることです。そのため、同様の情報を保持し、それをビジュアルユーザーのために画面にレイアウトするために使用されることを意図しています。スクリーンリーダーがページに遭遇すると、CSSベースとhtml属性ベースの両方のレイアウト情報を無視することがよくあります（これはすべてのスクリーンリーダーには当てはまりませんが、JAWS、Windows Eyes、 Linux用のOrcaです。
この目的のために、表形式のデータ、つまりある種のヘッダーを持つ2次元以上の順序で並べるのに論理的に意味のあるデータは、表に配置するのが最善であり、divを使用してページ上のコンテンツのレイアウトを管理します。 （「表形式データ」とは別の方法でグラフ形式で描画することです。できない場合は、表で表現するのが最善ではない可能性があります）。
最後に、テーブルベースのレイアウトでは、ページ上の要素の位置をきめ細かく制御するために、高度にネストされたテーブルがよく使用されます。これは2つの効果があります：1.）各ページのコードサイズの増加 - ナビゲーションと共通の構造はしばしばテーブルで行われるので、div/cssベースのレイアウトはcssファイルを引っ張りますが、同じコードがネットワークを通して送られます。一度、そしてそれから、より少ない単語のdivを使います。 2.）ネストしたテーブルがクライアントのブラウザで表示されるまでに時間がかかるため、読み込み時間がわずかに遅くなります。
どちらの場合も、 "ラストマイル"帯域幅の増加、およびはるかに高速なパーソナルコンピュータによってこれらの要因が軽減されますが、それでも、多くのサイトでは依然として既存の問題があります。
これらすべてを念頭に置いて、他の人が言っているように、それらはよりグリッド指向であり、より少ない思考を可能にするので、テーブルはより簡単です。問題のサイトが長く続くことが予想されない場合、または維持されない場合は、最も費用対効果が高い可能性があるため、最も簡単な方法を実行することをお勧めします。ただし、予想されるユーザーベースにかなりの部分の障害者が含まれている場合、またはサイトが他のユーザーによって長時間維持される場合は、時間を短縮して簡潔にアクセスできるようにします。
変更がすべてのブラウザ、特にすべてのハックなどで機能することを確認するためのテストの量を考えると、div/CSSがどのようにページデザインの変更を容易にするかについてはまだよくわかりません。それは非常にイライラして退屈なプロセスであり、これは膨大な時間とお金を浪費します。幸いなことに、508の法律はアメリカ（自由の権利の国）にのみ適用されます。そのため、私はイギリスを拠点としているので、自分の好きなスタイルでWebサイトを作成できます。米国の一般的な信念に反して、ワシントンで作られた法律は他の国々には適用されません。法律が施行された日は、Webデザインの世界では良い日だったに違いありません。私は、IT業界で25歳で年をとるにつれて、ますます皮肉になっていると思いますが、この種の法律は単に雇用を保護するためのものであると確信しています。実際には、誰でも合理的なWebページといくつかのテーブルを組み合わせることができます。 DIV/CSSでこれを行うには、もっと多くの努力と知識が必要です。私の経験では、非常に単純な問題の解決策を見つけたり、理想的な熱心な行動をしているフォーラムで理解できない記事を読んだりするためには、何時間も何時間もかかります。つま先を水に浸して、すべての場合に適切に機能するようにすることはできません。また、DIVS/CSSを「箱から出して」使用するための明確なガイドがないこと、ブラウザで作業すること、およびオタク話せずに「通常の」言語を使用して書かれていることも、ちょっとした保護主義。
私はアプリケーション開発者であり、基本的なアプリケーションの作成、ビジネスオブジェクトの設計と実装、およびデータベースの作成に比べて、レイアウトの問題を見つけてすべてのブラウザに対してテストするのにほぼ2倍の時間がかかります。バックエンド私の時間=私の顧客にとっても私の顧客にとってもお金なので、コストを削減し、顧客にお金に見合う価値を提供することに賛成してDIV/CSSのすべての主張を棄却しないのは残念です。たぶんそれは開発者が働くことを考えているまさにその方法ですが、複雑なテーブル構造を変更する方がDIV/CSSを変更するよりはるかに簡単に思えます。ありがたいことに、これらの問題に対する解決策が利用可能になったようです - それはWPFと呼ばれています。
Webサイトがどのように設計され実装されていても、そのWebサイトがうまく動作し、高速に機能する場合は、だれも気にしないと思います。
HTMLマークアップでは "table"タグと "div"/"span"タグの両方を使用します。
私がdivを選択している理由をいくつか議論しましょう。
テーブルの場合、少なくとも3つのタグ（table、tr、td、thead、tbody）を記述する必要があります。素敵なデザインの場合、入れ子になったテーブルがたくさんあることがあります。
私はページにコンポーネントがあるのが好きです。私は正確に説明する方法がわからないが、しようとします。あなたがロゴを必要とし、これが次のページのコンテンツの上に配置されなければならないと仮定します。テーブルを使用すると、2つの画像をカットしてこれを2つの異なるTDに配置する必要があります。 DIVを使用すると、必要に応じてそれを調整するための単純なCSSを使用できます。どのソリューションが一番好きですか。
dIVを使ってそれを再設計しようと思っていることをするために3つ以上のネストしたテーブルがあるとき
しかし、私はまだテーブルを使っています：
表データ
自己を拡大しているコンテンツ
dIVボックスモデルはブラウザごとに異なるため、多くのジェネレータがテーブルを使用しているため、高速なソリューション（プロトタイプ）
まだレイアウト用のテーブルを使用しているため、div側のイノベーションに欠けています。
多くの人がdivのレイアウト作成を容易にするソリューションを考え出しました。最も人気があるのはグリッドアーキテクチャです。このアーキテクチャに基づいた動的レイアウトジェネレータがあります。チェックアウト：1）960.gsと（http://grids.heroku.com/）2）青写真とそう最近の多く。
私はこれまで、テーブルレイアウトを使用したアーキテクチャとツールに関して、あまり革新を見たことがありません。
私が言うには、理論は別にしても、CSSとdivを使った実際のレイアウトは速いです。この方向へのむしろ革新はそれを何よりも容易にした。
テーブルはHTMLに適していて、単純なものや一時的なものにまとめています。大規模なWebサイトを構築している場合は、divとCSSを使用することをお勧めします。これは、Webサイトが変更されたときに時間の経過とともに管理する方が簡単だからです。
1：はい、ユーザーは気にします。彼らがスクリーンリーダーを使用している場合、それは失われます。ページから情報を抽出しようとする他のツールを使用する場合、表形式のデータを表すために使用されないテーブルに遭遇することは誤解を招きます。
正確にはこれらの要素の意味であるため、コンテンツの分離にはdivまたはspanを使用できます。私、検索エンジン、スクリーンリーダーなどがテーブル要素に遭遇したとき、これは「以下は表に表された表形式のデータ」を意味するものと期待しています。 divに遭遇すると、「これはdivコンテンツを個別の部分または領域に分割するために使用される要素です。
2：可読性：間違っています。すべてのプレゼンテーションコードがcssにある場合、htmlを読むことができ、ページのコンテンツを理解できます。または、CSSを読んでプレゼンテーションを理解できます。 htmlですべてが混ざり合っている場合、コンテンツとは何かを確認する前に、プレゼンテーションに関連するすべての部分を精神的に打ち消す必要があります。さらに、CSSを理解していないWeb開発者に会うのが怖いので、それが問題だとは本当に思いません。
3：テーブルの速度が遅い：はい、そうです。理由は簡単です。テーブルを完全に解析する必要があります。含むレンダリングする前にその内容。 beforeの内容が解析された場合でも、divが検出されるとレンダリングできます。つまり、ページの読み込みが完了する前にdivが表示されます。
そして、ボーナスがあります。テーブルははるかに壊れやすく、異なるブラウザで同じフォントやフォントサイズ、レイアウトを変化させる可能性のある他のすべての要素で常に同じようにレンダリングされません。テーブルは、特定のブラウザでサイトを1〜2ピクセルずらし、ユーザーがフォントサイズを変更したり、他の方法で設定を変更したときにうまく拡大されないようにする優れた方法です。
もちろん＃1が大きなものです。多くのツールとアプリケーションは、Webページのセマンティックな意味に依存しています。通常の例は、視覚障害のあるユーザー向けのスクリーンリーダーです。あなたがウェブ開発者なら、そうでなければサイトで働くためにあなたを雇うかもしれない多くの大企業を見つけるでしょうrequireこの場合でもサイトはアクセス可能です。つまり、htmlの意味的な意味について考える必要があります。セマンティックWeb、またはより関連性の高いmicroformats、rssリーダー、およびその他のツールを使用すると、ページコンテンツはブラウザのみで表示されることはなくなります。
私は私の英語が残念だが、ここにもう一つの理由がある：
私は何らかの政府組織で働いていましたが、TABLEを使用しない最大の理由は、障害者向けです。彼らはウェブページを「翻訳」するために機械を使用しています。
問題は、それがTABLEによって行われている場合、この「翻訳機械」はウェブサイトを読むことができないということです。どうして ？ TABLEはDATAS用です。
実際には、TABLESを使用する場合、CELLSごとに、障害のある人にTABLE内の位置を知らせるためにいくつかの情報を指定する必要があります。大きなテーブルがあり、画面に1つのセルしか表示されないようにズームする必要があるとします。どの行/列にいるのかを知る必要があります。
そのため、DIVが使用され、無効になっている人は単にテキストを読むことができ、そこにいる必要がないときにlines/colsに関する奇妙な情報を得ることはありません。
すばやく簡単なテンプレートを作成するためにもTABLEを使用しますが、今はCSSに慣れています。強力ですが、実際に行っていることを知っておく必要があります... :)
Flexには縦に並べるためのタグがあります。私は彼らが全体的なレイアウト/コンテンツの事柄を正直に言って正しいとは思わないが、少なくとも彼らはその問題を解決した。
CSSに苛立ちを感じている多くの人たちと同様に、私も遠くから広く答えを求めていたので、それを見つけたと思ったときには高揚感を覚え、その後Chromeでページを開いたときに希望を打ち砕いた。不可能だと言うほど熟練していませんが、ピアレビューのためのサンプルコードを誰もが提供しているのを見たことがありません。
それで、この島のCSS側からの誰かが縦のコラムをレイアウトするための考え方/方法論を推薦できますか？私は2行目と3行目で絶対配置を試してみましたが、どこにでも重なっているものになってしまい、ページが縮小された場合はfloatも同様の問題を抱えています。
これに対する答えがあったら私は - 正しいことをすることに夢中になるだろう - 「ちょっとあなたは**フローを試みたことがありますか：垂直|水平」そして私は完全にあなたの髪の毛からだ。
グーグルは、表の中に含まれるテキスト内容に非常に低い優先順位を与えます。私は地元の慈善団体にSEOのアドバイスをしていました。彼らのウェブサイトを調べる際には、サイトをレイアウトするためにテーブルを使っていました。各ページを見ると、Googleの検索ボックスで使用しているページのどの単語（または単語の組み合わせ）に関係なく、そのページがどのトップ検索ページにも表示されません。 （ただし、検索でサイトを指定することで、ページが返されました。）1ページは検索で良好な結果が得られるように通常の標準に従ってコピーライトされました。 （このテキストは表の中にあることに注意してください。）それから私は、ページではなく表の中にあるテキストのセクションを見つけました。そのdivからの単語のいくつかを検索エンジンに入れます。結果？検索結果の2位になった。
私はかつてテーブルが一度にロードされること、つまり接続が遅い場合、テーブル全体がロードされるまでテーブルが来るスペースは空白のままであることを知りました。そしてそれが既に完成しているかどうかにかかわらず。
要素をレイアウト内の特定の位置関係に維持する必要があることを確認する必要がある場合は、テーブルを使用します。データの場合、列を予想外の方法で折り返して関連付けを混同したくないため、通常はテーブルを使用するのが最善のレイアウト要素です。
また、特定の関係を維持しなければならない非データ要素もテーブルに表示する必要があると主張することもできます。
柔軟なCSSレイアウトは、モバイルデバイスや大画面、印刷、その他のディスプレイタイプに適したコンテンツに適していますが、コンテンツを特定の方法で表示する必要がある場合、スクリーンリーダーが簡単にアクセスできない場合それは非常に正当化されるかもしれません。
私はできる限りTABLEを避けようとしていますが、複数のコントロールタイプとさまざまなキャプション位置をグループ化のかなり厳密なコントロールと混在させる複雑なフォームを設計する場合、DIVの使用は信頼できないかほとんど不可能です。
さて、私はこれらのフォームをDIVベースのレイアウトに合わせて再設計することはできないと主張するつもりはありません。ユーザーが慣れ親しんだ紙のフォーム。
フォームの表示は動的であるため（一部のセクションの表示はケースの状態またはユーザーの権限に基づいています）、それぞれ論理的にグループ化されたフォーム要素のTABLEを含む一連のスタックDIVを使用します。 TABLEの各列はCSSで制御できるように分類されています。こうすることで、DIVで行を折り返すためのテーブルにならないという問題なしに、フォームのさまざまなセクションを無効にできます。
私は数年前にスクリーンリーダーとテーブルの問題を調査し、ほとんどの開発者が信じていることと矛盾する情報を思いついた。
http://www.webaim.org/techniques/tables/
「おそらく、アクセシビリティ提唱者の中には、レイアウトテーブルは良くない考えで、代わりにCSSレイアウト技術を使うべきだと言う人もいるでしょう。彼らの言うことには真実があります。アクセシビリティの観点から設計されている限り、あらゆる種類の障害のある人がテーブルに簡単にアクセスできます。」
これは一般的な問題に関連する問題だと思います。 HTMLが誕生したとき、誰もがその広範な使用を予見することはできませんでした。それ自身の成功の重さの下でほとんど崩壊したもう一つの技術。 HTMLページが緑色のテキスト端末の vi に書かれているときは、ページの訪問者にデータを提示するのに必要なのはTABLEだけで、ほとんどが表形式で意味のあるデータでした。
私たちは皆、物事がどのように進化したかを知っています。 TABLEは比較的最近時代遅れになりましたが、DIVやCSSベースのレイアウトを好む理由はたくさんあります（アクセシビリティは最後ではありません）。もちろん私は私の命を救うためにCSSを書くことはできません:-)そして私はグラフィックデザインの専門家が常に手元にいるべきだと思います。
とは言っても...現代のWebサイトでも表に表示すべきデータはたくさんあります。
これでテーブルアングルをサポートしている場合は、テーブルのあるサイトを見つけてスクリーンリーダーを入手してください - スクリーンリーダーをオフにしてモニターをオフにします。
それから、意味的に正しいdivレイアウトサイトで試してみてください。
違いがわかります。
テーブルのデータがページをレイアウトしないように表形式であれば、テーブルは悪くありません。
テーブルに関する私の知識によれば、あまりにも多くのテーブルがネストされている場合、ページをレンダリングする際にブラウザに大きなオーバーヘッドがあります。
1 - ブラウザは、テーブル全体がロードされるまで最終ビューの表示を待機します。
2 - テーブルをレンダリングするためのアルゴリズムは高価であり、一度ではありません。ブラウザは、コンテンツを取得するときに、コンテンツの幅と高さを計算してレンダリングしようとします。つまり、ネストしたテーブルがある場合、たとえばブラウザが最初の行を受け取り、最初のセルに大量のコンテンツがあり、幅と高さが定義されていないと、幅が計算され、最初の行がレンダリングされます。 2行目が表示されている間、セル＃2にはたくさんのコンテンツがあります。 2行目のセルの幅が計算されます。最初の行はどうですか。幅を再帰的に計算します。それはクライアント側では悪いです。プログラマとしては、データを取得する時間、最適化されたデータ構造などを最適化します。サーバーサイドで完成するものを最適化します。たとえば、in2秒ですが、最終的なビューは8秒ここで何が問題なのですか1.ネットワークが遅い可能性があります。ネットワークが正常な場合はどうなりますか？次の1秒間にネットワークは何を配信していますか？この余分な5秒間はどこで消費されますか？気になること - ブラウザは、テーブルの推定とレンダリングに長い時間をかけている可能性があります。
テーブルを最適化する方法テーブルを使用している場合は、セルの幅を常に定義することをお勧めします。これは、ブラウザが盲目的にこの幅だけを取ることを保証するものではありませんが、初期幅を決定する際にブラウザにとって非常に役立ちます。
しかし、結局のところ、CSSはブラウザによってキャッシュできるため、divは非常に優れた方法です。テーブルはキャッシュされませんが！
純粋なレイアウトとして使用されるテーブルは、（私が聞いたことのある）アクセシビリティに関していくつかの問題を引き起こします。しかし、私はここで何が求められているのかを理解しています。それはどういうわけかあなたがあなたのページ上の何かの正しい整列を確実にするためにテーブルを使ってウェブを不自由にしているからです。
私は、FORMのラベルと入力は実際にはデータであり、それらをテーブルに入れることが許されるべきであると人々が主張するのを聞いたことがあります。
いくつかの要素を正しく整列させるためにテーブルを使用することでコードが大幅に増加するという議論には、1つのDIVですべてのニーズを満たす方法の例が含まれる傾向があります。彼らはいつも彼らがIE5、IE5.5、IE6、IE7のために書かなければならなかった10行のCSSと特別なブラウザハックを含んでいません...
私はそれがあなたのデザインにバランスを使うことについて残っていると思う。テーブルはツールボックスの中にあります、それらが何のためのものであるかをただ覚えていてください...
確かに、OPはちょっと風変わりで、議論は今週のように見え簡単に打ち消されました。
WebページはWeb開発者のドメインであり、div＆CSSがテーブルより優れていると言っても私にはそれで十分です。
レイアウトがサーバーアプリケーションによって生成されたテーブルによって達成される場合、新しいレイアウトは、アプリケーションへの変更、つまりアプリケーションの再構築および再配布を意味します。
さらに、アクセシビリティ。レイアウトに使用されるテーブルはWebサイトにアクセスできなくするので使用しないでください。違法なことは言うまでもありません。
非常に短い答え：保守可能なWebサイトを設計するのはテーブルでは難しく、標準的な方法では簡単です。
Webサイトはテーブルではなく、相互作用するコンポーネントの集まりです。テーブルとして記述するのは意味がありません。
コンテンツを維持しながらサイトのメンテナンスとデザインの見直しを行うという点で（特にeコマースでは常に起こります）。
コンテンツとデザインがテーブルを介して一緒になった=コンテンツとデザインの両方を更新する。
デザインとは別のコンテンツ=デザインを更新することと、多少の内容が含まれる可能性があります。
私のやり方であれば、私は自分のコンテンツをPHP生成XMLに保ち、XSLTでマークアップに変換し、そして対話のためにCSSとJavascriptで設計しました。物事のJava側のために、マークアップを生成するJSTLへのJSP。
DIVを使えば、簡単に物事を切り替えることができます。たとえば、次のようにします。
Menu | Content
Content | Menu
Menu
----
Content
HTMLではなくCSSで変更するのは簡単です。また、いくつかのスタイル（右利き、左利き、小画面専用）を指定することもできます。
CSSでは、印刷に使用される特別なスタイルシートでメニューを隠すこともできます。
もう1つ良いことは、視覚的に表示されていても、コンテンツはコード内で常に同じ順序（メニューが最初、コンテンツが後）にあるということです。