純粋なCSSレイアウトを作成しようとするたびに、1つまたは2つのテーブルを使用する場合よりもはるかに時間がかかるようです。3つの列を同じ長さにし、データ量を変えるには、特にクロスブラウザーの問題を処理する場合に、特別なハックが必要になるようです。
私の質問：
これらのいくつかのテーブルが傷つくのは誰ですか？
表は表形式のデータで特にうまく機能しているようです—なぜこの時代に表はそれほど罵倒されているのでしょうか？
Google.comのソースコードにはテーブルがあるので、他の多くのサイトもそうです（ちなみにstackoverflow.comにはありません）。
これはスタックオーバーフローなので、プログラマーの回答を差し上げます。
セマンティクス 101まずこのコードを見て、ここで何が問題なのかを考えてみてください...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
もちろん、問題は自転車が車ではないということです。car クラスは、bike インスタンスには不適切なクラスです。コードにエラーはありませんが、意味的に正しくありません。プログラマーへの反映は不十分です。
セマンティクス 102これをドキュメントのマークアップに適用します。ドキュメントで表形式のデータを表示する必要がある場合、適切なタグは<table>. ただし、ナビゲーションをテーブルに配置すると、要素の意図された目的を誤用することになり<table>ます。2 番目のケースでは、表形式のデータを提示していません。<table>要素を (誤って) 使用して、提示上の目標を達成しています。
これは誰を傷つけますか？誰も。セマンティック マークアップを使用すると誰が得をしますか? あなた -- そしてあなたのプロとしての評判。さあ、行って正しいことをしてください。
多くのことのように、それはしばしば行き過ぎてしまうのは良い考えです。私はdiv+css駆動のレイアウトが好きです。なぜなら、スタイルシートだけで外観を大幅に変更するのは通常非常に簡単だからです。また、低レベルのブラウザやスクリーンリーダーなどに親しみやすいのも良いことです。しかし、プログラミングにおけるほとんどの決定と同様に、決定を下す際には、サイトの目的と開発コストを考慮する必要があります。どちらの側も、100％の確率で進む正しい方法ではありません。
ところで、表形式のデータにはテーブルを使用する必要があることに誰もが同意していると思います。
現実の世界では、1 つのデザインを使用して、マークアップに手を加えることなく完全にスキンを変更できる可能性はほとんどありません。ブログや csszengarden のようなでっち上げのデモには問題ありませんが、適度に複雑なデザインのサイトでは偽の利点です。CMS を使用することは、はるかに重要です。
DIV と CSS != セマンティックのいずれか。優れた HTML は、レイアウトにテーブルまたは CSS が使用されているかどうかにかかわらず、SEO とアクセシビリティにとって常に価値があります。非常にシンプルなテーブルと優れた CSS を組み合わせることで、非常に効率的で高速な Web デザインを実現できます。
テーブル レイアウトは CSS レイアウトよりもアクセシビリティが高く、逆もまた真です。コンテンツのソースの順序に完全に依存します。また、テーブルを避けたからといって、スクリーン リーダーを使用しているユーザーがサイトで自動的に楽しい時間を過ごせるとは限りません。 . CSS レイアウトを行う場合とまったく同じように、線形化したときにコンテンツが意味をなす場合、レイアウト テーブルはスクリーン リーダー アクセスとは無関係です。データ テーブルは異なります。適切にマークアップするのは非常に難しく、それでもスクリーン リーダー ソフトウェアのユーザーは通常、データを理解するために必要なコマンドを知りません。
いくつかのレイアウト テーブルを使用することに悩むよりも、見出しタグと代替テキストが適切に使用されていること、およびフォーム ラベルが適切に割り当てられていることを心配する必要があります。そうすれば、現実世界のアクセシビリティについてかなりうまくいくでしょう。
これは、Web アクセシビリティのユーザー テストを実行し、アクセシブルなサイトの設計を専門とする数年間の経験と、オンライン バンクである Cahoot のこのトピックに関する 1 年間のコンサルティングから得たものです。
したがって、ポスターに対する私の答えはノーです。テーブルよりも CSS を好むビジネス上の理由はありません。それはよりエレガントで、より満足のいくものであり、より正確ですが、CSS であれテーブルであれ、ネズミのお尻を与えているのは、それを構築する人であり、その後維持しなければならない人である世界で 2 人だけです。
テーブルをできるだけ少なくしたCSSレイアウトの方がクリーンで優れていると思いますが、テーブルを使用しなければならない場合もあることに同意します。
ビジネス的には、一般的に「最も速く、最も信頼できる方法でそれを実行するために何が行われるのか」です。私の経験では、いくつかのテーブルを使用することは一般的にそのカテゴリに分類されます。
CSSレンダリングでのブラウザー間の違いを軽減する非常に効果的な方法は、ページの上部にある「厳密な」Doctypeを使用することです。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
また、恐ろしいIE6 CSSの問題については、次のハックを使用できます。
.someClass {
background-color:black; /*this is for most browsers*/
_background-color:white; /*this is for IE6 only - all others will ignore it*/
}
セマンティックHTMLデザインを使用することは、それを実践しない限り、何が欠けているのかわからないことの1つです。私は、サーバー側のコードにほとんどまたはまったく影響を与えずに、事後にサイトのスタイルを変更したいくつかのサイトで作業しました。
サイトのスタイル変更は非常に一般的なリクエストです。私は、自分のやり方を話そうとする代わりに「はい」と言うことができるようになったので、今ではもっと気づきました。
また、ページレイアウトシステムの操作方法を学んだら、通常、テーブルベースのレイアウトよりも難しくはありません。
あなたが公開されているウェブサイトを持っているなら、本当のビジネスケースはSEOです。
アクセシビリティは重要であり、セマンティック（X）HTMLを維持することは、テーブルレイアウトを維持することよりもはるかに簡単ですが、Googleのその1位はベーコンを持ち帰ることになります。
月次Webレポート：7月の1億2700万ページビュー
..。
Latimes.comはSEO（検索エンジン最適化）で向上し続けています。これは、Googleや他の検索エンジンで私たちのストーリーが上位にランクされていることを意味します。Digg.comのようなサイトでもパフォーマンスが向上しています。これらすべてが、これまで以上に多くの露出と読者層につながります。
彼らのサイトを見ると、かなりまともなCSSレイアウトが進んでいます。
一般的に、最近のSERPでうまく機能しているテーブルレイアウトは比較的少ないことがわかります。
Web ページを DIV/CSS ベースのレイアウトに変更した主な理由は、テーブル ベースのページのレンダリングの遅延でした。
私たちは公開 Web サイトを持っており、そのユーザー ベースのほとんどはインドのような国にあり、インターネットの帯域幅がまだ問題になっています (日々改善されていますが、まだ同等ではありません)。このような状況で、表ベースのレイアウトを使用すると、ユーザーは空白のページをかなり長い間見つめなければなりませんでした。次に、ページ全体が目盛りで全体として表示されます。ページを DIV に変換することで、ユーザーが Web サイトにアクセスした直後に一部のコンテンツをブラウザーに表示することができました。これらのコンテンツは、ブラウザーがページのコンテンツ全体をダウンロードするまで、ユーザーを引き付けるのに十分なものでした。
テーブルベースの実装の主な欠点は、ブラウザがそのテーブルの html 全体をダウンロードした後にのみテーブルの内容を表示することです。この問題は、ページのコンテンツ全体をラップするメイン テーブルがあり、ネストされたテーブルが多数ある場合に発生します。「柔軟なテーブル」(幅が固定されていないテーブル) の場合、テーブル タグ全体をダウンロードした後、ブラウザはテーブルの最後の行まで解析して各列の幅を調べ、コンテンツを表示するために再度解析する必要があります。 . これらすべてが発生するまで、ユーザーは空白の画面をじっと見つめなければなりません。その後、すべてが一瞬で画面に表示されます。
レイアウトとコンテンツを分離しておくと、サイトを簡単に再設計したり、微調整や変更を加えたりすることができます。事前に少し時間がかかる場合がありますが、ソフトウェア開発の最も長いフェーズはメンテナンスです。コンテンツとデザインが明確に分離されたCSSフレンドリーなサイトは、メンテナンスの過程で最適です。
私の経験では、これが実際にビジネス価値を追加するのは、アクセシビリティを 100% サポートする必要がある場合だけです。視覚障害のあるユーザーやスクリーンリーダーを使用してサイトを表示するユーザーがいる場合、サイトがアクセシビリティ基準に準拠していることを確認する必要があります。
スクリーン リーダーを使用するユーザーは、スクリーン リーダーがページを簡単に解析できるようにする、独自の高コントラストで大きなフォントのスタイルシート (サイト自体が提供していない場合) を持っている傾向があります。
スクリーンリーダーがページを読み込んで表を見ると、それが表であることをユーザーに伝えます。したがって、レイアウトに表を使用すると、ユーザーは表の内容が実際には他の表形式のデータではなく記事であることを知らないため、非常に混乱します。メニューは、メニュー項目を含むテーブルではなく、リストまたは div のコレクションである必要があります。これもまた混乱を招きます。読みやすくするために、ブロック引用符、alt タグのタイトル属性などを使用するようにしてください。
デザインを CSS 駆動にすれば、ルック アンド フィール全体を取り除き、ユーザーにとって非常に読みやすい未加工のビューに置き換えることができます。インライン スタイル、テーブル ベースのレイアウトなどを使用している場合、それらのユーザーがコンテンツを解析するのが難しくなります。
サイトが純粋に CSS でレイアウトされている場合、いくつかの点でメンテナンスが容易になると思いますが、すべての種類のメンテナンスに当てはまるとは思いません。特に、クロスブラウザー CSS を扱っている場合はそうです。明らかに悪夢になる可能性があります。
つまり、ユーザーがページにアクセスできるようにする場合は、標準に準拠した方法でページの構成を説明する必要があります。必要性や要件がなく、将来的にも必要ない可能性が高い場合は、CSS の純粋主義者になろうとしてあまり時間を無駄にしないでください :) 自分に合ったスタイルとレイアウトのテクニックを組み合わせて使用し、仕事をしてください。より簡単に。
乾杯！
[編集 - この回答の間違った部分または誤解を招く部分に取り消し線を追加しました - コメントを参照してください]
もう 1 つ思い出したのは、印刷用と表示用に別のスタイルシートをページに割り当てることができるということです。
通常のスタイルシート定義に加えて、次のタグを追加できます
<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />
プリンターに送信するときに、そのスタイルに従ってドキュメントをレンダリングします。これにより、別のモジュールを作成することなく、背景画像、追加のヘッダー/フッター情報を取り除き、生の情報だけを印刷できます。
1 つのファイルを更新するだけで 15 ページの Web サイトを完全に刷新するのは天国です。
これは本当です。残念ながら、15,000 の複雑で大きく異なるページで 1 つの CSS ファイルが使用されると、最悪の悪夢が現実になります。何かを変更してください - それは千ページを壊しましたか? 知るか？
CSS は、私たちのような大きなサイトでは両刃の剣です。
アイデアは、設計者が設計でき、Web開発者が実装できるということです。これは特に、デザイナーがソースコードをいじり回したくない動的なWebアプリケーションの場合に当てはまります。
現在、テンプレートエンジンがありますが、デザイナーは明らかに夢中になるのが大好きで、CSSではテーブルよりもはるかに多くのスタントを引き出すことができます。
そうは言っても、開発者として、CSSレイアウトを放棄したのは、主に私のデザインがとにかくうまくいかないためです。少なくとも適切に機能する可能性があります:-)しかし、デザイナーを雇うとしたら、彼のWYSIWYGエディターが吐き出すものは何でも使用させます。
簡単に更新可能で準拠していることに加えて...
私はすべてのテーブルベースのWebサイトを設計するために使用し、最初は抵抗力がありましたが、少しずつCSSに移行しました。それは一夜にして起こりませんでした、しかしそれは起こりました、そしてそれはあなたが同様にすべきことです。
私がdivに適用していたスタイルが私が望むことをしていないので、私が窓の外にコンピューターを投げたいと思った夜がありましたが、あなたはそれらの障害から学びます。
ビジネスに関しては、CSSによって科学に至るまでWebサイトを設計するようになると、各サイトのプロセスを開発し、過去のWebサイトを使用して、異なるヘッダーグラフィックや色などを追加することもできます。
また、ヘッダー、サブヘッダー、フッターなど、ウェブサイトの再利用可能なすべての部分を必ず埋め込み/含めてください。
こぶを乗り越えると、そこからすべて下り坂になります。幸運を！
CSSレイアウトのビジネス上の理由：「私たちのポータルはコードを書かなくても完全にカスタマイズ可能/スキニング可能です！」と言うことで顧客を驚かせることができます。
繰り返しになりますが、テーブルを使用してブロック要素を設計することに悪は見られません。ブロック要素とは、異なるデザインで前述の要素を分解することが意味をなさない場所を意味します。
したがって、もちろん、表形式のデータは表とともに表示するのが最適です。独自のテーブル内で主要なビルディングブロック（メニューバー、ニュースティッカーなど）を設計することも問題ありません。全体的なページレイアウトをテーブルに依存しないでください。大丈夫です。
*私は彼のWYSIWYGエディターが吐き出すものは何でも彼に使用させます
。グラフィックデザイナーがCSSを手書きしているとは思いませんか?
おかしなことに、私は何人かのデザイナーと仕事をしてきましたが、その中で最高のデザイナーは、CSS を手作業で微調整しています。私が考えている男は、実際にはすべてのデザイン作業をいくつかの CSS ファイルを使用して XHTML ファイルとして行い、必要に応じてその場でグラフィック要素を作成します。彼は Dreamweaver を使用していますが、実際にはナビゲーション ツールとしてのみ使用しています。（私はあの人から多くのことを学びました）
純粋な CSS ベースのデザインを学ぶための投資を行い、少し経験を積むと (IE のどこが悪いのか [公平を期すために改善されている])、最終的にはより高速になることがわかりました。私はコンテンツ管理システムに取り組みましたが、デザイナーが根本的に異なる外観を思い付くために、アプリケーションを変更する必要はほとんどありませんでした。
::パームジーとジョンギャロウェイにうなずく::
保守性の要素に同意します。最初のレイアウトを完成させるのに少し時間がかかりますが（私はまだCSSアートのジェディ見習いなので）、1つのファイルを更新するだけで15ページのWebサイトを完全に刷新するのは天国です。
事業上の理由は全くないと思います。技術的な理由は、たぶん、それでもかろうじて-それは世界中で巨大なタイムサックです、そしてあなたはそれをIEで見て、壊れて泣きます。
私は実際にユーザーページでスタックオーバーフローのテーブルを見ることができます。
インラインスタイルもたくさんあります...
これが良い方法である理由をいくつか追加します。
スクリーンリーダーがページを読み込んで表を見ると、それが表であることをユーザーに伝えます。したがって、レイアウトに表を使用すると、ユーザーは表の内容が実際には他の表形式のデータではなく記事であることを知らないため、非常に混乱します。
これは実際には正しくありません。JAWS、Window Eyes、HAL などのスクリーン リーダーは、レイアウト テーブルを無視します。それらは、実際の Web を扱うのに非常にうまく機能します。
間違いなくあります。あなたがまだそれを目指して努力しているなら、あなたはそれを正しく理解していません。
DIV+CSS レイアウトは、保守性と生産性の点で、実際にはテーブル レイアウトよりもはるかに簡単です。それを言うのが早すぎる前に、それを練習し続けてください.
テーブル レイアウトも優れていますが、レイアウト用ではなく、マイナー チューニングに関しては例外的な欠点があります。