同じHTMLとCSSを書いても、ブラウザによって表示や挙動が少しずつ違う。制作の現場では当たり前のように受け入れている面倒だが、その差を毎年少しずつ埋めていく共同プロジェクトがある。Interopと呼ばれる取り組みで、ブラウザを作っている各社が参加し、年ごとに重点分野を決めて、各ブラウザの対応状況をテストの合格率で追いかけていく。

その来年ぶんの題材を決める提案の受付が、9月3日に始まった。締切は9月23日で、GitHubのissueとして誰でも出せる。同じ日にAppleのWebKit、Googleのweb.dev、MicrosoftのEdgeチームがそれぞれ呼びかけを出していて、どんな書き方が通りやすいかの説明も添えられている。読み比べると、重なっている勘所がいくつか見えてくる。

すでに標準として固まっているか

前提として、Interopは新しい技術を発明する場ではない。W3CやTC39といった場で仕様が固まり、ブラウザベンダーからの異論が残っていないものについて、実装の食い違いだけを潰していく。過去に選ばれた機能は、少なくともどれか一つのブラウザで実装済みだったものがほとんどだとされている。

WebKitの記事は、まだ存在しない機能がほしい場合はInteropではなく、CSSであればCSS Working Groupのissueなど、その技術を決める場に持ち込むよう案内している。順番を飛ばすと、そもそも土俵に乗らないという整理だ。

テストがあるかどうかで枠が変わる

Interopの進み具合は、Web Platform Testsの合格率で測られる。裏を返すと、テストが十分にない機能は、選ばれても点の付けようがない。提案するときは、既存のテストがどれくらいあるかを調べてリンクすることが求められる。

テストや計測の仕組みが足りない領域には、重点分野とは別に調査枠が用意されている。こちらは合格率を競うのではなく、将来の改善に向けて土台を整えるための宿題という位置づけになっている。出したい機能の成熟度によって、入り口が二つあるということになる。

範囲は狭く、具体的に

三社とも揃って書いているのが、提案の範囲を絞ることだ。WebKitは「タイポグラフィ」ではなくfont-size-adjustのように、一つの機能か、関係の近い小さなまとまりで出すよう勧めている。Edgeの記事も、「CSSを良くしてほしい」「フォームまわりを直してほしい」といった広い要望は評価しづらく、焦点の定まった提案のほうが選ばれやすいとしている。

実際に困った場面を書けるか

説得材料として重視されているのは、現場でどう困ったかという具体的な話だ。自分の案件で遭遇した食い違い、フレームワークやライブラリのissue、開発者アンケートの結果など、多くの人が同じ壁に当たっている証拠があると強い。

探す手がかりも用意されている。webstatus.devで各ブラウザの対応状況を確認したり、開発者からの要望を集めたリポジトリで、すでに公開されている使いどころを引いてきたりできる。数ある候補の中で、なぜこれを先に片付けるべきなのかまで書けると良いとされている。

提案を出さない人にもできること

提案文を書く時間がなくても、関われる余地はある。同じ内容のissueを二つ立てるより、すでにあるissueにコメントや反応を付けて後押しするほうが良いと、各社とも案内している。気になる提案に賛同の意思を残しておくだけでも、判断材料のひとつになる。

選ばれなかった提案も捨てられるわけではない、という説明も目を引いた。Edgeのチームは、落選した提案は開発者からの明確な要望として受け取り、長く残っている課題を整理したダッシュボードに反映していくと書いている。提案の結果が出るのは来年2月ごろの予定だという。

今年の重点分野には、View Transitions、Navigation API、アンカー位置指定、ダイアログとポップオーバー、コンテナスタイルクエリなどが並んでいる。こうした機能を数年後に「もうどのブラウザでも普通に動く」と言えるかどうかは、この時期の公募から始まっている。中小企業のサイトを作る側としても、いま回避策を書き足している場所を思い出しておくと、来年以降の道具立ての変わり方が少し読みやすくなる。