グリッドやフレックスで要素を並べたあと、そのすき間に細い線を入れたくなる場面は多い。カード一覧の区切り、料金表の縦線、記事リストの横罫。デザインとしてはごく普通の表現なのに、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、時間差のための番号付きクラス、位置合わせのための擬似要素。こうしたものは、書いた本人以外には意図が読み取りにくく、引き継いだ制作者が触りにくい部分でもあった。指定として名前が付くと、少なくとも何をしたかったのかは残る。

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

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

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

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