【发布时间】：2012-03-21 02:35:46
【问题描述】：
当使用百分比 (%) 来确定我的元素大小时，Chrome 显然更喜欢用数学方法来制定自己的规则。
我的理解是80+20加起来就是100；对？好的。 Chrome 也明白这一点。但是，如果我们用不同的方式写出相同的方程会怎样。例如：(78 + 1 + 1) + (18 + 1 + 1) 你得到了什么？是100吗？是的，我也是。
那么有人可以请告诉我为什么 Chrome 不这么认为吗？
取两个元素并将它们并排浮动。然后，将width:20% 应用于一个元素，将width:80% 应用于其余元素。您会注意到页面（或容器）的 100% 已被两个元素并排占用。但是，让我们保持简单，在每个元素的两侧添加仅 1% 的填充。这意味着一个元素将具有width:18%; padding:1%，而另一个元素将具有width:78%; padding:1%。理论上，这仍然应该有相同的结果：页面（或容器）的 100% 被两个元素并排占据。但在 Chrome 中，情况并非如此。不够用。
证据在布丁中：jsfiddle（如果您使用 Chrome，您会注意到细微差别）。
这很令人沮丧，因为当所有这些加起来时，尤其是在并排使用大量元素的情况下，它真的会使布局失控。我知道通过创建子元素来处理填充和/或边距，我们可以避免这种情况，但这可能会导致使用原本多余的标记。
我只需要解释一下为什么 Chrome 会有这种行为（也许它完全是一个 Webkit 的东西，我还没有测试过）。
【问题讨论】：
-
它看起来像一个舍入错误。如果您慢慢调整大小，您会注意到它会跳动一点。我怀疑 Chrome 会分别将 1% 的每一个四舍五入，所以当总宽度为 240 像素时，你最终会得到 4 块 2 像素的填充，最后留下 4 像素的间隙。
-
是的，绝对是一个四舍五入的“错误”。或者更确切地说，WebKit 似乎明白没有小数像素这样的东西，如果你做了一些导致它以小数像素结束的事情，它就会截断到最接近的整个像素。这很容易通过选择一个固定的容器宽度来证明，该宽度均匀地分布在所有使用的百分比上，而不会生成任何小数部分。例如：jsfiddle.net/XcA4F/2
-
Webkit 自 2012 年 5 月起与 subpixel rendering 合作。
标签： css google-chrome webkit