#悪魔の所業
もはや廃れたものだと思っていたのだが、マイクロソフトの技術系ページで見てしまった1ので、ムカムカを解消すべく記載する。SQL Serverのバージョン情報を見る限り、15年くらいは古いページなんだけれど。
最初の間違い：ブラウザのフォントサイズが16pxだと想定している
そもそも、<html>のfont-sizeを62.5%としている根拠は何か。それはブラウザの標準フォントサイズが16pxだからだ。10/16 = 62.5%ということ。つまり、1rem = 10pxとしたいわけだ（これ自体に問題をはらんでいるのだが、説明は後回しにする）。
しかし、ブラウザの文字サイズは変更できる。3年前のものではあるが、__3%ものユーザーがフォントサイズを変更している__というデータがある。ユーザーがブラウザのフォントサイズを1上げるだけで、設計が崩れる（2021/8/16追記: と書いたものの、この書き方を生み出した誰かさんはそのことを見越してこの設定にしていたはずだ。「2021/8/16追記 font-size: 62.5%;の真の意図」を参照）。
さらに、Webkit系ブラウザの等幅(monospace)フォントは他のフォントより3px小さく設定されている（相対的なサイズをユーザーが変更することはできない！）そしてお察しの通り、マイクロソフトは等幅フォントも16pxだと想定してCSSを組んでいるため、Chromeでは<code>要素の文字がやたら小さくなっている。読みづらいったらありゃしない！
また、4K以上の高解像度ディスプレイが普及していくにつれ、ブラウザがデフォルトフォントサイズを見直す可能性というのは否定できないだろう。16pxというなんとなく切りのいいだけの数字ではなく、20pxとか40pxのような人間的な計算がしやすい値になることも十分考えられる。大体、フルHDのディスプレイ（横幅1920px）は16pxの文字だと120em分に相当し、これは一般的に読みやすいとされる英文の文字数（50~75文字）の倍くらいある（そして、アルファベットの横幅は1emより狭いものが多い）。つまり、渡辺謙さんじゃないが世の中の文字は小さい！ 読みやすさを考えれば、現状でも1920 ÷ 60 = 32pxのフォントサイズが標準でもおかしくは無いのだ。もっとも、この話は単純な理想論で、大きい文字だからと言って読みやすいわけではないし、今までのWebとの互換性を維持するためにデフォルト文字サイズを変えることはしたがらないだろう。しかし、可能性は考えなければならない。
#根本的な間違い：ピクセルベースでのデザイン
このデザインの致命的な欠陥は、本来レスポンシブデザイン用に考えられたrem単位を、従来のピクセルベースデザインの代替として使っていることだ。
rem、つまりルートのemは、htmlファイル自身の文字サイズを基準とした単位だ。しかし、このデザイン方法では62.5%とすることで、__どこからも直接使われないフォントを設定している__ことになる。何をしたいかと言えば、今までpxでデザインしてきたホームページの単位をただ変えただけなのだ。
これは当然無駄な労力だし、rem本来の使われ方を無視しているとんでもないものだ。そして、pxベースでWebページを作っていくのも（まだ残存しているとはいえ）廃れていくべき手法である。
pxベースでWebページを作る罪はゆくゆく議論したいものであるが、今回言いたいことは<html>のfont-sizeを62.5%にするのはremをpxの代わりに使う、筋の悪い方法だよということである。
(2021/8/10)
2021/8/16追記 font-size: 62.5%;の真の意図
驚くべきことに、この筆者的には書き捨て同然の記事が、自己最高の閲覧を達成してしてしまった（2021/8/16時点で2131 views）。特にGoogle検索で乗っかるということも無かった（2021/8/16時点。2022/1/7現在では「html font-size 62.5」の3番目に載る記事に。思えば遠くに来たものだ）ので、びっくりしているとともに、この件に対しておかしいと思う同志がこれほどいるのか、と感慨がわいてくる。
しかし、エゴサもどきをしている最中に、font-size: 62.5%;と設定している意図を勘違いしていたことに気づいたので、そちらについてコメントする（結論の大きな変更は特にない）。
そもそも、ブラウザの文字サイズを変更して、表示幅を変えるのが目的だったわけだ。どういうことかというと、ブラウザ側を16pxにしたならbodyのwidthが1280pxになるように設定しているが、次のようにcssを組んで、ブラウザのフォントサイズを20pxに設定すれば自動的に20px ÷ 16px × 1280px = 1600pxで表示するようにしたい、というのがこの手のデザインをする最大の理由だった、というのが筆者の持論だ。
html {
font-size: 62.5%;
}
body {
width: 128rem;
}
そもそもfont-sizeの問題ではなかったのだ。こちらの記事を見てそのことに気づいたのだが、検索する限りfont-sizeのみの話題で「計算が楽になっていいよね」という回答しか見つからず、みんな深く考えていないなと呆れてしまった。
だがちょっと待ってほしい。そのような方法でレスポンシブを達成するのなら、最初から文字数ベースで設計すべきではないだろうか。今回の場合はfont-sizeに変更を加えなくてもwidth: 80rem /* 1280px ÷ 16px */とすればいいところを、中途半端にピクセルベース設計が残ってしまい、このような作り方になってしまった。慣れ親しんだピクセルベースデザインをレスポンシブにするため、以下の式で定義されるrpx (relative px)2とかあってもよかったんじゃないかとも思うが、今更ではある（サブピクセルでガタガタになりそうとか言うな）。
1rpx = 1px × （ユーザー設定フォントサイズ） ÷ （ブラウザのデフォルトフォントサイズ）
アルファベットは文字によって大きさがまちまちなのでこのようなピクセルベース設計に頼らざるを得ないかもしれないが、日本語の場合「P」フォントや「UI」フォントを選ばなければ文字数ベースのデザインが簡単にできる。MSゴシックは確かに恰好悪いが、今のWindowsにはメイリオや游ゴシックが同梱されているので、それらを使えば文字の見てくれはどうということはなかろう。Macのフォントの美しさは言うまでもない。Linuxは分からないが、最悪の場合Noto Sansを使えば何とかなるだろう。従って日本語ではfont-size: 62.5%;とする（≒ピクセルベースでデザインする）メリットは限りなく薄い！ 以上！
（2022/1/7 Google検索の件について追記）