Relationship between CSS transform translate() and GSAP x:

[katerlouis]

Hi folks,

 

I simply do not understand the relationship between GSAPs x-property and CSSs translate().

It appears to me that x just doesn't care what translate is doing; like GSAP looks where the element is on first x:-call, and from then on on calculates its matrices. 

 

Problem 1:

Seen in this CodePen I prepare an element to be off the viewport with CSS translate(114%) and want to animate it back to translate(0) with GSAP without hardcoding. 

 

Problem 2:

is there something similar to

tl.to(".el", 1, { x: "+=20" });
tl.to(".el", 1, { x: "reset what GSAP has done, but animate it" })

.

 

Dear Elders, please strike my forhead with enough light to fully comprehend this matter.

 

Thanks,

 

René

See the Pen OpVxRj by katerlouis (@katerlouis) on CodePen

[GreenSock]

The core problem is actually related to the fact that browsers always report the current transforms in terms of a matrix() or matrix3d() which contains no information about percentage-based values. They're all baked into those px-based matrices, thus it's impossible for GSAP to know that you originally intended the value to be percent-based. 

 

In other words, 114% gets converted (by the browser, not GSAP) to something like 68px (or whatever). 

 

As a convenience (and this is actually quite handy sometimes), GSAP allows you to have BOTH percentage-based AND px-based transforms on an element simultaneously (that's why we have "x" and "xPercent" properties, for example). In your case, since you set the original values outside of GSAP (in your CSS), it interpreted those as the regular (non-percent) values and then when you defined xPercent in your tween, it was layering that on top of the "normal" one, as if you did x:68, xPercent:"114%". 

 

I'd recommend always doing your transform-related stuff directly through GSAP whenever possible instead of doing some of it via CSS. Not only is this much faster for animation (GSAP can skip a bunch of interpretation of matrices), but it also delivers more accuracy (rotations beyond 360 and percentage-based things remain intact due to GSAP tracking the values internally). 

 

Another solution in your scenario is to just animate to x:0 instead of xPercent:0. 

 

Problem 2: 

tl.to(".el", 1, {x:"+=20", repeat:1, yoyo:true});

Or 

tl.to(".el", 1, {x:"+=20"})
  .to(".el", 1, {x:"-=20"});

Does that help?

[katerlouis]

Thanks for this insight.

 

I understand that GSAP has no idea about the CSS percentage. (which is a bummer for my problem 2)

As seen in this pen (

See the Pen MpjQga by katerlouis (@katerlouis) on CodePen

), like you suggested animating to x: 0 and then back to xPercent: 114 works.

Nice revelation for me, that x isn't relative to wherever GSAP begins, but x recognizes and takes the css translate into account.

But why doesn't xPercent do a thing?

 

Do as much with GSAP as possible

I am always sceptic setting things with javascript. Repaints / flashes need to be reduced to a minimum and javascript gets executed later, leaving a window where the output might not be set to 114% when done with JS alone, right?

 

As for Problem 2 it almost hurts that you don't trust me to make the bridge from a "+" to a "-"

I don't like this solution, because you would have to change 2 values; in a long and a complex timeline things get messy and the second value is easy to forget. That's why I hoped for something like "just reset it like x would never have been set, but animate back to it" – 

 

See the Pen aJmqOW by katerlouis (@katerlouis) on CodePen

the flash after the x: 200px tween reveals that GSAP does know where it all started. 

 

 

I'm looking for some kind of animated clearProps in a separate tween

 

 

 

PS: Finding out about those things is not easy; I don't want to flood the forum with these questions, but I can't find the resources where things like this are explained. Is this just my missing google-skill or does no such thing exist?

[Jonathan]

Hello kreativzirkel

 

In this post i advised in allowing GSAP to set the initial value by using the set() method, instead of your CSS like Jack also advised.

 

Just remove your transform: translateX(114%) in your CSS

.yellow {
     background: yellow;
     /*transform: translateX(114%);*/ /* you do not need, let GSAP set the translateX start value */
}

And set that with GSAP, timeline paused:true so you can see the starting position when page loads:

 

See the Pen BWLYxB by jonathan (@jonathan) on CodePen

 

Look at this with both your to() tweens paused via the Timeline and you will see GSAP start .yellow at the same place. the to translates to.

TweenLite.set(".yellow",{xPercent:114});

GSAP will set() it to the same place your 2nd tween animates to.

 

So just use the GSAP set() method to set your transform, in this case xPercent instead of x. And then GSAP will do all the fancy goodness Jack explained above. By allowing GSAP to set the starting value of your translateX() using xPercent.

 

And you can always wait to run your JS code until the DOM is ready and the window is fully loaded. Which is best practice to make sure your page runs consistently cross browser, so you know you don't start animating elements until the page is fully loaded and ready.. You could of course just run your code when you want, but JS gets parsed in the browser fast like GSAP.

 

So like Jack advised its better and faster to allow GSAP to do its math and magic for you with the matrix() or matrix3d() for transforms. So your transforms animate consistently cross browser.

 

Jack could explain this better than i can, but its just my two cents, Happy Tweening

[OSUblake]

 

Do as much with GSAP as possible

I am always sceptic setting things with javascript. Repaints / flashes need to be reduced to a minimum and javascript gets executed later, leaving a window where the output might not be set to 114% when done with JS alone, right?

 

FOUC. Don't display stuff that isn't ready to be displayed. Works every time.

See the Pen 1ca9abd527195fea490d9bd5de7d29ae by osublake (@osublake) on CodePen

 

Or you can use autoAlpha for a nice entrance effect. I'm not sure, but this thread sounds similar. Somebody wanted to use to use translateX percents from their CSS.

https://greensock.com/forums/topic/15851-reverse-callback-clearprops-doesnt-work/?p=69542

 

 

.

[katerlouis]

This FOUC-prevention definitely needs to only happen if JS is actually available. 

Call me conservative or paranoia; but blocking visibility doesn't feel right. On my next project I wanted to dig deep into perceived performance, lazy loading techniques, skeleton wireframes etc.; My memory says relying on JS for a first paint is evil!

[Shaun Gorneau]

This FOUC-prevention definitely needs to only happen if JS is actually available. 

Call me conservative or paranoia; but blocking visibility doesn't feel right. On my next project I wanted to dig deep into perceived performance, lazy loading techniques, skeleton wireframes etc.; My memory says relying on JS for a first paint is evil!

 

This is easily overcome by placing a small amount of JS in the head to assign a "js" class to <html>, and then use

html.js .some-selector{
 /* Whatever CSS properties you use to "hide" */
}

This way nothing is hidden if JS is unavailable.

[OSUblake]

My memory says relying on JS for a first paint is evil!

 

Does that mean developers who use Angular, or React, or make HTML5 games, or WebVR experiences are evil? If so, I'm really, really evil.

 

If there is no JS, there might not be any CSS either. But playing the no JS game isn't a very good solution. If you want a fast site, you should look into building a site that can work offline, at least partially. Here's a good article on that.

 

I gave you a very simple solution, Shaun's is even better. If you don't like those, you can always do the conversion yourself. xPercent is based on the width of an element, so that means you can figure it out using a little math.

See the Pen 553dbe2e7792195d24253b691196ba26 by osublake (@osublake) on CodePen

 

.

[Jonathan]

JS is fast, it's the browser that is slow and the bottleneck

[Dipscom]

Does that mean developers who use Angular, or React, or make HTML5 games, or WebVR experiences are evil? If so, I'm really, really evil.

 

If there is no JS, there might not be any CSS either. But playing the no JS game isn't a very good solution. If you want a fast site, you should look into building a site that can work offline, at least partially. Here's a good article on that.

 

I gave you a very simple solution, Shaun's is even better. If you don't like those, you can always do the conversion yourself. xPercent is based on the width of an element, so that means you can figure it out using a little math.

See the Pen 553dbe2e7792195d24253b691196ba26 by osublake (@osublake) on CodePen

 

.

 

Dang, beaten to the punch. I was going to say similar but no reason to repeat it. 

 

That's what you get for sleeping. Evil Blake comes in and does it all.

[PointC]

Evil Blake comes in and does it all.

I'm pretty sure that post was from regular Blake. Evil Blake is his twin brother. Evil Blake is easily recognizable by his goatee and comically over-sized Hollywood villain mustache. (No offense to Sir Jonathan)

[OSUblake]

That photo is probably a fake. Evil Blake has a monocle.