触发附加元素的 CSS 转换

正如 这个问题所观察到的,在新添加的元素上立即的 CSS 转换以某种方式被忽略——转换的结束状态被立即呈现。

例如,给定这个 CSS (这里省略了前缀) :

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


.box.in { opacity: 1; }

该元素的不透明度将立即设置为1:

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

我已经看到了几种触发这种转变以获得预期行为的方式:

// 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');

同样的方法也适用于普通的 JSDOM 操作——这不是特定于 jQuery 的行为。

编辑-我正在使用 Chrome 35。

JSFiddle (包括香草 JS 示例)。

  • 为什么忽略附加元素上的即时 CSS 动画?
  • 这些方法如何以及为什么起作用?
  • 还有别的方法吗
  • 如果有的话,哪一个是首选的解决方案?
50930 次浏览

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.

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.

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';

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.

@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;

Edit: the technique used in the original answer, below the horizontal rule, does not work 100% of the time, as noted in the comments by mindplay.dk.

Currently, if using requestAnimationFrame(), pomber's approach is probably the best, as can be seen in the article linked to in pomber's answer. The article has been updated since pomber answered, and it now mentions requestPostAnimationFrame(), available behind the Chrome flag --enable-experimental-web-platform-features now.

When requestPostAnimationFrame() reaches a stable state in all major browsers, this will presumably work reliably:

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


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


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

For the time being, however, there is a polyfill called AfterFrame, which is also referenced in the aforementioned article. Example:

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


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


.fade {
opacity: 0;
transition: opacity 2s;
}
<script src="https://unpkg.com/afterframe/dist/afterframe.umd.js"></script>


Original 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;
}

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.

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);
}

Anything fundamentally wrong with using keyframes for "animate on create"?

(if you strictly don't want those animations on the initial nodes, add another class .initial inhibitin animation)

function addNode() {
var node = document.createElement("div");
var textnode = document.createTextNode("Hello");
node.appendChild(textnode);


document.getElementById("here").appendChild(node);
}


setTimeout( addNode, 500);
setTimeout( addNode, 1000);
body, html { background: #444; display: flex; min-height: 100vh; align-items: center; justify-content: center; }
button { font-size: 4em; border-radius: 20px; margin-left: 60px;}


div {
width: 200px; height: 100px; border: 12px solid white; border-radius: 20px; margin: 10px;
background: gray;
animation: bouncy .5s linear forwards;
}


/* suppres for initial elements */
div.initial {
animation: none;
}


@keyframes bouncy {
0% { transform: scale(.1); opacity: 0 }
80% { transform: scale(1.15); opacity: 1 }
90% { transform: scale(.9); }
100% { transform: scale(1); }
}
<section id="here">
<div class="target initial"></div>
</section>