Javascript对于DOM操作而言太快了吗? [英] Javascript too fast for DOM-manipulation?

问题描述

在Javascript中，我通过AJAX从服务器加载了一些元素，并且为每个数据元素创建了一个<div>，其中包含另一个div和一个<img>.内部div包含2到5行文字.我将其中三个项目并排排列，然后将下三个项目并排放置，依此类推.

In Javascript I load some elements via AJAX from a server, and for each data-element I create a <div> that contains another div and an <img>. The inner div contains between 2 and 5 lines of text. I arrange three of this items side by side in a row, then the next three in the next row and so on.

但是由于文本的长度不同，所以我想对每一行中的元素进行一些微调.我希望所有三张图片的上边缘都处于相同的高度.为此，我这样做:

But since the texts have different lengths, I want to do some fine-adjustment of the elements within each row. I want the top-edges of all three images to be on the same height. To do this, I do this:

• 将三个<div><div>text</div><img></div>块插入其容器中.
• 获取三个<div>text</div>元素的高度
• 计算其最大值，然后
• 设置它们的padding-top属性，使其具有相同的高度.

• Insert the three <div><div>text</div><img></div>-blocks into their container.
• Get the heights of the three <div>text</div>-elements,
• calculate their maximum, and then
• set their padding-top properties in a way that gives them all the same height.

在Safari和Chrome浏览器中，当我打开控制台并设置断点以查看发生的详细情况时，此方法可以很好地工作.

In Safari and Chrome this works perfectly fine when I turn on the console and set breakpoints to watch what is going on in detail.

但是当我在这两个浏览器中关闭断点时，文本差异不会得到正确的填充值.

But when I turn off breakpoints in this two browsers, the text-diffs don't get their correct padding-values.

我非常确定，当javascript尝试测量text-div的高度时，在断点处，浏览器仍在努力插入三个dom元素并渲染图片.因此，它在没有最终值时对它们进行测量.该脚本读取了错误的值，因此将错误的值赋予padding-top-property.

I am pretty sure, that - at breakpoints off - the browser is still working on inserting the three dom-elements and rendering the pictures, when javascript tries to measure the heights of the text-divs. So it measures them at a time when they don't have their final values. The script reads wrong values and so it puts wrong values to the padding-top-property.

并非在所有浏览器中都发生这种情况:

This does not happen in all browsers:

正常运行时(没有控制台和断点)，它在以下情况下始终可以正常运行:

When running normally (without console and breakpoints) it works always fine within:

• Firefox
• 歌剧
• Internet Explorer(在我的iMac上的虚拟机中运行)

但是我有以下问题:

• Safari
• Chrome

我该怎么做才能确保在渲染机器完成操作后对元素高度进行测量?

What can I do to ensure, that the measurement of an elements height happens when the rendering-machin has finished its manipulation?

我发现了另一个非常重要的细节:

I found out another very important detail:

由于图像上方text-div的高度而出现问题.有时，文本会非常紧密地分成两行.任何行中再增加一个小写字母，它将是三行.

The problem occurs, because of the height of the text-div above the image. Sometimes the text fits very tightly into two rows. One small letter more in any of the rows and it would be three rows.

在这种情况下，我的脚本在创建div后立即运行，其高度为三行(60像素)，并且如果此div确实包含3行文本，则所有内容都是绝对正确的.如果此div确实是3行高，我的脚本将以一种完美的方式操纵元素.

In this case my script, that runs immediately after the div was created, measures a height of three lines (60 pixel), and everything would be absolutely correct, if this div did really contain 3 lines of text. My script manipulates the elements in a manner that would be perfect if this div really was 3 lines high.

但是显然，在我的脚本运行了几毫秒之后，浏览器(Safari和Chrome)对字体渲染进行了改进.然后，文本突然变成两行，这使得text-div仅高40像素.因此图像向上移动了20个像素，这破坏了我刚刚处理的结果(所有图像都在同一位置)

But obviously, some milliseconds after my script was running, the browser (Safari and Chrome) performs an improvement of font-rendering. And then suddenly the text fits into 2 lines, which makes the text-div only 40 pixels high. And so the image moves up 20 pixels, and this destroys my just processed result (all images was at the same position)

那么，这对您如何解决问题有任何想法吗?有没有办法让我的脚本的那部分在所有渲染抛光完成之后运行?是否有类似onFinishingRenderingImprovementsDone的事件?

So,does this give you any idea on how to solve the problem? Is there a way to let that part of my script run after all rendering-polishing has finished? Is there an event like onFinishingRenderingImprovementsDone?

(写在 5月4日与您在一起=星球大战纪念日)

(written on May the 4th be with you = Star Wars day)

推荐答案

如何让您的脚本在短时间内运行-setTimeout(function() {[your code here]}, 100)(或者需要多长时间……)-看看您是否可以简单地避免使用完全有问题吗?对于异步操作，可能不到一秒钟，添加一个非常短的等待可能就不会引起注意.

How about having your script run with a short delay - setTimeout(function() {[your code here]}, 100) (or however long it needs...) - and see if you can simply avoid the problem altogether? Less than a second probably, and for an async action, adding a very short wait would likely not be noticeable.

这篇关于Javascript对于DOM操作而言太快了吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！