As the title implies, is there a proper way to set some initial CSS properties (or class) and tell the browser to transition these to another value?
For example (fiddle):
var el = document.querySelector('div'),
st = el.style;
st.opacity = 0;
st.transition = 'opacity 2s';
st.opacity = 1;
This will not animate the opacity of the element in Chrome 29/Firefox 23. This is because (source):
[...] you’ll find that if you apply both sets of properties, one immediately after the other, then the browser tries to optimize the property changes, ignoring your initial properties and preventing a transition. Behind the scenes, browsers batch up property changes before painting which, while usually speeding up rendering, can sometimes have adverse affects.
The solution is to force a redraw between applying the two sets of properties. A simple method of doing this is just by accessing a DOM element’s
offsetHeight
property [...]
In fact, the hack does work in the current Chrome/Firefox versions. Updated code (fiddle - click Run
after opening the fiddle to run animation again):
var el = document.querySelector('div'),
st = el.style;
st.opacity = 0;
el.offsetHeight; //force a redraw
st.transition = 'opacity 2s';
st.opacity = 1;
However, this is rather hackish and is reported to not work on some android devices.
Another answer suggests using setTimeout
so the browser has time to perform a redraw, but it also fails in that we don't know how long it will take for a redraw to take place. Guessing a decent number of milliseconds (30-100?) to ensure that a redraw occurred means sacrificing performance, unnecessarily idling in the hopes that the browser performs some magic in that little while.
Through testing, I've found yet another solution which has been working great on latest Chrome, using requestAnimationFrame
(fiddle):
var el = document.querySelector('div'),
st = el.style;
st.opacity = 0;
requestAnimationFrame(function() {
st.transition = 'opacity 2s';
st.opacity = 1;
});
I assume that requestAnimationFrame
waits until right before the beginning of the next repaint before executing the callback, hence the browser does not batch up the property changes. Not entirely sure here, but works nicely on Chrome 29.
Update: after further testing, the requestAnimationFrame
method does not work very well on Firefox 23 - it seems to fail most of the time. (fiddle)
Is there a proper or recommended (cross-browser) way of achieving this?
Triggering transitions You can trigger CSS transitions directly with pseudo classes like :hover (activates when the mouse goes over an element), :focus (activates when a user tabs onto an element, or when a user clicks into an input element), or :active (activates when user clicks on the element).
The solution is actually quite simple using JavaScript. To trigger an element's transition, toggle a class name on that element that triggers it. To pause an element's transition, use getComputedStyle and getPropertyValue at the point in the transition you want to pause it.
You can make the transition from no display to block display smooth by playing with the opacity property so that when the element is given the "show" class it animates from an opacity of 0 to an opacity of 1 like so.
CSS transitions are generally best for simple from-to movements, while CSS animations are for more complex series of movements. It's easy to confuse CSS transitions and animations because they let you do similar things. Here are just a few examples: You can visualize property changes.
There isn't a clean way at this moment (without using CSS Animations -- see the nearby answer by James Dinsdale for an example using CSS Animations). There is a spec bug 14617, which unfortunately wasn't acted upon since it was filed in 2011.
setTimeout
does not work reliably in Firefox (this is by design).
I'm not sure about requestAnimationFrame
-- an edit to the original question says it doesn't work reliably either, but I did not investigate. (Update: it looks like requestAnimationFrame
is considered at least by one Firefox core developer to be the place where you can make more changes, not necessarily see the effect of the previous changes.)
Forcing reflow (e.g. by accessing offsetHeight
) is a possible solution, but for transitions to work it should be enough to force restyle (i.e. getComputedStyle
): https://timtaubert.de/blog/2012/09/css-transitions-for-dynamically-created-dom-elements/
window.getComputedStyle(elem).opacity;
Note that just running getComputedStyle(elem)
is not enough, since it's computed lazily. I believe it doesn't matter which property you ask from the getComputedStyle, the restyle will still happen. Note that asking for geometry-related properties might cause a more expensive reflow.
More information on reflow/restyle/repaint: http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/
The situation has changed since 2013, so here's a new answer:
You could use Web Animations. They are implemented natively in Chrome 36 and Firefox 40 and there is a polyfill for all the other browsers.
Example code:
var player = snowFlake.animate([
{transform: 'translate(' + snowLeft + 'px, -100%)'},
{transform: 'translate(' + snowLeft + 'px, ' + window.innerHeight + 'px)'}
], 1500);
// less than 1500ms later...changed my mind
player.cancel();
You shouldn't need too much JavaScript to achieve what you want, just use CSS keyframes and animations for the same effect.
div {
opacity: 0;
}
div.fadeIn {
-webkit-animation: fadeIn 2s forwards;
animation: fadeIn 2s forwards;
}
@keyframes fadeIn {
0% {opacity: 0;}
100% {opacity: 1;}
}
@-webkit-keyframes fadeIn {
0% {opacity: 0;}
100% {opacity: 1;}
}
As shown in this JsFiddle it works either from page load (with class already added) or when dynamically adding the class to trigger the animation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With