コンテンツのカラム幅は半角英数で45から75文字という説がある。それをem単位に直すとおおよそ25emから35emと考えられるが、実際にはフォントの横幅に依存する。一方CSSにはch単位というフォントの横幅によって変化する単位がある。ということはこの単位を幅や横方向の余白に利用すると、使用されるフォントに応じてカラム幅が適切に変化するはずだ……が、そうは問屋が卸さなかった。
利用はそれほど難しくない。ch単位は半角数字の0の横幅で決定されることさえ頭に入れておけばそれでよい。45から75文字を直すならそのまま45chから75chになるわけだ。一部でどうしても(r)em単位と組み合わせたい場合も出てくるだろうが、その場合はcalc()関数を使える。これでぱっと見はうまくいく。
しかしながらウェブフォントとの相性が非常に悪い。ウェブフォントの読み込み中と読み込み完了後でch単位の基準が変わってしまうので、リレイアウトされてしまう。少し複雑なレイアウトをしていると致命的な結果に終わるだろう。これだけならウェブフォントを使わない場合には役に立ちそうな気がするが、もうひとつメディア・クエリーにおける問題がある。
大雑把にそこそこ広い画面ならコンテンツ幅を60chに制限したいとしよう。CSSではメディア・クエリーを使って以下のように書くことが多いだろう。
@media (min-width: 720px) {
main {
max-width: 75ch;
}
}Chrome 54ではArialの場合は667.375px相当となり収まるが、Verdanaの場合は762.891pxとなり収まらない。日本語フォントではＭＳ Ｐゴシックだと600px相当でかなり余裕があるが、メイリオの場合は745.313pxとなり同じく収まらない。
これはかなり恣意的な例だが、大きなサイズをch単位で表現しようとすると必ず突き当たる壁と考えられる。「これくらいならこれくらいになる」という予測が難しくなるからだ。
では、とメディア・クエリーでもch単位を使って統一すればうまくいきそうだが、そうはいかない。メディア・クエリーでの計算は初期状態で行われるので、フォント指定は反映されずもっと予測が難しい(プラットフォームに依存する)ものになってしまう。
どういうフォントが使われるかを想定せずに行当たりの文字数をほぼ確定できるch単位の利用は、方向性は良かった。ウェブフォントの読み込みが失敗しても、ユーザー・スタイルシートで想定外のフォントへ変えられていても、そもそもフォントを指定しておらずどのようなフォントで表示されるかわからない場合でも、うまく機能する。
しかし実装に大きな壁があり、カラム幅のような箇所で使うのは無理があるようだ。今まで通りいくつかの特徴的なフォント(狭いMS UI Gothicや広いメイリオなど)を考慮に入れて行当たりの文字数のバランスをとる手法でいくしかないようだ。