在 WebKit 浏览器中，使用百分比值来设定某些元素可能会导致意想不到的结果。例如，如果您有一系列以百分比宽度和百分比填充设置的列，WebKit 可能会以相当奇怪的方式计算它们的尺寸。
更新：WebKit 现在 拥有 子像素渲染功能，这应该可以解决这个问题。
似乎是百分比本身存在问题。虽然我还没有找到很多关于它的信息，但我似乎记得很早以前读过关于它的一些内容。我认为它与子像素值是如何计算的有关。例如，如果一个容器当前的宽度为 657px，并且有四列，每列占 25%，则它们将分别为 164.25px 宽度，而 WebKit 无法很好地处理这种情况（四舍五入问题？）。其他浏览器可以正常处理“子像素”值。
感谢 Nicolas Gallagher 指出这一点。如果我在这方面落伍了，请随时责怪我，但请给我一些链接和信息，以便我用最准确的信息更新这篇文章。 此链接 似乎表明这个问题已经存在一段时间了。
请记住，只有在您使用这些示例中显示的带有纯色列的示例时，这才是真正的问题。如果您没有使用任何视觉分隔符，这可能不是什么大问题，只是一种很小的跨浏览器差异，很少有人会注意到。
你为什么费这么多心思啊，chris，别管这些了，yav
英文？
我不懂英文，你会说土耳其语吗？
Google 翻译给我的结果是：`Leave blank run them how they strive chris yav`
土耳其语->别这么说，这些事情在大型项目中很重要
我之前也注意到过这个问题，但不知道它是一个“子像素”问题。我认为我当时只是从百分比间距改为像素间距，以完全绕过它！
哎呀，真是太糟糕了！
他们应该尽快修复它。我并不经常使用百分比，但我也遇到过一些奇怪的行为。
希望垂直方向上不会出现一些与 em 相关的错误？
John Resig 之前写过一篇关于这个的文章
CSS 中的子像素问题
查看了那个页面上的演示——IE8 仍然做错了！令人惊讶的是，它仍然向上取整并破坏了布局，而那篇文章是在 2 年半前写的。
错了？微软的开发人员选择了一种不同的解决方案。在我看来，这并非最佳方案，但你不能说它错了。正如文章中所说！
…奇怪的是，我试着制作一个 50px 的 div，里面有 4 个浮动在左边的 div，每个 div 为 12.5px，但仍然有间隙。
事实证明，WebKit 似乎不渲染 CSS 中的小数点，它也会自动将这些小数点四舍五入。
是的，我一直很沮丧，在 WebKit 中，3 列分别为 33.3%、33.3% 和 33.4% 与在每个元素上指定 33%（不带小数点）的功能相同。唯一的解决方案是使用 33%、33%、34% 或类似的变体。
过去在处理流体网格时，我遇到过很多次这个问题，Firefox 和 Opera 似乎会尝试进行适当的四舍五入，即使存在一些奇怪的像素剩余，它们也能找到一种方法进行正确显示。不幸的是，IE 和 WebKit 选择了截断任何分数/子像素的方法，如果数学计算结果不整齐，这会导致浮动元素无法正确填充其容器。如果您查看当前几乎所有流体网格系统，IE 和 WebKit 都将提供不理想的结果。
正如 John Resig 所总结的那样，并没有绝对的正确或错误。令人沮丧的是，所有浏览器都没有使用相同的方法。在 Firefox 的情况下，它不再遵循 CSS 规则，该规则规定例如，四个浮动 div 宽度应该相等，而 WebKit 则遵循该规则。在某些情况下，一种方法的视觉效果可能比另一种方法更好，但这并不通用。
同意，但这确实令人沮丧，如果多列的百分比加起来为 100%，您会期望它们填充 100% 的行，而不是 98%（或在某些示例中更少），因为分数百分比被截断了。
即使规范没有明确说明哪种方法是正确的，我的猜测是，如果百分比加起来为 100%，设计人员可能希望它们填充整个行，而不是强制要求它们都相等，因为如果几个框有一些“四舍五入像素”，这比在行末留下大量空间对网站最终用户来说更不明显。
至少没有哪个浏览器会向上取整并导致浮动下沉！
这里有人参与 HTML5 规范制定，以便他们尝试为此添加一些定义吗？
在 IE/WebKit 中查看这一点，以查看更清晰的问题示例：http://www.designinfluences.com/fluid960gs/12/fluid/none/
嗨，Chris，
我们为 Elastic CSS 框架的开发涵盖了主要浏览器中子像素取整算法。
您可以在此处阅读：http://elasticss.com/determination-of-algorithms-used-for-percentage-based-rounding-divs-on-browsers-and-css-frameworks/
干杯
Sergio，我以前没有见过那个框架，感谢您的链接。
对于一些人来说，包括 JavaScript 来修复取整错误可能不理想，因为这会影响复杂页面的性能，尤其是在平均页面访问者（使用速度较慢的计算机）的情况下，但有很多情况下，流体/弹性网格是理想的选择，也是一个很好的解决方案。
正如您在对该问题的评论中建议的那样，如果浏览器供应商至少记录了他们如何处理取整，那将非常棒。也许如果这样做了，就会更清楚地知道存在问题，并且更可能出现标准化的努力。
我使用 *margin-right:-1px; 修复（IE6/7）用于 1 行 CSS 网格框架 http://www.vcarrer.com/2009/06/1-line-css-grid-framework.html
我尽量避免在宽度已定义的元素上使用填充，以避免出现这种情况。如果可能的话，我会将填充添加到子元素。
我认为，避免这个问题的唯一方法是确保您可以将容器划分为完整的像素。也就是说，如果您想将容器划分为 4 列，且每列大小相同，您需要将容器大小从 657px 调整为 656px。
从技术上讲，您需要遵循以下规则：container.size%number_of_columns = 0
顺便说一句，我已经在 IE6 和 IE7 中注意到了同样的问题，当您将 101px 的容器大小划分为两列，每列占 50% 时，在 IE6 和 IE7 中，每列将为 51px。我猜想它将 50.5px 四舍五入到 51px。
就像一些人在上面解释的那样，有 3 种类型的子像素计算方法。
IE 方法
– 对子像素进行经典的四舍五入
– 向下取整<0.535 ///// 32.3=>32
– 会导致浮动 div 在 IE 过度向上取整时破坏布局。
Opera/Safari 方法
– 始终向下取整子像素
– 例如 34.6=>34 ///// 32.3=>32
– 当 div 向左浮动时，会导致左侧出现一些空白像素；向右浮动时，会导致右侧出现一些空白像素。
Firefox 方法
– 复杂的舍入算法
–>http://elasticss.com/determination-of-algorithms-used-for-percentage-based-rounding-divs-on-browsers-and-css-frameworks/
– 导致布局效果最佳，但无法透明地确定哪个 div 获取哪个确切大小。
非常酷，感谢 Patrick 的总结。
有趣的话题，谢谢。
嗨，这篇文章很棒。
我们试图确保我们能够根据需要将容器划分为 3 到 4 列的整数像素，但客户需求并不总是如此，因此拥有解决方法很有帮助，谢谢。LT
请使用你之前的 CSS-Tricks 布局…
Opera 在百分比中使用小数也会出现问题。
http://www.brunildo.org/test/percwidth2.pl
网站不错，还保留了 Webkit 的网页错误。这对浏览器很有用，并且保留了 Webkit 的网页错误，并为网页错误提供了填充和百分比宽度，以及基于 Webkit 的浏览器中略微出乎意料的结果。
我在编写 CSS 网格时遇到了这个问题，很糟糕。
Safari 仍然存在这个问题，但 Chrome 现在已经解决了。
我制作了一个关于百分比错误和浏览器的漫画，如果你想对这种情况哈哈一笑的话。
http://www.digitalpod.co.uk/blog/web-browser-comic-percentage-layouts-with-gaps/
截至撰写本文时，Chrome (v 35.0.1916.114) 在处理用于包装以百分比浮动的元素的百分比填充时仍然存在问题。
查看此 Fiddle 并扩展你的窗口。
http://jsfiddle.net/mUudt/
你会注意到，当窗口区域扩展时，第三个子元素会向下移到下一行。原因是父元素对容器应用了 1% 的填充，而填充百分比会扩展以将最后一个 (第三个) 元素向下推。