Jump to content
Search Community

"+=n" vs "+n"

Dave Stewart 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

Hi Jack,

 

Was just wondering why we need to write "+=100" rather than just "+100".

 

(This is going to be "one of those" posts)

 

I looked through the TweenMax docs, and there wasn't one example where a value passed as a string wasn't relative. So my assumption would be that string values would always be relative

 

I threw my assumptions

See the Pen Gjoap by davestewart (@davestewart) on CodePen

and it looks like string values consisting of only numbers, such as "100" are parsed to numbers, so absolute, not relative.

 

String values consisting of "-=" or "+=" such as "+=100" are calculated relatively.

 

But what about string values consisting of leading "-" or "+" symbols, such as "+100" ? Parsed to 0.

 

So my thoughts are, what about assuming signed strings are relative, and allowing the developer to optionally drop the "=" ?

 

Consider:

// existing absolute
TweenMax.to(el, 1, {x:100});
TweenMax.to(el, 1, {y:'100'});

// existing relative
Tweenmax.to(el, 1, {x:'+=100'});
TweenMax.to(el, 1, {y:'-=100'});

// proposed relative
TweenMax.to(el, 1, {x:'+100'});
TweenMax.to(el, 1, {y:'-100'});


The only issue would be if someone was passing negative strings such as "-100" in existing code, which would be cast to a Number, I think, by TweenPlugin._addTween().

 

This is the backwards-compatibility flaw in my carefully thought-out plan. But then one has to question why a developer would be passing strings as numbers in the first place.

 

Anyhoo, it would make it just that little bit easier to write and read multiple sequential tweens.

 

Thoughts?

 

Cheers,

Dave

Link to comment
Share on other sites

Hi Dave,

 

Thanks for the thoughtful suggestion. 

 

IMHO I think it would be too confusing as these tweens would have different results

//assuming the pre-tween left is 500px

TweenMax.to(el, 1, {left:'-100'});//relative ends at 400
TweenMax.to(el, 1, {left:'-100px'});//absolute ends at -100

I think its better to stay consistent with the "+=" and "-=" than to have people deal with remembering that the behavior changes when they specify the units. 

 

Although "+=" and "-=" require more typing, I feel that they more clearly establish the developer's intent.

 

Thanks again for the suggestion. Please let me know if I misunderstood something or if you need more explanation.

  • Like 4
Link to comment
Share on other sites

Yup, the Getting Started Guide discusses how to specify units

 

You can even define properties that are not generally tweenable and GSAP will apply the property for you (like position:”absolute” or borderStyle:”solid”). It is typically a good idea to define a unit of measurement (like “24px” instead of “24″ or “50%” rather than “50″) but the default in most cases is pixels (px), so you can omit the unit if you prefer. And even if the unit of measurement doesn’t match the current one, GSAP will attempt to convert them for you. So, for example, you could tween a width from “50%” to “200px”.

 

Link to comment
Share on other sites

Yep, in addition to Carl's excellent point about units, there are a few other things to keep in mind:

  1. The "+=" and "-=" are somewhat universally recognized as relative. jQuery uses that as do many other libraries.
  2. When quickly reading through code, I think it's much more likely that people will recognize "-=100" as relative than '-100'.
  3. Some values need to be strings even if you're not defining units. For example, clip:"rect(0, 0, -100, 0)" which is very different than clip:"rect(0, 0, -=100, 0)". 
  4. Some people parse JSON files and feed those values in to tweens they create, and JSON values are typically read in as Strings (which has nothing to do with GSAP of course). If we implemented your suggestion, it would force people to always wrap numeric values in parseFloat() or parseInt() or Number(). That could get annoying because they'd have to inspect each value to know what it's supposed to be ("is this property supposed to be numeric? Does it have a suffix? Is it complex like clip:rect(....)?")
  • Like 2
Link to comment
Share on other sites

Sure. It makes sense to use this in the wider context of units.

 

It's kinda difficult to glean everything from some of the rather long WordPress-themed pages, in this case namely that strings are required to declare units, rather than just relativity.

 

Thanks for the input.

Link to comment
Share on other sites

PS. Having written the xJSFL selectors library, I know what it is like to parse complex user-provided symbolic references!

 

https://github.com/davestewart/xjsfl/blob/master/core/jsfl/libraries/elements/Selectors.jsfl#L157

 

And in the same vein as your clip() example above, here's an example of numeric ranges within attributes:

 

http://www.xjsfl.com/support/api/elements/selectors#pattern-matching

 

Having a flexible yet reliable syntax is key.

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...