Trigger CSS transition on appended element

As this question observes, immediate CSS transitions on newly-appended elements are somehow ignored - the end state of the transition is rendered immediately.

For example, given this CSS (prefixes omitted here):

.box { 
  opacity: 0;
  transition: all 2s;
  background-color: red;
  height: 100px;
  width: 100px;
}

.box.in { opacity: 1; }

The opacity of this element will be set immediately to 1:

// Does not animate
var $a = $('<div>')
    .addClass('box a')
    .appendTo('#wrapper');
$a.addClass('in');

I have seen several ways of triggering the transition to get the expected behaviour:

// Does animate
var $b = $('<div>')
    .addClass('box b')
    .appendTo('#wrapper');

setTimeout(function() {
    $('.b').addClass('in');
},0);

// Does animate
var $c = $('<div>')
    .addClass('box c')
    .appendTo('#wrapper');

$c[0]. offsetWidth = $c[0].offsetWidth
$c.addClass('in');

// Does animate
var $d = $('<div>')
    .addClass('box d')
    .appendTo('#wrapper');
$d.focus().addClass('in');

The same methods apply to vanilla JS DOM manipulation - this is not jQuery-specific behaviour.

Edit - I am using Chrome 35.

JSFiddle (includes vanilla JS example).

  • Why are immediate CSS animations on appended elements ignored?
  • How and why do these methods work?
  • Are there other ways of doing it
  • Which, if any, is the preferred solution?

Answers:

Answer

The cause of not animating the newly added element is batching reflows by browsers.

When element is added, reflow is needed. The same applies to adding the class. However when you do both in single javascript round, browser takes its chance to optimize out the first one. In that case, there is only single (initial and final at the same time) style value, so no transition is going to happen.

The setTimeout trick works, because it delays the class addition to another javascript round, so there are two values present to the rendering engine, that needs to be calculated, as there is point in time, when the first one is presented to the user.

There is another exception of the batching rule. Browser need to calculate the immediate value, if you are trying to access it. One of these values is offsetWidth. When you are accessing it, the reflow is triggered. Another one is done separately during the actual display. Again, we have two different style values, so we can interpolate them in time.

This is really one of very few occasion, when this behaviour is desirable. Most of the time accessing the reflow-causing properties in between DOM modifications can cause serious slowdown.

The preferred solution may vary from person to person, but for me, the access of offsetWidth (or getComputedStyle()) is the best. There are cases, when setTimeout is fired without styles recalculation in between. This is rare case, mostly on loaded sites, but it happens. Then you won't get your animation. By accessing any calculated style, you are forcing the browser to actually calculate it.

Answer

Using jQuery try this (An Example Here.):

var $a = $('<div>')
.addClass('box a')
.appendTo('#wrapper');
$a.css('opacity'); // added
$a.addClass('in');

Using Vanilla javaScript try this:

var e = document.createElement('div');
e.className = 'box e';
document.getElementById('wrapper').appendChild(e);
window.getComputedStyle(e).opacity; // added
e.className += ' in';

Brief idea:

The getComputedStyle() flushes all pending style changes and forces the layout engine to compute the element's current state, hence .css() works similar way.

About css()from jQuery site:

The .css() method is a convenient way to get a style property from the first matched element, especially in light of the different ways browsers access most of those properties (the getComputedStyle() method in standards-based browsers versus the currentStyle and runtimeStyle properties in Internet Explorer) and the different terms browsers use for certain properties.

You may use getComputedStyle()/css() instead of setTimeout. Also you may read this article for some details information and examples.

Answer

Please use the below code, use "focus()"

Jquery

var $a = $('<div>')
    .addClass('box a')
    .appendTo('#wrapper');
$a.focus(); // focus Added
$a.addClass('in');

Javascript

var e = document.createElement('div');
e.className = 'box e';
document.getElementById('wrapper').appendChild(e).focus(); // focus Added
e.className += ' in';
Answer

@Frizi's solution works, but at times I've found that getComputedStyle has not worked when I change certain properties on an element. If that doesn't work, you can try getBoundingClientRect() as follows, which I've found to be bulletproof:

Let's assume we have an element el, on which we want to transition opacity, but el is display:none; opacity: 0:

el.style.display = 'block';
el.style.transition = 'opacity .5s linear';

// reflow
el.getBoundingClientRect();

// it transitions!
el.style.opacity = 1;
Answer

Rather than trying to force an immediate repaint or style calculation, I tried using requestAnimationFrame() to allow the browser to paint on its next available frame.

In Chrome + Firefox, the browser optimizes rendering too much so this still doesn't help (works in Safari).

I settled on manually forcing a delay with setTimeout() then using requestAnimationFrame() to responsibly let the browser paint. If the append hasn't painted before the timeout ends the animation might be ignored, but it seems to work reliably.

setTimeout(function () {
    requestAnimationFrame(function () {
        // trigger the animation
    });
}, 20);

I chose 20ms because it's larger than 1 frame at 60fps (16.7ms) and some browsers won't register timeouts <5ms.

Fingers crossed that should force the animation start into the next frame and then start it responsibly when the browser is ready to paint again.

Answer

Unlike Brendan, I found that requestAnimationFrame() worked in Chrome 63, Firefox 57, IE11 and Edge.

var div = document.createElement("div");
document.body.appendChild(div);

requestAnimationFrame(function () {
  div.className = "fade";
});
div {
  height: 100px;
  width: 100px;
  background-color: red;
}

.fade {
  opacity: 0;
  transition: opacity 2s;
}

Answer

I prefer requestAnimationFrame + setTimeout (see this post).

const child = document.createElement("div");
child.style.backgroundColor = "blue";
child.style.width = "100px";
child.style.height = "100px";
child.style.transition = "1s";

parent.appendChild(child);

requestAnimationFrame(() =>
  setTimeout(() => {
    child.style.width = "200px";
  })
);

Try it here.

Answer

setTimeout() works only due to race conditions, requestAnimationFrame() should be used instead. But the offsetWidth trick works the best out of all options.

Here is an example situation. We have a series of boxes that each need to be animated downward in sequence. To get everything to work we need to get an animation frame twice per element, here I put once before the animation and once after, but it also seems to work if you just put them one after another.

Using requestAnimationFrame twice works:

Works regardless of how exactly the 2 getFrame()s and single set-class-name step are ordered.

const delay = (d) => new Promise(resolve => setTimeout(resolve, d));
const getFrame = () => new Promise(resolve => window.requestAnimationFrame(resolve));

async function run() {
  for (let i = 0; i < 100; i++) {
    const box = document.createElement('div');
    document.body.appendChild(box);

    // BEFORE
    await getFrame();
    //await delay(1);

    box.className = 'move';
    
    // AFTER
    await getFrame();
    //await delay(1);
  }
}

run();
div {
  display: inline-block;
  background-color: red;
  width: 20px;
  height: 20px;
  
  transition: transform 1s;
}

.move {
  transform: translate(0px, 100px);
}

Using setTimeout twice fails:

Since this is race condition-based, exact results will vary a lot depending on your browser and computer. Increasing the setTimeout delay helps the animation win the race more often, but guarantees nothing.

With Firefox on my Surfacebook 1, and with a delay of 2ms / el, I see about 50% of the boxes failing. With a delay of 20ms / el I see about 10% of the boxes failing.

const delay = (d) => new Promise(resolve => setTimeout(resolve, d));
const getFrame = () => new Promise(resolve => window.requestAnimationFrame(resolve));

async function run() {
  for (let i = 0; i < 100; i++) {
    const box = document.createElement('div');
    document.body.appendChild(box);

    // BEFORE
    //await getFrame();
    await delay(1);

    box.className = 'move';
    
    // AFTER
    //await getFrame();
    await delay(1);
  }
}

run();
div {
  display: inline-block;
  background-color: red;
  width: 20px;
  height: 20px;
  
  transition: transform 1s;
}

.move {
  transform: translate(0px, 100px);
}

Using requestAnimationFrame once and setTimeout usually works:

This is Brendan's solution (setTimeout first) or pomber's solution (requestAnimationFrame first).

# works:
getFrame()
delay(0)
ANIMATE

# works:
delay(0)
getFrame()
ANIMATE

# works:
delay(0)
ANIMATE
getFrame()

# fails:
getFrame()
ANIMATE
delay(0)

The once case where it doesn't work (for me) is when getting a frame, then animating, then delaying. I do not have an explanation why.

const delay = (d) => new Promise(resolve => setTimeout(resolve, d));
const getFrame = () => new Promise(resolve => window.requestAnimationFrame(resolve));

async function run() {
  for (let i = 0; i < 100; i++) {
    const box = document.createElement('div');
    document.body.appendChild(box);

    // BEFORE
    await getFrame();
    await delay(1);

    box.className = 'move';
    
    // AFTER
    //await getFrame();
    //await delay(1);
  }
}

run();
div {
  display: inline-block;
  background-color: red;
  width: 20px;
  height: 20px;
  
  transition: transform 1s;
}

.move {
  transform: translate(0px, 100px);
}

Tags

Recent Questions

Top Questions

Home Tags Terms of Service Privacy Policy DMCA Contact Us

©2020 All rights reserved.