When Does Reflow Happen in a Dom Environment

When does reflow happen in a DOM environment?

Both articles are correct.
One can safely assume that whenever you're doing something that could reasonably require the dimensions of elements in the DOM be calculated that you will trigger reflow.

In addition, as far as I can tell, both articles say the same thing.

The first article says reflow happens when:

When you retrieve a measurement that must be calculated, such as accessing offsetWidth, clientHeight, or any computed CSS value (via getComputedStyle() in DOM-compliant browsers or currentStyle in IE), while DOM changes are queued up to be made.

The second article states:

As stated earlier, the browser may cache several changes for you, and reflow only once when those changes have all been made. However, note that taking measurements of the element will force it to reflow, so that the measurements will be correct. The changes may or may not not be visibly repainted, but the reflow itself still has to happen behind the scenes.

This effect is created when measurements are taken using properties like offsetWidth, or using methods like getComputedStyle. Even if the numbers are not used, simply using either of these while the browser is still caching changes, will be enough to trigger the hidden reflow. If these measurements are taken repeatedly, you should consider taking them just once, and storing the result, which can then be used later.

I take this to mean the same thing they said earlier. Opera will try its hardest to cache values and avoid reflow for you, but you shouldn't rely on its ability to do so.

For all intents and purposes just believe what they both say when they say that all three types of interactions can cause reflow.

Cheers.

How does the timing of reflow / rendering work?

The .css() method is not asynchronous, thus you can safely assume that any statements after it will execute as you expect.

$('#foo').css('height', '100px');
console.log($('#foo').css('height')); // will log '100px'

do reflows occur once for each applied style?

When i do this in javascript:

element.style.width="100px";

element.style.height="100px";

Am i right to say that there are 2 reflows in the document?

Most unlikely. Reflows take (comparatively) a lot of time so they tend to only happen during JavaScript execution when they need to, for example when a piece of JavaScript reads back a property that depends on it's layout, e.g. offsetWidth.

But the details will be implementation dependent.

When something is appended to the DOM in memory, does that cause a browser reflow?

Basically, what I want to know is, does the browser only start to reflow when the pixels of the screen are told to change?

No, the browser reflows when the DOM changes. After that, it will repaint (tell the pixels on the screen to change).

For the details, have a look at this dev.opera.com article and the question When does reflow happen in a DOM environment?.

In short: There is of course optimisation for subsequent DOM changes, for example if you insert an array of elements in a loop. I would not expect your cases 1 and 2 to differ noticeable.

Only if you are doing really heavy DOM changes, you might need case #3. This makes reflows, should they happen during the insert loop, stop when encountering the hidden elements so they are basically prevented. However, the two display changes before and after the loop can lead to flickering in some browsers.

Can accessing layout information also cause browser reflows?

Of course it depends on implementation, but generally a browser triggers a reflow upon reading an element's property if it thinks that layout data needs to be re-queried (i.e. some layout-related properties on this element or any parent element changed).

You can find a list of affected properties for WebKit here: How (not) to trigger a layout in WebKit.
A more general article with examples: Rendering: repaint, reflow/relayout, restyle

Does touching the DOM trigger a reflow and repaint even if nothing changes?

Using the MutationObserver api you can detect DOM changes.

Here is an example you can use to see if a browser triggers the Dom Changed event, based on what you want.

You have here both a text('...') by jquery and an el.textContent (that doesn't use jquery).

$(document).ready(function() {  $('#btn1').click(function() {    console.log('text changed - jquery');    $('#a1').text('text 1');  });  $('#btn2').click(function() {    console.log('text changed - textContent');    $('#a1')[0].textContent  = $('#a1')[0].textContent   });  $('#btn3').click(function() {    console.log('class changed');    $('#a1').attr('class', 'cls' + Math.floor(Math.random() * 10));  });});

var target = $('#a1')[0];
// create an observer instancevar observer = new MutationObserver(function(mutations) {  var changed = false;  mutations.forEach(function(mutation) {    // You can check the actual changes here  });  console.log('Dom Changed');});
// configuration of the observer:var config = { attributes: true, childList: true, characterData: true };
// pass in the target node, as well as the observer optionsobserver.observe(target, config);

.cls1 {  border: 1px solid red;}.cls2 {  border: 1px solid pink;}.cls3 {  border: 1px solid cyan;}.cls4 {  border: 1px solid darkgreen;}.cls5 {  border: 1px solid orange;}.cls6 {  border: 1px solid darkred;}.cls7 {  border: 1px solid black;}.cls8 {  border: 1px solid yellow;}.cls9 {  border: 1px solid blue;}.cls10 {  border: 1px solid green;}

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script><div id="a1" class="cls1">text 1</div><button id="btn1">Change text - jquery (keep original)</button><br /><button id="btn2">Change text - textContent (keep original)</button><br /><button id="btn3">Change class (real change)</button>

How many Reflows does attaching a DocumentFragment Cause?

A single DOM reflow process occurs each time an action causing one is invoked.
We can read in this article that:

This pattern lets us create multiple elements and insert them into the
DOM triggering a single reflow. It uses something called a
DocumentFragment. We create a DocumentFragment outside of the DOM (so
it is out-of-the-flow). We then create and add multiple elements to
this. Finally, we move all elements in the DocumentFragment to the DOM
but trigger a single reflow.

There are various actions that can cause a DOM reflow, including appending a new element to the document. The purpose of using a DocumentFragment is to be able to append content to the DOM in a single operation causing a single reflow process.

According to this article, we can read that:

Sometimes reflowing a single element in the document may require
reflowing its parent elements and also any elements which follow it.

However, all these reflow operations will occur in a single reflow process.

I created a fiddle to demonstrate this. Using chrome's timeline, we can clearly see that rendering occurs in a single block.

---

Related Topics