Webプラットフォームにおける優先事項、技術的負債、難解な問題について話しましょう...

ブラウザエンジンプロジェクトは、他のほとんどのソフトウェアプロジェクトと多くの点で似ています。「管理者」は今も、休職中のメンバーなどを考慮に入れながら、マネージャーが統括する専門チームを編成し、予算を割り当てます。優先事項を決め、綿密な計画を立てる必要があります。そして筆者がこれまで見てきたどのプロジェクトとも共通する点として、同じようなプレッシャーや問題に直面します。全ての作業に十分なリソースが確保できることはなく、常に何かしら新たな要求が追加され、技術的負債が積み上がり、時折本当に難解な問題が発生します。 ブラウザエンジンプロジェクトに特殊な点があるとすれば、独立したプログラム以上のものになろうとしていることでしょう。相互運用可能な標準プラットフォームに貢献しようとしているのです。私たちにとって問題なのは、チーム独自の優先事項を「全て」クリアし、一般向けにリリースされるなどして、初めてその恩恵が得られるということです。

これは実際に経験するとつらいものです。 <details>要素を例に見てみましょう。これは文字通り最も単純なインタラクティブ要素です。これまでの経緯を以下に整理します。

• 2011年6月にChromeが<details>を導入
• 1年後の2012年7月にSafariが導入
• その1年後の2013年7月にOperaが導入
• その3年後の2016年9月にFirefoxが導入
• Microsoftは導入せず、2020年にEdgeがChromium版に移行してようやく導入

リリースから全てのブラウザに導入されるまで9年もかかりました。新たに定義された、ブラウザ普及率が100%に限りなく近い状態になったことを示す「Baseline: Widely Available」の条件を満たすのにさらに3年かかります。つまり、実質的には昨年ようやくWidely Availableとなったということです。

しかも、これはまだ初期段階であり、かつ魅力的な部分にすぎません。当然、これからバグが見つかって、新たなテストが追加され、最終的には改良版やアップグレードなどがリリースされます。現在も、ページ内検索などを改善したり、呼び出し元などの新しい概念を追加したりするたびに、テストが失敗する場合があり、<details>のサポート状況をばらばらなものにしています。

時間とともに、機能マトリクスの項目は増え続け、要件をクリアするよりも速いペースで未対応事項が増えています。技術的負債は積み上がる一方です。

Interopの登場

Interopは当初、技術的負債を減らすための手段として考案されました。優先事項を協力して選び、不合格を示す赤い四角を全部緑色に変えていく取り組みです。しかし、優先事項の判断は難しい問題です。

私たちは毎年おおよそ100件程度の要件を優先事項として指定されます。しかし、Interopは単にブラウザメーカーが同じ優先事項に合意する手助けをしているにすぎません。リソース自体が有限なのは変わりません。つまり、何かを優先するということは、必然的に他のものは優先しないということになります。

また、何を優先するか、なぜ優先すべきかについて、多くの競合圧力を各方面から受けます。

例えば、初期開発に共同で集中的に取り組むことができれば、デベロッパーにとっては極めて効率的です、といったことを言われるわけです。2011年、あるいは2012年に<details>を極めて高い品質で全てのブラウザに実装できていたらどうだったか、想像してみてください。

いくつかの新機能に共同で取り組む利点は他にもあります。まず、開発に携わる人々の熱意が違います。また、誰もが同じテーマについて同時に話すようになるため、誰も大きなイベントを見逃すことがなくなります。その結果、普及も早まります。ECMAの年次版のようなものも得られます。したがって、昨年InteropがCSSネスティング、ポップオーバー、相対カラー構文、宣言型Shadow DOMなどの領域を追加したのは意外ではありません。

しかしその一方で、すでにサポート状況がばらばらな機能も多くあります。これらは優先順位を判断するのが極めて難しく、いたるところに見られます。当然それぞれ価値が異なり、その価値についても議論の余地があります。対象となるコミュニティが全く異なる場合もあります。エンジンによってかかるコストが違う場合もあります。 こうした状況が重なることで、常に難解な問題がつきまといます。ニーズとしていつまでも、時に極めて長い期間残り続けます。

長期間にわたる難解な問題

こうした長期間にわたる難解な問題については、どういうわけか一向に優先順位が決まりませんが、筆者は今年、これらの問題を優先順位付けする方法を見つけなければならないと主張したいと思います。5年、7年、あるいは10年ごとに、こうしたプロジェクトに集中して取り組む必要があるかもしれません。

筆者のブログの読者やIgalia社のポッドキャストのリスナーは、MathML（Mathematical Markup Language）とSVGがおそらくこうした問題の最たる例であることをご存じでしょう。いずれも最古のWeb規格に数えられ、最初のバージョンがリリースされた時期はHTML4.0やCSS2と重なります。HTMLパーサーに特別に組み込まれ、現在はHTML Living Standard（MathML、SVG）に組み込まれています。

しかし、いずれも歴史的に大幅な資金不足の状態にあり、実際の作業の大半はボランティアや管理者以外の組織が担っています。26年が経った今もなお、最後の重要な作業に取り組む決心ができないのです。

そのため、Interopには毎年両方について要望が寄せられています。

2024年の「State of HTML」アンケートでは、デベロッパーが挙げるコンテンツの課題として<svg>がトップに選ばれ、「ブラウザサポート」に起因する課題の倍近くの得票数でした。SVGの他の使用方法は含めず、<svg>要素だけでもHTTPアーカイブデータのHTMLページの55%以上で使われています。約130個あるHTMLの要素のうち、<svg>よりも使用されているhtml要素は27個だけです。SVGは、Webエンジンを利用する埋め込みアプリケーションでも多用されています。

数式コンテンツは、arXivやWikipediaなど無数の数式を使用する特定のサイトや、オンライン教育や書籍に多く見られます。HttpArchiveのクロールは、主にあまり数式が使われない一般向けのホームページを対象にしているため、その測定にはあまり向いていません。しかしクロールでも、ネイティブ関数のレンダリングではなくギャップの橋渡しを行う最も一般的な2つのJavaScriptライブラリが、多くのページで読み込まれるのを見ます。これはパフォーマンスに悪影響を及ぼしますが、特殊な問題です。テキストのレンダリングにJavaScriptは必要ありません。また、Adobe InDesignやMicrosoft Wordなどの多くのドキュメント編集ツールもMathMLをサポートしています。これらはすでに多くのスクリプトが要求される複雑なアプリケーションであり、もしサポートが不十分な場合、さらに多くのスクリプトを読み込む必要があるということです。

Igalia社は、資金提供を受けながら自社資金も投じて実装や改善を行ってきました。開発を前に進めるために、私たちは毎年一定の出資を行っています。しかし、この方法では遅々として進みません。最後の作業を成し遂げるためには、共同での取り組みが必要です。そうすれば、はるかに速いペースで前に進み、大いに改善できるはずです。

これらの問題に集中的に取り組み、改善を推し進める考えに賛同していただける方は、ぜひ私たちや他のベンダーにご連絡ください。力になっていただけると思います。

もちろん、そう簡単には行かない可能性もあると思います。これまではそうでした。ベンダー以外の開発者が作業を行うことや、外部からの資金提供が有効であることは実証済みです。Igalia社はこれからも地道な取り組みを続けていきますが、外部からの資金提供がなければ、自らの出資だけでは限界があります。これらの取り組みの恩恵を受ける企業には、一部の作業への出資をご検討いただけるとありがたいです。もしくは、MathMLに関する作業に直接出資していただくことも可能です。