在单个（同步）函数执行期间，DOM渲染是否保证被阻止？ [英] Is DOM rendering GUARANTEED to block during a single (synchronous) function's execution?
问题描述
但是，我想知道如果实际的用户可见渲染的阻止是你可以实际 。大多数浏览器中我确信这是事实上的90％，但我希望这不仅仅是一个幸福的事故。我似乎没有找到DOM规范的任何明确的陈述，甚至是像MDM这样的供应商文档。
我稍微担心的是，尽管对DOM的更改确实不可见在页面中，内部DOM几何（包括CSS变换和过滤器）在同步执行期间实际更新。例如：
console.log（element.getBoundingRect（）。width）;
element.classList.add（scale-and-rotate）;
console.log（element.getBoundingRect（）。width）;
element.classList.remove（scale-and-rotate）;
...确实会报告两个不同的宽度值，虽然页面不显示到flash。添加类后同步等待（使用while循环）不会使临时更改也可见。在Chrome中执行时间线跟踪显示，内部绘画和重新绘制正在发生，这是有道理的。这是有道理的。
我担心的是，缺少一个具体的原因不是，有些浏览器，就像处理弱势移动CPU的用户一样，可能会选择在该功能的执行期间实际反映用户可见布局中的这些内部计算，从而导致一个丑陋的闪电。所以更具体地说，我所要求的是：他们有没有特定的理由吗？
（如果你想知道为什么我关心这一点，我有时需要使用 getBoundingRect 针对特定状态的元素来计算计算的维度，以计划间距或动画或其他此类内容，而无需实际将其置于该状态或首先将其动画化。 ..）
与事件相关的Javascript中没有任何事情。 JS根本没有定义一个并发模型。一切都是幸福的事故或多年的共识。
这就是说，如果你的函数没有调用像XMLHttpRequest或alert这样的奇怪的东西，可以将其视为单线程，无中断。
DOM blocking is something many people not familiar with JavaScript's strictly single-threaded synchronous execution model find out about the hard way, and it's usually just something we want to work around somehow (using timeouts, web-workers, etc). All well and good.
However, I would like to know if blocking of the actual user-visible rendering is something you can actually rely on. I'm 90% sure it is de facto the case in most browsers but I am hoping this isn't just a happily consistent accident. I can't seem to find any definitive statements from DOM specifications or even vendor documentation like MDM.
What worries me slightly is that while changes to the DOM are indeed not visible looking at the page, the internal DOM geometry (including CSS transforms and filters) does actually update during synchronous execution. For example:
console.log(element.getBoundingRect().width);
element.classList.add("scale-and-rotate");
console.log(element.getBoundingRect().width);
element.classList.remove("scale-and-rotate");
... will indeed report two different width values, though the page does not appear to flash. Synchronously waiting after the class is added (using a while loop) doesn't make the temporary changes visible either. Doing a Timeline trace in Chrome reveals that internally paint and re-paint is taking place just the same, which makes sense...
My concern is that, lacking a specific reason not, some browsers, like say, those dealing with underpowered mobile CPUs, may choose to actually reflect those internal calculations in the user-visible layout during that function's execution, and thus will result in an ugly "flash" during such temporary operations. So, more concretely, what I'm asking is: Do they have a specific reason not to?
(If you are wondering why I care about this at all, I sometimes need to measure calculated dimensions using getBoundingRect for elements in a certain state to plan out spacing or animations or other such things, without actually putting them in that state or animating them first...)
There is nothing in Javascript related to concurrency that is anything but de facto. JS simply does not define a concurrency model. Everything is happy accident or years of consensus.
That said, if your function does not make any calls to weird things like XMLHttpRequest or "alert" or something like that, you can basically treat it as single-threaded with no interrupts.
这篇关于在单个（同步）函数执行期间，DOM渲染是否保证被阻止？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
