一般情况下，在CSS中，对于单行的纯文本元素，它的高度（height）就是由它的行高（line-height）决定的。例如，将一段只有一行的文字的行高设置为30px，那么这一个“块”的高度也就是30px。
但在实践中我发现，FireFox、Edge、IE等浏览器应用上述规则时都没有问题，但是Chrome浏览器在根据行高计算元素的高度时，结果与理论值会有偏差，显示出来的height值可能会略小于line-height，而且这个偏差值还有周期性规律。
应用11段一模一样的文字进行第一次测试，字号（font-size）全设为18px，margin和padding全设为0。唯一的差别是11段文字的行高均不相同，从1倍行高一直到2倍行高，共11种不同的行高（倍值具体为1.0、1.1、1.2、1.3、1.4、1.5、1.6、1.7、1.8、1.9、2.0）。理论上，这11段文字的行高（line-height）和高度（height）应该均分别为18、19.8、21.6、23.4、25.2、27、28.8、30.6、32.4、34.2、36（单位px）。
具体代码如下：
<!DOCTYPE html>
以及
p（字体可忽略，主要是我不同的浏览器设置了不同的字体，为了测试时效果统一所以规定了一种字体）
现用不同的浏览器打开这个文档，在Firefox和Edge中，均表现正常，完全符合理论预期。但是在Chrome中，却出现了问题，详见下图（共11张图，每张图请注意右下角的height和line-height数值）。
如上我们可以看到，chrome中显示的height和line-height数值并不一定一致（而在其他浏览器中这两个值是一定一致的），从p0开始，height和line-height的差值依次为0.4、0.6、0、0.2、0.4、0.6、0、0.2、0.4、0.6、0，每四个一组呈现一定的周期性。
现在更换字号进行第二次测试，将字号设置为16px，其余代码保持不变。这一次，Chrome和其他浏览器一样，全都能正常显示，height和line-height完全一致。（图略）
现在更换字号单位进行第三次测试，将字号由18px改为18pt，其余代码保持不变。这一次，Chrome和其他浏览器一样，全都能正常显示，height和line-height完全一致。（图略）
现在更换行高计算方式进行第四次测试，字号改回18px，行高不再使用倍数关系，直接分别写为18px、20px、22px、……、38px。这一次，其他浏览器均显示正常，而Chrome把它们显示成了……17.6、20、21.6、24、25.6、28、29.6、32、33.6、36、37.6……，height与line-height的差值分别为0.4、0、0.4、0、0.4、0、0.4、0、0.4、0、0.4，每两个一组呈现一定的周期性。
（其余图略）
综上，通过不断地变换条件，Chrome在一些情况下能正确计算line-height和height的关系，但在另一些情况下不能，具体能否正确计算与设置的字号（font-size）值或行高（line-height）值有关。而其他浏览器在任何情况下都能正确计算这两个数值。
似乎Chorme始终不会把height设为某些特定的数值（包括很多整数），而另一些数值则反复出现，例如17.6、21.6、33.6，即便我们并没有将line-height或height设为这些值。而上面这些值与72都能构成简单整数比关系（17.6/72=11/45，21.6/72=3/10，33.6/72=7/15），而英寸（in）和点（pt）的换算关系就是1in=72pt，同样地，传统上屏幕的分辨率也是72dpi（dots per inch）。Chrome的这一反常计算结果，是不是与这些内容有关，目前还暂不清楚。
扫一扫
1349
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
