ウェブ制作の現場で長く続いてきた作業のひとつが、ブラウザに足りない機能をJavaScriptで補うことでした。開閉するパネル、画面全体に出るダイアログ、装飾された選択メニュー。本来はただの部品なのに、ライブラリを読み込み、初期化のコードを書き、キーボード操作や読み上げの面倒まで見て、数年後の保守で頭を抱える。制作に関わっていれば、たいてい心当たりのある流れだと思います。

ここ数年、その前提が少しずつ変わってきています。7月28日に安定版が出たChromeの最新版の変更点を眺めると、方向がかなりはっきり見えます。カメラとマイクの扱い、Shadow DOMの組み立て、画面切り替えの計測。どれもこれまではJavaScriptの領分だったものが、HTMLの要素や属性、あるいはブラウザ標準の計測項目として整理されつつあります。今回はこの流れを、直近のブラウザ各社の動きと並べて眺めてみます。

カメラとマイクの入口がHTMLの要素になる

目を引くのは usermedia という新しい要素です。ブラウザが用意した操作部品として画面に置かれ、そこからカメラやマイクの利用が始まります。Chromeの開発者向けブログによると、利用者の意図をはっきりさせた上で許可を求め、映像や音声のストリームを受け取るところまでを、この要素が受け持つとされています。

従来はJavaScriptから取得用の関数を呼ぶと、いきなりブラウザの許可ダイアログが出る作りでした。押した覚えのないタイミングで「カメラを使いますか」と聞かれれば、多くの人はまず拒否します。そして一度拒否されると、設定から手で戻してもらうしかない。許可の取りこぼしは技術の問題ではなく導線の設計の問題で、その導線をブラウザ側に寄せるという判断は理にかなっています。

使いどころとしては、オンライン相談の受付ページ、採用ページで応募者に短い動画を録ってもらう仕組み、業務用の写真アップロードなどが考えられます。ただし現時点ではChromeだけの機能なので、これ抜きでも成立する作りにした上で、対応ブラウザでは体験が良くなる、という積み方が現実的です。

影の中の差し込み口も属性で書ける

同じ版では、template 要素に shadowrootslotassignment という属性が加わりました。Shadow DOMの中で、どの中身をどの差し込み口に入れるかを手動で割り当てる指定です。これまでは JavaScript から Shadow DOM を作るときにオプションで渡すしかなく、スクリプトが動くまで組み立てが完了しませんでした。

地味な変更に見えますが、意味は小さくありません。サーバー側が吐き出したHTMLだけで部品が完成するなら、最初の表示が崩れて後から整うという、あの落ち着かない一瞬が減ります。PHPでHTMLを組み立てるWordPressのような環境とも相性が良く、ブロックやテーマの作り込みで恩恵を受ける場面はありそうです。

見た目の調整からスクリプトが抜けていく

この半年ほどの各ブラウザの更新を並べると、同じ傾向がもっと広い範囲で起きていることが分かります。グリッドやフレックスの隙間に線を引く指定、箱の幅に合わせて文字の大きさを自動調整する指定、入力欄が中身の量に応じて伸縮する指定。最後のものはFirefoxが対応したことで、主要なブラウザエンジンすべてで使える状態になりました。矢印キーでの移動先をまとめて宣言できる属性も加わっています。

どれも、かつては手で書いていた処理です。文字幅を測って収まるまで縮めるコード、入力のたびに高さを再計算するコード、キーボード操作を自前で組み立てるコード。案件ごとにコピーして、少しずつ挙動が違う状態で増えていく類のものでした。それが数行のCSSや属性ひとつに置き換わるなら、書く量が減るだけでなく、動作の説明もしやすくなります。

制作者側の実利は、たぶん「新しい表現ができる」よりも「消せるコードが増える」ところにあります。納品後に触る人が読む量が減るのは、それ自体が品質です。

足並みがそろわない例もある

とはいえ、宣言的に書ける方向へ一直線に進んでいるわけではありません。分かりやすい例が、選択メニューの見た目を自由に整えられる仕組みです。Chromeでは去年のうちに安定版に入り、Safariは開発者向けの先行版で確認できる段階、Firefoxは試験版でフラグを立てて試す段階。MDNの解説でも、広く使われるブラウザの一部で動かないため安定して使える状態には達していない、という位置づけになっています。

ブラウザごとの歩幅の違いも、この7月にそのまま表れました。Chromeが新しい要素を入れた前日にはSafariの更新版が出ていますが、こちらはWebAssemblyまわりの小さな追加と、CSSや通信の不具合修正が中心です。文字の大きさの単位が拡大表示でずれる問題や、要素の配置指定が意図した位置に戻らない問題が直されています。新機能を並べる回もあれば、土台を固める回もある、というだけの話ですが、対応状況を「だいたい揃った」で済ませられない理由ではあります。

ブラウザ間の差を埋める取り組みとしては、Apple、Google、Igalia、Microsoft、Mozillaが共同で進めるInterop(相互運用性)のプロジェクトがあります。今年の重点領域は二十近く挙げられており、テストの通過率がダッシュボードで公開されているので、気になる機能の足並みを自分で確かめられます。営業資料に「最新の書き方に対応」と書く前に、こういう一次情報で裏を取る癖をつけておくと安全です。

体感速度の測り方も追いついてきた

もうひとつ、Chromeの最新版には計測まわりの追加があります。画面を読み込み直さずに表示を切り替える作りで、その切り替えを一区切りとして扱い、操作をきっかけに描かれた主要な内容が出るまでを測れるようになりました。

これは長く空いていた穴です。表示速度の指標は最初の一画面に強い一方、その後の画面遷移は測りにくく、「最初は速いのに使い始めると重い」という感想を数字で示せませんでした。予約フォーム、商品の絞り込み、地図の切り替えなど、中小企業のサイトでも読み込みを挟まず描き替える作りは増えています。改善の順番を決めるときに、体感に近い数字が手元にあるかどうかは大きな差になります。

もっとも、指標が増えれば追う手間も増えます。全部を見るのではなく、その画面で一番使われる操作をひとつ決めて、その前後だけ測るくらいでも十分に判断材料になります。

どこから取り入れるか

実務での見極めは、三つに分けて考えると迷いません。まず、主要なブラウザすべてで使える状態になったものは、素直に置き換えの候補にできます。入力欄の伸縮や要素同士を結びつける配置指定はこの段階です。次に、特定のブラウザだけで動くものは、無くても成立する上乗せとして扱う。カメラの新しい要素は今のところここに入ります。最後に、置き換えによって読み込んでいるライブラリやプラグインを一つ減らせるかどうかを見る。減らせるなら優先度は上がります。

この最後の観点が、長く運用するサイトでは一番効きます。数年前に選んだライブラリの更新が止まり、依存関係の警告だけが増えていくという話は珍しくありません。ブラウザに入った機能は簡単には消えないので、同じことができるなら標準の側に寄せておくほうが、後々の手間は少なくて済みます。

新機能の一覧を追いかけるのは楽しい作業ですが、実利という意味では逆向きの棚卸しのほうが効くのかもしれません。いま抱えているJavaScriptのうち、どれがすでにHTMLやCSSで書けるようになっているのか。手元の案件をひとつ開いて、読み込んでいるファイルを上から見ていくだけでも、消せる候補はいくつか見つかるはずです。