Thanks for the high praise, now in regards to your issue, I wouldn’t call it a flaw in the library itself, but more so the implementation. In my example, every time you click the “Go” button your creating a new instance of FX which handles that animation and only that animation and is unaware of any other manipulation to the element.

Now you could use the callback to put together some simple queuing to manage this for you. For example, to make an element continually fade-in and fade-out you could do this:

function show(){
new FX(el, {opacity: {to: 1}}, 1, hide).start();
}

function hide(){
new FX(el, {opacity: {to: 0}}, 1, show).start();
}

It’s actually funny you mentioned this, because with the next version of the framework I am actually adding as a plugin an entire queuing system as well as a bunch of features to have more control over the element itself.

Thanks again, and check back in the next couple months for the next version which hopefully should solve your problems.

(http://ryanmorr.com/archives/fx-2-0-the-full-featured-animation-framework)

Here’s the deal… If you launch your example page, located at http://www.ryanmorr.com/tests/fx/, you’ll soon discover the issue by repetitively clicking on the “Go!” button. The animations continue to “queue up” until they each retire, causing some rather erratic behavior. It appears as though the $fx() lib accounts for this, which is why I’ve settled on it in the past.

The only way around this issue in other libs, that I’ve adopted in the past, is through killing any input method once the animation starts, then re-enabling input once it has completed. This keeps any contiguous attempts to start other animations on the same element until the current one completes. In other words, disable the button once it is clicked, and only enable it again in the callback.

Any *other* way around this? Can your lib effectively “kill” any current animations for a given element upon starting a new one on that element? I plan on combing through your code in a moment to see if I can extend it to catch such issues, but wanted to drop a line beforehand.

Regardless… Thanks for the top-notch contribution to the community.

The link seems to work for me. You might want to try downloading the newer version of this framework just released a few days ago.

It looks like the link to compressed.js is down, when you have a moment could you look into this?

Thanks
Alex

Honestly, not only can I not believe I didn’t notice that, but I’m not sure I ever even knew that. Apparently I don’t know JavaScript prototypes as well as I thought I did.

I would consider this a bug, and therefore will not wait until version 2 to make this change.

Thanks for the heads up!

var fx2 = new FX(‘bar2′, {
‘left’: { from: 0, to: 150 }
});
fx2.play();

Here, a property called frame is a pointer to an Object containing one style “left” with value 100.
Because frame is a reference value, both instances of FX point to the same Object. This means that when
“150” is added to fx2.frame, it is also reflected in fx1.frame.

I see what your driving at… you want easing capabilities, don’t worry, its coming.

Aside from that, I don’t see much difference between your implementation and mine other than moving “frame”, “endAttr”, and “startAttr” into the constructor.

Not sure what the difference is. Is their a particular reason why you’ve done this?

this.FX = function(el, attributes, opt) {
this.el = DOM.get(el);
this.attributes = attributes;
this.duration = opt.duration || 0.7;
this.tweenType = opt.tweenType || “Sine”;
this.easeType = opt.easeType || “easeInOut”;
this.callback = opt.callback || function() { };
this.ctx = opt.ctx || window;

/**
* The object to carry the current values for each frame
* @type Object
*/
this.frame = {},

/**
* The object containing all the ending values for each attribute
* @type Object
*/
this.endAttr= {},

/**
* The object containing all the starting values for each attribute
* @type Object
*/
this.startAttr= {};
};