Closed
Bug 1068965
Opened 11 years ago
Closed 11 years ago
CSS transition ignored when adding element to DOM and animating after requestAnimationFrame
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: mikehenrty, Unassigned)
Details
If I add an element to the DOM and then change a css property with a transition to that element on the next animation frame, the transition is ignored in gecko. The animation is not ignored in the latest blink or webkit it seems. Oddly, using setTimeout instead of requestAnimationFrame below 10ms doesn't work most of the time, but above 10ms it seems to always animate. Pasting test case below.
Test case:
<!doctype html>
<html>
<head>
<style>
.progress {
background-color: blue;
height: 10px;
width: 0%;
transition: width linear 2s;
}
.progress.full {
width: 100%;
}
</style>
</head>
<body>
<button id="button">Add</button>
<script>
var button = document.getElementById('button');
button.onclick = function() {
var progress = document.createElement('div');
progress.classList.add('progress');
document.body.appendChild(progress);
// add transition triggering animation on next frame
requestAnimationFrame(function() {
progress.classList.add('full');
});
};
</script>
</body>
</html>
I don't think it's related; I also wouldn't have expected it to work. Why should we have computed style by the time the requestAnimationFrame callback has happened -- it's there so that script can do things before the work we do in that refresh tick happens, right?
Flags: needinfo?(dbaron)
(It would be interesting to know why it works in Blink and WebKit, certainly.)
|
Reporter | |
Comment 4•11 years ago
|
||
(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #2)
> I don't think it's related; I also wouldn't have expected it to work. Why
> should we have computed style by the time the requestAnimationFrame callback
> has happened -- it's there so that script can do things before the work we
> do in that refresh tick happens, right?
Hmm, my thought was that the page would not repaint (and thereby call the requestAnimationFrame callback) until the new element was added to the layout and rendered to the screen. Would you say this bug is invalid then?
Also, do you know if there is a preferred way to add an element to the screen and then animate it? It seems right now the amount of time you have to wait after adding an element to the DOM before changing a css property to get a transition to trigger is ~10ms. But it is indeterminate.
Flags: needinfo?(dbaron)
|
|
||
Comment 5•11 years ago
|
||
> Hmm, my thought was that the page would not repaint (and thereby call the
> requestAnimationFrame callback)
The callback happens _before_ the repaint. That's the whole point.
> Would you say this bug is invalid then?
Imo, yes.
Note that there is a movement to actually specify this stuff; we'll see how that goes.
> Also, do you know if there is a preferred way to add an element to the screen and then
> animate it?
The simplest way is to add it, then wait two rAF ticks.
|
|
Reporter | |
Comment 6•11 years ago
|
||
Thanks for the info David and Boris.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(dbaron)
Resolution: --- → INVALID
I still think it's worth figuring out why this works in Blink and WebKit.
|
|
||
Comment 8•11 years ago
|
||
Blink used to have a style recomputation timer independent of requestAnimationFrame, as far as I know. WebKit might still have that...
That makes sense, at least if it's still true for both Blink and WebKit.
|
|
||
Comment 10•11 years ago
|
||
It's not longer entirely true for Blink; I can't quite figure out what their new setup looks like and how things are ordered in it.
You need to log in
before you can comment on or make changes to this bug.
Description
•