时间戳

首页 > 解决方案 > 为什么以 em 为单位的高度有时大于适当的文本行数乘以它们的行高？

css - 为什么以 em 为单位的高度有时大于适当的文本行数乘以它们的行高？

问题描述

考虑代码：

p {
  display: inline-block;
  font: 17px / 1.5 serif;
}

.floating {
  float: right;
  background: bisque;
  width: 10em;
  height: 9em;
}
<p>
  <span class="floating"></span>
  Line 1<br>
  Line 2<br>
  Line 3<br>
  Line 4<br>
  Line 5<br>
  Line 6<br>
  Line 7 should not break
</p>

我很难理解是什么原因导致浏览器（例如 Chrome 和 Safari）认为此示例中的浮动块高于 6 行非常统一的文本，行高 = 1.5，因此在 font-size=17px 上的结果看起来像这样：

第 7 行由于与浮动元素的冲突而中断

而且，假设我选择 font-size=20px，结果看起来如预期： 第 7 行没有断，而且字

这是一个错误还是非常预期的事情？如果后者是有效的，我在哪里可以阅读以像素为单位计算结果行高的微妙之处（可能取决于字体属性）？

标签： css

解决方案

向皮特致敬，他想出了为什么会发生这种情况的想法。

正如我们所发现的line-height，与其他浏览器（例如，Firefox）相比，基于 Webkit 的浏览器处理像素分数的方式略有不同。

问题的结果line-height是17px * 1.5 = 25.5px，因此，每行文本占用 25px，即被Math.floor实现，而不是任何其他理论上可能的选项（Math.ceil或在奇数行和偶数行之间分配 25px 和 26px，或其他）。

因此，6 行占据的高度等于25px * 6150 像素。另一方面，浮动元素的高度被定义为25.5px * 6153px。

因此，从数学上讲，我们看到了一种常见情况，即floor集合中 -ed 元素的总和小于或等于floor这些元素的 -ed 总和，或者：

{\sum_i^n 楼层(L_i)} \leq 楼层({\sum_i^n L_i})，其中 L 是线的高度。

这就是为什么一个可接受的解决方案是考虑 Webkit 处理像素分数的方式，即地板。这在其他浏览器中看起来是一致的（除非累积了更大的错误），即使它们ceil在这种情况下应用 -ing 也是如此。

推荐阅读