Easier positional parameter to align finishes (syntactic sugar)

[Spymastermatt]

I was just wondering if the devs would be open to the idea of >| as syntactic sugar for >-=100% for aligning the ends of animations in a timeline?

I'm happy to implement it if it's something that might be considered.

[Rodrigo]

Hi,

 

Exactly what you're trying to do? How you want to align the instances in a timeline?

 

The position parameter is super robust and battle tested so I can safely say that it should accommodate most of the needs of almost every case I can think of.

 

If you can can please provide a minimal demo as well.

 

As for changing the API, we're very careful about that especially if doing so could create extra KB overhead or performance issues. I'm quite sure that it might not be the case with this request, but still making changes is not something that is done without some evaluation.

 

Happy Tweening!

[GreenSock]

So you're saying that you want to add yet another way to do this?: ">-=100%" by using ">|"? Seems a bit odd to me, honestly, although I love how concise and visual it is. I wonder how many people then might ask "why isn't there a "<|"? And "does '|' always mean -=100% in GSAP now?" 

 

Honestly, if you find yourself using that value a lot and don't want to type it as much or if you don't think it's intuitive enough, you could just create a variable like: 

const ALIGN_ENDS = ">-=100%";

And then plug that in wherever you need it. Just a thought. 

[Spymastermatt]

Fair enough.

 

I was largely because at first I spotted that I was able to use < for aligning starts and > for aligning start of B with end of A, but felt that the use of <-=100% was:

A ) Less visual and concise compared to the other 2

B ) A source of confusion, since the docs have to very explicitly state the difference between >-100% and >-=100%.

 

I was also thinking that >| as "align ends" could then be used like the other 2 arrows, i.e. I could now do >|+50%, which would align B's mid point with the end of the previous animation.

 

I understand though the desire to keep the codebase small (an uncomplicated) for performance and maintenance purposes and what I'm proposing definitely isn't necessary.