我有很多大文本，我正在使用精简版本的columnizer jQuery插件(https://github.com/adamwulf/Columnizer-jQuery-Plugin)转换为“列”，以便在另一个插件中使用。就我的目的而言，Columnizer的执行效果不错–只要要进行列化的块中没有 float 内容。
在大多数情况下，Chrome，FF和IE10在纯文本或包含图像和其他简单html的文本上都具有相似的性能。但是，如果包括 float 内容(在这种情况下为图像)，则情况会发生巨大变化:
带有图片的大书，大约创建了700列
测试条件Firefox(秒)Chrome(秒)
-------------------------------------------------- ---------------
普通书籍的构造(图片， float 图片)31.5 1254.2
如上，但没有图像23.2 18.9
w /有图像，但没有 float 图像25.1 24.7
只有一些 float 图像27.6 1010.9
删除除“p”外的所有图像，标签21.3 18.9
如您所见，这是巨大的差异。 (我确实缓存了构建，但是由于每个浏览器/ OS组合呈现的内容略有不同，因此，我仍然必须首先在“主要”浏览器中构建每个构建。直到在iPad上等待Safari来构建它之前，您还没有活过。东西-将Windows chrome数字乘以4。)
所以我的问题是:在不被问到的情况下，firefox做“正确”的事情是什么，我该怎么做才能重新处理列化程序代码以在其他浏览器中模仿它？ Columnizer相当“肮脏”，因为它执行了数千个(我认为在本书中为100,000个)附加项，我知道这绝对不酷。是否使用文档碎片？还有其他技巧吗？
Columnizer要求目标容器(进行内容流的位置)在dom中，以便可以正确应用样式(即，没有“display:none”，然后在完成时进行切换)。在我的CSS中，我建议将其设置为position:absolute，visible:hidden。我认为FF必须以其他浏览器无法看到的方式查看这组属性。要么...？
我应该注意到，在过程的最后，除了字体呈现的细微差异之外，浏览器之间的输出是相同的。
最佳答案
我不确定这是否能回答我自己的问题，但我确实做得更好，在某些方面对我来说已经足够了。 我很想真正了解为什么我的解决方案会有所不同。
背景:我将尽我所能在PHP中对本书的文本进行“预格式化”，因为在服务器端进行清理和其他平凡的文本琐事要快得多。然后，将这些清理过的html块放入div，这就是我分栏的内容。该容器(我们称其为“raw”)和用于列的空目标容器(“dest”)需要位于dom中，因此我在具有“raw”和“dest”的包装div上使用了此CSS小时候:
position: absolute;
top: -2000px;
left: -2000px;
width: 700px;
height: 500px;
visibility: hidden;
overflow: hidden;
这从页面上“删除”了两个div(就我们的眼球而言)，但是它们仍然在dom中，允许Columnizer与它们一起使用。
Hmmm:在Firefox中，这足以使一切正常运行， float 或不运行。但是在Chrome，Safari和IE中...嗯，请看我最初提出的问题中的表格。 uck
但是通过在“原始”中添加“position:absolute”，其他浏览器的性能得到了显着提高。它们不如FF快，但不落后于FF。整本书呈现后，Chrome现在无需花费1200多秒的时间，而只需40秒。 ipad不会花费冰河时代，而是需要花费几分钟。
为什么？对我来说是个谜。在准备过程中，这似乎是分栏器中的相关位:
...
var $sourceHtml = $('div.raw'),
$cache = $('<div></div>'),
$inBox = $('#dest'),
$destroyable, $col;
...
$cache.append($sourceHtml.contents().clone(true));
$inBox.empty();
$inBox.append($("<div style='width:" + options.width + "px;'></div>"));
$col = $inBox.children(":last");
$inBox.empty();
try {
$destroyable = $cache.clone(true);
} catch(e) {
$destroyable = $cache.clone();
}
...
此时，作为缓存创建的空div应该位于DOM中，但应位于HTML页面之外，因为尚未将其附加到任何内容。嗯因此，在对其进行操作时，无需重新粉刷页面。
我半信半疑的理论是，尽管FF认识到了这一点，但其他浏览器却没有，并认为$ destroyable可能位于页面的绘制区域内-可能将其附加到body标签甚至“包裹”(尽管看着)通过Chrome的检查器显示没有这种东西)？
当节点从$ destroyable剥离并附加到正在创建的列时，每次$ destroyable更改时，其他浏览器都会重新绘制页面。快速使用块和内联控件，添加浮点数时很昂贵。
但是要戳破这个半生半熟的想法:尝试在$ destroyable中添加“position:absolute”没什么区别。只有当原始的“原始” div具有该属性时，事情才会加速。
无论如何，回到大量饮酒和无知。如果可以的话，请耐心叹口气，并使其成为可教的片刻!