フレームは滅び、テーブルは永久に

あの頃を振り返る

table も frame も Netscape Navigator が独自に開発した要素だったのですが、 IE でもこれらが表現可能だった為、実際問題として公認せざるを得ない状況となりました。テーブルとフレームという私生児が W3C に公認されたのは、テーブルが HTML3.2（'97年1月勧告）から、フレームが HTML4.0（'97年12月勧告）からです。メーカーが参考にするような標準が存在しなかった '90年代ですが、 '97年になってようやく HTML3.2 が勧告されました。 Yahoo! JAPAN のスタートは '96年。アクセスメディアインターナショナル株式会社の調査によると、 '97年末の時点で日本のインターネット人口は884万人であったと推測されています。 Yahoo! JAPAN の記事によると '98年初頭には 1000万人に達したようだと記載されています。

table と frame を W3C が採択した頃、インターネットは普及の兆しは見せたものの皆が使うものではありませんでした。個人的にはその頃大学生だったのですが、まったく興味ナシオ君でした。ヤングでも触ったことのない者の方が多かったんじゃないですか？　まだ、低速回線しかなかった頃ですし...。

ちなみに、'96年は Netscape 絶対正義の時代だったらしいです。なにせ、テーブルやフレームという概念を HTML に定着させたのは Netscape の功績（？）です。「勝てば官軍じゃろがい！」と、ばかりに圧倒的シェアを誇る Netscape が威張っていましたが、 '99年には IE 帝國に追い落とされました。 '97年には NN4 と IE4 がリリースされましたが、この IE4 が Netscape の絶対支配体制に楔（くさび）を打ち込む名将だったのです。 IE4 は大衆の支持を得ました。 NN4 が大衆の支持を得られなかった要因は、CSS への対応があまりにも酷かったからだとも言われています。当時の情勢としては、「唯我独尊の（剛の拳）Netscape」、「W3C への理解を示す（柔の拳）IE」という感じだったみたいです。柔よく剛を制す。

長々と時代背景を書きましたが、 table と frame が W3C に認知された '97年がどのような時期だったのか知る必要があると思ったからです。つまり、ウェブを作るほとんどの人が テーブルとフレームは最初から存在していた要素であると認識しているハズじゃないか？　...と。

フレームの代わりならいます！

最新版の HTML4.01（'99年勧告）では、三つの DTD が用意されましたが、フレームを許容しているのは Frameset のみです。 Transitional では iframe（インラインフレーム）のみ許可、 Strict ではフレームの完全廃止を提言しています。

また実益を考えたときに、フレームと検索エンジンの相性が悪いという事情（ファイルを検索しにくいし、テキストがクロールされにくいなど）もあって最近では敬遠されています。フレーム埋め込み用ファイルのアドレスが裏に潜るコトを要因として、様々な弊害が生まれているのが実際のところです。

しかし、フレームが廃れてきた本当の理由は上記二点の他にあるのかもしれません。それは、フレームが他のもので代替可能であるからではないでしょうか？　実際、CSS で div に overflow を用いれば擬似フレームが作れますし、ブログなどの HTML 自動生成マシーンでも div を多用して画面を分割しているようです。巨大サイトの更新作業に役立つ便利ツールも続々開発されており、フレームを使わなくともリンク構造の管理を容易にできるようになりましたし...。

つまり、フレームが無くなりつつある原因の一つは弊害の多さであり、一つは代替が可能であったからだと思います。 HTML4.01 の Strict で撤廃されたものとして、 frame の他にも font などのメーカー由来の独自要素が多々ありますが（CSS で代替可能）、これらよりもシリアスな問題を多く抱えていたのがフレームです。しかし、都合のよい代替手段が全く無ければフレームは高い普及率を維持しただろうと思われます。まあ普通に考えて、問題児であって代わりが見つかるようならば捨てられるのが世の法則です。

テーブルの代わりはいません！

position 、 float 、 ovaerflow などを用いて何度か試してみましたがダメでした。擬似テーブルは作るコトができなくもありませんが、柔軟性や弾力性があまりにも足りないので実用的な使用に耐えられない木偶人形でした。 CSS で table の完全なる代替物を作ったというハナシは聞いたコトがありません。フレームと違って、テーブルの代わりは見つかりません（少なくとも '04年現在では）。

テーブルは広く用いられています。実際に表はそんなに頻繁には見かけないのですが、レイアウト目的でのテーブル利用は Yahoo! JAPAN をはじめとして、いたるところで見かけます。

本来の目的である ”表” 以外の用途で使用するコトは Strict ではない、とはよく言われますがソレを無視してメリットとデメリットを考えてみたいと思います。レイアウト目的でテーブルを利用する場合、タテとヨコに展開する雑誌やカタログのような構図が容易に描画できます。しかも、同様のものを CSS で作ろうとするよりも素晴らしい仕上がりになります。デメリットは、複雑に作れば作るほどレンダリングに時間がかかるというコトです。レンダリングに時間がかかるとは、ブラウザが HTML・CSS を読んで画面上に組み立てるのに時間がかかるというコトであり、高速回線だったしても待たされます。しかも、100% 構築するまではテーブル要素全体が表示されないので白紙のまま待たされるというコトです。

レンダリングの待ち時間を解消する対策は、一つのテーブル内に全てを押し込めるのでは無く、複数の小テーブルに分割する、h1 や div などのブロックレベル要素を（テーブルから切り離して）別個に配置するなどが考えられます。複数に分割すれば、画面上部から徐々に描画されていくのでビジターには親切な配慮となります。また、マージンを 0 にすれば、お互いが密接しているように見えるので見栄えも問題ありません。

IE におけるテーブルの表示を検証

左が IE6 、右が Firefox0.9.3 で同じファイル（DTD: HTML4.01 Strict）を開いたもの。

縦横ともに四段、table の背景色は silver、border は 6px 幅の gray です。デフォルトだと th 、 td ともに背景色が transparent（無色）なので、 table 本体の背景色を透過します。故に間仕切りは存在しないように見えます。

テーブルの仕組み特に幅を指定しなかった場合、テーブルは列（Ｙ軸）の中で最も長い部分に適応した幅になります。だから左の画像で説明すると、一列目と三列目は同じ横幅を持ちます。一列目と三列目は、GREEN,GREEN が最も横幅を取るセルであり、それに合わせた列幅に生成されているからです。

下記の三点画像は以下の設定

td,th {
       background-color: #eee;
       width: 6em;
       padding: 0 1em
}

IE6 Strict

IE6 Transitional

Firefox
Firefox0.9.3

セルに width と padding を指定したら、支離滅裂な対応になります。 IE では DTD によらず、width に padding を含んで計算します。 Firefox では padding を無視して width の幅全部にテキストが詰め込まれます。よって、見栄えは Firefox の方が横長になります。通常なら、Strict を宣言した HTML では IE6 と Firefox（及び Opera や Safari）における padding の扱いは同等になるものですが...。上記三点図を参照。

セルが破裂したら？
・・・table の overflow 処理

テーブルの構成要素、th や td は一般的なルールとは若干違う処理が行われるようです。例えば、横６文字（width: 6em）、縦２行（height: 2em）に td を指定したとします。これで12文字のテキストが収まるワケですが、20文字であるとか許容範囲をオーバーしたテキストを詰め込んだらどうなるでしょうか？

テーブルのセルは文字数が許容範囲を越えたときのオーバーフロー処理が常に一定のようです。つまり、横幅（width: 6em）は守りますが、縦幅（height: 2em）は守らずに縦に長くして文字を収める方式です。 overflow の値である hidden 、scroll 、 auto などはセルには通用しません。これは、 tr 、 th 、 td といったテーブルの構成要素がインラインでもブロックでも無い特殊要素だからです。ちなみに、table 本体はブロックレベル要素扱いとなります。

td,th {
       background-color: #aac;
       width: 6em;
       height: 2em;
       display: block;
       overflow: auto
}

ムリヤリ th と td をブロックレベル要素に置換して、overflow を auto に指定しました。 IE では置換行為自体が無視されましたが、Firefox では有効になりました。ただし、th と td がブロックレベル扱いになった時点でテーブルの枠組みは破綻して、ただの一段積みに変化したので使い道の無い方法です。ただし、CSS の記述を忠実に実行したのは Firefox の方だといえるでしょう。

また、table 要素本体に width を指定せず、 th や td だけに width を指定した場合、ウィンドウの横幅を縮めると縦長に変形していきます。 これも、重要なテーブルの特性でしょう（IE と Firefox で同様）。

テーブルの線形レイアウト

「一時期、W3C のウェブサイトでもテーブル・レイアウトを行っていた。結局、W3C もテーブル・レイアウトを許容している」と、いう意見があります。それに対して、「あれはテーブルでレイアウトしていたが、線形レイアウトだった。テーブルが表示できない状態にしても順を追って読める構図だったから、矛盾していない」と、いう反論があります。 ...線形レイアウトとは？

元のテーブルこのテーブルの意味は、光の三原色が混じったときにどの色になるのかを示したものです。 RED と GREEN が混ざると yellow になる、という具合の簡単な表です。

線形化テーブル今度は上の表を線形化してみました。こうなると、意味不明です。しかし、”表” なんだから、"表" の体裁が無くなれば意味不明になるのは誰に責められよう？　と、いうハナシです。純粋なる ”表” の場合は線形レイアウトを考慮する必要性がありません。というか、線形で表現しようが無いからテーブルで表現しているワケです。

今度は、段組の場合を考えてみます。テーブルを利用した段組です。テキストを段組にする目的は「省スペース化」・「視認性の向上」・「デザイン」のいずれかでしょう。

九頭立てレース線形版今度は競馬の九頭立てレースで出走する馬を記述した一覧表（上図）です。これは、必ずしも表にする必要はないのですが、横長のレイアウトにしたいなどの都合があって上の様にまとめるケースもあるでしょう。それで、この場合は線形化しても意味が通じるんですよ（左図）。

ちなみに、"table of contents" で目次という意味になります。「コンテンツの一覧」みたいな和訳の仕方でしょうか？　table という言葉、日本人には食卓、あるいは「タイム・テーブル」くらいしか浮かんできません。しかし、欧米人は HTML に table という要素があるのを知ったとき、「これで一覧をつくればいいのね」と、素直に思ったコトでしょう。かくして、table を用いた段組が普及していったのです（知らんけど...）。

IE 帝國 その戦略と大衆支配の構造