Bug 27159 – Unsetting an object's transition property to restyle it without animating doesn't work

• Component: CSS
• Status: RESOLVED CONFIGURATION CHANGED

[Neven Mrgan]

Created attachment 32579 [details]
Example document

When an object has a transition defined on a property, it would be helpful to be able to change that property without animating. The obvious solution would be to set the object's transition property to "none", set the desired properties, then re-set the transition. Unfortunately, because of concurrency or other issues, this method does nothing. As illustrated in the attached example, the object will continue animating even after the transition has been set to "none".

[Neven Mrgan]

Re-setting the transition property in a timeout - even at 0 ms - will make the setting/unsetting work as expected.

    function moveBack()
    {
    	document.getElementById('obj').style.webkitTransition = 'none';
	    document.getElementById('obj').style.webkitTransform='translateX(0px)';
	    setTimeout('document.getElementById("obj").style.webkitTransition = "-webkit-transform .5s linear";', 0);
	    i = 0;
    }

[Simon Fraser (smfr)]

This doesn't work because of style batching (which every browser does). The setTimeout is a reasonable workaround.

[Andy Matuschak]

Then can we maybe have some API or some not-so-hideous way of performing an update without going through a transition?

[Andrew Dupont]

I second Andy's request.

JavaScript animation libraries often have to chain multiple effects together, and on firing of "webkitTransitionEnd" would need to (a) reset any transition-related style properties; (b) set new values for those same properties for the next effect in the queue.

Currently, (a) and (b) can't be done together; (b) must be deferred with a "setTimeout" call, at which point the animation library loses the rigid control of timing that is so important to keep things working properly.

[Simon Fraser (smfr)]

This is expected behavior because of the way that the browser batches style changes. This behavior is common to all the major browsers.

I agree that it can be annoying with transitions, but the alternative would be to force expensive style updates when transition properties change, that we don't want to do that.

[Andrew Dupont]

(In reply to comment #5)
> This is expected behavior because of the way that the browser batches style changes. This behavior is common to all the major browsers.
> 
> I agree that it can be annoying with transitions, but the alternative would be to force expensive style updates when transition properties change, that we don't want to do that.

Simon, I understand as much. I think this will need to be addressed one way or another (and not only in WebKit) as an unintended consequence of how CSS transitions work.

Before now, style batching had no real downside, because:
(a) the order in which style properties were set (within a batch) made no real difference;
(b) no property change behaved in a different way based on the _current value_ of a completely different property.

Anyway, I'm not suggesting that the browser should force expensive style updates by default; it would simply be nice to be able to trigger such an update if you think it's necessary — or otherwise be able to create your own "batches," each of which would be applied atomically.

Another option would be a first-class JavaScript interface to transitions and animations, rather than having to set style properties.

[Thomas Fuchs]

I concur with Andrew that an API call to force the browser to apply style changes would be helpful, for example an "render" call (or some other method name) on the style property of an element.

(In reply to comment #6)
> (In reply to comment #5)
> > This is expected behavior because of the way that the browser batches style changes. This behavior is common to all the major browsers.
> > 
> > I agree that it can be annoying with transitions, but the alternative would be to force expensive style updates when transition properties change, that we don't want to do that.
> 
> Simon, I understand as much. I think this will need to be addressed one way or another (and not only in WebKit) as an unintended consequence of how CSS transitions work.
> 
> Before now, style batching had no real downside, because:
> (a) the order in which style properties were set (within a batch) made no real difference;
> (b) no property change behaved in a different way based on the _current value_ of a completely different property.
> 
> Anyway, I'm not suggesting that the browser should force expensive style updates by default; it would simply be nice to be able to trigger such an update if you think it's necessary — or otherwise be able to create your own "batches," each of which would be applied atomically.
> 
> Another option would be a first-class JavaScript interface to transitions and animations, rather than having to set style properties.

[Simon Fraser (smfr)]

Calling document.body.offsetWidth will force a style update and layout, but doing so repeatedly is very expensive.

[Andrew Dupont]

Awesome! That's good enough for my purposes.

(In reply to comment #8)
> Calling document.body.offsetWidth will force a style update and layout, but doing so repeatedly is very expensive.

[Brent Fulgham]

Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.