Web サイトの CSS フォント指定について考える
Web サイトにおけるベストな CSS フォント指定について毎年のように考察記事が書かれる。今年はこれ！という感じで。それらは確かによく調査されており考察も面白いのだけど、そろそろ決定版がほしいものだ。というわけで私なりに考察してみる。
前提
先に結論。
/* 未指定 */なにも指定しなければ Web ブラウザーがプラットフォーム毎の環境依存を考慮したフォントを選ぶ。ユーザーが明示的に設定していた場合はそれが維持される。安全なのは当然として、外観についてもプラットフォームの文字描画エンジンや標準フォントの進歩にあわせて自動的に改善されてゆくだろう。
以降はこれを念頭に CSS フォント指定の考察記事 (以下、考察記事) で言及されがちな font-family と font-size を代表として、指定の意義やリスクについて考える。
font-family
font-family の指定方法を安全な順に並べる。
sans-serifやmono-spaceのような generic-familyfont-faceに指定された Web フォント- ユーザーのローカル環境にインストールされたフォント
1 は具体的なフォント名ではなく大まかな種別の指定。種別へ対応したものが Web ブラウザーのフォント設定から選ばれる。この設定はユーザー指定も含む。
2 は自前、または Google Fonts や FONTPLUS のようなサービスにより提供されたものを明示的に指定。ダウンロードが発生するため通信コストや失敗のリスクがあるものの、成功すれば確実に目的のフォントが選ばれる。失敗したとしてもフォールバックなし、または generic-family を指定しておけば安全だろう。
問題は 3。考察記事でも散見されるものだ。例えば以下のように指定 (現時点の Cookpad から引用) される。
body {
font-family: -apple-system, "Roboto", "Helvetica Neue", "Droid Sans", "ヒラギノ角ゴ ProN", "Hiragino Kaku Gothic ProN", "Meiryo", "メイリオ", "Osaka", "MS PGothic", arial, sans-serif;
}なぜこれが好ましくないのか。それはユーザーのローカル環境を網羅しきれないため。考察記事ではこの問題を承知のうえで
- 主要プラットフォームに標準インストールされているであろうフォントを候補にする
- より注意深いものとしてはプラットフォームのバージョン差による標準フォントの変遷も考慮する
- これらと
font-familyのフォールバックを利用した順序指定で安全性を高める
のように安全性と外観の両立を狙う。よく調べるものだと感心する。しかし font-family は環境を分岐する機能がないためフォールバックによるハックに頼らざるを得ない。いちおう例にもある -apple-system は環境指定と言えなくもないが、あくまでフォールバックである。分岐ではない。
フォールバックは曲者だ。指定されたフォントが見つかれば検索はそこで止まってしまう。つまり想定外のフォントが選ばれる可能性もある。自由度の高いデスクトップ OS だとユーザーが任意のフォントをインストール可能なので、この問題に遭遇する確率は高まる。
例えば Mac OS X から標準採用されて人気を博したヒラギノ。これを Windows 上で表示すると文字描画エンジンの違いにより、かすれてしまい読みにくかった。最近は高 DPI ディスプレイ上のスケーリング表示により綺麗になったという話も聞くが、どちらにせよ font-family を指定したなら列挙したもの全てが適用されることを想定すべきである。
これは茨の道だ。プラットフォームのバージョン更新に伴ってインストールされるフォントも変更される可能性がある。これを継続的に検証してゆくは運用コスト面で見合わない。ならばいっそ指定をやめてしまうのはどうか？そうすれば楽になれる。
どうしても明示的に指定したいなら Web フォントを選ぼう。検証環境の組み合わせもフォントの分は単一になるため、運用コストはずっと下がる。ダウンロード失敗時の指定については前述のとおり。
本サイトでは Web フォントを 2 種類、採用している。1 つは UI 用に IcoMoon で生成したもの。2 つ目は以下の記事で紹介されている約猫。
これは技術書典 8 で頒布予定だった「Vivliostyleで本を作ろう Vol.3」に採用されたことで知った。約物に限定してアキを調整してくれるスグレモノ。
本文全体については Web ブラウザー標準またはユーザー指定を優先させたいので、あえて未指定としている。私なりに好みのフォントはいくつかあるけれど、各種プラットフォームでの文字描画を検証してまで採用する強い理由はない。
font-size
font-size については rem、em、% といった相対値を利用できる Web ブラウザーが一般的となったためだろうか、理想値の考察記事を見る機会が減った。しかし現在も font-size へ相対値ではなく px などで絶対値を指定したサイトが散見される。
絶対値の問題について。
例えば font-size: 10px が指定されたとする。これはスマートフォンやタブレット端末上なら小く感じても読めるだろう。しかしデスクトップ PC のディスプレイ上では相当に厳しいはず。参考として以下のサイトによる集計だと 2020/3 時点のデスクトップ PC では FWXGA (1366x768) と Full HD (1920x1080) が大半を占めるようだ。
Dot by Dot 表示するとして FWXGA ならまだしも、Full HD だと 10px の文字はゴマ粒のように見えるのではないか。私が職場で利用している Apple Cinema Display 27inch の WQHD (2560×1440) だと 14px でも読みにくい。両目視力 1.2 の私でもこうなので視覚に問題を抱えているユーザーなら一層、厳しいだろう。
では 16px、18px のように大きくしてゆくのはどうか？現時点の note.com は本文に 18px を採用しており読みやすく感じる。しかし問題の本質は大きさではなくユーザー設定を無視することだ。
前述の職場環境では Web ブラウザーの文字サイズを 20px にしている。note.com の 18px を読みやすい例として取り上げたが、それは 14px などと比べた場合の話。大き目なサイズではあるけれど、それでも私の指定を無視している。
これを rem、em、% にすれば Web ブラウザーの文字サイズが基準となる。特に rem は HTML 全体の em を基準とするため、暗黙的なサイズ継承による問題も避けられて更に安全だ。
ここまでを踏まえると font-size は
- 文章の本文は未指定、または
1rem以上 - 見出しなど本文より目立たせたいものなら
1rem以上
とするのが適切だろう。本サイトではそのようにしている。
ページ幅
オマケ。フォント指定ではないがサイトのレイアウト考察でたまに見かけるページ幅について。
文章主体の Web サイトにおいて本文の幅を制限するのは定番である。幅が広いと 1 行の文字数が増えすぎて可読性を損なう。「幅 = 行の長さ」なので、これを制限することで読みやすくなる。紙の書籍でいう段組みのようなものだ。この幅について
1024pxなど絶対値にする80%などの相対値にする
といった派閥がある。私はこれまで px 派だった。font-size とは逆で相対値だと横組み 1 行を調整しにくい。Web ブラウザーの表示幅から受ける影響が大きすぎる。例えば 80% を指定した場合、表示幅 1024px と 1600px では 1 行の長さがまったく異なる。
そのため px で広さを制限した。ページ幅が狭まったとしても max-width と min-width、これらを前提にした Media Queries による対応が可能なため px で実用十分である。
しかしこれでは本記事で問題としてきたものと一緒ではないか。という感じでずっとモヤモヤしていたのだが、業務で印刷・出版系の人たちに関わる機会が増えたので再考することにした。紙の本には 1 行の長さについて定石があるのではなかろうか？
ということで紙の組版に詳しい人へ聞いてみた。すると文字のポイント数にもよるが、文章主体なら概ね 20 〜 35 文字ぐらいとのことだった。人によって下限と上限に多少の振れはあるものの、だいたい近似値である。そこで width を em 単位へ移行してみた。
実際に試すと確かに 35em は読みやすい。ただし私のブログだとプログラミングの話題でソース コードを掲載することが多いく、これは 80 文字を一つの基準とする。そのためもう少し長い 45em を採用。ソース コード表示には足らないが、文中へ引用される局所的なものならインデントも減るだろうよいと判断した。
- 2020/9/7 追記
em は親要素に影響されるため好ましくなく他の文字サイズ単位は rem 統一しているので 45em から 45rem に変更した。この記事を読み em でもよいと認識されるのを避けるため補足しておく。
まとめ
font-family と font-size を安全に運用するのは難しく、特に Web という対象環境の極めて広いプラットフォームでは工夫しても徒労に終わる可能性が高い。よって基本は未指定とし、必要に応じて限定的に利用するのが安全で楽。
今後も理想的な CSS フォント指定は提案され続けるだろう。しかし本記事で取り上げた問題を解消していないなら避けるほうが安全だし、私はそうする。