サイトのグローバルメニューで「今いるページ」だけ色を変える。制作の現場では当たり前にやっている処理ですが、実装の中身はいまだに泥臭いままです。WordPressならテンプレート側で付与されるクラスを頼りにし、静的サイトなら手書きでクラスを足すか、JavaScriptでURLを見て付け替える。ページ遷移のアニメーションまで含めると、さらに手数が増えます。

その領域をCSSの言葉で書けるようにしよう、という提案が7月末に公開され、8月に入って各所で取り上げられています。Chromeの開発者リレーション側から出ているもので、CSS Working Groupのベルリンでの対面会議でも議論されたとされています。仕様案の名前はCSS Route and Navigation Matchingです。

URLのかたちに名前をつける

提案の土台になっているのが@routeという新しい記法です。URLのパターンに対して名前をつけておく、という発想で、たとえばトップページを表すパターンと、詳細ページを表すパターンをそれぞれ別の名前として登録します。パターンの書き方は、サーバー側のルーティングで広く使われている記法をそのまま持ち込む形になっています。

ここが効いてくるのは、URLの判定ロジックがスタイルシートの中に集約される点です。今までは「このページかどうか」の判定がテンプレート、JavaScript、CSSのクラス名の三箇所に散っていました。名前をつけて参照する形になれば、少なくとも見た目に関わる部分は一箇所に寄せられます。

サイトのURL設計そのものをスタイルシート側に書き写すことになるので、運用の途中でURLを変えたときの追従先が明確になる、という副次的な効果もありそうです。逆に言えば、パターンの登録場所が増えれば管理箇所も増えるわけで、そのあたりの落としどころは実装が出てからの評価待ちでしょう。

どこから来てどこへ行くかで演出を変える

@navigationは、遷移の出発点と到着点を条件にして、その組み合わせのときだけスタイルを効かせる仕組みです。一覧から詳細へ進むときは左へ流れ、詳細から一覧へ戻るときは右へ戻る、といった向きのある演出を、遷移の向きそのものを条件として書けます。

従来これを実現するには、遷移を横取りして遷移前と遷移後のURLを比べ、View Transitionの種類をスクリプトから動的に指定する必要がありました。ページ数が少ないうちはよくても、階層が増えるほど条件分岐が膨らみます。宣言的に書けるようになるなら、この手のコードはかなり減らせそうです。

実務の目線で言えば、遷移演出は「入れたいが手間に見合わない」と判断されがちな部類です。デザイン段階では案に上がっても、実装コストと不具合の起きやすさを考えて見送る。書き方が数行で済むなら、その判断のラインは確実に動きます。

リンクの行き先を見て装飾する

もうひとつ、:link-to()という擬似クラスが提案されています。リンクの行き先が、登録しておいたルートやURLパターンに合致するかどうかで、そのリンク自体の見た目を決められるというものです。冒頭に挙げたグローバルメニューの現在地表示は、まさにこれで書ける範囲に入ります。

あわせて、遷移のきっかけになった要素そのものを指す:nav-sourceも用意されています。押されたリンクやボタンだけを起点にした演出が組めるので、カード一覧から詳細へ移る際に押したカードだけを動かす、といった表現が素直に書けるようになります。

現時点でできること

状態としてはまだ仕様の草案段階で、Chrome Canaryで実験的機能のフラグを立てれば試せる、という位置づけです。仕様の細部は議論の最中で、GitHub上で意見を募っている段階でもあります。今日の案件に持ち込むものではありません。

ただ、方向としては注目に値します。この一年ほど、JavaScriptで組み立てていた挙動がHTMLやCSSの側へ移っていく流れが続いており、この提案もその延長線上にあります。中小企業のサイトのように、メニューが数項目で、遷移の演出も凝ったものは求められない案件ほど、この手の機能は恩恵が大きいはずです。現在地の表示のためだけにスクリプトを1本読み込む、という判断をしなくて済むからです。

今のうちにできるのは、自社サイトや保守案件で現在地表示や遷移演出をどう組んでいるかを把握しておくことくらいでしょう。実装が散らばっているほど、こうした仕様が実装されたときの整理の効果は大きくなります。