Jump to content
Search Community

Tween custom property changed between 1.6 and 1.8?

Imager test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I have been using GSAP on a recent web-site development to which I planned on giving a speed boost by applying the latest version of GSAP. I modified my code to support the latest changes in the API, but couldn't get the following code to work anymore.

 

// worked on 1.6.4.

// obj is a <img> node fetched with jquery
obj[0].currentFrame = 1;

var tLine = new TimelineMax({repeat:-1});
tLine.fromTo(obj, animationDuration,{currentFrame:1},{currentFrame:parseInt(fc)+3, onUpdate:animation, onUpdateParams:[obj], ease:Linear.easeNone}); 
 

 

Previously this tween set and changed the currentFrame property accordingly, but 1.8.x doesn't. Did I miss something down the line?

 

Thanks,

 

-Teemu

Link to comment
Share on other sites

First, let me give you the simple solution: add "autoCSS:false" to your vars. 

 

tLine.fromTo(obj, animationDuration,{currentFrame:1, autoCSS:false},{currentFrame:parseInt(fc)+3, onUpdate:animation, onUpdateParams:[obj], ease:Linear.easeNone, autoCSS:false});
 

Now for the explanation...

 

 

At its core GSAP is an extremely flexible tweening engine that isn't just for animating DOM elements - it can tween ANY numeric property of ANY object. To do special stuff (like handling DOM element styles), plugins are used, like CSSPlugin. When we originally launched GSAP, if you wanted to animate DOM element styles, you had to wrap those properties in a css:{} object to clarify your intent (like {css:{left:100, top:20}}). This made a lot of sense in terms of raw logic, but we came to realize that since it is SO common to animate DOM element styles, the css:{} wrapper degraded usability and made mistakes a bit more common (like people nesting things incorrectly, like an onComplete or ease inside the css:{} instead of outside). Therefore, in version 1.8.0 we added some logic to the TweenLite core that allows you to skip the css:{} wrapper. See http://www.greensock.com/update-2013-01/ for details.

 

Basically, it will check to see if the target is a DOM element and the CSSPlugin is loaded and you did NOT define a css wrapper - if all of those conditions are true, it assumes your intent is to animate css styles of the target and it creates the css:{} wrapper for you internally, passing the non-reserved values to CSSPlugin to animate. This is a boon for productivity because it shortens your code and reduces nesting errors. However, if you're trying to tween non-css values of a DOM element (which is what you're doing here - currentFrame is obviously a made-up property) and you loaded the CSSPlugin (it's inside TweenMax), then it ends up treating non-css properties as if they're css, thus not giving you the results you want.

 

 

The solution is to simply pass autoCSS:false into your vars object which tells it not to automatically create the css wrapper for you. Either that or you can create an empty css:{} wrapper so that it understands the delineation between css props and non-css props of your DOM element. We didn't want to create an internal dictionary of all valid css properties and check against those because not only would it degrade performance (checking every property against the dictionary for every tween), but it'd also mean that as new features become available in the future inside the browser, they wouldn't get recognized by CSSPlugin. We'd rather have a very flexible system that can handle just about anything you throw at it.

 

In version 1.8.3 (which will be released soon), I added another conditional check so that if the element has a property defined, it won't get added to the css:{} object which should resolve your problem here too, thus autoCSS probably won't be necessary for you in 1.8.3 (although it's perfectly acceptable to leave in). 

 

Does that clear things up?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...