Share Posted January 7, 2015 When you animate the width of an element expressed as a percentage fractions with zeros to the right, the animation is not performed correctly. See the Pen EaZaJO by angel-teran (@angel-teran) on CodePen Link to post Share on other sites
Share Posted January 7, 2015 Hello angel.teran, and Welcome to the GreenSock Forum! Have you tried using autoRound:false in your tween? .. It is part of the GSAP CSSPlugin: Working example: See the Pen yygNyj by jonathan (@jonathan) on CodePen autoRoundBy default, CSSPlugin will round pixel values and zIndex to the closest integer during the tween (the inbetween values) because it improves browser performance, but if you'd rather disable that behavior, pass autoRound:false in the css object. You can still use the RoundPropsPlugin to manually define properties that you want rounded.:: $(function() { var tl = new TimelineLite(); tl.to("#lifebar > b", 1, { autoRound:false, /* add this */ width: "50.5%", ease: Linear.easeNone }); tl.to("#lifebar > b", 1, { autoRound:false, /* add this */ width: "100%", ease: Linear.easeNone }); tl.to("#lifebar > b", 1, { autoRound:false, /* add this */ width: "50.50%", ease: Linear.easeNone }); }); : Feel free to check out the CSSPlugin Docs. Hope this helps! 1 Link to post Share on other sites
Author Share Posted January 7, 2015 Hi Jonathan, thank you very much for your quick response! But the problem doesn't seem to be resolved. The first part of the animation is successful (width: 50.5%), but the latter does not (width: 50.50%), the only difference is a 0 at the end of the value. I think that is a correct value which should not cause problems. Link to post Share on other sites
Share Posted January 7, 2015 Hmm.. I tested the above in Firefox 34 on Windows 7 (64-bit) and the animation became smooth. Which browser and browser version are you seeing this on? Which OS and OS version are you seeing this on? Until then you could try animating scaleX instead of width.. so this way it will animate on a sub-pixel level by default since its a CSS transform. See the Pen pvRJeZ by jonathan (@jonathan) on CodePen This one uses TimelineMax: See the Pen RNKPLo by jonathan (@jonathan) on CodePen The above example uses scaleX to animate a progress bar with the GSAP onUpdate special property: More info at the GSAP JS Documentation pages: TweenMax TweenLite TimelineMax TimelineLite Plugins Thanks! Link to post Share on other sites
Share Posted January 7, 2015 It certainly seems like you're reporting a legitimate bug here. It occurs with other units too e.g. "50.50px". Looks like there's a small error in the value parser. Once the big guy sees this I'm sure he'll be able to weigh in. 1 Link to post Share on other sites
Share Posted January 7, 2015 I see why it's happening, and yes, it's only because you're adding extra zeros to the right which is breaking the pattern-finding algorithm that was written to prioritize speed. I can switch to using a regular expression and it shouldn't impact things too terribly much speed-wise, but it's a bit of a bummer to have to do that. I'm curious - why are you passing in numbers with extra zeros? 1 Link to post Share on other sites
Author Share Posted January 8, 2015 Hi guys! Thank you very much for keeping an eye on my problem. I'm using toFixed(x) function of Number to truncate a decimal number and sometimes leaves zeros on the right. Your library is awesome, thank you very much for your work. Link to post Share on other sites
Share Posted January 8, 2015 (edited) Hi angel.teran you can use one of these methods to remove extra zeros : var n = 1.2045000000 var noZeroes = n.toString() // = 1.2045 or var n = "1.2045000000" var noZeroes = parseFloat(n) // = 1.2045 Edited January 8, 2015 by jamiejefferson Numbers automatically truncate the extra zeroes (ex 1). parseFloat converts Strings to Numbers, truncating the zeroes (ex 2). Link to post Share on other sites
Author Share Posted January 8, 2015 Thank you very much Diaco.AW!, parseFloat() solves my problem very well Link to post Share on other sites