利用しているフォントの「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
単位でも発生する(cap
やlh
単位は実装がない)。
このウェブサイトのカラム幅をch
単位で指定しようとしたら、まんまと遭遇した。html
要素の文字サイズを描画領域幅とカラム幅の差から計算していたので、ぴったりとこのような使い方になっていた。変わったことをしている自覚はあったので、すぐに気づけた。カスタム・プロパティーで定義、それを使って計算、というような書き方だと、どこでどのような単位を使っているか忘れてしまうので、遭遇しやすいかもしれない。
このバグはどうもWindows 10でスケーリングを200%にすると起こるようだ。100%にすると起こらず、150%にすると1.5倍になった。高解像度なWindows 10のパソコンはそこそこ存在すると思うので、気をつける必要があるし、エミュレーター(スケーリングが100%のまま)などでは気づけない可能性も高いので、より注意が必要かもしれない。