Chrome及其处理％s

当使用百分比（％）来计算我的元素大小时，Chrome显然更喜欢用数学方式组成自己的规则。Chrome及其处理％s

这是我的理解，当你添加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的事情，我还没有测试过）。

来源

2012-03-21 Vin Burgh

它看起来像一个舍入误差。你会注意到，如果你慢慢调整大小，它会跳转一点点。我怀疑Chrome是分别舍入每个1％，所以当总宽度是240px时，最终会有4个填充为2px的填充，最后会留下4px的空白。 – 2012-03-21 02:42:38

是的，绝对是一个舍入“错误”。或者说，WebKit似乎明白，没有像分数像素那样的东西，并且如果你做了一些导致它以分数像素结束的事情，它会截断到最接近的整个像素。这很容易通过挑选固定的容器宽度来展示，该宽度在所有使用的百分比之间均匀分割而不会生成任何小数分量。例如：http：//jsfiddle.net/XcA4F/2/ – aroth 2012-03-21 02:59:07

自2012年5月起，Webkit与[子像素渲染]（http://trac.webkit.org/changeset/116009）一起工作。 – 2013-12-11 17:22:20

这是一个bug。

来源

2012-03-21 02:38:19 bookcasey

绝对是舍入错误：http://www.screenr.com/pvB8 – benesch 2012-03-21 02:45:19

用于screencap的TY：]内容丰富。 – 2012-03-21 16:59:25

我解决了我的问题，改变了chrome的webkit margin，例如我用：

-webkit-margin-start：-5％;

来源

2013-03-19 21:58:35 kristophbarbour

在你的浮动元素周围放置一个包装，并且溢出隐藏（以防万一）。然后在没有正确舍入的div上，使用calc（X％+ 1px）来解决问题。

来源

2014-07-18 15:20:24 arrow

Chrome及其处理％s

回答

相关问题