Bug 27159 - Unsetting an object's transition property to restyle it without animating doesn't work
: Unsetting an object's transition property to restyle it without animating doe...
Status: UNCONFIRMED
: WebKit
CSS
: 528+ (Nightly build)
: Macintosh Intel Mac OS X 10.5
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-07-10 14:34 PST by
Modified: 2010-06-14 14:04 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-07-10 14:34:30 PST
Created an attachment (id=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 From 2009-07-10 14:40:35 PST -------
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 From 2009-08-10 14:17:39 PST -------
This doesn't work because of style batching (which every browser does). The setTimeout is a reasonable workaround.
------- Comment #3 From 2009-08-10 14:24:08 PST -------
Then can we maybe have some API or some not-so-hideous way of performing an update without going through a transition?
------- Comment #4 From 2010-06-10 19:38:50 PST -------
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 From 2010-06-10 19:56:02 PST -------
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 From 2010-06-11 12:23:04 PST -------
(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 From 2010-06-11 12:34:53 PST -------
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 From 2010-06-11 13:07:46 PST -------
Calling document.body.offsetWidth will force a style update and layout, but doing so repeatedly is very expensive.
------- Comment #9 From 2010-06-14 14:04:12 PST -------
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.