タグ: CSS

横に長い表を作るとき、見出し行や左端の項目名をどう固定するかで手が止まった経験は多いと思う。Chromeの開発者向けブログに8月20日付で公開された次期版の先行情報によると、その悩みに直接効く変更がブラウザに入る。overflowプロパティで縦と横に別々の値を組み合わせられるようになるというもので、たとえば横はスクロールさせ、縦は切り取り(clip)にする、という書き分けが指定どおりに扱われる。ひとつの軸だけがスクロールする箱、という考え方をCSSの側で素直に表せるようになる。まだ先行版の段階なので、正式版で使えるようになるのはもう少し先になる。

これまでのCSSは、片方の軸にスクロール系の値を指定すると、もう片方も実質的にスクロール可能な箱として扱っていた。clipと書いても内部的にはhiddenへ変換されるため、その中でposition: stickyを使った要素は、思っていたのとは別の箱を基準にして固定される。表の上端と左端の両方を固定したかったのに片方しか張り付かない、という現象の正体はここにあった。公開されている提案文書でも、この扱いが出発点の課題として説明されている。スクロールのたびに位置を計算しなおす回避策もあったが、電池を消費し、保守も面倒で、スクロールが非同期である以上ぴったり合わせるのは難しかったとされている。

表とカルーセルで違いが出る

提案文書が挙げている例は二つある。ひとつは、上に見出し、左に項目名を並べた表を、スマートフォンから縦にも横にも動かして読む場面。表を包む要素にoverflow: scroll clipを書いておけば、どちらのラベルも見えたまま奥まで読み進められる。もうひとつは横並びのカルーセルで、縦方向は見た目の上で隠してあっても、スクリプトからscrollIntoViewを呼んだ拍子に縦へずれてしまうことがある。hiddenは利用者が触れないだけで、スクリプトからは動かせるためだ。しかも利用者の側は手で戻せないので、ずれたままになる。clipを指定した軸は動かないと決められる、という整理になっている。

気をつけたいのは互換性で、以前はoverflow: scroll clipと書いてもscroll hiddenとして解釈されていた。古いコードにこの書き方が残っているサイトでは、見え方が変わる可能性がある。同じ先行版には、斜めに動かしたいのにブラウザが勝手に一方向へ寄せてしまうのを止めるscroll-axis-lockという指定も入っており、スクロールまわりの細かい要望が続けて拾われている印象がある。料金表や仕様一覧のように横へ広がる表は、中小企業のサイトでも珍しくない。JavaScriptで位置を合わせていた部分をそのまま減らせる場面は出てくるはずなので、正式版に降りてくる時期を見ながら、手元の表がどの箱に閉じ込められているかを一度確かめておきたい。

WebKitが公開しているSafari Technology Previewの最新版に、文字の見え方を細かく決めるCSSの追加がまとまって並んでいた。先行版のリリースノートは地味な項目の羅列になりがちだが、今回は日本語の組版に直接関わるものが混じっていて目に留まった。正式版に入る前の段階とはいえ、どこへ向かっているかは読み取れる。

ひとつはルビの張り出しを扱う ruby-overhang というプロパティだ。ルビは親文字より横に長くなることがあり、既定でははみ出した分が隣の文字に少しかぶる。指定できる値はこれまで、ブラウザの判断に任せる auto と、はみ出しを一切許さない none の二つだった。リリースノートによると、ここに spaces という値のサポートが加わり、張り出してよい相手を隣り合う空白や約物に限る、という中間的な指定ができるようになった。none は spaces の別名という扱いに変わっている。MDNのリファレンスでも、このプロパティの形式的な構文はすでに auto と spaces の二つで書かれていて、仕様側で進んでいた整理が実装に降りてきた形になる。

あわせて white-space-trim も入った。これは white-space を構成するプロパティのひとつで、要素の前後や内側に残る空白を捨てるかどうかを指定する。値は discard-before、discard-after、discard-inner を組み合わせて使う。テンプレートの改行やインデントがそのまま余白として出てしまう場面を、HTMLの書き方を詰めて回避するのではなく、CSS側で処理できるようにするものだ。MDNの white-space のページには、この構成プロパティはまだどのブラウザにも実装されていない、という注記が残っている。先行版に限った話とはいえ、実装が一つ出てきたことになる。

ほかにも、下線の位置をずらせる text-decoration-inset、箇条書きの記号そのものに content を指定できるようになった ::marker、要素の内側での折り返し方を扱う wrap-inside が並んでいる。修正の側にも、::selection に指定した text-decoration が描画されない問題や、直交する書字方向の子要素を持つブロックの幅がつぶれる問題が挙がっている。どれも派手さはないが、縦組みや細かな文字詰めを一度でも触ったことがあれば思い当たる類の話だ。

いま使うというより、頭の隅に置く段階

ここで挙げたものはSafariの先行版に入った段階で、正式版や他のブラウザで使えるかどうかはこれからの話になる。中小企業のサイトで来週から使う、という性質のものではない。ただ、ルビや余白の詰めは、これまで全角スペースの調整やJavaScriptでしのいできた領域でもある。ブラウザ側で素直に扱える方向へ仕様が動いていることを知っておくと、次に組版で困ったときに探す場所が一つ増える。リリースノートは項目ごとに短くまとまっているので、気になる分野だけ拾い読みしておくのでも十分だろう。

動画や音声を埋め込んだページで、再生が始まったら中央の大きな再生ボタンを消す、読み込み待ちの間だけ画面を少し暗くする、といった切り替えを組んだことはないでしょうか。こうした見た目の出し分けは、これまでJavaScriptで再生や停止のイベントを拾い、要素にクラスを付け外しして実現するのが定番でした。その状態の判定を、CSSの側から直接書ける指定がブラウザに入ってきています。

再生中か止まっているかを見分ける指定

Chromeの開発者向けブログが公開したChrome 152ベータ版の案内には、:playing、:paused、:seeking、:buffering、:stalled、:muted、:volume-lockedという疑似クラスが並んでいます。いずれもaudio要素とvideo要素を、そのときの状態にもとづいて選ぶためのものです。

MDNの説明によると、:playingはメディアが再生されている状態を表します。興味深いのは、いま実際に映像や音が進んでいる場合だけでなく、利用者の意思以外の理由で一時的に止まっている場合も再生中として扱う点です。つまり、回線が細くて読み込み待ちになっている最中も:playingに当てはまります。利用者が自分でボタンを押して止めたときが:paused、というすみ分けになっています。

読み込み待ちや消音といった細かい状態も拾える

:bufferingは、再生を続けたいのにデータが足りず、読み込みを待っている状態を指します。MDNには、:bufferingに当てはまる要素は:playingにも同時に当てはまる、とはっきり書かれています。待機中の表示を出しているあいだも再生中用のスタイルは効いたままになるので、両方が重なる前提で指定を組む必要があります。

:mutedは、音を出せる要素が消音されている状態です。似たものに:volume-lockedがありますが、こちらは端末やブラウザ側の設定によって、JavaScriptからは消音の切り替えも音量の変更もできない状態を指します。作り手が制御できる消音と、作り手には手が出せない音量の固定を、別々に見分けられるようになっているわけです。

書き方は素直で、MDNにはvideo:mutedに枠線を付ける例が載っています。video:not(:muted)と組み合わせれば、音が出ている状態との出し分けもできます。利用者が再生コントロールで消音を切り替えれば、その場でスタイルのほうも切り替わります。

状態の同期をスクリプトに任せなくてよくなる

この手の状態管理は、地味に事故が起きやすいところです。イベントの取りこぼし、同じ画面に複数の動画を置いたときの指定の衝突、画面を切り替えたあとに前の状態が残ってしまう、といった不具合は制作の現場ではおなじみでしょう。判定をブラウザ自身が持ってくれるなら、そもそも表示と実態がずれる余地が小さくなります。

地方の中小企業のサイトでも、会社紹介の動画や商品の紹介映像を置くことは珍しくありません。凝った独自プレーヤーを作らない場合でも、再生が始まったら重ねていた説明の見せ方を控えめにする、読み込みが長引いているときだけ待機中の表示を出す、といった調整はCSSの側だけで書けるようになります。スクリプトを増やさずに済む分、表示の軽さにも保守のしやすさにも効いてきます。

いまの対応状況と現実的な取り入れ方

ただし、すぐにどこでも使えるわけではありません。MDNの各ページには限定的な対応と表示されていて、広く使われているブラウザの一部では動かないためBaselineには達していない、と明記されています。手元のブラウザで動いたからといって、すべての来訪者に同じ見え方を届けられる段階ではない点は押さえておきたいところです。

一方でChromeの案内では、これらの疑似クラスがInterop 2026の重点分野の一つに挙げられています。Interopはブラウザごとの実装のばらつきを揃えていくための取り組みなので、そこに入っているということは、対応が広がる方向で足並みが揃いつつあると読んでよさそうです。

現実的な取り入れ方は、これまでどおりの作りを土台に置いたうえで、対応しているブラウザでは見え方がもう少し気の利いたものになる、という上乗せの形でしょう。動かないブラウザでも困らない範囲から試してみると、次にプレーヤーまわりを触るときの引き出しが一つ増えます。

サイトのグローバルメニューで「今いるページ」だけ色を変える。制作の現場では当たり前にやっている処理ですが、実装の中身はいまだに泥臭いままです。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本読み込む、という判断をしなくて済むからです。

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

CSSの使われ方を毎年たずねている調査「State of CSS」の最新の結果が公開された。回答を集めたのは今年の5月中旬から6月末にかけてで、世界の制作者4,902人が答えている。新機能の発表そのものではないが、現場で何が実際に使われていて、何がまだ様子見なのかが数字で並ぶので、自分たちの手札を確かめる材料になる。

使用率の上位は、条件に合う子要素を持つ親側を指定できる :has() が83.7%、縦横比を保つ aspect-ratio が81.3%、入れ子で書ける CSS Nesting が70.6%と続いた。少し前まで「便利そうだが対応状況が心配」と言われていた顔ぶれが、上から順に普通の道具として定着したことになる。逆に、この春から夏にかけて主要ブラウザに入ったばかりの指定は使用率が数%にとどまっており、ブラウザで使えるようになったことと、実案件で使われることの間には、やはり数年単位の距離があるとわかる。参考にしている情報源としては、MDN と Can I Use を挙げた人が多かった。新しい指定を試す前に対応状況を確かめる、という手順が広く共有されているということだろう。

気に入られている機能と、使われている機能

面白いのは、注目度と使用率が一致していない点だ。回答者が最も気に入った新機能として挙げたのは、要素を別の要素に紐づけて配置するアンカーポジショニング(anchor positioning)だった。ところが「対応状況が理由で使えていない機能」の筆頭にも、同じ名前が並ぶ。画面遷移をなめらかに見せる View Transition API や、条件分岐を書ける if() も似た位置にいる。触ってみたい気持ちと、納品するサイトに入れられるかどうかの線引きが、はっきり分かれている様子がうかがえる。

つまずきどころとして多く挙がったのは配置まわりで、次いで :has()、コンテナの幅で見た目を出し分ける @container が並んだ。どれも、うまくはまれば記述量がぐっと減る反面、思ったように効かないときの原因追いに時間を取られやすい種類の機能だ。それでも全体の満足度は5段階でおよそ4と、ここ数年ほぼ横ばいのままだった。書きやすくなった実感と、細かいところでの引っかかりが同居している、という受け止め方が続いていることになる。

中小企業のサイトを預かる立場からすると、この手の調査は流行を追うためというより、線引きの目安として使いやすい。使用率が高く枯れた機能は迷わず採用し、話題の新しい指定は、効かなかったときの見え方まで用意できる範囲で試す。企業サイトは公開してから何年も動き続けるものが多く、閲覧環境の幅も広い。上位に並ぶような定着した機能であれば、古い端末が混ざる相手でも心配は少ない。数字を眺めながらそのあたりの分け方を決め直すだけでも、調査に目を通す価値はある。詳しい内訳は調査結果のページで公開されている。

グリッドやフレックスで要素を並べたあと、そのすき間に細い線を入れたくなる場面は多い。カード一覧の区切り、料金表の縦線、記事リストの横罫。デザインとしてはごく普通の表現なのに、CSSで素直に書ける指定がなく、制作側が毎回それらしい形に組み立ててきた領域だった。ここへ来て、その部分がブラウザ側で片付きはじめている。

すき間に線を引くために、これまでやってきたこと

いちばん多かったのは、並べた要素そのものに枠線を付ける方法だろう。カードの右側にだけ線を引き、行末の要素は擬似クラスで線を消す。三列で組んだグリッドなら、三の倍数番目を狙って消していく。動くには動くが、列数がブレークポイントごとに変わると、消す対象も一緒に書き換えなければならない。

フレックスで折り返す並びだと事情はもっと厄介になる。何番目で折り返すかは中身の幅次第なので、要素の番号を狙う書き方が成り立たない。仕方なく擬似要素を絶対配置で置いたり、親に背景色を敷いてすき間だけ透かして線に見せたり、要素の背景色との差で線を演出したりしてきた。どれも見た目は作れるが、線の色を変えたいだけの依頼で三箇所直すことになる。

背景色を敷いて線に見せる手も、条件がそろえば見た目はきれいに決まる。ただし親の背景が写真やグラデーションだと途端に成立しないし、余白の値を変えると線の太さまで一緒に動く。ダークモードの切り替えを入れると、線の色ではなく背景色を二重に管理することになり、あとから読む人には何が線で何が下地なのか分かりにくい。

要するに、線を引くための仕掛けが、線とは関係のない場所に散らばっていた。すき間そのものを指定できる手段がなかったからで、これは書き手の工夫が足りないという話ではなかった。

もともと段組みだけのものだった指定が広がった

CSSには以前から column-rule という指定がある。ただしこれは段組みレイアウト専用で、グリッドやフレックスでは効かなかった。線を引く指定は存在するのに、いちばん使いたいレイアウトでは使えない状態が続いていたわけだ。

今回入ったのは、この column-rule をグリッドとフレックスにも広げ、さらに横方向のすき間に線を引く row-rule を新しく用意する、という変更になる。Chromeの開発者向けブログによると、ChromeとEdgeのバージョン149から既定で有効になった。段組み、グリッド、フレックスのいずれでも同じ書き方が通る。

書き味としては枠線の指定とほとんど同じで、太さと線種と色をまとめて渡すだけでいい。要素の何番目かを数える必要はなく、折り返しが増えても減っても、すき間があるところに線が入る。列数をブレークポイントで切り替えても、線の指定はそのままでいい。この一点だけでも、日々のCSSの見通しはかなり変わる。

交差やはみ出しをどこまで決められるか

実際にやってみると気になるのが、細部の扱いだ。縦線と横線が交わるところをどうするか、線をすき間いっぱいまで伸ばすのか少し余らせるのか、中身の入っていない列にまで線を出してしまわないか。この手の判断は、これまで擬似要素の位置調整でごまかしてきた部分でもある。

新しい仕様では、そこにもそれぞれ指定が用意されている。交差点の処理は column-rule-break と row-rule-break、線をどこまで伸ばすかは column-rule-inset と row-rule-inset、空の行や列に線を出すかどうかは column-rule-visibility-items と row-rule-visibility-items が受け持つ。開発者向けの試用段階では伸縮の指定が別の名前だったが、仕様の側に合わせて整理された経緯がある。

加えて、線の太さや色、伸縮の量はアニメーションの対象になる。マウスを載せたときにだけ区切り線をうっすら出す、といった演出が、余計な要素を足さずに書けるということでもある。細かい話に見えるが、ここまで決められるかどうかで、回避策から本当に卒業できるかが分かれる。

使えるブラウザと、いまの構え方

現時点で対応しているのはChromiumを土台にしたブラウザで、SafariとFirefoxはまだ入っていない。ここは正直に見ておいたほうがいい。日本の中小企業サイトだとiOSのSafariの比率が高い案件も珍しくないので、いますぐ全面的に頼れる指定ではない。

ただ、この機能は使えなかったときの壊れ方が穏やかだ。対応していないブラウザでは、すき間に線が出ないだけで、レイアウトそのものは何も崩れない。区切り線が装飾として効いている程度の場面なら、対応済みのブラウザで少し丁寧に見える、という積み増しの使い方ができる。線がないと情報の区切りが読み取れない、という設計になっている場合だけ、従来の手法を残しておけばいい。

従来の手法を残す場合も、両方を無条件に書くと対応済みのブラウザで線が二重になる。対応しているかどうかで書き分ける @supports を挟んでおくと、この衝突は避けられる。新しい指定が使える環境では新しい書き方を、そうでない環境では今までの回避策を、という形にしておけば、数年後にSafariとFirefoxが追いついた時点で、古いほうのかたまりを削るだけで済む。移行の作業を先に用意しておく、という考え方に近い。

未対応のブラウザ向けのポリフィルも開発が進んでいるとされている。ただ、装飾のためにスクリプトを足すのは本末転倒になりやすいので、まずは飾りとして入れて様子を見る、という順番が現実的だと思う。

見た目の細部がCSS側に寄っていく流れ

この変更を単体で見ると、便利なプロパティが増えた、という話で終わる。ただ、ここ一年ほどのCSSの動きを並べると、同じ方向を向いた変更が続いていることに気づく。

たとえば、並んだ要素に少しずつ時間差を付けて動かす書き方は、長らく要素の番号を手で書き並べるか、スクリプト側で遅延を計算するしかなかった。それが、自分が何番目の兄弟かをCSSの中で数えられる関数として一部のブラウザに入りはじめている。枠線の形をもっと自由に扱うための border-shape のような提案も議論が進んでいて、CSS-Tricksあたりでは繰り返し取り上げられている。

共通しているのは、見た目のために増やしていたマークアップやスクリプトを減らす方向だということだ。区切り線のための空の div、時間差のための番号付きクラス、位置合わせのための擬似要素。こうしたものは、書いた本人以外には意図が読み取りにくく、引き継いだ制作者が触りにくい部分でもあった。指定として名前が付くと、少なくとも何をしたかったのかは残る。

受け継いだサイトを触る側から見ると

制作会社としてありがたいのは、新規で作るときの快適さより、あとから触るときの読みやすさのほうかもしれない。他社が作ったサイトを引き継いで直す仕事では、擬似要素で引かれた線の位置が微妙にずれている、といった相談がわりとよくある。中身を追うと、当時の列数を前提にした番号指定が残っていて、その後の改修で列数だけが変わっていた、という筋書きだ。

すき間に線を引く指定が一行で済むなら、こうした置き土産は減っていく。すぐに全部を書き換える必要はないし、動いているものを触るリスクのほうが大きい場面も多い。ただ、次にそのブロックへ手を入れるとき、回避策を継ぎ足すのではなく、素直な指定に置き換えられる選択肢ができたのは小さくない。

新しい指定が出るたびに全部追いかける必要はないと思う。それでも、長く回避策で埋めてきた場所が正面から解決されたときは、覚えておくと後で効いてくる。区切り線はまさにその手の場所だった。

Safariの次の版のベータが公開され、58件の新機能と525件の修正が入るとされています。WebKitの発表を読むと、目新しい機能を数多く並べるというより、既存の機能の細かい挙動を揃える作業に重心が置かれているのが分かります。

とはいえ、制作の現場ですぐ効きそうな追加もいくつか含まれています。中小企業のサイトでも出番がありそうなものを、順に並べてみます。

セレクト要素の見た目を組み直せるようになる

フォームのセレクトボックスは、ブラウザごとに見た目が違ううえ、選択肢の並びに手を入れられない部分が長く残っていました。デザインに合わせたい場合、select要素を捨ててdivとJavaScriptで作り直すのが定番の回避策です。

今回のベータではappearance: base-selectに対応し、本来の要素のまま見た目だけを組み直せるようになります。キーボード操作や読み上げ、フォーム送信の挙動は標準のまま残るので、作り直したときに抜けがちな部分を自前で用意しなくて済みます。問い合わせフォームのように、崩れると直接損をする箇所ほど恩恵が大きいところです。

遅れて読み込まれた要素で読む位置がずれない

記事を読んでいる途中で、画面の上のほうにある画像や埋め込みが遅れて表示され、本文が下に押し出される。よくある不快な挙動です。スクロールアンカリングは、こうしたときに表示位置を自動で補正して、読んでいた行を保ちます。

他のブラウザではすでに動いていた機能なので、Safariが加わることで挙動の差が縮みます。ただし、画像に幅と高さを書いておくといった基本の対策が不要になるわけではありません。ブラウザ側の補正はあくまで最後の受け皿と考えておくのが安全です。

見出しをまとめて指定できる疑似クラス

:headingは、h1からh6までをまとめて指す疑似クラスです。これまではセレクタに六つ並べて書くのが普通で、余白や行間を揃えたいだけの場面では冗長でした。

書く量が減るだけの小さな追加に見えますが、見出しの階層が増えたり減ったりする構成では、書き漏らしを防ぐ意味もあります。ブログのように書き手が複数いるサイトでは、想定していなかった深さの見出しが入ることも珍しくありません。

余白まで含めて幅を伸ばすstretchという値

幅や高さの指定にstretchという値が使えるようになります。親の中で余白の分まで含めて伸ばす指定で、これまでcalcを使って余白を引いて調整していた場面を素直に書けます。

あわせてrevert-ruleというキーワードも入りました。そのルールが当たる前の状態まで戻す指定で、後から足したCSSが積み重なって入り組んだサイトの調整に向きます。どちらも派手さはありませんが、既存サイトに手を入れる仕事では出番がありそうです。

画像のsizes属性をブラウザに計算させる

遅延読み込みを指定した画像で、sizes属性にautoと書けるようになります。実際のレイアウト幅をブラウザが測り、srcsetに並べた候補から適したものを選びます。

これまでは画面幅ごとの表示幅を自分で書き並べる必要があり、レイアウトを変えるたびに書き直す手間がありました。書いた値が実際のレイアウトと食い違うと、必要以上に大きい画像を読み込んでしまいます。手作業の当て推量が減るのは、表示速度の面でも助かります。

同じ時期に出たChromeの新しい安定版には、矢印キーでの項目移動を属性の指定だけで有効にできるfocusgroupが入っています。片方は新しい書き方を先に出し、片方は既存の機能の足並みを揃える。方向は違いますが、どちらも自前のスクリプトで埋めていた部分を標準側に寄せる動きです。実務では、対応が片方だけの機能はしばらく補助的に添える程度にとどめ、両方に入ったものから本番へ回すのが無難だと思います。

日本語のページを組んでいると、ふりがな、つまりルビの扱いで地味に手を取られることがある。難読の地名や人名に読みを添えたい、子ども向けや自治体のページで漢字に読みを振りたい、といった要望は今も普通に出てくる。HTMLにはもともと ruby 要素があり、<ruby>石動<rt>いするぎ</rt></ruby> のように書けば親字の上に読みが乗る。ところが実際に組んでみると、読みのほうが親字より長いときの見え方がブラウザまかせになりがちで、そこを細かく指定する手段が長らく足りていなかった。Chromeのベータ版に入った新しいCSSプロパティは、その足りなかった部分をひとつ埋めるものになっている。

ルビは日本語サイトの地味な難所

ルビの厄介さは、親字と読みの長さが一致しないところにある。二文字の漢字に四文字の読みを振れば、読みの側が横にあふれる。ブラウザはこのあふれた分を隣の文字の上に少しはみ出させて表示することが多い。行がむやみに間延びしないので、組版としてはむしろ自然な処理だ。

問題は、そのはみ出しが常に望ましいとは限らないことだった。隣にリンクや強調が続いていると読みが重なって見えづらくなる。狭いカラムや表のセルの中では、はみ出しのせいで折り返し位置が予想と変わる。逆にはみ出しを一切許さないと、親字と読みの幅を揃えるために文字間が広がり、本文の中でその部分だけ間延びして見える。どちらを選ぶかは文脈次第で、これまではCSSからその判断を伝える標準的な手段がなかった。制作側は文字サイズを下げる、ルビを画像にする、そもそもルビをあきらめるといった回り道をしてきた。

はみ出しの許し方を選べるruby-overhang

Chrome 151のベータで加わったのが ruby-overhang というプロパティで、ルビが隣にはみ出すことを許すかどうかを書き手が指定できる。初期値は auto で、これは従来どおりブラウザの判断ではみ出しを許す振る舞いにあたる。隣にも別のルビが並んでいる場合など、重なると読めなくなる状況では自動的にはみ出さない、といった配慮も仕様に含まれている。

もうひとつの値が spaces で、はみ出してよい相手を空白と約物、つまり句読点やかっこの類に限る。隣が普通の文字なら、はみ出さずにその手前で止まる。Chromeの説明によれば none は spaces の別名として扱われ、はみ出しを完全に禁じた結果として不自然な隙間ができるのを避ける形になっている。この none の解釈は資料によって記述が揃っていない段階なので、実際の見え方は手元で確かめておきたいところだ。

書き方そのものは短い。読みが隣の文字に重なると困る箇所に ruby-overhang: spaces; を当てるだけで、あとはブラウザが処理してくれる。JavaScriptで文字幅を測って調整する、といった作業はいらない。

位置や揃え方を決める指定との組み合わせ

ルビまわりのCSSは、これが最初というわけではない。読みを親字の上に置くか下に置くかを決める ruby-position、親字に対して読みをどう割り付けるかを決める ruby-align は以前から使える。縦書きで読みを右側に出したい、読みを親字の幅いっぱいに散らしたい、といった調整はこれらが受け持つ。

今回の指定は、そこに「隣との境界をどう扱うか」という軸を足すものだと考えるとわかりやすい。位置と揃え方を決めたうえで、あふれた分を外に出してよいかどうかを別に決められる。組み合わせると、たとえば見出しの中のルビははみ出しを許して行の高さを保ち、本文の狭い箇所でははみ出しを止める、といった使い分けができる。

現時点で試すときの構え

ruby-overhang は主要ブラウザすべてに揃った状態ではなく、Baselineの対象にもなっていない。Chromeでもまだ安定版ではなくベータの段階にある。今すぐ本番の見た目を左右する前提で組むものではない、というのが正直なところだ。

とはいえ、対応していないブラウザではこの指定が無視されるだけで、ルビ自体は従来どおり表示される。壊れるのではなく、これまでの見え方に戻るだけなので、段階的に足していける類の機能になる。ルビを多用しているページがあるなら、対応済みのブラウザで spaces を当てたときにどう変わるかを一度見ておくと、将来の判断が早くなる。

中小企業のサイトでルビが主役になる場面は多くないが、社名や商品名の読み、地域名、業界特有の用語など、読みを添えたい単語は意外とある。読みを振ると崩れるから避ける、という選択をしてきた現場ほど、こうした指定が揃ってきたことの意味は大きい。日本語の組版に関わる指定がウェブ標準の側で少しずつ整っていくのは、地味だが歓迎したい流れだ。