ResizeObserverで書いていた切り替えをコンテナクエリに置き換え、差分の大半が削除行になる。そんな整理を気持ちよく終えた経験のある制作者は多いと思います。Smashing Magazineに11月3日付で載った記事は、その「消した行の多さ」と「サイト全体の分かりやすさ」は別物だと指摘しています。筆者は新しいCSSの機能そのものを否定しているわけではなく、既存のCSSやJavaScriptとの関わりを確かめないまま入れると、ひとつのファイルは短くなっても全体の挙動を追いにくくなる、という立場です。

記事が挙げる落とし穴は四つあります。一つ目は、同じ振る舞いに持ち主が二人いる状態です。コンテナクエリを足したのに、別ファイルのResizeObserverと古いクラス指定が残り、ブレークポイントを片方だけ変えた結果、誰も書いていない中途半端な見た目が生まれる例が紹介されています。二つ目は container-type: inline-size の副作用です。この指定は新しいブロック整形文脈を作るため、マージンの相殺が止まり、回り込みの扱いも変わります。さらに、中身から幅を決めていたフレックスアイテムなどは、幅が0pxにつぶれて見えなくなることがあるそうです。

三つ目は詳細度です。.card:has(img) p のような短いセレクターは、コメント欄のアバター画像にも反応し、詳細度でもコメント側の指定に勝ってしまいます。筆者は子結合子 > で範囲を絞る方法や、:where() で重みをなくす方法を勧めています。カスケードレイヤーについても、新しい指定だけをレイヤーに入れると、レイヤー外の古い指定が常に勝つ点に注意が要るとしています。四つ目は表示速度で、5,000行の一覧で試したところ、単独では軽い二つの :has() の規則が同じスタイルシートにそろったときだけ、一行の切り替えで5,001要素が再計算されたという計測が示されています。これはChromeの一環境での結果で、筆者も数字より傾向を見てほしいと書いています。そのうえで、移す前と後でChromeの開発者ツールのパフォーマンスパネルを記録し、スタイルの再計算やレイアウトにかかる時間を、本番に近い量のデータで比べることを勧めています。

移行の前に確かめたいこと

記事の終わりには、振る舞いの持ち主、影響範囲、カスケード、古い実装の削除、性能の計測、次の担当者への分かりやすさの六つを、プルリクエストの説明に書いておくという確認項目が並んでいます。新機能の紹介記事の多くはまっさらな状態を前提に書かれているが、実際に世に出す仕事の多くは移行だ、という筆者の言葉には頷かされます。新規の案件より既存サイトの改修が多い制作会社にとって、この視点は身近です。テーマやプラグインのCSSが何層にも重なったWordPressサイトでは、新しい機能を一か所に足しただけで、別のページの余白や幅が変わることは珍しくありません。置き換えたあとは部品単体ではなく、その部品が実際に置かれているページをひと通り開いて確かめる。地味ですが、それがいちばん確実な後始末になりそうです。