晩年のIEに思いを馳せる

これはRecruit Engineers Advent Calendar 2021の1日目の記事です。

昨年くらいから多くのプロダクトでIE11のサポート終了が盛んになり、今年はIE11自体がサポートを来年終了することを発表したり、Google検索のIEサポート終了があったり、1つ大きな時代の節目のようなものを感じる1年でした。
IEは最盛期は95%近くのシェアを占めていたそうですが、2021/10時点のデータではIEのシェアはPCで4%程度とやはりだいぶシェアも落ちてきた印象もあるし、そもそも昨今はスマホブラウザの流入が多いプロダクトなんかではIE対応自体ほとんどやってなかったという方も多いのかもしれません。

僕は昔IE7までは対応したことがあり、当時の感覚で言うとIE11って相当バグや特殊な仕様が少ない方だったイメージだったのですが、下記のIEサポートを終了すると使える機能一覧を見るとやはり数年の進化の差は大きくすでにだいぶ取り残されてる状態だったのだなと思います。

https://github.com/progfay/benefit-from-end-of-ie

一方、「Safariは新たなIEなのか」という議論が以前から上がっており、最近も再びこの話題を目にしました。

参考

• https://http203.libsyn.com/is-safari-the-new-ie
• https://dev.to/nektro/safari-is-the-new-internet-explorer-1df0
• https://blog.logrocket.com/safari-next-internet-explorer/

本稿ではIE対応とは、そしてIEとはどんな存在だったのかを改めて振り返りつつ、現在のSafariなどと比較してみようと思います。

IEの功績

IEは前述の通り、一時は95%以上のシェアを誇りインターネットを世に広めることに大きく貢献したプロダクトです。僕が初めてインターネットなるものを触れたのも当然IEを通してでした。当時の僕にとってはインターネット＝IEでした。IEは多くの人が利用してその恩恵を受けてきたはずです。
IEを通してインターネットが世に与えた影響は計り知れません。もちろんIEがなくてもNetscapeやOperaなどの当時の競合プロダクトが代わりに流行ったのかもしれませんが、それでもIEがインターネット世界にもたらした影響というのは非常に大きかったように思います。

IE対応の回想

この偉大な功績の一方で、我々開発者にとっては対応に開発者の工数と体力を大きく消費する象徴とされることが多かったかと思います。IE対応自体したことないという方もいらっしゃるかもしれないので、IE対応とはどういうものだったのかをIE7以降を中心に解説してみようと思います。

かなり記憶に頼って書いてます。誤りがあればご指摘ください。

互換モード対応

IEには互換モードというものがあり、これをユーザーが有効にすることでレンダリングモードの切り替えが可能でした。IE8にIE7モードというレンダリングモードがあるのです。

この互換モードがちょっと曲者で、互換と言ってますが実際のIE7とは別なエラーや崩れが出たりすることがあり、仕様を調べても大抵「IE7同様の表示をします」くらいの情報しか出てこず、対応しようとすると結局自前でエラー回避の手段を考えて検証するしかないということが多かったです。

今だと大抵の場合Githubでissueを検索するなりissue立てるなりで良いかもしれませんが、IEはオープンソースではなかったのですし、多くの場合は自力でバグの再現条件を自力で解明したり対策しなければいけなかったのです。
これは答えが出るかわからない調査を続けることになり開発者を消耗させる一因だったと思います。

（今考えるとMicrosoftに直接問い合わせるとか、やりようはあったのかもしれませんが当時の僕には英語でのやりとりはハードルが高かったです）

プリント対応の難しさ

プリント対応とかしてた場合、IEのプリントレイアウトでだけ崩れたり、異常に長いページになってしまうことなどがありました。これはプリントするときだけCSSのレイアウト仕様が若干異なっていたり、プリント時だけ使えないプロパティなどがあったために起きる事象でした。

例えば当時のCSSハックで-9999pxのような指定をすることが時折あったのですが、それを使ってると空白のページが大量に出たりすると言うものもありました。ですがなぜそのページがそんな長くなってしまうのか、この仕様を知らないとなかなか気づけないし、知っててもどこでどういう指定をしているのか調査するのは長時間の調査が必要になることもありました。

バグの多さ

IEには前述の互換モードやプリント対応・いくつかのバージョンなど、サポートしようと思うと結構な数のパターンがありました。
定量的なデータがあるわけではないので個人の感想ですが、IEはバージョンや互換モード固有など特定のケースで起きるバグというのが多かったです。「IE8,10,11では崩れないのにIE9だけ崩れる」ということがあったり、「互換モードにするとエラーが出る」「windowsXPのIE8だけおかしい」というように、テストしていくとどこかだけ壊れてて、それを直すと今度は別のパターンで壊れ・・・というように、ある種袋小路のようになることも多々ありました。

IE6のmarginとfloatを同じ方向にすると何故かmarginが倍になるというバグは特に有名で、まだCSS2でできることが少なかった時代にこれが封じられるのはなかなか辛いものがありました。

float: left;
margin-left: 10px; // この場合、marginが何故か20pxとなってしまう

最新の実装が使えない/独自メソッドの多さ

また、「Chromeは動くのにIEは動かない」と言うことも多々ありました。IEのメジャーリリースは主にOSと連動しており、現在と異なり新しいOSを使いたければPCなりOSなりを買い直さなければいけない時代だったので、常に最新が使えたChromeと異なりIEは最新の実装が使えないことも多かったのです。
そうでなくともChromeやFirefoxでは実装されてる機能がIE11では使えない、ということも多かったため多くの開発者はIEでは動かないものが多いようなイメージがあったかもしれません。

またIEは標準化される前に実装されたIE独自のメソッドを使用しないといけないケースが結構ありました。
代表的なのはaddEventListenerが使えず（！！！）、attachEventを使わなければいけなかったことです。

if (el.addEventListener) {
  el.addEventListener('click', modifyText, false);
} else if (el.attachEvent)  {
  el.attachEvent('onclick', modifyText);
}

こうした違いをいちいち自前で実装せず吸収してくれたのが、当時のjQueryです。今babelなどを通して開発してるのと同様に、当時はjQueryを通してある程度この辺りの分岐を吸収してもらうのが一般的だったような気がします。

バージョンごとの破壊的変更

IEはバージョンアップデート時に破壊的変更が行われることがあり、それが原因で使えない機能などもありました。
記憶に残ってるのは、css3のborder-shadowです。たしかIE9とIE11は同じ表示だったのですが、IE10でだけ0.5px影が右にずれるような表現になっており見た目が揃わず苦戦しました。結局、当時は影をつけるようなUIのときには影の画像を作ってbackground-imageで指定してbackground-repeatさせたものです。

また当時はCSSハックを駆使してこの破壊的変更に対応することも多かったです。CSSハックとはベンダープレフィックス的なもので、特定のIEバージョン以降にだけ有効なプロパティなどを駆使することです。

.element 
{
  color: #000;
  color: #888\9;  /* IE10以下 => 結果的にIE8のみ */
  *color: #000;   /* IE7以下 */
}
.element:not(:target)  /* IE9以上 */
{
  color: #000\9;  /* IE10以下 */
}

これもなかなかややこしく、プロパティ毎にどのバージョンまで影響が出るか考える必要があるのでなかなか考慮漏れが起きやすい部分でもありました。

IE開発チームの苦悩

ここまででIE対応がどう辛かったのかはある程度伝わったかと思います。ただ一方で、MicrosoftのIEの開発チームも相当に苦しい思いをしたであろうということはちゃんと理解する必要があると思います。
IEは新たなバージョン開発時に、高い後方互換性が常に求められたそうです。これはIEが実際Microsoftの多くのクライアント企業から要望として上がっていたという背景があるようです。IE7で動いてた社内システムがIE8で動かなくなったり崩れたりしたら、それは利用者側の企業としては苦しいところですよね。

ただ数年に一度のアップデートなのでhtml標準の変更やIE独自実装の廃止など、どうしても破壊的変更もあり、そういった背景があって互換モードが誕生したようです。後方互換を完全に維持して実装するより、そっちの方がおそらく影響度的にも限定的にできるし、アーキテクチャ的にも良いと判断だったのでしょう。

なのでIE対応の辛さの背景にあるのは、標準化プロセスがまだまだ未整備だった時代背景だったり、我々消費者側の要望に多く応えようとした結果であって、仕方なかったものだと思います。IE対応は我々にとって辛いものだったかもしれませんが、IEが悪いのかと言われると当時のMicrosoft開発チームって相当に優秀な人たちで形成されてたんじゃないだろうかとも思いますし、むしろ一番IEというプロダクトで苦しんだのはIE開発チームなのかもしれないので、安易な批判はできないと思います。

Safariは新たなIEなのか

さて、では過去のIEと比べて昨今のSafariはどういった点で「新たなIEなのか」と議論されるようになったのでしょう。

OSと同期的なアップデート

IEとSafariの共通点としてわかりやすいのはアップデートのタイミングです。IEは新しいWindowsが出たタイミングや新製品発表時にメジャーアップデート製品としてIEをリリースしていました。ChromeやFirefoxなどとは違い、OS毎にIEのバージョンはほぼ決まっていたというわけです。
これはIEに限らず、当時のMicrosoft製品は全部そうでしたね。

Safariもこれと近しい部分として、Safari単体でのアップデートはできずOSアップデートと連動する形でSafariもアップデートするという形をとっています。これはつまり、古いOSシェア分だけ古いSafariシェアがあるということです。

iOSはご存知の通り、あまり頻繁にアップデートしない方が結構います。かく言う僕もメジャーバージョンのリリース直後は様子見で、ある程度安定したかなってころにアップデートするようにしてたりめんどくさくて結構放置してしまったりします。そのため、古いバージョンのiOSシェアは一定数常にいるため、サポート対象としては「iOS 13~15 Safari対応」みたいになることも多いかと思います。これが「IE8~11対応」と似てるということですね。

バグの多さと更新の遅さ

前述の通りSafariの場合、Chromeのように常に最新版が適用されるとは限らないので、ブラウザ側のバグを考慮しながら開発者が実装する必要がある場合があります。
これによってIE同様バージョン毎のバグや仕様・未実装の機能を考慮しながら開発しなければなりません。またこれとは別に、IE同様ChromeやFirefoxでは使える機能がSafariだと使えない、ということも比較的多い気がします。

https://github.com/progfay/safari-aka-next-ie

もちろんこれは逆に「Safariだと使えるのにChromeでも使えない」というケースもあるし、IEの時よりかは主要なAPI群で対応されてないものは少ない気もしており、これに関しては一概に当時のIEと状況が似てるとは言えないかと思います。

ITPなどの独自路線

SafariにはITP(Intelligent Tracking Prevention)と呼ばれるユーザーのプライバシーを保護を目的としたトラッキング防止施策が存在します。ブラウザを選択する際にプライバシー観点の機能の充実度というのは差別化としての意味も大きく、重要だと思うのですがこれによってこれまでのトラッキングができなくなるため主にトラッキング広告を中心に大きな影響を受けました。CNAME Cloakingと呼ばれる、DNSレコードのCNAMEを介して1st partyなCookieを発行する対応など、広告企業たちは多くの対応を行いましたが、それに対してもSafariは対策を講じるなど非常に強力な対策を講じています。

こういった独自路線について我々Web開発者はこの違いを理解し対応しなければいけないため、痛みを伴うことがあります。ITPリリース時に何度か、僕も調査を行なったこともありますし人によって対応工数を取られた方もいるのではないでしょうか？

これはIEでも見られた「独自メソッド」と近いものを感じますが、少し毛色が違うような気もします。というのも、IEの独自路線はあくまで「独自メソッド」があることでJSでやたら分岐しなければいけなかったもので、Safariが独自メソッドが多いかと言われるとある程度はありますが普段開発してて意識しなければいけないほど多いなとは感じないので、これもまた当時のIEと状況が似てるとは言えないかと思います。

比較するとそこまで似た状況ではない

このように、Safariはある程度は確かに当時のIEに近いものがあるにはあるのですが、どれも当時ほどのものではないというのが現状なように思えます。

これは当時の開発者たちがそれまでの経験から、JSやhtmlの標準化団体を設立し標準化プロセスをまとめた（tc39やwhatwg）ことによって、現代の開発者は標準という壁に守られてるという現状が大きいように思えます。
また、Safariにバグや独自路線があってもbabelやcore-jsなどの努力によって、我々開発者が意識しなくても良いようになっており守られている部分も大きいと思います。

ChromeとFirefox

ではSafari以外のブラウザは当時のIEと比較してどうなのでしょう？

Chromeも独自路線は強い

Chromeは現在最も使われているブラウザとなりましたが、当時からIEとはあまり似たようなところは少ないように思えます。

ただし、Chromeも独自路線感は強いような気がします。AMPやService Worker始め、多くの新機能をどんどんリリースしてる印象があり、標準化や周りのブラウザの実装がまだまだ追いついてないような気がします。もっともこれは他ブラウザの対応が遅いというよりかは、ブラウザごとに実装優先順位を決めてることが起因してるので致し方ないことなのかもしれません。Chromeが描くWebの未来の話は個人的にはわくわくするものも多いのですが、なかなかSafariで実装されず開発者としては利用できないものがあったり、むず痒い状況に思えます。

またChromeは大元がGoogleなので、ITPのようなトラッキング防止施策は自分たちの売り上げの低下に直結するので安易に追従できないのもあってか、折衷案（privacy sandbox）を提案していますが、これにSafariやFirefoxが追従するのかは不明です。

ある程度Safariが提案したものをもとにしてたりもするんですが、そもそもSafariのITPなどのプライバシー施策はGoogleの広告事業を意識したものにも思えますし、受け入れない可能性は十分あるかと思います。実際、FLoCはBraveなどの一部Chromium系ブラウザでも採用しない方向のようです。
この辺についてはAppleとしてもいろいろ思惑とかもあるのかないのか...Appleの本音がどうなのか気になりますね。

シェアが落ちてるFirefox

Firefoxは比較的独自路線色やバグなどそこまで多くないように思いますが、そもそもシェアが落ちてきているため影響力が弱まってしまっているのかもしれません。実際Doh（DNS-over-HTTPS）など率先してやってる部分はあるのですがそこまで話題になってはなさそうな気がしますし、プライバシー保護施策もSafari同様強く勧めてるのですが、どうしても語られるのはChromeとSafariの比較が多い気がします。
Mozillaは非営利団体である種バランサー的な立ち位置な気もするので、シェアが伸びて欲しいなと個人的には思います。

まとめ

こうやって比較してみると、確かにIE同様Safariにも似たような状況は多少見られるものの、一方で当時よりは多くの面で状況が改善されており、Safariを新たなIEと言うにはだいぶ状況が違うと言えるように思えます。

これは当時のjQuery然り、babelやcore-jsなどツールチェーンやpolyfillの努力、そして標準化団体の取り組みによって我々開発者が以前より守られてる証拠でもあり、感謝すべきことだと思います。

一方、まだ我々はSafariやChromeそれぞれの独自路線や標準化の戦いの渦中にいて、ITPやprivacy sandbox始めれぞれの施策の影響を未だ大きく受ける立場にあります。特にSafariは、やはり独自路線や強行路線の色が濃く、普段の我々の開発にも影響があるような大きな施策を今後も打ち続けることが予想され、我々は来年もSafariの動向には引き続き注目する必要があることでしょう。

そして今やMicrosoftも「IEは技術的負債もたらす」として、利用しないよう呼びかけています。IE対応は確かに辛いものもありましたが、それは時代背景や我々消費者の要望が背景にあり、またIEがもたらしたWebの進化と恩恵は尊敬すべきものだと思います。
IEが「対応に開発者の工数と体力を大きく消費する象徴」という意味で使われなくなる日を願いながらの、2022年IEサポート終了の年に向かっていくアドベントカレンダーでした。