なぜ人々はdivでテーブルを作っているのですか？
最近のウェブ開発では、このパターンに頻繁に出くわしています。次のようになります。
<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>（それはnotテーブルです！）そして、とにかくそれをテーブルにするCSSを追加します。
世界中のすべての人にとって、これは任意の不要な障害物をあなたの道に置き、それを回避するために余分な作業をするように私に見えます。
レイアウトのためにテーブルから離れるという当初の議論は、後で表形式のレイアウトを変更するのは難しいというものでした。しかし、「フェイクテーブル」レイアウトを変更することも同じ理由で同じ理由で困難です。実際、実際にはレイアウトの変更は常に困難であり、マイナーな微調整よりも深刻なことをしたい場合は、CSSを変更するだけでは不十分です。あなたはwill重大な設計変更のためにHTML構造を理解して変更する必要があります。また、テーブルはdivよりも難しくも簡単でもありません。
実際、テーブルがレイアウトの変更を困難にする可能性があると私が見る唯一の方法は、 abそれらを使用して、不敬な混乱を作成しました。あなたもdivでそれを行うことができます。
だから...これを暴言から首尾一貫した質問に変えようとして：私は何が欠けているのですか？ actual「偽の表」を実際の表よりも使用する利点は何ですか？
重複リンクについて：これは別のタグなどを使用するための提案ではありません。これは、<table>とdisplay:tableの使用に関する質問です。
これは、レスポンシブテーブルを作成するための一般的なパターンです。表形式のデータは、テキストを読むためにページが拡大されるため、モバイルで表示するのは難しいです。つまり、テーブルがページの端から外れ、ユーザーが前後にスクロールしてテーブルを読むか、ページが縮小されるためです。 、これは通常、テーブルが小さすぎて読み取れないことを意味します。
レスポンシブテーブルは小さな画面でレイアウトを変更します-一部の列が非表示になったり、列が統合されたりします。大きな画面では名前とメールアドレスが別々になることがありますが、小さな画面では1つのセルに折りたたまれているため、スクロールしなくても情報を読むことができます。
いくつかの理由により、<div>タグの代わりに<table>sを使用してテーブルを作成します。 <table>タグを使用する場合は、独自のコードを追加する前に、ブラウザーのデフォルトのスタイルとレイアウトをオーバーライドする必要があるため、この場合、<div>タグは多くのボイラープレートCSSを節約します。さらに、IEの古いバージョンでは、デフォルトのテーブルスタイルを上書きできません。そのため、<div>sを使用すると、ブラウザ間の開発もスムーズになります。
かなり良い CSS-Tricksのレスポンシブテーブルの概要 があります。
編集：私はこのパターンを主張していないことを指摘する必要があります-それはdivitisトラップに分類され、セマンティックではありません-これがdivsから作成されたテーブルを見つける理由です。
問題は、データが意味的に表（つまり、2次元で論理的に編成されたデータのセットまたは情報の単位）であるか、または視覚的なレイアウトにグリッドを使用するだけか、などです。サイドバーを拡大したいので。
情報が意味的にテーブルである場合は、<table>タグを使用します。レイアウトのためにグリッドだけが必要な場合は、他の適切な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>
この開発者が行ったのは、CSSクラス名を使用して元の<table>マークアップを複製することだけです。これは、このレイアウトがテーブルではなくなった時点で、クラス名が矛盾していることを意味します。
この開発者がすべきことは、表にある情報を検討することです-それはサムネイルギャラリーですか？じゃあ：
<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を使用するかを選択できます。
そして 数年前のベストプラクティス は、表形式のデータを提示する必要がないときにテーブルを回避するためのものです。
昔は、列幅にパーセンテージを使用すると、テーブルレンダリングエンジン "appeared"が遅くなります。エンジンは基本的に、データセット全体をダウンロードしてからでないと、画面に描画するためにすべてがどれほど大きいかを理解する必要がありました。
DIVエンジンは異なりました。ブラウザがDIVを検出すると、DIVを配置してコンテンツをインラインで埋め始めます。もちろん、データの読み込みが完了すると、divがジャンプする可能性があります。それゆえ、なぜ私は上記の引用文の中に現れたのでしょう。両方が完了するまでの時間枠は同じでしたが、テーブルが最後まで描画されなかったため、ユーザーが1秒か2秒ロードしているかどうかがわかりませんでした。
テーブルが入れ子になったため、これはさらに悪化しました。
その後、テーブルのレンダリングをFAR FARより速くする方法がありました（現在も存在しています）。基本的に、列のサイズが変更されていないことをヒントにすると、ブラウザはすぐに表形式データのレンダリングを開始します。結局のところ、これはテーブルが実際に正しい位置に表示できることを意味しますより速い divよりも優れているように見えます。
しかし、それだけではありません。残りの部分は、ほとんどの開発者がこれを知るのに十分なほど自分の技術を学ぶ気にならないということです。代わりに、彼らはさまざまなバンドワゴンに飛び乗って、コピー/貼り付け可能なコードを使用します。今日でも、Doctypeごとの違いを知っているWeb開発者はほとんどいません。これが、さまざまなサイトがさまざまなブラウザーをカバーするためのあらゆる種類の回避策を備えている最大の理由です。
だから、質問をするあなたに+1します。
ここで少し「メタ」を取得できる場合、これは私の心に2つの問題をもたらします。
１：誰かが何らかの正当な理由でルールを提案し、人々は精神を無視しながらルールのテクニカルレターに従うことでポイントを完全に逃します。彼らはルールが言葉通りに技術的にルールに従っている間に、ルールが防止しようとしていたすべての悪いことを達成するためのいくつかの方法を見つけます。
2：誰かが問題を見て、それを防ぐためのルールを提案します。他の人はこのルールの価値を見ます。それから彼らは、本来あるべき問題に関係なく、そして/または他のどのような問題が発生するかに関係なく、この規則への盲目的な献身を主張する。私は誰かが「Xがルールなので、Xを実行する必要があります」と言って、「なぜXを実行する必要があるのか」と尋ねると、困惑と憤慨で私を見て、「でも言いました！ルールだから！」 「しかし、それは解決するよりも多くの問題を引き起こすようです。Yを実行したほうがよいと思います。」そして、その人は、「いいえ、見て、私があなたに見せます。ほら、この本のここにあります。Xがルールです。」と言います。
この場合、問題があります。tableタグは2つのことを行います。1つは、ドキュメントのレイアウトを制御します。 2つ目は、囲まれたデータが数値またはその他のデータの行と列で構成されているという考えを伝えます。
非常に多くの人々が解決策を提案しました：論理的に「テーブル」ではないもののレイアウトを制御するためにテーブルタグを使用しないでください。 CSSを使用します。
しかし、このソリューションには問題があります。 tableタグとそのサブタグは、CSSを使用して簡単に実現できない非常に便利なレイアウト機能を実行します。これらの機能を実現できる場合、そのために必要なコードは扱いにくく、読みにくく、保守が困難です。クリーンで簡単な方法があるのに、不器用で難しい方法で物事を行う必要があるのはなぜですか。
個人的には、「テーブルタグの中に何かがあるという事実は、必ずしもそれが数値の行と列を表すことを意味するわけではない」と宣言したほうがよいと思います。これは法外な宣言ではなかっただろう。 「p」タグは、実際には文法的に正しく、論理的に構成された英語の文の段落であるものにのみ使用できると誰かが言うのを聞いたことがありません。シーケンス番号ではなく箇条書きを使用したいという理由だけで、実際には論理的な順序でリストに「ul」タグを使用するのが間違っていると誰かが言うのを聞いたことがありません。等。
ここにはすでにすばらしい答えがトンあります。しかし、table要素にはdiv要素には存在しないレンダリング制限があることを追加したかったのです。仮想スクロールを行うテーブルを試してみてください（例： SlickGrid 、 DataTables など）。そうすれば、非常にがっかりします。機能しません。ほとんど（すべて？）の最新のJavaScriptグリッドはdivsを使用します。これは、CSSにより、はるかに柔軟なレンダリングが可能になるためです。
他にも制限があります。私の一般的なルールは、テーブル全体を1つの画面に表示し、カスタムレンダリングをあまり/多くしたくない場合は、table要素を使用することです。それ以外の場合は、divを使用します。結果をはるかに簡単に制御できます。
HTMLとCSSはある程度の柔軟性を進化させました。つまり、<div>（HTMLの最も古く、最も一般的な形式のブロックコンテンツ）のような概念的に「ブロック」要素でさえ、ブロックとして表示する必要がありません。
div { display: inline; }
お気づきのように、<div>は<table>およびその仲間の旅行者をエミュレートするために再利用できます。実際、ほとんどのタグはできます。それらの特別な役割を考えると、<html>、<head>、<body>、<script>などのマクロタグを便利に再マッピングできるとは思えませんが、<div>などの「一般的な」タグ、<p>、<b>、<em>、<span>、<pre>？つかむために。インラインタグブロック、インラインブロック、事前にフォーマットされたタグフロー、静止したタグをフロートにします。あなたが好きなら、狂ってください！
それは可能です。 「セマンティックマークアップ」を使用する方法について糸を紡ぐのがいいかもしれませんblah、またはPythonistasに「1つだけ、そしてできれば1つだけあるべきだ」と信じてください。 -それを行う明白な方法。」まだ Tim Toady は賢くて好奇心旺盛な男です。フリーハンドが与えられれば、彼はそれらすべてを探索します。これには、利用可能な柔軟性を使用して置換を行うことが含まれます。賢明な人もいれば、そうでなければ証明される人もいます。しかし、それを見つける唯一の方法は、試行錯誤と経験です。したがって、置換のための十分な条件が存在します。
代替も必要だと言っても過言ではないと思います。最低でも、それは非常に便利です。長い間、HTMLには<menu>、<section>、または<aside>要素がありませんでした。しかし、どこにでもあるWebページやアプリには、メニュー、セクション、サイドバーがあります。どうやって？ HTMLリスト要素（<ul>、<ol>、および<li>）は簡単に再利用され、一部の使用法はメニューコンテナーおよびパーツとして再分類されたためです。 <div>は、<article>、<section>、<aside>、<figure>、および<summary>の代わりになる可能性があります。 HTML5は、これまで対処されていなかったいくつかのユースケースに追いつき、そのカスタムエレメントを追加しました。これは、一般的な実際の使用に対応するための優れた更新と修正です。
それでも、 オーダーメイドのタグやセマンティックモデルを持たない多くの一般的なイディオム が残っています。ページ、脚注、引用、コメントストリーム、関連付けられたアバター、「いいね」、小見出し、私や他の多くの人々が毎日使用している字幕のようなもの。私たちは何をすべきか？私たちができること。 HTML6またはHTML7が追いつくまでの5年、10年、または何年もの間、私たちの作業をサポートするために、クラスとIDを使用して「近いが不正確」な要素を転用します。 HTML/CSSの「はい、理論上はXですが、タグを付けてYとして処理する」という機能は非常に便利です。本当に不可欠です。 Webコンテンツを柔軟にし、もろくしません。
さらに進んで、「セマンティックマークアップ」には、取り返しのつかない制限があります。これは、コンテンツについて想像できるあらゆる種類の厳密な構造に当てはまります。
標準形式は、人間のニーズ、欲求、多様性のすべてを網羅することはできません。彼らはいつも人々がしていることの「曲線の後ろ」にいるでしょう今。彼らが革新している方法。ちなみに、HTML5は、脚注、小見出し、その他の17世紀の印刷技術の革新にまだ遅れを取っています。多くのインフォメーションワーカーやコンテンツ作成者に不可欠な機能が不足しています。だから即興です。
さらに不変なのは、情報が1組のルールに従っていないことです。確かに、それはテーブルとして始まります。しかし、多分あなたは単に要約が欲しいです-リストとして各行のタイトルを言ってください。多分それはあまりにも多くのスペースを必要とし、あなたはそれをスペース節約のインラインリストとして望んでいます。たぶん、タイトルが欲しいだけのレコードがあり、クリックすると、基本的な詳細が表示されます。または、複雑なリストまたはテーブルのアイテムをグループ化して分類することもできます。ああ、今度はそれを転置して別の方法で分類したい。または、棒グラフとしてプロットされた値。これらは、アプリ、スプレッドシート、データの視覚化で毎日行われていることです。これらは、私たちの情報ランドスケープの一部であり、ウェブ上で私たちが望んでいることとする必要があることです。人間は常にデータの形式と表示を再編成します。それはただ1つのこと、1つの形式/レイアウト、または1つの概念ではありません。状況に応じて、またユーザーがインタラクティブに行う選択に応じて、セマンティクスが変化する可能性があります。はい、テキストを「強調」（<em>）としてマークしますが、これは単なる慣例です。私は、少なくとも6種類以上のさまざまな種類の "強調"があるドキュメントに取り組んできました。さまざまな用途、さまざまな解釈に合わせてカスタマイズおよび再マッピングできるようにする必要があります。ある種のHTML強調？耐え難いほど還元的。制限。もろい。 <table>、<p>などについても同様です。
「何がどこに行くのか」についてのコミュニティ全体の考えを整理するのに役立つタグ/要素があることは素晴らしいことです。これは、慣例や慣用句を確立するのに役立ち、全体として私たちをより効率的にします。しかし、物事を再マッピングし、それらの構造を再指定して再利用する機能はありますか？これは、Webの包括性とその成功の一部です。
ユースケースは重要です。コンテンツページとアプリケーションでは、レイアウト/プレゼンテーションに大きな違いがあります。コンテンツでは、SEO認識とユーザビリティにとって意味論は非常に重要です。このような場合、表を使用して表形式のデータを表示することは、一般的に正しいことです。他の人が指摘したように、検索エンジンはあなたにペナルティを課し、法令で政府のユーザビリティガイドラインに準拠するよう要求された場合、ユーザビリティ法に違反する可能性さえあります。
Webアプリケーションでは、開発者はSEOとユーザビリティの目的で完全に別個のビューを作成することを選択できます。レスポンシブデザインにより、デスクトップとモバイルのレイアウトを処理できるビューを作成するようになり、divはこれらの使用例ではテーブルよりも優れています。
たとえば、eコマースサイトを見てみましょう。ブラウズまたは検索の結果で製品のリストを表示すると、通常、製品のリストが表形式で表示されますが、これらのビューは、テーブルではなくdiv（より汎用的で柔軟なレイアウトとスタイルのオプションを提供）を使用して生成することもできます。 AmazonとeBayは、このアプローチの良い例です。どちらかのサイトで検索結果を調べると、深くネストされたdivのセットが表示されます。