ブラウザのシチュエーションシップ：ブラウザは合意しても、仕様は合意しない

著者名Twitter @atbrakhi 数日前、ブラウザと仕様について話していたところ、同僚のBrian Kardellがブラウザの世界でよくある状況についてコメントしました。それは、ブラウザが仕様書とは少し異なる動作で合意してしまうことがあるというものです。 私の即座の反応は、これはブラウザ間のシチュエーションシップのように聞こえる、ということでした。誰も仕様書にコミットしたがらないのです。 それは冗談でしたが、それから考え始めました。仕様書が一方のことを言い、Chrome、Firefox、Safariがすべて別のことをしている場合、実際に何が起こるのでしょうか？答えは明白だと思うでしょう。仕様書は仕様書なので、ブラウザが間違っており、ブラウザは修正されるべきだと。しかし、それが常に起こることではありません。時には、代わりに仕様書を変更します。 仕様書を最初に書かれたアルゴリズムや一連のルールとみなし、ブラウザが後から来る実装だと考えるなら、それは奇妙に聞こえるかもしれません。しかし、ウェブの歴史はそれほど単純ではありません。仕様書とブラウザの実装は最初から互いに影響を与え合っており、その関係は今日でも非常に活きています。 では、何が先か：ブラウザか、仕様書か？ ニワトリと卵の質問だと思うかもしれません。しかし、そうではありません。歴史的に正しい答えは、それほど劇的ではありません。それらは共に成長しました。 1989年、Tim Berners-Leeは、後のWorld Wide Webとなるものを提案しました。1990年末までに、彼は最初のウェブサーバーと、WorldWideWebという最初のブラウザ/エディタを書いていました。同時期に、彼はHTML、HTTP、URIの初期バージョンも開発していました。 したがって、誰かがウェブの巨大な仕様書を完成させ、ブラウザエンジニアがそれを実装しに行ったという明確な瞬間は、実際には一度もありませんでした。アイデアがあり、実装があり、そのシステムがどのように機能するはずかについての説明がありました。それらすべてが共に進化しました。 W3Cのウェブの歴史は、URI、HTTP、HTMLに関するBerners-Leeの初期の仕様書が、ウェブが広がるにつれてより大きな円で洗練され、議論されたと記述しています。最後の部分は非常に重要です。ウェブが広がるにつれて、です。 1つの実装が自己対話するのは比較的容易です。複数の独立した実装が同じ動作を理解し、再現しようとするところで、標準が必要になり始めます。 より多くのブラウザが登場し、より多くの人々がウェブサイトを構築し始めると、ウェブは共通の合意を必要としました。すべてのブラウザがHTMLの理解を完全に異にしていたら、開発者は同じページがどこでも一貫して動作することを期待できませんでした。各実装が独自のルールを発明するウェブは、もはやウェブではなくなります。ここでのユーザーエクスペリエンスを想像してみてください！ 1994年10月、Berners-Leeはウェブ標準の開発を調整するためにWorld Wide Web Consortium（W3C）を設立しました。1年後、1995年11月、HTML 2.0はInternet Engineering Task Force（IETF）を通じてRFC 1866として公開されました。この時点でもHTMLの標準化はさまざまな場所を移動していました。W3Cは後のHTMLバージョンで主導権を握ることになります。 そのRFCの一部は、この文脈で特に興味深いものです。それは、HTML 2.0が、すでに一般的に使用されていた機能を統合、明確化、および形式化したものとして説明しています。言い換えれば、ウェブはすでに存在し、ブラウザはすでにHTMLを実装しており、仕様書は人々がすでに使用していたものを説明し、安定させるのに役立っていました。 これは、標準を実装が存在する前に届けられる命令と考えるのとはかなり異なります。 なぜ仕様書が重要なのか これは、仕様書がブラウザが好きなときに無視できる単なる提案のように聞こえるようにしたくはありません。そうではありません。 仕様書は、ウェブが機能する理由の1つです。 共有された仕様書は、独立したブラウザエンジンに共通のターゲットを与えます。Blink、Gecko、WebKit、Servo、またはその他のブラウザエンジンは、内部的に完全に異なるアーキテクチャを持つことができますが、ウェブサイトが同じ入力を与えたときに何が起こるかについては、依然として合意する必要があります。 その合意があるからこそ、website-for-chrome.com、website-for-firefox.com、website-for-safari.comを維持する代わりに、1つのウェブサイトを構築できます。 もちろん、ウェブの歴史には、ブラウザ固有の動作がこれをはるかに困難にした時期がありました。ブラウザ戦争には、ブラウザが独自の機能をリリースし、開発者が互換性のない実装に対処しなければならなかった例が数多くあります。標準化は、異なる実装がターゲットにできる共通言語を作成することで、ウェブをはるかに予測可能にしました。 現代のブラウザ開発には、Web Platform Tests（WPT）のような共有テストスイートもあります。WPTには、複数のブラウザで実行できるWebプラットフォームの動作のテストが含まれています。これにより、ブラウザエンジニアや仕様作成者は、仕様書の文章だけでは得られない、より具体的なもの、つまり独立した実装が実際に合意しているかどうかをテストできます。 理想的な世界では、関係は単純です。仕様書は動作を記述し、ブラウザはその動作を実装し、共有テストがそれを検証し、全員が合意します。 残念ながら、私たちはソフトウェアエンジニアです。 そして現実は起こります 仕様書は人間によって書かれます。ブラウザは人間によって書かれます。ウェブサイトは間違いなく人間によって書かれます。未来はAIに属するかもしれませんが、今は人間にとどまりましょう。なぜなら私は人間であり、まだブラウザのバグを修正しているからです！ 3つすべてにバグがあります。 仕様書には間違いが含まれる可能性があります。文章が曖昧な場合があります。アルゴリズムが、実際には実用的でない動作を記述している場合があります。2つのブラウザエンジンが同じ言葉を異なる方法で解釈する場合があります。ブラウザが誤ってバグをリリースする場合があります。そして、ウェブサイトはそのバグに依存し始めることがあります。 そして、十分なウェブサイトが何かに依存するようになると、「正しい」とは何かという問題は驚くほど複雑になります。 仕様書がXと言い、Chrome、Firefox、SafariがすべてYを実装していると想像してください。 一見すると、これは簡単です。Chromeにバグがあり、Firefoxにバグがあり、Safariにバグがあります。3つのブラウザすべてを修正し、Xを実装させます。 しかし、もしブラウザが長年Yのように動作していたらどうでしょうか？もし既存のウェブサイトが、それに依存していることさえ知らずに、その動作に依存していたらどうでしょうか？すべてのブラウザをXに変更すると、実装は仕様書と一致するかもしれませんが、同時に実際のユーザーのために実際のウェブサイトを壊してしまう可能性があります。 その時点で、有用な質問はもはや単に「誰が仕様書に違反したか？」ではありません。 有用な質問は、「ウェブを壊すことなく、どのようにして1つの相互運用可能な動作に戻るか？」となります。 ここで、ブラウザ間のシチュエーションシップが面白くなり始めます。 実際のブラウザのシチュエーションシップ コンピュータサイエンスで最もエキサイティングなトピックの1つに関わる、驚くほど良い現実世界の例があります。HTMLフォーム送信における改行文字です。 ついてきてください。 2020年、現在私の同僚であるAndreu Botellaは、HTMLフォームをシリアライズする際にブラウザが改行文字をどのように正規化するかを調査していました。改行は、LF、CR、CRLFなど、さまざまな方法で表現できるため、見た目よりも複雑です。 その作業中、Andreuは、特定のフォーム送信におけるファイル名に関するブラウザの動作と、仕様書の記述（そのまま書かれている場合、それらのファイル名を正規化しない）との間に不一致を発見しました。 関連するWHATWGの問題には、このブログ全体にほぼ完璧な一文が含まれています。 「すべてのブラウザは改行を正規化することに同意しますが、仕様書では正規化なしになります。」 ほら、これです。Chrome、Firefox、Safariは公式にシチュエーションシップにあります。 仕様書は一方のことを言いました。Chrome、Firefox、Safariは別のことに同意しました。 提案された解決策は、単に3つのブラウザバグを報告し、すべての実装に変更を強制することではありませんでした。この場合、修正は仕様書の側で行われました。ブラウザがすでに合意していた正規化が実際に仕様化されるように、シリアライズルールが更新されました。結果として標準化された作業がマージされ、Andreuは後に詳細を記述しました。