Bug 27159 - Unsetting an object's transition property to restyle it without animating doesn't work
Summary: Unsetting an object's transition property to restyle it without animating doe...
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-10 14:34 PDT by Neven Mrgan
Modified: 2022-07-11 16:51 PDT (History)
5 users (show)

See Also:


Attachments
Example document (963 bytes, text/html)
2009-07-10 14:34 PDT, Neven Mrgan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neven Mrgan 2009-07-10 14:34:30 PDT
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".
Comment 1 Neven Mrgan 2009-07-10 14:40:35 PDT
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;
    }
Comment 2 Simon Fraser (smfr) 2009-08-10 14:17:39 PDT
This doesn't work because of style batching (which every browser does). The setTimeout is a reasonable workaround.
Comment 3 Andy Matuschak 2009-08-10 14:24:08 PDT
Then can we maybe have some API or some not-so-hideous way of performing an update without going through a transition?
Comment 4 Andrew Dupont 2010-06-10 19:38:50 PDT
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.
Comment 5 Simon Fraser (smfr) 2010-06-10 19:56:02 PDT
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.
Comment 6 Andrew Dupont 2010-06-11 12:23:04 PDT
(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.
Comment 7 Thomas Fuchs 2010-06-11 12:34:53 PDT
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.
Comment 8 Simon Fraser (smfr) 2010-06-11 13:07:46 PDT
Calling document.body.offsetWidth will force a style update and layout, but doing so repeatedly is very expensive.
Comment 9 Andrew Dupont 2010-06-14 14:04:12 PDT
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.
Comment 10 Brent Fulgham 2022-07-11 16:51:11 PDT
Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.