- 1990年代の個人Webは標準化されたレイアウトツールが不足しており、
, , 1x1.gif, , DHTMLのような手法で配置と効果を無理やり作っていた時代だった
- CSSレイアウトが定着する前は、
1x1.gifと繰り返しの が要素の位置を押し出す中核的な配置ツールのように使われており、本文はそれを大げさなノスタルジーとして風刺している
- 初期のCSSはリンクの下線を消したり、
a:hoverのスタイルを変えたりするような小さな視覚効果に集中しており、その結果リンクと通常テキストの区別が曖昧になった
- DHTMLはCSSとJavaScriptを組み合わせ、読み込み時の
alert()、雪の結晶、アコーディオンメニュー、カスタム``のような効果を作るコピー＆ペースト文化と結び付いていた
- ピクセルフォント、88x31ボタン、Internet Explorer 4.0、GeoCities、FrontPage ’98は、当時の個人Webサイトが技術選択とアイデンティティを誇示する方法として登場する
とがアニメーションだった時代
をの中に入れる組み合わせは、1990年代のWebではすごいコンピューターアニメーションのように冗談交じりに扱われていた- 1990年代のWeb開発者には、今日のjQueryや非リレーショナルデータベースよりも重要な話があった、というような誇張された自負が根底にある
1x1.gifでページを押し出していたレイアウト
1x1.gif、spacer.gif、transparent.gifはいずれも1ピクセル×1ピクセルの透明GIFを指す- HTML画像の
WIDTHとHEIGHT属性を大きく指定して見えない空間を作り、ページ要素を望む位置へ押し出すことができた
- サンプルコードでは、
, , , , ``、WebカウンターCGIを一緒に使い、構造と装飾をまとめて処理している
1x1.gifが要素をページ上のどこにでも配置できるようにしてくれ、今日に至るまで垂直方向の中央揃えの唯一の方法だ、というような風刺が続く
で合わせていた手動の間隔
- 画像タグを使うのが難しければ、
を繰り返して間隔を合わせる方法もあった
PLEASE SIGNとMY GUESTBOOK BELOW:の間に複数の を入れて、ゲストブックの文言を配置する例が出てくる- 1990年代に
を使った回数だけニッケル硬貨をもらえていたなら、AOLの月間超過料金を払うのに十分なお金があったはずだ、という冗談へと続く
初期のCSSはリンクの下線から消した
- CSSはHTMLの黄金期の終わりに登場し、コンテンツとスタイルの分離を約束した技術として紹介される
- 当時CSSで最初にしたことは、リンクの下線を消すことだった
- リンクがテキストのように見え、テキストがリンクのように見えるようになり、どこをクリックすべきか分かりにくくなった
- マウスカーソルの後ろに炎の軌跡が残る効果もあわせて言及される
- 2000年の
index.shtmlファイルの例には、インラインCSSとしてa:hover {text-decoration: none; color: #000000}だけが入っている
- ホバー時に下線を消し、色を黒に変えるコードである
- SSIを使う
index.shtmlファイルである点も、冗談のように強調されている
DHTMLとコードコピー文化
- CSSでリンクの下線を消した後、JavaScriptでページ読み込み時に
alert("Welcome to my website!")を表示する流れが続く
- CSSとJavaScriptの結合は、DHTMLという「恐怖の技術」として風刺される
- DHTMLの効果には、ページ上に降る雪の結晶、アコーディオンメニューのアニメーション付きイメージマップ、
を使ったカスタムなどが含まれる
- Dynamic Driveのようなサイトのおかげで、問題を自分で解くよりも50行のコードブロックをコピーして貼り付ければ解決するかのように扱われる
- DHTMLは当時のTwitter Bootstrapになぞらえられている
ピクセルフォントと低解像度の美学
- 当時のコンピューター画面はCRTだったため物理的には大きかったが、解像度は高くなかった
- 限られたピクセルを効率よく使うため、6ポイント程度の小さなフォントを使う雰囲気があった
- シンプルなピクセルベースの書体を見たWeb開発者たちはイラストレーターになろうとし、スプラッシュ画面にアイソメトリックなピクセルイラストを入れる試みもあった
- その時間とお金は、PhotoshopのインストールよりもドットコムIPOへの投資に使ったほうがよかったかもしれない、という冗談も添えられる
Internet Explorer 4.0と88x31ボタン
- 今日の人々がInternet Explorerを嫌う理由は、Internet Explorer 4.0の「純粋な形」から遠ざかったためだ、というふうに風刺される
- Internet Explorer 4.0はActive DesktopとChannelsを備えた完璧なブラウザのように誇張されている
- 当時のWebサイトには、訪問者がどのブラウザを使うべきか、どのツールやサービスを使っているかを知らせる88x31ピクセルのボタンがたくさん貼られていた
- ボタンは軍服の勲章のように、サイト運営者の選択と所属を示す装置になぞらえられる
- エディタの例はFrontPage ’98
- Webサーバーの例はGeoCities
- Webリングはサイトを最も上位に上げてくれる場所を望んでいたが、実際には存在しなかった、という冗談が付く
今日のWebに向けた冗談
- 今日のWebは、JavaScriptの上に複数の抽象化が積み重なった状態として表現される
- JavaScriptが数学もまともに計算できないという冗談とともに、今日のWebにたどり着いたことが驚きだ、という形で締めくくられる
- 次のpull requestに大量の
を付けて、チームをいたずらっぽく困らせようという提案で終わる
1件のコメント
Hacker News のコメント
サーバーサイド・イメージマップの話は本当に他人事とは思えない
Webプログラマーというより、ときどきWebベースのツールを作るシステム管理者なので、Webの腕前は2000年代初頭で止まっていて、JavaScriptにも妙な抵抗感がある。最近のツールで、画像上の点を扱う基本動作が必要になったのだが、JavaScriptなら5行で済むことを、2023年にサーバーサイド・イメージマップで処理した
結局、JavaScript 5行の代わりに、状態を管理するPython 50行と、妙なフラグメント構文を処理するリクエストハンドラの特殊ケースができてしまった。少し気恥ずかしいが、それでも動くようにできたのは妙に誇らしい
archive.orgのWayback Machineで古いサイトを見つけても、ホームページ全体がサーバーサイド・イメージマップだと、元のサーバーなしにはサイトの残り部分へのリンク先URLを知る方法がなく、完全な行き止まりになる
当時はほとんど壊れていて、ズームが100%でなかったりpaddingが0でなかったりすると座標がずれ、似たような問題がいくつもあった。誰も気づかなかったのは、イメージマップ自体がほとんど使われておらず、サーバーサイド・イメージマップはなおさら使われていなかったからだ
私もJavaScriptなしで楽に逃げたくて90年代のHTMLを思い出したのだが、結局Chromiumのバグを直したあと、サーバーサイド・イメージマップは微妙だという結論になってJavaScriptを使い、JavaScript版のほうが良かった
HTMXは本当に救いのようだし、Tailwind UIを買えば誰でもフロントエンドでかなり危険な人間になれる。それでも、なぜJavaScriptが気持ち悪いのか、別の視点も気になる。個人的には文法の一貫性のなさが大きく、TypeScript方面は
node_modulesフォルダを見るだけで胃がむかむかする全体として何が起きているのかを制御できないという感覚のせいで、長いあいだフロントエンドから離れていた
Lispを数十行書いて、画面のイメージマップを提供するWebサーバーを作り、イメージマップのリクエストが来たらクリックを挿入するようにした。通勤の往復を省くために作った小さな使い捨てツールだったが、その後COVIDが発生して、あまりにも多くの人が使うことになり、今も誰かが使っているかもしれない
「今でも要素を縦方向に中央揃えする唯一の方法」はもはや事実ではないが、この30年間、
divの中でただvertical-align: middle;を使えなかったことによる生産性コストは数十億ドルだったのではないかと思うIE4やIE6のころ、リンクの
:hoverにoverlineスタイルを付ける流行も覚えている。テーブルで角丸のdivやボタンを作ったりもしたし、2000年代にもPhotoshopで切り出してテーブルセルに入れる苦痛は続いていたVALIGN=MIDDLEがあった90年代にも可能だったかは分からないが、2000年代には確実に存在していた
ただし、ルール2〜3個で十分なのに5個以上を付けるような重複したルールもよく混ざる。本当にばかばかしいほど間抜けだ
あの忌々しい角のために、どれだけ時間を使ったか分からない
Tailwind CSSでも単純ではなく、要素がブロックなのか、テキストなのか、親のレイアウトが何なのかなどをずっと考えなければならない
div { display: table-cell; vertical-align: middle; }だすべての状況で通用するわけではないが、最初は汚く感じても、関心の分離は依然として保たれているし、特にほかの欠点は見当たらない
この文脈での DHTML はDistributed HTMLではなくDynamic HTMLで、だからDynamic DriveのDynamicでもある
ほかの人たちも同じように誤引用しているのを見ると、筆者が最近ふざけて修正した可能性もありそうだ
結論としては、冗談ではあるが良い冗談ではない、という方向だった
フレームも外せない。全ページのナビゲーションバーを修正しなければならない問題に対する、元祖「解決策」だった
問題は、検索エンジンが各フレームページを別々にインデックスできたため、誰かがフレームページに直接入ってきた場合にどう処理するかを考えなければならなかったこと。セクション間の切れ目も常にはっきりしていて、不自然で使いにくかった
HTMLの中に特殊なコメントを入れておくと、Apacheがクライアントへ送る前に別ファイルの内容で置き換えてくれた
frame-busterスクリプトを配布し、自分のフレームなしでページが孤立するとframe-joinerスクリプトを呼び出した理論は https://martinfowler.com/articles/micro-frontends.html#Run-t... にあり、実装は https://luigi-project.io で見られる
そこにHTMLテーブルが基本機能を備え、データソース駆動のテーブルやリストビューが2000年代半ばに提供されていたなら、途方もない時間とお金を節約できただろう
Webが決済標準を受け入れ、ブラウザ自体が決済入力を処理していたら、どれほど多くのお金を節約できたかについて語り始めるときりがない
みんな、全員が同じブラウザを使っていなかった時代があったんだ
1996年、Microsoftのホームページにはマウスオーバーで開くメニューバーがあり、それがどう動いているのか突き止めようと決心した
当時のIEには「ソースの表示」ボタンがあったが、プラットフォーム感覚が足りなくてNotepad文書として開かれた。サーバーはUnixなので改行は
\n、一方Windowsは\rを期待するため、HTMLソースは1行の長い文書に見えたソースを隅々まで見ても、HTMLタグは全部知っているものばかりで、内容もページに見えているテキストだけだった。唯一見慣れなかったのはHTMLエンティティで、動くメニューのあるサイトにはどこにも出てきたので、間違いなく関係があると信じていた
6か月間、DHTML効果は実は HTMLエンティティ というものの魔法の呪文で実装されているのだと信じていて、その後WebMonkeyのチュートリアルを見つけたことが、キャリア全体につながった
ミニファイツールやコンパイラは素晴らしいが、よく設計されたサイトの整理され管理されたソースを読んでいた時代が本当に懐かしい
本番コードでも元のソース形式を保存し、世界中の他の人々が自分たちのコードを読むという期待を保てる圧縮方式に進んでいたらよかったのに、と思う。初期のWebが急速に発展したことにも、こうした文化は大きな役割を果たしたし、自分がこの業界に入った経緯の中でも間違いなく大きな部分だった
Barnes & Nobleで JavaScript Bible を買って週末に読み、それからずっと学び続けることになった
テーブルが 角丸 にも使われていたことを忘れてはいけない
3×3のテーブルを作り、中央のセルを除いたセルに画像を入れて角丸のWebサイト要素を作ったのだが、それが人類の表現力の頂点のように感じられた
HTMLメールも流行していて、メールクライアントはブラウザよりはるかに更新が遅かったため、正しく表示したいならこの手法は2010年代まで使われていた
tl.gif、tr.gif、bl.gifのような画像セットを作っていたことは絶対に忘れられない当時のブラウザは空セルの背景画像をレンダリングしなかったため、左右のセル背景を見せるには本文で触れられていた
1x1.gifも必要だった。良い時代だったborder-radiusを手に入れた途端にデザインの流行が変わり、誰も角丸を欲しがらなくなったテーブルで角丸を作る前には、Trillianというマルチチャットアプリをスキン変更するようにいじっていた記憶がある。Yahoo ChatやICQなどに対応していて、角丸を扱うのと同じように上部と側面のセルに繰り返し画像を入れ、ウィンドウサイズの変更がうまくいくようにしていた
偉大にして全能なるオズの最高傑作。まあ、iPhoneのほうが大きかったかもしれない
90年代/00年代のWebサイトなら「800×600解像度に最適化」ボタンは欠かせなかった
もう少し格好をつけたければ「Valid HTML 4.01」も付けた
当時の広告は、最近の複雑なJavaScriptの束や動画広告ではなく、単純な標準サイズのバナーだった。Norton Internet Security 2003が訪問したページのHTMLをこっそり書き換え、標準広告サイズのバナーだけを削除して他はそのままにしているのを見て衝撃を受けた記憶がある。広告ブロッカーはセキュリティソリューションである、という20年前の確認でもある
記事全体に webmaster という単語が一度も出てこないなんて、Zachは本当に90年代にいたのかと思ってしまう
当時その肩書きがどれほど「格好よかった」かは、誰にも理解できないだろう。今見ると自分でさえ気恥ずかしいが、本当に良い思い出がたくさんある
冗談ではなかった
90年代のWebを実際に体験してみたいなら、The Geocities Gallery https://geocities.restorativland.org/ がおすすめ
こうした個人Webページには、何か美しいものがある。各ページはそれぞれはっきりした見た目を持っていて、それだけでも作成者の性格をかなり物語っている
たいていは自己紹介、ランダムな個人写真が数枚、短い説明付きのおすすめリンク集、趣味についてのゆるい文章などがあり、とても個人的で落ち着いている。どのプロフィールページも同じように平板で退屈に見え、際限なく増えるコンテンツや特定の人生イメージを維持しなければならないというプレッシャーがある今日のソーシャルメディアとは、鮮明な対比をなしている
Area51 の下のどのディレクトリにあったのか思い出せず、もしかするとアーカイブされていないかもしれない昔の自分のサイトを探したり、ただ当時を追体験したりして、かなりの時間を過ごした
記憶とは不思議なものだ。Geocities を見ると昔のインターネットの匂いまで思い出したが、おそらくそれはコンピューターが置いてあったファミリールームの匂いだったのだろう
ACID、ICE、FIRE のような BBS アートグループの初期作品も、当時は本当にかっこよかった
IE5/6 支配以前、より高度なものはおおむね Flash に流れていった。2000年代初頭には E4X ベースで React に似たフレームワークを作り、ActionScript/Flash/Flex、Mozilla/Netscape がそれをサポートしており、VB.Net の XML リテラル記法にも似ていた
Microsoft と Google は採用せず、最終的には JSON が王者になった
90年代には、Webレイアウトに関する質問の答えはほとんど常にテーブルだった
テキストの整列がずれた？ テーブル。かっこいいメニューが必要？ テーブル。サイト全体を作る？ ネストしたテーブル。行とセルでデザインをハックできるのに、なぜ CSS が必要だっただろうか
fontタグを入れなければならなかったことも忘れてはいけない動的デザインには本当に優れていて、列/行の結合、整列、重み付けにも対応している。CSS は今でも昔のテーブルよりずっと複雑だ