27159 2009-07-10 14:34:30 -0700 Unsetting an object's transition property to restyle it without animating doesn't work 2022-07-11 16:51:11 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Mac (Intel) OS X 10.5 RESOLVED CONFIGURATION CHANGED P2 Normal --- 0 neven.mrgan webkit-unassigned andy bfulgham simon.fraser thomas webkit oldest_to_newest 130962 0 32579 neven.mrgan 2009-07-10 14:34:30 -0700 Created attachment 32579 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". 130965 1 neven.mrgan 2009-07-10 14:40:35 -0700 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; } 138818 2 simon.fraser 2009-08-10 14:17:39 -0700 This doesn't work because of style batching (which every browser does). The setTimeout is a reasonable workaround. 138821 3 andy 2009-08-10 14:24:08 -0700 Then can we maybe have some API or some not-so-hideous way of performing an update without going through a transition? 236650 4 webkit 2010-06-10 19:38:50 -0700 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. 236653 5 simon.fraser 2010-06-10 19:56:02 -0700 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. 236966 6 webkit 2010-06-11 12:23:04 -0700 (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. 236977 7 thomas 2010-06-11 12:34:53 -0700 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. 236991 8 simon.fraser 2010-06-11 13:07:46 -0700 Calling document.body.offsetWidth will force a style update and layout, but doing so repeatedly is very expensive. 238035 9 webkit 2010-06-14 14:04:12 -0700 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. 1882232 10 bfulgham 2022-07-11 16:51:11 -0700 Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains. 32579 2009-07-10 14:34:30 -0700 2009-07-10 14:34:30 -0700 Example document test.html text/html 963 neven.mrgan PGh0bWw+CjxoZWFkPgogICAgPHRpdGxlPlRlc3Q8L3RpdGxlPgogICAgPG1ldGEgaHR0cC1lcXVp dj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPiAgICAK ICAgIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+CiAgICAKICAgICNvYmogewogICAgCXdpZHRoOiAx MDBweDsKICAgIAloZWlnaHQ6IDEwMHB4OwogICAgCQogICAgCQogICAgCS13ZWJraXQtdHJhbnNp dGlvbjogLXdlYmtpdC10cmFuc2Zvcm0gLjVzIGxpbmVhcjsKICAgIH0KICAgIAogICAgPC9zdHls ZT4KICAgIDxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4KICAgIAogICAgdmFyIGkgPSAw OwogICAgZnVuY3Rpb24gc2xpZGVSaWdodCgpCiAgICB7CiAgICAJaSArPSA1OwogICAgCWRvY3Vt ZW50LmdldEVsZW1lbnRCeUlkKCdvYmonKS5zdHlsZS53ZWJraXRUcmFuc2Zvcm0gPSAndHJhbnNs YXRlWCgnICsgaSArICdweCknOwogICAgfQogICAgCiAgICBmdW5jdGlvbiBtb3ZlQmFjaygpCiAg ICB7CiAgICAJZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ29iaicpLnN0eWxlLndlYmtpdFRyYW5z aXRpb24gPSAnbm9uZSc7CgkgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ29iaicpLnN0eWxl LndlYmtpdFRyYW5zZm9ybT0ndHJhbnNsYXRlWCgwcHgpJzsKCSAgICBkb2N1bWVudC5nZXRFbGVt ZW50QnlJZCgnb2JqJykuc3R5bGUud2Via2l0VHJhbnNpdGlvbiA9ICctd2Via2l0LXRyYW5zZm9y bSAuNXMgbGluZWFyJzsKCSAgICBpID0gMDsKICAgIH0KICAgIAogICAgPC9zY3JpcHQ+CjwvaGVh ZD4KPGJvZHkgb25sb2FkPSJzZXRJbnRlcnZhbCgnc2xpZGVSaWdodCgpJywgNTAwKTsiPgoKCTxk aXYgaWQ9Im9iaiI+bW92aW5nPC9kaXY+CgkKCTxpbnB1dCB0eXBlPSJidXR0b24iIHZhbHVlPSJN b3ZlIEJhY2siIG9uY2xpY2s9Im1vdmVCYWNrKCkiIC8+CgkKPC9ib2R5Pgo8L2h0bWw+