インターネットを形作ったHTMLハック技法
(tedium.co)- 初期のWeb開発者は、ブラウザごとに標準実装と不具合が異なり、有効なHTML/CSSだけで望むレイアウトや挙動を安定して保証するのが難しかった
- Netscape 4、Internet Explorer 5/6/7、Safari/WebKit、Outlookのような環境は、CSS、PNG透過、コメント、セレクタ、メールプレビューにおけるブラウザ別の回避コードを生み出した
- HTMLテーブルレイアウト、sIFR、Chrome Frame、レスポンシブデザインは、本来の意図とは異なる組み合わせによってデザイン上の制約や旧式ブラウザの問題を乗り越えようとした事例だった
- こうしたハックには、アクセシビリティ低下、非標準コード、Flash・プラグイン依存といった限界があったが、当時は互換性と視覚表現を確保する現実的な手段だった
- Web標準の理想と実際の利用方法は絶えず衝突し、開発者とデザイナーの繰り返しの回避策は、Webデザイン、メールHTML、モバイル対応のやり方に長く残った
ブラウザの不具合を避けていたCSSハック
- Netscape Navigator 4.0の
@importハックは、Netscapeが対応できないCSSをあえて@importで読み込み、そのブラウザに高度なスタイルを適用させないようにする方式だった- 基本CSSは
<link>で読み込み、より発展的なCSSは@importで分けて読み込む構造だった - CSS Cookbookは、この方式がNetscapeで動作しないCSSファイルも一緒に読み込む効果を生んだと整理している
- NetscapeはCSSの代わりにJSSSを推しており、W3CがCSSを選択した後、1997年夏にNetscape 4へCSSを急いで実装した
- Netscape 4ではJavaScriptを無効にするとCSSも無効になる副作用があった
- 基本CSSは
- Internet Explorer 6向けのCSSハックは、
_widthのようにプロパティの前にアンダースコアを付け、IE6だけがその宣言を解釈するようにする方式だった- W3Cのボックスモデルでは
widthはborderとpaddingを含まないとされたが、Internet Explorerはpaddingとborderを異なる形で処理し、ブラウザ間のレイアウト差を生んだ - 例としては
width: 300px; _width: 320px; padding: 10px;のように、標準CSSとしては無効な宣言をIE6向け補正値として使う形だった !importantの後ろに感嘆符をもう1つ付けて、IE7以下でのみ異なる動作をさせるといったIE専用ハックもあった
- W3Cのボックスモデルでは
レイアウトのために意味構造をねじ曲げる
- HTMLテーブルレイアウトは、本来表形式データを表現するための
<table>を視覚的なページ配置ツールとして使った代表的なハックだった- David Siegelは伝統的なデザイナーの視点からWebにアプローチし、HTMLの視覚的な結果をブラウザが決めるという慣例に逆らって、より見栄えの良いWebサイトを作ろうとした
- Creating Killer Web Sitesでは、彼は構造的マークアップを迂回し、画像を使って2次元配置を作り、テーブルが登場すると列にテキストを入れる方法を扱っている
- The History of the WebのJay Hoffmanは、HTML/XML純粋主義者たちがデザインとコード構造の混在を大きな禁忌とみなしていたとまとめている
- テーブルレイアウトはアクセシビリティを損ない、それを回復するのに時間がかかったが、開発者がWebポータルを視覚的に構成できる価値を示した
- レスポンシブデザインは、テーブルレイアウトのように既存技術を新しい方法で組み合わせたものだったが、Web標準の範囲内で画面サイズに応じてレイアウトを変える方法だった
- 2000年代のWebデザインでは、3列がページ下部まで続く「Holy Grail layout」をCSSで実装する問題が大きな論争の的だった
- 背景画像で偽の列を作るなど、さまざまな回避策があり、その後CSSはグリッドベースのレイアウトをサポートするようになった
- スマートフォンの普及により従来の3カラムレイアウトの意味は薄れ、別個のモバイルWebサイトに費用をかけなければならない状況が生まれた
- Ethan MarcotteはA List Apartのresponsive web design記事で、メディアクエリを使ってWebサイトの配置を画面形式に合わせる方法を提示した
- レスポンシブデザインは当時、なじみの薄いメディアクエリを使ったハックのようにも見えたが、Webデザインを長期的に変えた
Internet Explorer時代の画像とコメント回避策
AlphaImageLoaderは、Internet Explorer 5と6がPNG透過を正しくサポートできない問題をMicrosoft専用フィルターで回避した- Internet Explorerはバージョン4からPNGをサポートしていたが、多くの場面で正しくレンダリングできず、特にIE5/IE6の透過PNG非対応が大きな問題だった
- Perishable PressのJeff StarrはPNG fix for Internet Explorerで、当時の解決策がMicrosoft独自のAlphaImageLoader透過フィルターを必要としていたと述べている
- 例では、IEには
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(...)を適用し、非IEブラウザには[class]セレクタで通常の背景画像を適用する方式だった - こうした小さな機能の欠落が、2000年代後半から2010年代前半の開発者にブラウザ別ハックを引き続き意識させた
- 条件付きコメント（Conditional Comments）は、MicrosoftがIEのバージョンごとに特定のHTMLをレンダリングするかどうかを決められるようにしたHTMLコメント拡張だった
- Internet ExplorerがWebサイト実装にあまりにも多くのハックを要求したため、Microsoftはそのハックを管理するための別のハックを導入した
- 本来実行用ではないHTMLコメントが、IEのバージョン条件に応じて動作する構造へと変わった
- Internet Explorer 5で初めて導入され、Windows版Microsoft Outlookの複雑なメールデザインでは今でも必要になることがある
- Jens Oliver Meiertは2007年の記事で、条件付きコメントはIEのバージョン対応のたびに各文書やテンプレートのHTMLを再調整させ、構造と表現の分離を損なうと批判した
- 条件付きコメントはIE9以降で削除され、JavaScriptのconditional compilationが代替手段として使えた
フォント、メール、旧式ブラウザのための非標準な組み合わせ
- sIFR（Scalable Inman Flash Replacement）は、Webセーフフォントに縛られずに望むフォントを表示するため、テキストをFlash埋め込みに置き換えるJavaScriptベースのハックだった
- MicrosoftのCore Fonts for the Webは、限られたWebセーフフォントの使用を事実上推奨していたが、その後終了した
- 初期のフォント置換技法は画像利用から始まったが、アクセシビリティと表現の面で限界があった
- Shaun Inmanは、望むフォントを小さなAdobe Flashファイルで置き換えるアイデアを出し、Mike DavidsonはsIFRを通じて、必要に応じてフォントが拡張されるようにした
- Davidsonは2004年のsIFR公開記事で、ユーザーがインストールしていないカスタム書体を配信する問題はまだ解決されていないと見ていた
- sIFRは本格的なWebフォント解法へ向かう途中段階であり、Flashがモバイルへ広がれなかったため長続きしなかった
- プリヘッダーテキストハックは、メールクライアントのプレビュー行で望まない次の本文テキストが続けて表示されるのを防ぐため、非表示文字と空白文字を入れる方式である
- プリヘッダーはメール受信箱で件名の次に表示される短いテキストで、メールのサブタイトルのように機能する
- メールクライアントがHTMLタグや無関係な本文をプレビューとして引っ張ってくることがあるため、意図したプリヘッダーと次のテキストの間に余白を強制的に挿入する
- Litmusが推奨した例は、
display: none、max-height: 0px、overflow: hiddenを適用した領域に͏、、のような文字を繰り返し入れる形だった
- Google Chrome Frameは、Internet Explorer内でChromeのレンダリングエンジンを使えるようにし、IE6依存環境でも現代的なWeb機能を使えるようにしたブラウザプラグインだった
- 一部の企業は、強いIT部門の統制やIE6ベースの技術依存のため、最新ブラウザへ移行しにくかった
- Googleは2009年にChrome Frameを作り、古いInternet Explorerに現代的なエンジンを提供することで、開発者が複数バージョンを作ったり新機能を諦めたりしなくて済むようにした
- Chrome Frame引退記事によれば、当時は多くのユーザーが最新機能から取り残されたブラウザを使っていた
- Google WaveやYouTubeのようなツールはHTML5機能を必要としており、IE6対応はGoogleにとって制約だった
- Chrome Frameは5年間市場に存在し、その期間の後にはChromeが非常に支配的なブラウザとなった
Safari/WebKit専用対応とWebの実際の進化
- WebKit専用セレクタハックは、
@supports (-webkit-appearance:none) {}のように特定ブラウザ専用のCSS対応有無を利用し、WebKit系ブラウザにだけCSSを適用する方式である- Safariは登場当初、オープンソースコミュニティにルーツを持つエンジンを基盤としており、初期にはHTML/CSS標準への対応が強かった
- Apple MailはWebKitを使用しており、メールコーディングでは概ね良好に動作する環境と見なされていた
- 時間がたつにつれ、Safariのリリース日程がMacやiOSの日程に縛られ、業界より遅れがちになる問題が生じた
- 開発者たちは、Appleがバグを無視したり、競争上不利な機能を遅らせたりしていると批判した
- RedditのあるユーザーはSafari開発への不満投稿で、APIを実装してもバグが多かったり、後で壊れたりすると書いている
- このハックは、WebKitベースで始まった初期のChromeでも動作した
- HTMLの意図と実際のWeb利用のされ方は大きく異なっており、デザイナーやUI専門家は奇妙なコードにもかかわらず、インターネット上に視覚表現を築いた
- David Siegelの説明のように、標準化団体はHTMLがRSSのように最終デザインよりもユーザーと構造を重視する形で動作することを望んでいた
- 同時期に登場したGopherのようなプロトコルも、デザインの影響が大きくない形で動作していた
- しかし、インターネット利用者の創造性と商業インターネットの視覚言語への依存のため、その哲学は主流になれなかった
- メールHTMLでは、標準HTML/CSSだけでは簡単な透過グラデーション処理すら難しく、古いStackOverflowコメントのHTMLテーブルのグリッチのような回避策が今なお解決策になり得る
1件のコメント
Hacker News のコメント
レイアウトにテーブルを使うのはかなり理解できる
でもテーブルが流行遅れになった後の数年間は、レイアウトを float で組むのがすべてだった。あの時代こそ荒々しかったのに、リストに入っていないのは意外
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
「もともとはテキストブロック内で画像を浮かせるためのものだった float プロパティが、Web ページの複数カラムレイアウトを作る最も一般的なツールの1つになった。flexbox と grid の登場により、今では本来の目的に戻っている」
仕上げるころに IE で開いてみたらデザイン全体が崩れていて、ターゲット顧客はほぼ確実に IE を使う人たちだったので、結局テーブルベースで書き直さざるを得なかった。悲しい日だった
テーブルが退いた後、多くのフロントエンドチームが「純粋主義者」たちの信念を守ろうとして、float の小細工に累計で何カ月も浪費し、はるかに理解しにくい Web ページを作るのを見て、そこから重要な教訓を得た
Joel Spolsky は優れた記事でそうした開発者たちを Architecture Astronauts と呼んでいた。最小限の努力でうまく動くソフトウェアを実際に作ることが自分の仕事だということを忘れるタイプだ。最初の EJB 仕様の滑稽さや、Java の嘲笑された AbstractFactoryBuilderConstructor のようなものも、その類いが生み出したものだと思う
時間が経つにつれ、こういう傾向を見抜いて距離を置くのがうまくなった
https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
.clearfix::after { content: ""; clear: both; display: table; }[1] https://www.w3schools.com/howto/howto_css_clearfix.asp
float は扱いにくく、きちんと合わせるのが難しかったし、多くの人が単にテーブルに戻ったが、正直責められなかった
spacer.gif は敬意を払われないのか？
もちろん HN にはまだあり、すべてのページリクエストに含まれている
https://news.ycombinator.com/s.gif
好きだったものがいくつかある
Faux columns は視覚的に伸びているように見せ、サイドバーが本文と同じ長さであるかのようにした: https://alistapart.com/article/fauxcolumns/
さらに、9-patch と9個の div、または 3x3 のテーブルで、軸ごとに背景を繰り返して独自にボーダーをまねることもできた。CSS3 で border-image が登場して少し助けにはなったが、こうしたボーダースタイルは今ではあまり流行していない
角丸も 9-patch で作ることができ、多くの人はジェネレーターで複数の要素を作り、角丸をシミュレートする HTML を作っていた。この記事が説明している: http://benogle.com/2009/04/29/css-round-corners.html たいてい追加マークアップは画像よりバイト数が大きいが、ラウンドトリップのリクエストが減り、かなり簡単にできるという認識だった
ActionScript 寄りだったが、スタイリングの発想は同じだったので記事も書いた: https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co...
もう1つ気に入っていたのは、繰り返さない背景スタイルのパターンに cicada principle を使う方法だった
それでも、これだけ年月が経っているのに今でもすっきりしている
HN が今でもこのうちの一つを使っているのが気に入っている: HTML テーブルでレイアウトを組む
もう少し真面目に見ると、このリストは標準なしで開発すると、制御情報がいくつもの「まあ何とか我慢できる」副次的な経路にエンコードされることをよく示している
こうした混乱や衝突の可能性は、現在の W3C プロセスが時に受ける軽蔑を見直させる。このプロセスは、標準主導の Web 技術の進化とブラウザ主導のイノベーションを組み合わせ、両者が交互に先行したり並行して進んだりできるようにしている
よく揶揄されるとはいえ、以前のやり方より持続可能で安定した方法だとも解釈できる
新しい W3C-ベンダー規範を非難する人たちのうち、この「奇妙なハック10選」が思い起こさせる浮き立った時代に戻りたい人がどれほどいるのか気になる
やりたいことが機能として扱われていなければ、どうにか創意工夫してやることになる。標準は十分に成熟して潜在的な要求をすべて捉えられないと、かえって硬直性を生み、こうした状況を招く。特に Web のように、必要に合うかもしれないし合わないかもしれない標準に縛られる場合はそうだ
他の分野ではたいてい選択肢が十分にあり、その中のどれかは必要なことをこなせるほど柔軟なので、それを選べばよい
研究寄りの仕事を長くしていると、やりたいことがハック的な技術アプローチを必要とするケースが驚くほど多い。多くの標準や機能セットは、お金が集まるビジネス/消費者の相互作用とその周辺システムを中心に生まれるからだ
ブラウザ機能に依存する多くのプレイヤー、たとえばアプリを WebKit や Chromium のバージョン内で動かす TV ベンダーは、標準委員会では完全に沈黙している。だから実際には Google、Apple、Mozilla の三者による綱引きにすら達していない
結果として div の中に入ったテーブルを得ることになる。ただし 12 列なだけだ
HTML 3.2 で学んだので、IE と Netscape のせいでどんなビザンチン式の馬鹿げたことが必要だったかはよく知っている。だがそれは MS と Netscape の選択であり、W3C の存在感がもっと大きかったとしても、MS と Netscape が新しい標準に従う保証や示唆はなかった
それでも、今のように一つの大企業が望めば残りの Web が引き受けなければならないゴミのような状況よりは、当時の方がましだった
本当にずっと良くなったなんて、素晴らしいね /s
自分の「お気に入り」のハックが抜けている。アクセシビリティ用の見出しを
-10000の位置に置き、画面にはレンダリングされないがスクリーンリーダーには読ませる方法だaria-labelのようなものがこのパターンの一部の用途を置き換えたが、すべてではないすべての CSS より先に読み込んでブラウザの quirks をなくしていた html5 shiv の話がない
https://paulirish.com/2011/the-history-of-the-html5-shiv/
テーブルセルをおとなしくさせるために使っていた 透明な 1×1 ピクセル GIF の古き良き時代を思い出す
https://news.ycombinator.com/item?id=38485665
なぜそうしていたのかも覚えていない。もっと速く読み込むためだったのかな？
初期の頃からもう一つ挙げるなら、改行なしスペース文字エンティティである
コンテナ内でテキストを右や左に押し出すときに使い、記憶ではテーブルセルをおとなしくさせるために 1x1 スペーサー GIF のようにも使っていた。ページによっては
現代の Web 開発者が CSS Grid があり IE が死んだことで甘やかされているのか、それとも当時の私たちが現代のフレームワークやビルド過程の複雑さを経験しなかったことで甘やかされていたのか、時々わからなくなる
ただ、今の方が簡単ではありそうだ。技術的には現代のフレームワークやビルド過程を必ず使う必要はなく、現代の CSS と JavaScript だけで、昔なら複雑だったサイトやアプリを簡単に作れるからだ
業界が車輪をより複雑な形で再発明し続ける習慣を身につけている
いちばんありそうな推測は、Web が新人開発者や経験の浅い開発者により頻繁に選ばれる分野であることの副作用だというものだ
レスポンシブデザインは本当にハックなのか？ メディアクエリは素晴らしい
条件ロジックを JavaScript に入れる代わりに CSS に置くのは大きな勝利だ。特にサーバーサイドレンダリングを望む場合はそうだ
ユーザーエージェントのさまざまな特性を問い合わせ、その結果に応じて別の CSS を提供できる。これをハックと呼ぶのは無知であり、レスポンシブデザインを作るために必要な部分だ