正直に言います。
最初にcqwを見たとき、私は「また単位増えたのか」と思いました。
vwがあり、vhがあり、vminがあり、vmaxがあり。
そこに今度はcqw。
もういいだろう、と。
でも触ってみると分かります。
これは単なる新しい単位ではない。
レイアウト設計の思想が変わるやつです。
この記事ではCSSのcqwについて、実務目線で掘ります。
なぜ使うのか。
なぜ場合によっては止めるべきなのか。
メリットとデメリット。
そしてサンプルコード。
フロントエンドを勉強中の人も、現場で日々デザインと戦っている人も。
「分かったつもり」で終わらせない話をします。
cqwとは何か まずは定義から
cqwはContainer Query Widthの略です。
コンテナの幅に対する1パーセントを意味します。
つまり、
1cqw = コンテナ幅の1%
vwがビューポート幅基準なのに対し、
cqwは親コンテナ基準。
ここが本質です。
今まで「画面幅に応じて」調整していたものが、
「コンポーネント幅に応じて」変わる。
分かりますか、この差。
これ、設計思想が変わる瞬間です。
なぜcqwが必要になったのか
レスポンシブ設計は長らくviewport基準でした。
メディアクエリでブレイクポイントを切る。
それが正義だった。
でも今は、コンポーネント駆動の時代です。
カード、モジュール、ウィジェット。
ページ全体ではなく、部品単位で再利用する。
そのとき、こう思いませんでしたか。
「このカード、横幅が違うだけで文字サイズが崩れるな」と。
viewport基準では限界があった。
そこでcontainer query。
そしてcqwです。
基本的な使い方
まずは最低限のコードを見ましょう。
HTML
<div class="card-container">
<div class="card">
<h2>Title</h2>
<p>Container width based scaling example.</p>
</div>
</div>
CSS
.card-container {
container-type: inline-size;
width: 400px;
}
.card {
font-size: 5cqw;
padding: 5cqw;
background: #f5f5f5;
}
container-typeを指定することで、その要素がコンテナになります。
そしてその中でcqwが有効になる。
シンプルです。
でも、罠もある。
メリット 実務で感じる強さ
1 コンポーネント単位で完結する
カードをどこに置いても、
その幅に応じて自然にスケールする。
これは設計的に美しい。
依存関係が減る。
2 メディアクエリの削減
ブレイクポイント地獄から少し解放されます。
600px, 768px, 1024pxと刻む必要が減る。
3 デザインとの相性が良い
Figmaでコンポーネント設計している人なら分かるはず。
横幅に比例して文字や余白が変わる。
それをCSSで自然に再現できる。
デメリット ここを見落とすと事故る
1 container-typeの指定が必須
これを忘れるとcqwは効きません。
効いていないのに気づかず悩む。あるある。
2 レイアウト再計算コスト
container queryはブラウザ側で再計算が走ります。
複雑なネスト構造だと負荷が増える可能性もある。
3 古い環境との互換性
現代ブラウザではほぼ問題ない。
ただし企業案件で古い環境を求められる場合は注意。
ここで一度考えてみてください。
「その案件、本当にcqwが必要ですか」。
止めるべきケース
私は万能論者ではありません。
- 単純なLPで固定レイアウト
- 明確なブレイクポイント設計がある案件
- パフォーマンス最優先の環境
こういう場合、無理にcqwを使う必要はない。
使えるから使うは、設計として弱い。
実務レベルのサンプル レスポンシブカード
HTML
<section class="grid">
<div class="item">
<h3>Card 1</h3>
<p>Content text here.</p>
</div>
<div class="item">
<h3>Card 2</h3>
<p>Content text here.</p>
</div>
</section>
CSS
.grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
gap: 20px;
}
.item {
container-type: inline-size;
background: #ffffff;
padding: 4cqw;
font-size: 4cqw;
}
カード幅が変わると、自然に文字と余白が比例します。
メディアクエリを書かずに。
気持ちよくないですか。
私はこういうコードが好きです。
cqwとvwの違いを整理する
vwは画面幅基準。
cqwはコンテナ基準。
例えばサイドバー内コンポーネント。
vwだと画面に引っ張られる。
cqwならサイドバー幅に追従する。
コンポーネント設計の未来はどちらか。
考えるまでもない。
現場での設計指針
私の偏見を置きます。
- 再利用するUIにはcqw
- ページ全体制御はvw
- 極力混ぜない
混ぜすぎると、誰も理解できなくなる。
未来の自分も含めて。
関連して知っておきたいこと
- container-type: size と inline-size の違い
- cqh cqi cqb など他のcontainer units
- CSS clampとの併用
例えばこう。
.card {
font-size: clamp(14px, 3cqw, 24px);
}
これ、実務ではかなり強いです。
暴走を防ぎつつ、柔軟性を保てる。
cqwは魔法ではありません。
でも、正しく使えば設計を一段上げる武器になります。
あなたはどの案件で使いますか。
そして、どこであえて使わないと判断しますか。
