html - 古い - レイアウトテーブルとは




なぜHTMLでレイアウト用のテーブルを使用しないのですか? (20)

HTMLのレイアウトにはテーブルを使用しないでください。

どうして?

私は決してこれについての良い議論を見たことはありません(または正直であることはめったにありません)。 通常の答えは次のとおりです。

  • レイアウトからコンテンツ分離するのは良いことです
    しかし、これは誤った議論です。 クリシェ思考 。 私はレイアウトのためのテーブル要素の使用が表形式のデータとほとんど関係ないと思う。 だから何? 私の上司は気にしますか? ユーザーは気にしますか?

    おそらく私または私の仲間の開発者は、Webページのケアを維持する必要があります...テーブルの保守性は低いですか? 私はテーブルを使用するとdivとCSSを使用するeasiereasierだと思います。

    ちなみに...なぜdivやスパンをレイアウトと表からのコンテンツの分離が良いのではないのですか? divのみで適切なレイアウトを取得するには、多くのネストされたdivが必要になることがよくあります。

  • コードの可読性
    私はそれが別の方法だと思います。 ほとんどの人がHTMLを理解しており、CSSを理解する人はほとんどいませ

  • SEOがテーブルを使用しない方が良い
    どうして? それは誰でも何か証拠を示すことができますか? または、Googleの声明では、テーブルはSEOの観点から落胆していますか?

  • テーブルは遅いです。
    余分なtbody要素を挿入する必要があります。 これは現代のWebブラウザのためのピーナッツです。 テーブルの使用がページを著しく遅くするベンチマークを私に教えてください。

  • レイアウトの見直しはテーブルなしで簡単です。css Zen Gardenを参照してください。
    アップグレードが必要なほとんどのWebサイトでは、新しいコンテンツ(HTML)も必要です。 新しいバージョンのWebサイトで新しいCSSファイルが必要なシナリオはあまりありません。 禅ガーデンは素晴らしいウェブサイトですが、少し理論的です。 そのCSSのmisuseはもちろんですが。

私は本当にテーブルの代わりにdivs + CSSを使う良い議論に興味があります。


レイアウトからコンテンツを分離するのは良いことです
しかし、これは誤った議論です。 クリシェ思考

HTMLテーブルはレイアウトなので、間違った議論です! コンテンツはテーブル内のデータであり、プレゼンテーションはテーブル自体です。 このため、HTMLとCSSの分離は非常に困難な場合があります。 コンテンツをプレゼンテーションから分離するのではなく、プレゼンテーションからプレゼンテーションを分離しています。 入れ子にされたdivの山はテーブルと変わりありません。タグの別のセットです。

CSSからHTMLを分離する際のもう1つの問題は、相互に密接な知識が必要なことです。本当にそれらを完全に分離することはできません。 HTMLのタグレイアウトは、あなたが何をしていてもCSSファイルと密接に結びついています。

私はテーブル対divsはあなたのアプリケーションのニーズになると思う。

私たちが仕事で開発するアプリケーションでは、ページのレイアウトが動的に自分のコンテンツに合わせるようなページレイアウトが必要でした。 私はこれをCSSとDIVを使ってクロスブラウザで動作させることを試みるのに数日間を費やし、それは完全な悪夢でした。 私たちはテーブルに切り替えました

しかし、私たちは製品のための非常に閉鎖されたオーディエンスを持っています(私たちはウェブインタフェースを備えたハードウェアを販売しています)。アクセシビリティの問題は私たちの関心事ではありません。 スクリーンリーダーがテーブルをうまく扱うことができない理由はわかりませんが、開発者がそれを処理しなければならないかどうかはわかります。


私はレイアウトのためのテーブル要素の使用が表形式のデータとほとんど関係ないと思う。 だから何?私の上司は気にしますか?ユーザーは気にしますか?

Googleや他の自動化されたシステム気にしますが、多くの状況で同様に重要です。セマンティックコードは、非インテリジェントシステムが解析して処理するのが容易です。


CSS / DIV - それはデザインボーイの仕事だけですね。 私はDIV / CSSの問題をデバッグするのに何百時間も費やしてきました。マークアップの一部を不明瞭なブラウザで処理するためにインターネットを検索しています。 あなたは一つの小さな変更を行い、全体のレイアウトはひどく間違っています - ここでは、eathがそのロジックです。 3ピクセル何かをこのように動かす時間を費やすと、他のピクセルは2ピクセルになります。 これは何とか私に間違っているようです。 あなたが純粋主義者であり、何かが「正しいことではない」という理由だけでなく、あなたの生活を1000倍も簡単にするならば、それを第n次およびすべての状況下で利用すべきではありません。

だから私は最終的に商業的な理由で、私は最小限に抑え続けていますが、DIVを正しく配置するために20時間の作業が必要な場合は、テーブルに固定します。 それは間違っている、それは純粋主義者を混乱させるが、ほとんどの場合、それは時間がかかり、管理するのが安価である。 私はその後、純粋主義者を喜ばせるのではなく、顧客が望むようにアプリケーションを動かすことに集中することができます。 彼らは結局のところ法案を支払っていますし、CSS / DIVの使用を強制するマネージャーに私の主張をしています - 私は単に顧客が給料を支払うことを指摘しています!

これらのCSS / DIV引数がすべて発生する唯一の理由は、最初にCSSの欠点があり、ブラウザが互いに互換性がないため、世界中のWebデザイナーの半分が仕事を失うためです。

Windowsフォームをデザインするときは、レイアウトした後にコントロールを動かしてみることはありません。なぜなら、なぜ私はあなたがウェブフォームでこれをやりたいのかというと奇妙だと思います。 私はこの論理を理解できません。 始めるためにはレイアウトの権利を取得し、問題は何か。 デザイナーはクリエイティビティを好む傾向があり、アプリケーション開発者は実際にアプリケーションを稼働させ、ビジネスオブジェクトを作成し、ビジネスルールを実装し、顧客データのビットがどのように相互に関係しているかを検証し、現実世界のような要件 - あなたが知っている - 。

私が間違ってはいけない、どちらの引数も有効ですが、フォームを設計するためのより簡単でより論理的なアプローチを選択した開発者を批判しないでください。 私たちはしばしば、divの上にテーブルを使用する正しいセマンティクスよりも心配するべき重要なことがあります。

このケースでは、いくつかの既存のtdsとtrをdivに変換しました。 45分は、すべてのものが隣に並ぶようにしようとしていて、私はあきらめた。 10秒後にTDが戻ってくる - すぐに動作する - すべてのブラウザで、これ以上何もしない。 私に理解させてください - 私は他の方法でそれをやりたいと思っていますか?


この重複した質問を参照してください。

あなたがそこにいることを忘れている1つのアイテムはアクセシビリティです。 たとえば、スクリーンリーダーを使用する必要がある場合、テーブルベースのレイアウトは変換されません。 また、政府のために働く場合は、スクリーンリーダーのようなアクセシブルなブラウザをサポートする必要あります。

私はまたあなたが質問に述べたことのいくつかの影響を過小評価していると思う。 たとえば、デザイナーとプログラマーの両方であれば、プレゼンテーションとコンテンツの分離度合いを十分に理解できない場合があります。 しかし、いったん2つの異なる役割を果たす店に入ると、その利点はより明確になり始める。

あなたが何をしているのかを知っていて、良いツールを持っているなら、CSSはレイアウトのテーブルよりも大きな利点があります。 そして、各項目はそれ自体放棄テーブルを正当化することはできませんが、一緒に取ることは一般的に価値があります。


DIVの議論は私に有利ではない。

私は言う:靴が合う場合は、それを着用してください。

2つまたは3つのカラムでコンテンツをレンダリングするという優れたDIV + CSSメソッドを見つけることは、不可能ではないにしても、すべてのブラウザで一貫していても難しいことではありません。

これは、私のレイアウトの大半でテーブルのほうにバランスをとるヒントです。そして、私はそれらを使用することを犯したと感じます(ダニーなぜ人々はそれが悪いと言うので、私はそれらを聞こうとする)、最終的に、実利的な見解はちょうどテーブルを使用するのが簡単かつ迅速になりました。私はその時までに払われていないので、テーブルは私のために安いです。


いくつかのアプリケーションによって生成されたネストしたテーブルの6つのレイヤーを含むWebサイトで作業しなければならなかったので、それは無効なHTMLを生成していました。

もちろんこれはエッジケースですが、テーブルベースのデザインは維持できません。CSSを使用する場合は、スタイルを分けて、HTMLを修正するときに、壊れにくいことを心配する必要はありません。

また、JavaScriptでこれを試してください。1つのテーブルセルをある場所から別のテーブルの別の場所に移動します。むしろ、div / spanがコピー・ペースト・ワイズで動作するようにするのは複雑です。

"私の上司のケアはありますか?"

もし私があなたの上司だったら。あなたは気にします。;)あなたの人生を大切にするならば。


これは決して決定的な議論ではありませんが、CSSを使用すると、媒体に応じて同じマークアップとレイアウトを変更することができます。これは優れた利点です。 印刷ページでは、たとえば、プリンタに適したページを作成することなく、静かにナビゲーションを抑制することができます。


セマンティックマークアップに関する考え方全体は、レイアウトを含むマークアップとプレゼンテーションの分離です。

Divはテーブルを置き換えるものではなく、コンテンツを関連するコンテンツ(、)のブロックに分けて使用します。スキルがなく、テーブルに頼っているときは、目的のレイアウトを得るためにコンテンツをセルに分けなければならないことがよくありますが、セマンティックマークアップを使用するときは、マークアップに触れてプレゼンテーションを行う必要はありません。これは、静的ページではなくマークアップが生成されているときには、本当に重要です。

開発者は、プレゼンテーションのニーズが変わったときに変更を加えるためにコードに戻ってくる必要はなく、コンテンツを提示するスキルを持つ人たちが仕事に乗ることができるように、レイアウトを意味するマークアップの提供をやめる必要があります。


レイアウト用のテーブルはそれほど悪くないでしょう。 しかし、ほとんどの時間に1つのテーブルで必要なレイアウトを得ることはできません。 まもなく、2つまたは3つのネストされたテーブルがあります。 これは非常に面倒です。

  • それは読むのが大変です。 それは意見に反するものではない。 そこには識別マークのないネストされたタグがあります。

  • プレゼンテーションからコンテンツを分離することは、あなたがやっていることに集中することができるので、良いことです。 2つを混ぜると読みにくい膨大なページにつながります。

  • スタイル用のCSSは、ブラウザがファイルをキャッシュすることを可能にし、後続のリクエストはずっと高速です。 これは大変です。

  • テーブルはあなたをデザインに固定します。 確かに、誰もがCSS Zen Gardenの柔軟性を必要としているわけではありませんが、ここで少し変更する必要はないサイトでは一度も作業していません。 CSSを使う方がはるかに簡単です。

  • テーブルのスタイルは難しいです。 あなたはあまり柔軟性がありません(つまり、表のスタイルを完全に制御するためにHTML属性を追加する必要があります)

私はおそらく4年間で非表データのためのテーブルを使用していません。 私は振り返っていない。

Andy BuddによってCSS Masteryを読むことを提案したいと思います。 すごいね。

ecx.images-amazon.comの画像http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg


明らかな答え: CSS Zen Gardenを参照してください。 テーブルベースのレイアウトで簡単に同じことができると言われたら(覚えておいてください - HTMLは変化していません)、レイアウトのためにテーブルを使用してください。

その他の2つの重要なことは、アクセシビリティとSEOです。

両方とも、情報がどのような順序で提示されるかを気にしています。 テーブルベースのレイアウトでページ上の2番目のネストしたテーブルの2番目の行の3番目のセルに配置すると、ページの上部にナビゲーションが簡単に表示されません。

だからあなたの答えは、保守性、アクセシビリティとSEOです。

怠惰にしないでください。 学ぶのが少し難しい場合でも、適切かつ適切な方法で行います。


残念なことに、CSS Zen Gardenは良いHTML / CSSデザインの例として使用できなくなりました。 ほとんどの最近のデザインでは、セクション見出しにグラフィックを使用しています。 これらのグラフィックファイルはCSSで指定されています。

したがって、コンテンツをデザインから守るという利点を示すことを目的としているウェブサイトは、今や、コンテンツをデザインするためのUNSPEAKABLE SINを定期的にコミットしています。 (HTMLファイル内のセクション見出しが変更される場合、セクション見出しは表示されません)。

それは、厳格なDIV&CSS宗教を主張する者でさえ、自分たちのルールに従うことができないことを示すためだけにある。 あなたは、あなたがそれらにどれほど密接に従うかのガイドラインとしてそれを使用するかもしれません。


私はあなたの議論を次々と辿り、エラーを見せようとします。

コンテンツとレイアウトを分けることは良いことですが、これは誤った議論です。 ClichéThinking。

HTMLは意図的に設計されているので、それはまったく間違っているわけではありません。 要素の誤用は完全に疑問ではないかもしれない(結局のところ、新しいイディオムも他の言語でも開発されている)が、否定的な意味合いは相殺されなければならない可能性がある。 さらに、今日の<table>要素の悪用に対する議論がなくても、明示的にブラウザベンダーが要素に特別な扱いを適用する方法があるかもしれません。 結局のところ、 " <table>要素は表形式データ専用である"ことを知っており、この事実を使ってレンダリングエンジンを改善し、 <table>の振る舞いを微妙に変化させ、

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

依存します。 あなたの上司は尖っていますか? それから彼は気にしないかもしれない。 彼女が有能であれば、ユーザーwill気になるので気willます。

おそらく私または私の仲間の開発者は、Webページのケアを維持する必要があります...テーブルの保守性は低いですか? 私はテーブルを使用してdivsとCSSを使用するよりも簡単だと思います。

プロのWeb開発者の大半はあなたに反対しているようです [ 必要な引用 ] 。 実際、そのテーブルは管理しにくいのは明らかです。 レイアウト用のテーブルを使用するということは、企業のレイアウトを変更することは、実際には1ページごとに変更することを意味します。 これは非常に高価になる可能性があります。 一方、意味的に意味のあるHTMLをCSSと組み合わせて賢明に使用すると、そのような変更がCSSや使用される画像に限定される可能性があります。

ちなみに...なぜdivやスパンをレイアウトと表からのコンテンツの分離が良いのではないのですか? divのみで適切なレイアウトを取得するには、多くのネストされたdivが必要になることがよくあります。

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

コードの読みやすさ私はそれが別の方法だと思います。 ほとんどの人はhtmlを理解し、cssはほとんど理解していません。 それはより簡単です。

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

SEOがテーブルを使用しない方が良い

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

テーブルは遅いです。 余分なtbody要素を挿入する必要があります。 これは現代のWebブラウザのためのピーナッツです。

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

テーブルの使用がページを著しく遅くするベンチマークを私に教えてください。

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

アップグレードが必要なほとんどのWebサイトでは、新しいコンテンツ(html)も必要です。 ウェブサイトの新しいバージョンが新しいCSSファイルだけを必要とするシナリオはあまりありません。

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

別物。 テーブルレイアウトにより、Webサイトの自動解析(スクリーンスクレイピング)がはるかに難しくなります。 結局のところ、誰がそれをするのか、これは些細なことかもしれません。 私は自分自身に驚いた。 問題のサービスがそのデータにアクセスするためにWebServiceの代替手段を提供していない場合、スクリーンスクレイピングは多くの助けになります。 私はこれが悲しい現実であるバイオインフォマティクスに取り組んでいます。 現代のWeb技術とWebサービスはほとんどの開発者には届いておらず、しばしばスクリーンスクレイピングがデータを取得するプロセスを自動化する唯一の方法です。 多くの生物学者がこのような作業を手動で実行するのは不思議ではありません。 何千ものデータセット。


CSSレイアウトは一般に、アクセシビリティの方がはるかに優れています。コンテンツが自然な順序で表示され、スタイルシートなしで意味がある場合に限ります。テーブルベースのレイアウトと闘うだけのスクリーンリーダーではなく、モバイルブラウザがページを適切にレンダリングするのがずっと難しくなっています。

また、divベースのレイアウトでは、ヘッダー、フッター、ナビゲーションを印刷したページから除外するなど、印刷スタイルシートを使って簡単にクールな作業を行うことができます。これは不可能であるか、少なくとも難しいと思います。テーブルベースのレイアウト。

レイアウトとコンテンツの分割がテーブルよりもdivより簡単であることに疑問がある場合は、CSS Zen GardenのdivベースのHTMLを見て、スタイルシートを変更することで大幅にレイアウトを変更できるかどうかを確認し、 HTMLがテーブルベースであれば、同じ種類のレイアウトを実現できます。テーブルベースのレイアウトを行っている場合は、CSSを使用してセル内のすべてのスペースとパディングを制御することは考えられません(もし最初に浮動小数点のdivなどを使用する方が簡単に見つかるでしょう)。 CSSを使用してすべてを制御することなく、テーブルがHTMLの左から右、上から下の順番を指定しているため、テーブルはHTMLでレイアウトが非常に固定的になる傾向があります。

現実的には、divを少し変更することなく、divおよびCSSベースのデザインのレイアウトを完全に変更することは非常に難しいと思います。しかし、divおよびCSSベースのレイアウトでは、さまざまなブロック間の間隔や相対的なサイズなどの調整がずっと簡単です。


あなたはちょうどテーブルに慣れているように見えます、それだけです。レイアウトをテーブルに置くと、そのレイアウトだけに制限されます。CSSを使用すると、ビットを移動することができます。http: //csszengarden.com/を見てください。レイアウトは、大量のネストされたdivを必要としません。

レイアウトや適切なセマンティクスのためのテーブルがないため、HTMLははるかにクリーンで読みやすくなります。なぜCSSを理解できない人がそれを読もうとしますか?誰かが自分自身をウェブデベロッパーと見なすなら、CSSをよく理解することが必要です。

SEOのメリットは、最も重要なコンテンツをページの上位に持ち、コンテンツとマークアップの比率を上げることができることにあります。

will


これは実際には、divがレイアウト用のテーブルよりも優れているかどうかではありません。CSSを理解している人は、「レイアウトテーブル」を使用しているデザインを簡単に複製することができます。本当の勝利は、彼らが何のためにHTML要素を使用しているかです。テーブル化されていないデータにテーブルを使用しない理由は、整数を文字列として格納しないのと同じ理由です。テクノロジは、目的に合わせて使用​​するとはるかに簡単に動作します。レイアウトのためにテーブルを使用する必要があった場合(1990年代のブラウザの欠点のため)、確かに今ではありません。


なぜなら、テーブルを使用するサイトを維持するのはちょっと面倒なので、コードを書く時間が長くかかります。あなたが浮動小数点のdivを怖がっている場合は、それらのコースを取る。彼らは理解するのが難しくありませんし、約100倍の効率と100万倍の痛みを伴います(理解していない限り、コンピュータの世界に歓迎します)。

テーブルを使ってレイアウトをすることを考えている人は、私がそれを維持するとは思っていません。これは、ウェブサイトをレンダリングするのに最も難しい方法です。私たちは今よりはるかに良い選択肢を持っている神に感謝します。私は決して戻っていません。

いくつかの人々が現代的なツールを使ってサイトを作成することによる時間とエネルギーのメリットを認識していないかもしれないことは恐ろしいことです。


テーブルレイアウトを使用するツールは、レイアウトを作成するために必要なコード量のために非常に重くなります。SAPのNetweaver Portalは、デフォルトでTABLEを使用してページをレイアウトします。

私の現在のギグのプロダクションSAPポータルには、HTMLが60Kを超え、7つのテーブルがページ内で3回深くなっているホームページがあります。Javascriptを追加すると、内部に同様のテーブルの問題がある16個のiframeが乱用されたり、過度に重いCSSなどが表示されたり、ページの重さが5MBを超えます。

帯域幅を使用してユーザーとのやり取りを行うことができるように、ページの重みを下げる時間を取ることは価値があります。


中央のコンテンツ列がページレイアウトのサイドバーの前に読み込まれてレンダリングされるように、CSSとdivを調べる価値があります。しかし、ロゴをいくつかのスポンサーシップテキストと縦に並べるためにフローティングディビジョンを使用するのに苦労している場合は、テーブルを使用して人生を進めてください。禅の庭の宗教だけでは、多くの打撃を与えることはありません。

コンテンツをプレゼンテーションから分離するというアイデアは、異なる種類の作業が異なるコードブロックに影響を及ぼすようにアプリケーションを分割することです。これは実際に変更管理に関するものです。しかし、コーディング標準では、コードの現状を表面的にしか調べることができません。

コーディング標準に依存するアプリケーションの変更ログは、「プレゼンテーションからコンテンツを切り離す」ために、垂直サイロ間で並行して変化するパターンを示します。「コンテンツ」への変更が常に「プレゼンテーション」への変更を伴っている場合、その分割はどれくらい成功していますか?

コードを生産的に分割したい場合は、Subversionを使用して変更ログを確認してください。次に、div、テーブル、JavaScript、インクルード、関数、オブジェクト、継続など、最も簡単なコーディング手法を使用して、変更を簡単かつ快適に収めるようにアプリケーションを構造化します。


私はボートが航行したと思う。業界が取っている方向性を見ると、CSSとオープンスタンダードがその議論の勝者であることがわかります。これはフォームを除いてほとんどのhtml作業を意味しますが、デザイナーはテーブルの代わりにdivを使用します。私はCSSの教祖ではないが、それがそうであるので、私はそれに苦労している。


表は一般的に CSSよりも簡単でメンテナンスが容易ではありません。しかし、テーブルが実際には最も簡単で最も柔軟なソリューションであるいくつかの特定のレイアウト上の問題があります。

プレゼンテーションマークアップとCSSが同じ種類のデザインをサポートしている場合は、CSSが明らかに好ましいですfont。CSSはfontタイトグラフと同じパワーを与えるので、タイトグラフをCSSで指定するよりもタグが優れていると主張する人はいませんはるかにクリーンな方法。

ただし、テーブルに関する問題は、基本的にMicrosoft Internet ExplorerではCSSのテーブルレイアウトモデルがサポートされていないことにあります。したがって、テーブルとCSSは同等のパワーではありません。欠落している部分は、セルのエッジが垂直方向と水平方向の両方に整列する一方で、セルは内容を含むように展開されているテーブルのグリッド様の動作です。この動作は、純粋なCSSではいくつかのディメンションをハードコーディングせずに達成するのは容易ではありません。これにより、デザインが堅く脆くなります(インターネットエクスプローラをサポートする必要がある限り - 他のブラウザでは簡単に使用できますdisplay:table-cell)。

テーブルやCSSの方が望ましいかどうかという問題ではありませんが、テーブルを使用することでレイアウトを柔軟にすることができる特定のケースを認識することが重要です。

テーブルを使用しない最も重要な理由はアクセシビリティです。Webコンテンツアクセシビリティガイドラインhttp://www.w3.org/TR/WCAG10/レイアウトのためのテーブルを使用したアドバイス。アクセシビリティが懸念される場合(場合によっては法的に義務付けられる場合もあります)、表が単純な場合でもCSSを使用するべきです。CSSと同じレイアウトをテーブルと同じように作成することもできますが、それ以上の作業が必要な場合もあります。





css