[解決済み] HTMLのレイアウトにテーブルを使用しない理由は？[クローズド］

質問

のようです。 一般的な意見 HTMLのレイアウトにテーブルを使うべきではない、ということです。

なぜですか？

これに対する正論を見たことがない（正直言ってほとんどない）。通常の回答は

• には良いことだと思います。 コンテンツとレイアウトの分離
  しかし、これは誤った議論です。 陳腐化した思考 . レイアウトにtable要素を使っても、表形式のデータとはあまり関係がないのは事実でしょうね。だからどうした？私の上司は気にしますか？私のユーザーは気にしますか？
  もしかしたら、私やウェブページをメンテナンスしなければならない開発者仲間は気にしているかもしれませんが...。テーブルを使うとメンテナンス性が悪くなる？私は、テーブルを使うことは 簡単 divとCSSを使うよりも。
  ところで...なぜdivやspanを使うとコンテンツとレイアウトの分離がうまくいき、テーブルを使うとうまくいかないのでしょうか？divだけで良いレイアウトにするには、多くの場合、divを入れ子にする必要があります。

• コードの読みやすさ
  私は逆だと思います。ほとんどの人はHTMLを理解していますが、CSSを理解している人はほとんどいません。

• テーブルを使わない方がSEO的に有利です
  なぜ？誰かその根拠を示せる人はいますか？あるいは、SEOの観点からテーブルが推奨されないというGoogleの声明がありますか？

• テーブルを使うと遅くなる。
  tbody要素を1つ余計に挿入しなければならない。これは、最近のウェブブラウザにとってはたいしたことではありません。テーブルの使用によってページの速度が大幅に低下するベンチマークをいくつか示してください。

• レイアウトの見直しは、テーブルがない方が簡単です。 css禅の庭 .
  バージョンアップが必要なWebサイトの多くは、新しいコンテンツ（HTML）も必要です。新しいバージョンのWebサイトが、新しいCSSファイルだけを必要とするシナリオは、あまり考えられません。Zen Gardenは素敵なWebサイトですが、ちょっと理屈っぽい。言うまでもないが、その 誤用 のCSSを使用しています。

テーブルの代わりにdiv＋CSSを使用するための良い議論にとても興味があります。

どのように解決するのですか？

あなたの主張をひとつひとつ確認し、その誤りを示していこうと思います。

<ブロッククオート

コンテンツとレイアウトを分離するのは良いことだ しかし、これは誤った議論であり、クリシェ・シンキングです。

HTMLは意図的に設計されたものなので、全く誤りではありません。ある要素を誤って使用することは、全く問題がないわけではありませんが（実際、他の言語でも新しい慣用句が開発されています）、起こりうる負の影響は相殺されなければなりません。さらに、たとえ <table> ブラウザベンダーがこの要素を特別扱いしているため、今日はそうでも、明日はそうなるかもしれません。結局のところ、彼らは " <table> 要素は表形式データ専用です。」そして、この事実を利用してレンダリングエンジンを改良し、その過程で <table> が動作するようになり、これまで誤用されていたケースが解消されます。

<ブロッククオート

だから何？私の上司は気にしますか？私のユーザーは気にしますか？

場合による あなたの上司は髪がとがっていますか？それなら、気にしないかもしれませんね。もし彼女が有能なら、気にするでしょうね。 意志 .

もしかしたら、私やウェブページをメンテナンスしなければならない開発者仲間は気にしているかもしれませんが...。テーブルはメンテナンス性に劣るのでしょうか？テーブルを使うのは、divやcssを使うより簡単だと思うのですが。

プロのウェブ開発者の大多数は、あなたに反対しているようです。 ^{[ 要引用 ]} . そのテーブル は ということは、保守性が低いということです。レイアウトにテーブルを使うということは、会社のレイアウトを変えるということは、実はすべてのページを変えるということなのです。これは 非常に が高い。一方、意味的に意味のあるHTMLをCSSと組み合わせて賢く利用することで かもしれません。 そのような変更は、CSSと使用する画像に限定されます。

ところで、なぜdivやspanを使うとコンテンツとレイアウトの分離がうまくいき、テーブルを使うとうまくいかないのでしょうか？divだけで良いレイアウトにするには、多くの場合、divを入れ子にする必要があります。

深いネスト <div> は、テーブルレイアウトと同様、アンチパターンである。優れたウェブデザイナーは、その多くを必要としないのです。一方、そのような深く入れ子にされたdivであっても、テーブルレイアウトの問題の多くは持っていません。実際、コンテンツを論理的に分割することで、意味的な構造に貢献することさえあります。

<ブロッククオート

コードの読みやすさ 私は逆だと思います。ほとんどの人はhtmlを理解しているが、cssはほとんど理解していない。そのほうがシンプルでいい。

"ほとんどの人 "は重要ではありません。プロフェッショナルが重要なのです。プロにとっては、テーブルレイアウトはHTML＋CSSよりも多くの問題を引き起こします。これは、ほとんどの人にとってメモ帳の方がシンプルだから、GVimやEmacsを使うべきではないと言っているようなものです。あるいは、MS Wordの方がシンプルだからLaTeXを使うべきではない、と言っているようなものです。

<ブロッククオート

テーブルを使わない方がSEO的に良い

これが本当かどうかわからないし、これを論拠にすることもないだろうが、論理的にはそうだろう。検索エンジンの検索対象は 関連 データです。表形式のデータはもちろん関連性があるかもしれませんが、ユーザーが検索するのは稀です。ユーザーが検索するのは、ページタイトルやそれに近い目立つ位置で使用されている用語です。したがって、表形式のコンテンツをフィルタリングから除外し、処理時間（とコスト！）を大幅に削減することは論理的なことなのです。

<ブロッククオート

表は遅くなる。 余分なtbody要素を挿入しなければならない。これは、最近のウェブブラウザにとっては大したことではありません。

余分な要素は、テーブルが遅くなることとは関係ありません。一方、テーブルのレイアウト アルゴリズムは非常に難しく、ブラウザはコンテンツのレイアウトを開始する前にテーブル全体の読み込みを待つ必要があることが多いのです。さらに、レイアウトのキャッシュは機能しません（CSSは簡単にキャッシュできます）。これらはすべて、以前から言われていることです。

<ブロッククオート

テーブルの使用によってページの速度が著しく低下するベンチマークを教えてください。

残念ながら、ベンチマークのデータは持っていません。この議論がある種の科学的厳密さを欠いているのはその通りなので、私自身は興味があります。

バージョンアップが必要なWebサイトの多くは、新しいコンテンツ（html）も必要です。新しいバージョンのWebサイトが、新しいCSSファイルだけを必要とするシナリオは、あまり考えられません。

そんなことはないですよ。私はこれまで、コンテンツとデザインを分離することで、デザインの変更を簡略化したケースをいくつか手がけてきました。HTMLのコードを変更する必要があることはよくありますが、変更は常にずっと限定されたものになります。また、デザインの変更は、時には動的に行わなければなりません。ブログシステム「WordPress」で使われているようなテンプレートエンジンについて考えてみましょう。テーブルレイアウトは、このシステムを文字通り殺してしまうでしょう。私は、商用ソフトウェアで同じようなケースを担当したことがあります。HTMLコードを変更することなくデザインを変更できることが、ビジネス要件のひとつでした。

もうひとつ。テーブルレイアウトは、ウェブサイトの自動解析（スクリーンスクレイピング）をより困難にします。これは些細なことに聞こえるかもしれませんが、結局のところ、誰がそんなことをするのでしょうか？私自身、驚いています。スクリーン・スクレイピングは、問題のサービスが、そのデータにアクセスするためのWebServiceの代替手段を提供していない場合に、大いに役立ちます。私はバイオインフォマティクスに携わっていますが、これは悲しい現実です。最新のWeb技術やWebServicesはほとんどの開発者に行き渡っておらず、データを取得するプロセスを自動化するためにはスクリーン・スクレイピングが唯一の方法であることが多いのです。多くの生物学者がいまだにこのような作業を手作業で行っているのも不思議ではありません。数千のデータセットに対して