Invert: Bad parameter.

[aslilac]

It would seem that the invert property is helpful and convenient. It's not.

It's not needed, and limits what the user thinks can be done with Plax.

Not needed

I say it's not needed, because the same effect can be achieved with a little less code.

Instead of..

$('#id').plaxify({ 'xRange': 50, 'yRange': 50, invert: true });

..you could just do..

$('#id').plaxify({ 'xRange': -50, 'yRange': -50 });

Limits what the user thinks can be done

Now what could I possibly mean by this?

It makes the user feel like inversion is all or nothing.

You can actually invert just one axis. This wouldn't be true parallaxing, but if the user just wants to use the plugin to move stuff around, then why not let them?

Say you want only x to be disobedient..

 $('#id').plaxify({ 'xRange': -50, 'yRange': 50 });

..then that would do the trick for you.

Cleaner code

I also noticed that you use a lot of if (invert) statements, that could be avoided if you removed the parameter.

It would break the API for a few people, and a few of your use cases, but I think it overall improves usability.

[cameronmcefee]

I'll admit, you have a valid argument. However, it goes against my core goal for Plax. My original intention was to provide the quickest, most math-less way for both coders and non-coders to do realistic parallaxing. The invert parameter takes out the mathematical guesswork that a non-coder would have to do to come up with inverting the directions. Granted, it seems like a small issue, but if you think about the idea of a negative range from a non-mathematical perspective, it doesn't really make sense, especially with how Plax calculates.

Plax assumes that the start position of the item is the center point of that range, so by saying 50 px you are actually saying 25 px in either direction. This is a relatively natural thing to assume or at least accept while it's a positive value, but when specifying -50 px, my first inclination would be to assume that it would travel -50 px backward from it's start point, rather than invert the direction in which it travels.

For this reason, as well as avoiding breaking current implementations, I prefer to retain the invert parameter. You did, however, raise a good point about limiting what the user thinks they can do with the script. For that reason, I'll update the docs to indicate that negative values will have the same/customizable effects. I'd rather provide the user the quickest means to an end on the surface, and provide the customizability only if they need it.

[aslilac]

Alright. Some people with less experience working with numbers then me might not see how that would work, so it'd be very nice to have that in the docs.

Rather then look at it as negative 50 pixels, I prefer to look at it as 50 pixels inverted, which isn't really correct, but it makes more sense in the circumstance and I think it's just a little more elegant. I guess it's nice to leave invert there anyway, for someone who finds that the more elegant solution.

In the end, what matters is making it easy for every one, and as long as both inversion methods can be implemented together, they might as well be. Your plugin inspired me to make my own for the library I use, and I opted to exclude any sort of direct invert parameter, so I just thought I'd bring it up, see what you think.