利用しているフォントの「0」のグリフ幅によって変わるch単位は、実装されて久しい。これを、font-sizeプロパティーでcalc()clamp()など計算するCSS関数を通して使うと、Chrome 88やEdge 88で想定より大きくなってしまうバグがあるようだ。Firefox 85やSafari 14では問題なく、またwidthプロパティーなどでなら発生しない。

.test .raw {
  font-size: 2ch;
}

.test .calc {
  font-size: calc(2ch);
}

このようなコードで再現する。同じ大きさ(16px前後)になるはずだが、Chrome 88やEdge 88で.calcの方が倍の大きさになってしまう。例えばNoto Sans CJK JPだと、17.76pxのはずが35.52pxになった。

2度計算してしまっているような気がするが、3chにしても倍なので、そういうわけでもないようだ。単に1chが倍に解釈されてしまうように見える。とにかく挙動不審だ。解決策もなさそうで、使わないようにするしかない。フォントによって変わるサイズを利用する時は頭に入れておくべきだろう。ex単位でも発生する(caplh単位は実装がない)。


このウェブサイトのカラム幅をch単位で指定しようとしたら、まんまと遭遇した。html要素の文字サイズを描画領域幅とカラム幅の差から計算していたので、ぴったりとこのような使い方になっていた。変わったことをしている自覚はあったので、すぐに気づけた。カスタム・プロパティーで定義、それを使って計算、というような書き方だと、どこでどのような単位を使っているか忘れてしまうので、遭遇しやすいかもしれない。

追記

このバグはどうもWindows 10でスケーリングを200%にすると起こるようだ。100%にすると起こらず、150%にすると1.5倍になった。高解像度なWindows 10のパソコンはそこそこ存在すると思うので、気をつける必要があるし、エミュレーター(スケーリングが100%のまま)などでは気づけない可能性も高いので、より注意が必要かもしれない。