なぜ人々はdivでテーブルを作っているのですか？

現代のWeb開発では、このパターンに頻繁に出くわします。次のようになります。

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

CSSには次のようなものがあります。

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{*（クラス名は例示のみです。実際には、これらは要素の内容を反映した通常のクラス名です）}

私も最近自分でこれを試してみました。なぜなら、みんながそれをやっているからです。

しかし、まだわかりません。なぜこれを行うのですか？テーブルが必要な場合は、ブラスト<table>を作成して完了です。はい、レイアウト用であっても。それがテーブルの目的です-ものを表形式でレイアウトします。

私が持っている最も良い説明は、今では誰もが「レイアウトにテーブルを使用しない」というマントラを聞いているので、彼らは盲目的にそれに従うということです。しかし、彼らはまだレイアウト用のテーブルを必要とします（他にテーブルの拡張機能がないため）、彼らは<div>（テーブルではないので！）作成し、とにかくそれをテーブルにするCSSを追加します。

すべての世界にとって、これはあなたのやり方で任意の不必要な障害物を置き、それらを回避するために余分な仕事をするようなものです。

レイアウトのためにテーブルから移動するための元の引数は、後で表形式のレイアウトを変更するのは難しいということでした。しかし、「フェイクテーブル」レイアウトの変更も同じ理由で同じくらい難しいです。実際、実際にはレイアウトの変更は常に困難であり、マイナーな調整よりも深刻なことをしたい場合は、CSSを変更するだけでは十分ではありません。あなたはします深刻な設計変更のためのHTMLの構造を理解し、変更する必要があります。そして、テーブルはdivよりも仕事を難しくしたり簡単にしたりしません。

実際、テーブルを使用してレイアウトを変更するのが困難になる可能性があると私が思う唯一の方法は、abを使用して、邪悪な混乱を作成した場合です。divでも同様です。

だから...これを暴言から首尾一貫した質問に変える試みで：私は何が欠けていますか？実際のテーブルよりも「偽物のテーブル」を使用する実際の利点は何ですか？

重複リンクについて：これは、別のタグなどを使用するための提案ではありません。これは<table>vsの使用に関する質問display:tableです。

これは、レスポンシブテーブルを作成するための一般的なパターンです。表形式のデータは、ページがテキストを読むためにズームインされ、テーブルがページの外側に移動し、ユーザーがテーブルを読むために前後にスクロールする必要があるか、ページがズームアウトされるため、モバイルで表示するのが難しい、通常は表が小さすぎて読めないことを意味します。

レスポンシブテーブルは、小さな画面でレイアウトを変更します。たとえば、一部の列が非表示になったり、列が融合したりする場合があります。

<div>sは<table>、いくつかの理由でタグの代わりにテーブルを作成するために使用されます。<table>タグを使用する場合、独自のコードを追加する前にブラウザのデフォルトのスタイルとレイアウトをオーバーライドする必要があるため、この場合、<div>タグは多くの定型的なCSSを節約します。さらに、IEの古いバージョンでは、デフォルトのテーブルスタイルをオーバーライドできません。そのため、<div>s を使用すると、ブラウザ間の開発がスムーズになります。

CSS-Tricksのレスポンシブテーブルの概要は非常に優れています。

編集：私はこのパターンを提唱していないことを指摘する必要があります-それはdivitisトラップに陥り、セマンティックではありません-しかし、これはdivs から作られたテーブルを見つける理由です。

問題は、データが意味的にテーブル（つまり、2次元で論理的に編成されたデータのセットまたは情報の単位）であるか、視覚的なレイアウトにグリッドを使用するかどうかです。

情報が意味的にテーブルである場合、<table>-tag を使用します。レイアウト目的でグリッドが必要な場合は、他の適切なhtml要素を使用display:tableして、スタイルシートで使用します。

ときにデータがテーブル意味的でしょうか？データが2つの軸に沿って論理的に編成されている場合。行または列のヘッダーに意味がある場合は、セマンティックテーブルがあります。意味的に表ではないものの例は、新聞のように列にテキストを表示することです。これは意味的にはテーブルではありません、なぜならあなたはそれをまだ直線的に読み、プレゼンテーションが削除されても意味が失われないからです。

OK、意味的にテーブルであるものだけでなく、すべてに使用してみません<table>か？視覚的には明らかに同じです（テーブル要素display:elementはデフォルトのスタイルシートにあるため）。

違いは、セマンティック情報が代替ユーザーエージェントを支援できることです。たとえば、スクリーンリーダーを使用すると、テーブル内の2次元に移動し、現在地を忘れた場合に両方の軸のセルのヘッダーを読み取ることができます。テーブルが意味的にテーブルではなく、視覚的なレイアウトに使用される場合、これは混乱を招くだけです。

<table>対display:table議論は、セマンティックマークアップを使用して、より一般的な原則の念です。例：なぜ適切に意味論的にマークアップするのでしょうか？または、なぜ検索エンジンのセマンティックマークアップがより重視されるのですか？

場合によっては、アクセシビリティ上の理由からセマンティックマークアップを使用することが法的に義務付けられている可能性があります。いずれにしても、意図的にページのアクセシビリティを低下させる理由はありません。

障害のあるユーザーを気にしない場合でも、コンテンツとは別にプレゼンテーションを行うとメリットがあります。たとえば、代替スタイルシートを使用して、モバイルの単一列に3列のレイアウトを表示できます。

実際、あなたの例で「テーブル」のようなクラス名を使用することは、セマンティックマークアップを試みるときに、人々が実際に何をしているかを実際に理解していないことを示していると思います。コンテンツが表形式のデータではないことを示すためにマークを取得しますが、クラス名が間違っているためマークを失います。

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

この開発者が行ったことは<table>、CSSクラス名で元のマークアップを複製することだけです。これは、このレイアウトがテーブルでないとすぐに、クラス名が対立することを意味します。

この開発者がやるべきことは、表に含まれる情報を考慮することです。これはサムネイルギャラリーですか？じゃあ：

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

これで、適応CSSを作成できます。

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

なぜテーブルではなくdivなのか

表には表形式のデータが含まれています。表の表示は表の構造と密接にリンクしています。表形式のデータは、そのコンテンツを配置する場所や表示する画面/デバイスに関係なく、常に表形式にする必要があります。

サムネイルギャラリー（または登録フォーム、メニューなど、他の多くのもの）は表形式のデータではありません。いくつかのデザインレイアウトではテーブルのように表示される場合がありますが、狭い電話画面のように、従来のブロックレイアウトを使用する場合もあります。または、メインコンテンツ領域ではなくサイドバーにサムネイルを表示することもできます。

ここでの選択は、ワイドスクリーンコンテンツ（テーブル）とサイドバーまたはナロースクリーンコンテンツ（div）に異なるマークアップを出力することです。つまり、プログラムでビルドする場合、サーバー側のスクリプトはコンテンツの行き先を認識しなければなりません。 -または、サーバーサイドスクリプトに同じマークアップを出力させ（これをどこに配置するかは関係ないため）、さまざまな状況に応じて異なるCSSルールを使用します。

したがって、常にテーブルを出力し、次に自然なテーブル表示ルールをブロックでオーバーライドするか（これは開発者の頭の中でいくつかのギアを実際に粉砕する必要があります）、またはスタイリングへのより柔軟なアプローチを可能にする適切にラベル付けされたdivを使用する選択肢があります。

そして、ここ数年のベストプラクティスは、表形式のデータを提示する必要がないときにテーブルを避けることでした。

昔は、列幅にパーセンテージを使用すると、テーブルレンダリングエンジンの「表示」が遅くなりました。エンジンは基本的にデータセット全体をダウンロードしてから、画面に描画するためにすべてがどれだけ大きいかを判断しなければなりませんでした。

DIVエンジンは異なっていました。ブラウザがDIVに遭遇すると、先に進んでそれを配置し、コンテンツをインラインで埋め始めます。もちろん、データの読み込みが完了すると、divがジャンプする可能性があります。したがって、なぜ私は上記の引用符で登場しました。両方の完了の時間枠は同じでしたが、テーブルは最後まで描画されませんでした。つまり、ユーザーがロードしているかどうかが1〜2秒間分からなかったのです。

これは、テーブルがネストされるにつれて悪化しました。

そのため、FAR FARを高速にテーブルレンダリングする方法がありました（まだ存在していました）。基本的に、列のサイズが変わらないというヒントを与えることで、ブラウザーは表形式のデータのレンダリングをすぐに開始します。最終的に、これはテーブルがdiv よりも正確に正しい位置に実際に表示され、より良い外観になることを意味します。

しかし、それだけではありません。残りの部分は、ほとんどの開発者が単にこれを知るのに十分なほど自分の技術を習得することに煩わされないことです。代わりに、彼らはさまざまな時流に飛び乗って、コピー/貼り付けが可能なコードを使用します。今日でも、あるdoctypeと次のdoctypeの違いを知っているWeb開発者は非常に少ないことがわかります。それが、さまざまなサイトがさまざまなブラウザーをカバーするためのあらゆる種類の回避策を持っている最大の理由です。

だから、質問をしてくれたあなたに+1。

ここで少し「メタ」を取得できる場合、これは2つの問題を思い起こさせます。

1つ：誰かが何らかの正当な理由でルールを提案します。そして、人々は、精神を無視しながら、ルールの技術的な手紙に従うことによって、その点を完全に見落とします。彼らは、ルールが防止しようとしていたすべての悪いことを達成するための何らかの方法を見つけながら、言葉どおりにルールを技術的に守ります。

2：誰かが問題を見て、それを防ぐルールを提案します。他の人はこのルールの価値を見ます。その後、彼らは、解決すべき本来の問題に関係なく、および/またはそれが他のどんな問題を引き起こすかに関係なく、この規則に対する盲目的な献身を主張します。誰かが「Xをやるのがルールだから」と言う会話を何度もしてきましたが、「でもXをやるのはなぜですか？」言ったばかりです！ルールだからです！」「しかし、それは解決するよりも多くの問題を引き起こしているようです。Yをやったほうがいいと思います。」そして、その人は、「いや、見て、お見せします。この本のここにあります。Xがルールです。」と言います。

この場合、問題があります。tableタグは2つのことを行います。1つは、ドキュメントのレイアウトを制御します。2つ目は、囲まれたデータが数字またはその他のデータの行と列で構成されているという考えを伝えます。

多くの人々が解決策を提案しました。論理的に「テーブル」ではないもののレイアウトを制御するためにテーブルタグを使用しないでください。CSSを使用します。

しかし、このソリューションには問題があります。テーブルタグとそのサブタグは、CSSを使用して簡単に実現できない多くの非常に便利なレイアウト関数を実行します。また、実現できる場合、それを行うために必要なコードはしばしば煩雑です。クリーンで簡単な方法があるのに、なぜ不器用で難しい方法で物事を行う必要があるのですか？

個人的には、「テーブルタグ内に何かがあるという事実は、それが必ずしも数字の行と列を表すことを意味するわけではない」と宣言した方がよかったと思います。これはとんでもない発言ではなかっただろう。「p」タグは、文法的に正しい、論理的に構築された英語の文の実際の段落である場合にのみ使用できると言う人はいません。シーケンス番号ではなく箇条書きが必要だったからといって、実際には論理的な順序でリストに「ul」タグを使用するのは間違っていると言う人はいません。等。

ここにはすでにたくさんの素晴らしい答えがあります。しかし、table要素には存在しないレンダリング制限があることを追加したかったのdivです。仮想スクロールを行うテーブル（SlickGrid、DataTablesなど）を作成してみてください。そうすると、非常に失望します。うまくいきません。ほとんどの（すべて？）最新のJavascriptグリッドはdivsを使用します。これは、cssがはるかに柔軟なレンダリングを可能にするためです。

他にも制限があります。私の一般的なルールは、単一の画面でテーブル全体を表示し、そのためのカスタムレンダリングをあまりしたくない場合はtable要素を使用することです。 、はるかに簡単に。

HTMLとCSSはある程度の柔軟性を進化させました。つまり、概念的に「ブロック」要素<div>（HTMLの最も古く最も一般的な形式のブロックコンテンツ）でもブロックとして表示する必要はありません。

div { display: inline; }

ご注意として、<div>エミュレートするために再利用することができ<table>、その仲間の旅行者。実際、ほとんどのタグは可能です。彼らの特別な役割を考えると、私はあなたが有効のようなマクロのタグを再マッピングすることができ疑う<html>、 <head>、<body>、および<script>等が挙げられるが、「普通」のタグ<div>、<p>、<b>、<em>、<span>、と<pre>？つかむために。インラインタグブロック、インラインブロック、事前にフォーマットされたタグフロー、静止タグをフロートさせます。あなたが好きなら、夢中になります！

それはです可能。あなたは、私たちは、すべての「セマンティックマークアップ」何とか何とか使うべきかについての糸を回転することもできます何とか、またはことPythonistasと信じている「 -と、好ましくはただ一から一があるはずです。それを行うには明白な方法」しかし、ティム・トーディは賢くて好奇心guy 盛な人です。フリーハンドが与えられれば、彼はそれらすべてを探検します。これには、使用可能な柔軟性を使用して置換を行うことが含まれます。賢明な人もいれば、そうでなければ証明される人もいます。しかし、それを見つけるには試行錯誤と経験しかありません。したがって、代替の十分な条件が存在します。

代替も必要だと言っても過言ではないと思います。最低限、非常に便利です。長い間、HTMLは持っていなかった<menu>、<section>または<aside>要素。それでも、ウェブページとアプリにはどこにでもメニュー、セクション、サイドバーがあります。どうやって？HTMLのリスト要素（ので<ul>、<ol>と<li>）は、簡単に再利用し、いくつかの用途では、メニューの容器や部品として再分類されました。<div>以下のためで立つことができ<article>、<section>、<aside>、<figure>、と<summary>。HTML5は、これまで対処されていなかったユースケースに追いつき、特注の要素を追加しました。一般的な実際の使用に対応するための優れた更新と修正です。

それでも、オーダーメイドのタグやセマンティックモデルを持たない一般的なイディオムは数多く残っています。ページ、脚注、プルクォート、コメントストリーム、関連するアバター、「いいね」、サブヘッド、字幕など、私や他の多くが毎日使用しているもの。私たちは何をしますか？できること。「閉じているが不正確な」要素をクラスとIDで再利用して、HTML6またはHTML7が追いつくまでの5年、10年、または何年にもわたって私たちの仕事をサポートします。HTML / CSSの「はい、理論的にはXですが、これをタグ付けしてYとして処理する」機能は非常に便利です。本当に不可欠です。Webコンテンツを柔軟にし、脆弱ではありません。

さらに進むと、「セマンティックマークアップ」には制限がありません。これは、コンテンツに対して想像できるあらゆる種類の厳密な構造に当てはまります。

標準形式は、人間のニーズ、欲求、および多様性のすべてを網羅することはできません。彼らは常に人々が今やっていることの「曲線の後ろ」にいるでしょう。彼らがどのように革新しているか。ちなみに、HTML5は、脚注、小見出し、および17世紀のその他の印刷技術革新の背景にあります。多くのインフォメーションワーカーやコンテンツクリエーターに不可欠な機能が欠けています。即興です。

さらに変わらないのは、情報が1つのルールセットを順守しないことです。確かに、それはテーブルとして始まります。しかし、単に要約が必要な場合があります。たとえば、各行のタイトルをリストとして表示します。たぶんそれはあまりにも多くのスペースを占有し、スペース節約のインラインリストとしてそれが欲しいでしょう。たぶん、タイトルだけが必要なレコードがあり、クリックすると、基本的な詳細が表示されます。または、複雑なリストまたはテーブル内のアイテムをグループ化し、分類したい場合。ああ、今、あなたはそれを転置し、別の方法で分類したい。または、棒グラフとしてプロットされた値。これらは、アプリ、スプレッドシート、データの視覚化で毎日行われています。それらは私たちの情報環境の一部であり、ウェブ上で何をしたいのか、何をする必要があるのか​​です。人間は常にデータの形式と表示を再編成しています。それはただ一つのものでも、一つのフォーマット/レイアウトでもありません、または1つの概念。状況とユーザーが対話的に行う選択に依存するセマンティクスを備えた代替可能です。はい、テキストを「強調」としてマークします（<em>）、しかしそれは単なる慣習です。私は少なくとも半ダースの異なる種類の「強調」を伴うドキュメントに取り組んできました。私たちは、必要なカスタマイズと異なる用途、異なる解釈のためにそれを再マッピングできるようにします。ある種のHTML強調？驚くほど還元的。制限。脆い。同じことが当てはまります<table>、<p>など

「どこに行くのか」についてのコミュニティ全体の考え方を整理するのに役立つタグ/要素があると便利です。これは、慣習とイディオムを確立するのに役立ち、集合的により効率的になります。しかし、物事を再マップし、それらの構造を再指定して再利用する機能はありますか？これは、Webの包括性とその成功の一部であり、一部です。

ユースケースは重要です。コンテンツページとアプリケーションのレイアウト/プレゼンテーションには大きな違いがあります。コンテンツでは、SEO認識とユーザビリティにとってセマンティクスが非常に重要です。これらの場合、表を使用して表形式のデータを表示するのが一般的に正しいことです。他の人が指摘しているように、検索エンジンはあなたにペナルティを科し、政府のユーザビリティガイドラインに従うことを法律で義務付けられている場合、ユーザビリティ法に違反することさえあります。

Webアプリケーションでは、開発者はSEOとユーザビリティの目的で完全に別個のビューを作成することを選択できます。レスポンシブデザインにより、人々はデスクトップおよびモバイルレイアウトを処理できるビューを作成するようになり、divはそれらのユースケースのテーブルよりも優れています。

たとえば、eコマースサイトをご覧ください。ブラウズまたは検索結果で製品のリストを表示すると、一般に、表形式で製品のリストが表示されますが、これらのビューは、テーブルではなくdiv（より汎用的で柔軟なレイアウトとスタイルオプションを提供）を使用して生成される場合があります。AmazonとeBayはこのアプローチの良い例です。いずれかのサイトで検索結果を調べると、深くネストされたdivのセットが表示されます。