TranslateY only

[iDad5]

I want the center Element to go to the very top get smaller but stay in the center. I very much would like to keep the CSS / DOM structure that way, as I need it in my more complex project organized that way.

 

I tried to animate the center element from transform: translate(-50%, 50%) to transform: translate(-50%, 0%) but it always ended up ad translate(0%,  0%).
I searched around a while and understood that percentage Values in translate are at least trick, but some of the information I found was quite old and so I decided to go ahead and ask. Could someone point me in the right direction please. thx

See the Pen zYoeXjP by mdrei (@mdrei) on CodePen

[PointC]

gsap.to("#center", { duration: 1, top: 0, width: "20%", yPercent: -50 });

 

[iDad5]

Thanks a lot Craig.

[ZachSaucier]

Also keep in mind that avoiding animating width, height, top, left, etc. properties to improve performance when you can is a good idea.

[iDad5]

Thank you for the reminder, but in this case I think the tradeoff is acceptable. 

[iDad5]

Me again. I didn't work Craig's solution into me project yesterday, and when I did I found, that it didn't work as I hoped for. The reason is that my actual 'center'-element has no fixed width, but scales it's height proportional. The yPercentage solution seems to measure the height at the beginning and adds an additional translate in pixels to the percentages.
Is there a way to actually end with (only) a translate value of (-50%, 0%) or should I try to go for a onUpdate  function?

[PointC]

I guess I'm confused. What does the width have to do with the yPercentage?

 

Do you have a new demo of the problem?

[iDad5]

Thank You for your Help. 

FYI: I solved the current situation in my project be reworking it to 'vw' units, but that won't work for me under other circumstance. So im still interested in understanding the problem.

 

While trying to build / rework the example I found another very astonishing thing, which might be of interesst before we go about the slightly more complex situation where '#center' has a height that is proportional to its' width:

My original attempt works as expected  in Safari. After the tween finished the element in the inspector reports (in CodePen):

<div id="center" style="transform: translate(-50%, 0%); width: 20%; top: 0%;"></div>

and the element is at the position and size it should be.

In Chrome on Mac as in Chrome on Windows as in FF and Edge on Windows the exact same CodePen reports after finishing the tween:

<div id="center" style="transform: translate(0px, 0px); width: 20%; top: 0%;"></div>

And therefore sits not at the center but starts with its's left edge at the center.

That looks somehow like a bug to me, or am I getting something wrong?

 

 

[PointC]

I'm on PC so I can't test Safari, but if it were me, I'd set all my transforms with GSAP rather than the CSS. I'd also use xPercent and yPercent.

 

Please try that and see if you get consistent results in all browsers.

[iDad5]

That is unfortunately not really a good option for me in most cases. My layouts usually work up to a certain body width (often 1920px nowadays) and scale with percentage based values down to often 1440 or 1280px with only minor adjustments with media queries.More adjustments for 2 major and some minor local adjustments follow. That combination is quite ok and reacts, if well done to most resizing without JavasScript event based conditionals. (More or less most current pages do so.)

A lot of my gsap work offers eye-candy or usability enhancements on certain pages, that rely on the General CSS layout structure. If done right those animations survive a lot of CSS adjustments, but I also want rely on the CSS after the animations are done, so that resizing works as expected. (Often I do from tweens and remove the style tag on complete.) Writing al lot of  conditional gsap.set() lines in sync with media-queries for al lot of elements is error prone and not good style in my opinion. That is totally different of course, when you develop a game, or an application that relies on dynamic, script driven layout to 99%.

 

Also I'm more than ever convinced that my original approach is valid and should work on all browsers as it does in Safari. 

 

PS.: I removed the 'solved' attribute from the thread, as I think the inkonsistent behavior on different browsers makes the problem more relevant than just my example. I hope you don't mind.

[GreenSock]

This is one of the many reasons we strongly recommend setting your transforms via GSAP, as explained here. It's fine to set them in CSS initially too if you want, but then you can also specify them via GSAP in order to ensure that everything is parsed properly.

 

The core of the problem has to do with how the browsers report computed styles. GSAP must figure out what the current values are, of course, so that it can properly interpolate to the new ones. Browsers report them as a matrix() or matrix3d() which is ALWAYS pixel-based, so there's no concept of any percentages whatsoever. For example, if you set transform: translateX(-50%) in your CSS on an element that's 400px wide, when GSAP asks for its current transforms the browser will basically report it as -200px! And of course if you set translateX(-200px) that'd get reported identically. So how is GSAP supposed to understand that you meant -50%? See the issue? 

 

Since it's so common for people to use -50% to center elements, there's some code in GSAP to automatically sense that particular scenario as a convenience. It assumes that if the x/y offsets are exactly negative half of the element's width/height in px, it's safe to assume the user meant -50%. 

 

In any case, GSAP must extrapolate all the components from the matrix/matrix3d, like rotation, skew, x, y, scaleX, scaleY, etc. Those get cached and ensure things are totally accurate and super-fast from that point on. The raw matrix()/matrix3d() values are ambiguous especially for rotational values. For example, the matrix/matrix3d for a rotation of 180 is the same as 540 and 900. It's also the same as scaleX: -1, scaleY: -1. But if you always use GSAP and its transform component aliases (x, y, xPercent, yPercent, scaleX, etc.), you'll never run into those ambiguous situations where you risk losing data, like if you already animated to a rotation of 540 and then you try to animate to 900, it'll only do one full revolution whereas if you try to parse matrix values it'll resolve to 180 degrees and you'll either get 2 rotations or none, depending how you define your final value. 

 

This is also why we recommend not defining transforms as strings like transform: "translateX(-50%) translateY(0%)" - strings could contain anything in any order, so the only way to parse them somewhat accurately is to throw them at the browser and have it report it as a matrix()/matrix3d() and then parse that...but we're back to the same issue I described above. 

// NOT AS GOOD
transform: "translateX(-50%) translateY(50%)"

// MUCH BETTER (faster, more accurate)
xPercent: -50,
yPercent: 50,
x: 0,
y: 0

 

Note that above I'm explicitly defining all the x and y values (not just xPercent/yPercent) - that's because GSAP lets you COMBINE xPercent/yPercent AND x/y for some powerful/convenient effects. When GSAP parses the matrix, it will EITHER put the x translation into the "x" or the "xPercent", and same for y/yPercent. The only time it'll put it into xPercent/yPercent, actually, is when it's exactly -50. So in your demo, you've got a POSITIVE translateY(50%), thus it gets put into the "y" component, not the yPercent. This is all working as expected as far as I can tell. I'm just explaining all this so you understand the WHY behind things. 

 

So basically your parsed components looked like this: 

transform: "translate(-50%) translateY(50%)"

// PARSES TO:
x: 0,
xPercent: -50,
y: 50,
yPercent: 0
    

So when you try to animate to yPercent of 0, nothing happens (because it's ALREADY 0). That's why I showed the need to define the y component too, so it'll animate from 50 to 0, thus both yPercent and y will be 0. 

 

Does that clear things up? 

[iDad5]

Thank you Jack,

I had found some of the information you gave when researching my issue before posting and some I already knew from previous own experience, but your description helped clarifying things in context a lot.
I was impressed with your work before and am so now even more. Also your level of customer support is beyond excellent!

 

I feel like I should simply bow to you (which I do - kudos) and never use css transforms again.

(I always hated the way all transformations are implemented in one value anyhow.)

I can't help to feel somehow insolent if I go on now, and I hope I'm not disrespectful - I don't mean to be.
I totally get that tweening complex transforms set in CSS is in certain cases not doable at all and that it is hard even in supposedly simple cases.
But what I get in my test case still confuses me.

 

Regardless if I tried to transform to

transform: 'translateY(0%)'

or

transform: 'translateX(-50%) translateX(0%)'

or

transform: 'translate(-50%, 0%)'

 

GSAP always  did the same (good) job in understanding what I wanted. But only in Safari it succeeded to end up with the correct transformation at the end. 

 

transform: 'translate(-50%, 0%)'

 

All other Browser I tested (I admit I didn't make a comprehensible effort) came up with the wrong/unexpected value of 

 

transform: 'translate(0%, 0%)'

 

as end result.

 

 

My first guess was that safari would report the transform in a different way, but a least in my simple layman's check with getComputedStlye().transform Safari reports exactly the same as Chrome.

 

3 hours ago, GreenSock said:

This is all working as expected as far as I can tell.

 

I do not concur with that. If my combination of CSS transform and tweening simply isn't solvable I gladly accept that. But that GSAP gets it right in one (webkit-) browser and wrong in another - I wouldn't expect that. (No offense meant by wrong but if I want to tween to transform: 'translate(-50%, 0%)' and end up with transform: 'translate(0%, 0%)'  it feels wrong to me.) I would expect it to either work or doesn't work, granted I know that that's is a simple minded one's hope.

 

[GreenSock]

1 hour ago, iDad5 said:

All other Browser I tested (I admit I didn't make a comprehensible effort) came up with the wrong/unexpected value

Could you please provide a minimal demo of that? I haven't seen that at all...ever (at least not that I can recall). I'm super curious to see the test case, though. I tried your original CodePen in Safari and Chrome and I didn't see any unexpected behavior. What am I missing? 

[iDad5]

actually my demo does exactly that.

I attached 2 screenshots Chrome left and Safari right. In the second one you can see in the respective inspectors the difference in the end state.
Safari is 14.1
Chrome 89

Further testing:

 

Mac:
Firefox bad (like Chrome)

Opera good (like Safari)

 

Windows:

Edge, FireFox and Chrome bad,

Opera and Vivaldi good

 

Not surprisingly on iPadOS Safari, Chrome and Edge behave like Safari on Mac

[iDad5]

@PointC - I owe you an explanation / example of what I meant by the proportional problem with yPercent as solution. I have made a CodePen and would gladly discuss that with you, but I feel that it might confuse this thread. So if you (or anybody else) is interested I will open a new thread. 

[GreenSock]

I see the problem. Contributing factors:

• It was behaving fine in my Chrome, I hadn't checked your demo in Firefox
• My local version where I was double-checking already had a patch applied that had resolved this (but the fix was targeting a different scenario so it didn't click with me that this one you ran into was related)
• Firefox doesn't report computed style cssText which is what was needed internally for declaring the width/height and doing the measurements to sense the percent stuff in that particular scenario. Chrome and most other browsers do report cssText. 

This should be resolved in the next release which you can preview at https://assets.codepen.io/16327/gsap-latest-beta.min.js. 

 

For the record, it would only happen when: 

• You don't follow best practices for defining the components individually (xPercent, x, etc.) in the tween, and instead tween to a transform string.
• There's a percentage-based transform applied originally via CSS only (again, not following best practices of setting all transform values via GSAP).

But I'm glad you persisted and pointed this out, as it confirmed that the patch in 3.6.1 resolves this. Let me know if it works better for you once you swap in the beta GSAP. Seemed to work fine for me. 

 

Thanks again. 🙌

[iDad5]

You are very welcome and I thank you 🙇‍♂️

 

Gerat work as always.

For me it now works on Chrome (Mac and Win) Firefox Mac, Edge as expected.

Strangely Only Firefox on Windows isn't behaving as well.
FF win is obviously calculating the necessary values as Pixels at the start of the animation and ends up with a transform in pixel values.
As it seems the resulting value is based on the elements width at the starting point and does not take into account that the element's width is shrinking during the animation it ends up a the perfect place for the element's original width but not where it should be with it's new width.

(Is it possible that FF on Mac reports cssTex and on Windows it does not?)

 

 

40 minutes ago, GreenSock said:

For the record, it would only happen when: 

• You don't follow best practices for defining the components individually (xPercent, x, etc.) in the tween, and instead tween to a transform string.
• There's a percentage-based transform applied originally via CSS only (again, not following best practices of setting all transform values via GSAP).

 I hear you there and I fully understand that - still in my environment those best practices are often not easy to follow. 

In my current project I was able to change my approach to vw only and that helped. Still in other scenarios that might not work as well.  But I really want to get better at using best practices and i will post the slightly more complex scenario in a new thread in the hope of learning. 

[GreenSock]

Hm, did you clear your cache? I kinda suspect you had an old version of the beta file cached(?) I'm not able to reproduce what you're describing. Is anyone else? 

[PointC]

31 minutes ago, GreenSock said:

I'm not able to reproduce what you're describing. Is anyone else? 

Nope. Fine on FF Win10 for me.

[iDad5]

1 hour ago, GreenSock said:

Hm, did you clear your cache? I kinda suspect you had an old version of the beta file cached(?) I'm not able to reproduce what you're describing. Is anyone else? 

Ok, I did clear my cache, ic have no change options set iFF-inspector->network, I did clear the cache manually and even restarted my windows computer, the problem persisted. FF 86.01 on Win 10 pro 64 
 

But I also have an older FF (84) prepared to run independently for archived Flash stuff and that is doing jus fine.

I checked, the GSAP js is version 3.6.1 in the 86.01 FF. I'm at a loss.

[GreenSock]

I'm on the same version of Firefox. No problems at all from what I can tell. It's pretty tough to diagnose if I have no way of reproducing the issue unfortunately. 

[iDad5]

Ok, good news here, now my latest FF on win does what it should do. 

 

The one thing that made it do it was RE-SIZING. Throughout Three restarts various cache purges Update etc. it seems i just moved the window around and restarted FF again and again, but always at the same size.
Once I resized the window everything was fine. I'm not sure now, if that was a glitch in the Matrix or if FF does something incredibly sinister like caching animations somewhere in a hidden  treasure cove guarded by dwarfs and dragons.