「コンテナクエリ」はもうブラウザサポートも十分なのに、実際にはメディアクエリの延長線上でしか使われていない、という話をよく見かけるようになりました。
改めて調べてみると、たしかに自分自身も「画面幅の代わりにコンテナ幅を見る便利機能」くらいの理解で止まっていたな、と反省させられました。
「メディアクエリ」はビューポート、つまり画面全体の幅を基準にレイアウトを切り替える仕組みです。それに対して「コンテナクエリ」は、あるコンポーネントの親要素の幅を基準に、そのコンポーネント自身のスタイルを切り替える仕組みです。
似ているようで、実は「何に対して responsive であるべきか」という設計思想がまったく違う、というのが元記事の主張でした。
「画面幅」だけを見ていた頃の苦労
自分がまだメディアクエリだけでレイアウトを組んでいた頃、いちばん困っていたのは「同じカードコンポーネントなのに、置かれる場所によって崩れる」という問題でした。
トップページでは3カラムに並ぶカード、サイドバーでは1カラムで細長く置かれるカード。どちらも同じHTML構造・同じCSSクラスを使いたいのに、画面幅基準のメディアクエリでは「今このカードがどれくらいの幅で表示されているか」までは分かってくれません。
結局どうしていたかというと、サイドバー用に別クラスを作って上書きしたり、`.card–narrow` のような修飾クラスを増やしたりして、その場しのぎで対応していました。
CSSファイルはどんどん肥大化しますし、半年後に見返すと「このクラス、どこで使われているんだっけ」と自分でも分からなくなる。あるあるだと思います。
正直、あの頃の自分に『コンポーネント側で幅を判断できるようになるよ』と教えてあげたいです。修飾クラスの数だけ、地味に運用コストが積み上がっていたので……。
「置き場所」に依存しないコンポーネントという発想
コンテナクエリの本質は、コンポーネントが「自分がどんな幅の箱に入れられているか」を自分自身で判断できるようになる、という点にあると理解しています。
つまりページ全体のレイアウトを気にする必要がなく、コンポーネント単体で完結した「responsive」を実現できるわけです。これは地味なようで、実際のデザインシステム運用ではかなり大きな違いになります。
以前、クライアントワークでコンポーネントライブラリをFigmaとコードの両方で管理する案件がありました。デザイナー側は「このカードはどこに置いても崩れない」という前提でパーツを作りたいのに、実装側はメディアクエリの都合上、置き場所ごとに微妙に違うスタイルを当てざるを得ない。
デザインとコードの間に見えない溝があって、レビューのたびに「あれ、ここだけ余白が違いますね」というやり取りが発生していました。
