Web・UI・CSS
16pxは何rem？基準の文字サイズでどう変わる？
使うツール
デザインには24pxと書かれているのに、コードでは1.5rem。どちらかが間違いというわけではありません。基準が16pxなら同じ大きさを表します。ただし、その基準が20pxなら1.5remは30pxです。単位変換は文字列の末尾を書き換える作業ではなく、何を基準に長さが決まるかを整理する作業です。基準を一つずつ変えながら、数値の意味を確かめてみましょう。
24pxをremへ直す前に、基準を確認する
CSS単位計算で入力24、変換元px、変換先rem、基準フォント16pxにすると1.5remです。計算は24÷16です。今度は基準だけ20pxへ変えると1.2remになります。元の24pxを維持するなら必要なrem値が変わる、という実験です。逆に1.5remという指定を維持して基準を20pxへ変えれば、表示される長さの方が30pxへ変わります。何を固定したいかを先に決めます。
24px / 16px = 1.5rem
24px / 20px = 1.2rem
1.5rem × 20px = 30px16pxはこの計算例の基準であり、すべての利用者やサイトで必ずそうなるという保証ではありません。実ページのルート要素の計算済みfont-sizeを確認し、ブラウザー設定やCSSの指定も考慮します。デザイン値をすべて16で割る前に、そのページがどの基準を採用しているかを確かめるだけで、全体が少し大きい・小さい原因を見つけられることがあります。
emは、どの要素の文字サイズかが重要
emはremと違い、要素の文字サイズとの関係で決まります。特にfont-size自体へemを指定すると親の文字サイズが基準になるため、入れ子で倍率が積み重なることがあります。16pxの親に1.2em、その子にもfont-size:1.2emを指定する例では、19.2px、23.04pxと大きくなります。remへ変えれば必ず正しいという話ではなく、部品の中で比例させたいのか、ルートへ統一したいのかを選びます。
現在の通常画面ではemの基準にルートの設定値を使います。実ページの異なる親・要素フォントを自動で読み取るわけではないので、入れ子のemを診断する際にはこの制限を意識してください。ブラウザーの開発者ツールで実際の計算済み値を確認し、倍率の計算を別に整理します。変換結果の前提表示を見ずに、すべてのemが同じpxになると解釈しないようにします。
10vwは、画面が変わるとどれだけ動くか
10をvwからpxへ変換し、viewport幅を1440pxにすると144pxです。幅を375pxへ変えると37.5pxになります。横幅に比例するので、同じ値がスマートフォンで小さくなることを確認できます。一方、10vhは高さが900pxなら90pxです。横方向の大きさへvhを使っても基準は高さのままなので、どの寸法に比例させたいかを区別します。
この計算のviewportは入力した寸法です。実際の端末ではブラウザーのUI、スクロールバー、ズームなども確認が必要で、ここへ端末の物理解像度を入れれば実画面を完全再現できるわけではありません。特にモバイルで高さを決める設計では、画面上部のUIが出入りする状態も実機で試します。このツールの対応単位はpx、rem、em、vw、vhで、svh・dvhなどを自動で同じ単位へ読み替えません。
換算が正しくても、レイアウトが収まるとは限らない
カード幅をremへ直しただけでは、カード間のgap、内側のpadding、境界線、サイドバーの幅は消えません。画面幅いっぱいを三等分してからgapを足すと、全体がはみ出すこともあります。CSS単位計算で寸法の基準をそろえた後、Flexbox・Grid生成で並べ方を試し、実際の親要素の幅に収まるかを確認します。viewport幅と、カードを置く領域の幅も同じとは限りません。
文字のサイズだけを流動的にした結果、狭い画面で本文が小さくなりすぎる場合もあります。数値として変換できることと、読みやすい指定であることは別です。最小・最大の考え方を設計側で整理し、本文を無理に一行へ押し込まず折り返せるようにします。この変換ツールはCSSのレスポンシブ設計全体を生成する機能ではなく、指定条件で長さを確認する道具です。
数値と一緒に、基準も渡す
『24pxは1.5rem』というメモには、『ルート16pxのとき』を添えます。vwならviewport幅、emなら参照した文字サイズも必要です。別の担当者が同じ数値を入力したとき、同じ前提へ戻れるようにするためです。結果に出る前提条件を確認し、単位の後ろに隠れている基準を見える形で共有します。
実装後は既定サイズだけでなく、利用者が文字を大きくした状態も試します。計算が正しくても、固定高さのボタンから文字がはみ出すことはあります。長い翻訳、二行の見出し、拡大した本文で、周囲の余白や操作領域がどう変わるかを見るところまでが、変換結果を実用へつなげる確認です。小さく見える理由を探すときは、値だけでなく基準から見直してください。
viewportの幅と、カードの幅は同じではない
画面幅1440pxで10vwは144pxですが、左右の余白やサイドバーを引いたカード領域が1440pxあるとは限りません。vwは親要素の10%ではなくviewportを基準にします。カード内のラベル幅を10vwにしたら、別の画面構成で大きすぎたり小さすぎたりするのは、換算ミスではなく参照している基準の違いかもしれません。割合の%も、使うプロパティによって参照先が変わるので、vwから%へ数字だけ置き換えて同じ動作とは考えないようにします。
remを使う場合も、ブラウザーで実際に適用されているルートの文字サイズを見ます。標準の16pxを前提に換算した24px＝1.5remは、ルートが20pxなら30pxになります。これは変換が壊れたのではなく、利用者やサイトの設定に応じて伸びる指定です。デザインの元数値を移す作業では、換算時の基準を記録し、実画面で文字拡大時にボタンや入力欄が切れないかを確認します。固定高さへ文字だけを拡大すると、正しい換算でも内容を隠す原因になります。
Mobileでは、表示中のブラウザーUIや仮想キーボードによって見えている領域も変わります。この単位計算は、入力したviewport寸法から数値を求めるもので、その端末のレイアウトを再現するブラウザーエミュレーターではありません。対応範囲にない動的viewport単位の挙動まで、vhの一つの結果から推測しないようにします。換算表で候補を作った後、実際の狭い画面と拡大表示で確認するという順序なら、数式で分かる部分と実画面で確かめる部分を分けられます。