Javascript 使用jquery的Firefox宽度之和超过预期值

截至5月12日，Firefox/Safari/Chrome在macOS上发布了所有最新的稳定版本

jQuery v3.1.0

我有一个

jquery

脚本，它可以动态地调整图像的大小（具体地说，一个容器

div

，其中有一个

img

元素将其100%填充在一个集合容器

div

中，以提供类似砖墙的效果。概括起来，我的逻辑是按照当前窗口宽度的首选大小计算图像，并将它们相加（包括水槽），直到它们超过该窗口宽度。然后我减去最后一个元素，并将余数按比例放大

这在Chrome和Safari中效果很好。Firefox可以在大多数行上运行，但有时最后一个元素会跳到下一行，并抛出整个合成。经过检查，有罪行的罪魁祸首似乎是所有行元素的总和最多超过收集容器1个像素，而不是更多。它通常是一个像素的一小部分。我的直觉是这是一个四舍五入或小数位的问题；或者我在研究中发现了一个与浮点有关的问题

代码： 如果我在下面的代码中遗漏了任何相关内容，请原谅。我觉得通过

jquery

（特别是我的scaleFactor结果）计算各种元素的宽度就足够了，这样就可以让它更清晰一些：

脚本中的计算：

// Once it's been determined that a row has the required number of elements to fill it:

var windowwidth = $(window).width();
var gutter = 23;
var scaleFactor = (windowWidth - (sum of total gutters in row))  / (sum of total element widths in row);

// Looping through each element, resize them as such:

var w = $(this).width();
var h = $(this).height();
// Set new width and height
$(this).css({'width': (w * scaleFactor) + 'px'});
$(this).css({'height': (h * scaleFactor) + 'px'});

结果: Chrome和Safari制作的一行中，所有排水沟和元素的总和始终低于窗宽的一小部分，提供了完美的视觉间距，如下所示：

（23）+936.094+（23）+415.859+（23）//对于1421的窗口宽度，给出了1420.953的总和

Firefox在检查最后一个元素跳到下一行的行时，给出了如下相同的示例：

（23）+938.9+（23）+417.117+（23）//对于1425的窗宽，求和为1425.017

其他信息：

• 我已经给出了

  img

  元素、它们的容器

  div

  和内容 容器

  div

  框大小调整

  css中的

  边框框的值
  在每个浏览器的宽度值中删除任何样式差异。
  不管怎样，都没有任何填充或边框
  

• 我在这里提到的内容容器

  div

  包含所有排列成行的元素。它是窗的宽度减去一个檐槽，用作边距。我在所有的计算中都考虑到了这一点，我很有信心我做得很恰当，因为如果我忽略了更多的东西，总和将大大超过一个像素的一小部分。我故意将元素缩放到窗口宽度，而不是内容容器（其主要目的是为每个元素的侧面提供一个相对的边距，每个元素必须在每个元素周围提供一致且相等的排水沟），但已对内容容器进行了缩放测试，结果相同

• 我还确认了我在这里使用的

  宽度
  值：
  （
  行中的元素总宽度）
  在所有浏览器和
  源于每个元素的
  jquery的
  width（）
  函数。这个
  所有浏览器上的窗口大小值略有不同-I
  想象一下，由于滚动条的不同，但我只能假设它是
  精确的我使用了其他方法来获得窗口宽度，但没有
  滚动条和它们（据我所知）确认
  使用的值是正确的
  

• 我试着把不同的部分绕成一圈，这证实了我的想法 假定当宽度之和 超出容器0.5以上

• 在装载完所有内容物后进行测量 使用

  $（窗口
  ).on（“加载”，function（）

  函数

最佳解决方案： 理想情况下，我希望我忽略了上面代码中计算的一个方面，可以对其进行调整，以确保相同的变量在浏览器中产生相同的结果

这可能是一厢情愿的想法，因此我的方案b将是一种优雅的补偿方式。目前，我可以在计算后将窗口宽度与总和进行比较，并将其缩小。或者我可以放弃精确的排水沟，目标是缩小到窗口宽度，小于一个像素

第一个想法的问题是，修补一个简单的计算结果似乎是一个糟糕的设计。它浪费了代码行和开销，我尽可能避免膨胀。第二个解决方案激怒了我的完美主义者，如果我以依赖于某个信念的方式扩展项目，可能会带来长期的复杂性在整个布局中都可以看到真实情况，例如排水沟

---

更新：

---

我还没有排除在计算中对各种浮点数进行舍入的可能性，但主要是通过猜测来实现的。我的主要线索是尝试对

widthBefore

var进行舍入，因为它有时是一个浮点数，而

scaleFactor

中的所有其他变量都是整数。

Round

，和以前一样，都不起作用。令我惊讶的是，

flo或者

不起作用。我原以为它会在间距上留下细微可见的边缘差异，但它仍然留下超过窗口宽度的行。更让我惊讶的是，

天花板

起作用了。我无法解释为什么Firefox需要我用

天花板

来舍入这个值才能起作用，但我这么做的一切都很好到目前为止。我还必须看看对排水沟尺寸的影响。我无法完全解释其背后的逻辑。可能需要有人知道不同浏览器之间数学计算的细微差别，但通过

天花板
将
之前的宽度四舍五入保持相同的r