テーブルレイアウト、フレーム、スペーサーGIF：ソースコードで読むウェブの歴史

今日このソースを読むためには、当時の回避策の独特な語彙を理解する必要がある。具体的に3つの技術——スペースをゼロにしたネストされたテーブル、不可視のスペーサーGIF、複数ドキュメントのフレームセット——を識別すれば、誰でもすぐに古いページがどのように構築され、なぜ現代のデバイスで表示が崩れるのかを理解できる。

テーブルタグをビジュアルグリッドに転用

初期のビジュアルレイアウトの基盤はHTMLテーブルだった。もともと行と列で構造化データを表示するために設計されたtable要素は、XHTMLやCSSが普及する以前に、マルチカラムページ構造の主要なメカニズムとなった。ICS Mediaが公開した歴史的概要によると、当時の制作者たちはtableタグをビジュアルグリッドとして扱い、ヘッダー、サイドバー、コンテンツカラムにわたる複雑な雑誌風インターフェースを組み立てていた。

データテーブルをシームレスなページレイアウトに変えるため、開発者はブラウザのデフォルトボーダーとパディングを排除する必要があった。HandmadeLyticsの記録では、ウェブ制作者がcellspacing=0 cellpadding=0をtable開始タグ内に直接記述していた。

<table width="760" border="0" cellpadding="0" cellspacing="0">
 <tr>
 <td width="160" valign="top">ナビゲーション</td>
 <td width="600" valign="top">コンテンツ</td>
 </tr>
</table>

セル間隔とセル内余白の両方をゼロに設定することでブラウザの標準マージンが削除され、テーブルセルは端から端まで密着して配置できた。開発者はさらに、バナーやサイドナビゲーションメニュー、テキストコンテナ用のサブグリッドを作成するために、個々のテーブルセル(<td>)内に二次的、三次的なテーブルをネストしていた。

この構造的アプローチには根本的な機械的弱点があった：ブラウザのレンダリングエンジンはコンテンツに基づいてセルの寸法を動的に計算する。ユーザーがブラウザウィンドウをリサイズしたり、セル内のテキストが不十分だった場合、意図したビジュアル階層が崩れてカラムが内側につぶれてしまうのだ。

スペーサーGIFの仕組みとNetscapeの失敗したタグ

テーブル寸法を固定するため、開発者はスペーサーGIFを導入した。WorldWideMartの記録によると、スペーサーGIFは正確に1×1ピクセルの透明グラフィックだった。開発者はspacer.gif、blank.gif、shim.gifなどの一般的な名前でこれらのファイルをアップロードしていた。

1×1ピクセルの透明画像はほとんどファイルサイズを持たないため、ダイアルアップ接続でも瞬時にダウンロードできた。制作者はHTMLのwidthとheight属性で寸法を上書きし、この画像をテーブルセル内に挿入した：

<td><img src="images/spacer.gif" width="160" height="1" alt=""></td>

不可視画像を160ピクセル幅に引き伸ばすことで、開発者は剛性のある見えない支柱を作り出した。ICS Mediaは、これらの支柱がテーブルセル全体で最小幅と高さを保証し、隣に配置されるコンテンツに関係なくカラムが崩れるのを防いだと指摘している。1px.comの回顧録によると、スペーサーGIFはネストされたテーブル全体にわたるピクセル単位の精密な制御を維持するために使用され、目に見えない機械的なストッパーとして機能していた。

Netscapeはこの挙動を公式化しようと、専用の<spacer>要素をブラウザに導入した。MDNのHTML要素リファレンスアーカイブによれば、Netscapeは外部画像ファイルを必要とせずに1ピクセルレイアウトグラフィックの挙動を再現するためにspacerタグを特別に作成した。このタグは広まらず、主要ブラウザもサポートを追加しなかったため、引き伸ばされた1×1GIFが当時の普遍的なレイアウトハックとして残った。

フレームセットによるウィンドウ分割とネストドキュメント

テーブルレイアウトが単一ファイル内の幾何学を制御する一方で、フレームセットはブラウザウィンドウ全体を別々のドキュメントに分割した。WorldWideMartの記録によると、1996年にNetscape Navigator 2.0がフレームを導入し、その後MicrosoftもInternet Explorerにこの機能を採用した。

フレームセットは標準の<body>要素全体を置き換える。MDN Web Docsによると、frameset要素は個々のframe要素のコンテナとして機能する。各frameはブラウザビューポートに完全に独立したHTMLファイルを読み込む個別の矩形領域を定義する。W3C HTML 4仕様では、FRAMESET要素はメインウィンドウのレイアウトを矩形部分空間で指定するツールと定義されている。

<frameset cols="200,*">
 <frame src="menu.html" name="sidebar">
 <frame src="main.html" name="content">
 <noframes>
 <body>お使いのブラウザはフレームをサポートしていません。</body>
 </noframes>
</frameset>

標準的な2カラムフレームセットでは、開発者はmenu.htmlを左側200ピクセルの固定ペインに、main.htmlを残りの可変スペースに読み込んだ。サイドバーのリンクをクリックするとコンテンツペインがターゲットされ、ナビゲーションウィンドウは静的なまま右ペインだけがリロードされる。

CSS以前のタイポグラフィと現代のレンダリング障害

これらのレイアウト内でテキストをスタイリングするには明示的なインラインタグが必要だった。HandmadeLyticsは、fontタグがCSS以前の道具箱における遍在する要素であり、center、blink、marqueeと並んで使用されていたことを特定した。制作者はsize、color、face属性をテキストスパンに直接適用して見出しや本文をスタイリングした：

<font face="Arial, Helvetica, sans-serif" size="2" color="#333333">
 アーカイブされたテキストエントリ
</font>

現代のブラウザ、検索インデックスボット、モバイルビューポートがこれらのレガシー構造に遭遇すると、レイアウトロジックは完全に破綻する。固定幅テーブルと引き伸ばされたspacer.gifファイルで構築されたページは、スマートフォンの画面に合わせて柔軟に調整できず、代わりに横スクロールを強制したりコンテンツを切り取ったりする。

フレームセットはさらに深刻な崩壊をもたらす。フレームセットがページを別々の矩形部分空間に分割するため、最上位のURLにはmain.htmlのテキストではなく、子ドキュメントへの参照しか含まれない。現代の抽出ツールやリーディングモードが親ドキュメントを解析しようとしても、空のコンテナしか見つからない。ブラウザベンダーは複数フレーム階層をどう扱うか統一的な技術仕様を公開していないが、この構造的分断により線形ドキュメント抽出は信頼できない。

ソースコード内のこれらのマーカー——cellspacing="0"、引き伸ばされた1×1画像ファイル、<frameset>宣言、インライン<font>タグ——を認識することで、CSS以前のウェブ開発の正確なメカニズムが明らかになる。現代ブラウザで壊れたレンダリングに見えるものも、マークアップから直接読み取れば計算ずくのエンジニアリングシステムとして理解できるのだ。