Jump to content
Search Community

TranslateX on an element that takes up the whole viewport

emilychews 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

 

I have some odd behaviour when translating a div that is 100% of the viewport width and height when I translate it in an out of the viewport itself.

 

The example is a simplified example of what's going to be a slide-in menu sitting off the viewport using translateX: -100% in my CSS.

 

When I animate it in and out, it works OK using xPercent. But when I resize the window it doesn't work. I tried using vw units with the normal x: property but this created other problems.


How do I get the behaviour that happens when the code first loads, to work after the window is resized?  When I use scaleX on the element I don't encounter the issue (for obvious reasons I guess), but sadly I do need to translate the element in this instance because it will contain text.

Any help would be fab

 

var button = document.getElementById("button");
var menuClicked = false;

var menuAnimation = new TimelineMax();

function menuIn() {
  
    if(menuClicked === false) {
        
        menuAnimation
        .to("#main-nav", .75, {xPercent: 100});

        menuClicked = true;

    } else {

       menuAnimation
        .to("#main-nav", .75, {xPercent: -100});

        menuClicked = false;

    }

}

button.addEventListener("click", menuIn, false)

 

See the Pen oELBEa by emilychews (@emilychews) on CodePen

Link to comment
Share on other sites

Wait I thought xPercent was equivalent of translate and that GSAP will take in account any prior CSS declarations. But in OP's example I noticed that GSAP would calculate translate in matrix and would reset the position of element using xPercent, so if you resize the element will just get offset from the expected position.

 

So I tried to add translate plus default matrix to css declaration to FORCE gsap to calculate from it's current position and not reposition element in matrix but it behaves same. Personally I would expect GSAP to respect my css declarations because in practical use, I will want my element to stay hidden while scripts are loading.

 

Here is how I would get around it by animating x to zero along with xPercent so I will be able to hide elements using CSS.

 

See the Pen RQROwX?editors=0110 by Sahil89 (@Sahil89) on CodePen

 

  • Like 4
Link to comment
Share on other sites

That is a fine solution too, Sahil.

 

When you use GSAP to set xPercent and x like:

 

TweenLite.set(something, {x:100, xPercent:-100) 

 

it will put the x in a matrix and the xPercent into translate separately.

 

 

However, if you have a percentage based translation in your css it does not get put into a separate translate style, it all goes into a matrix.

Once values go "into the matrix" they have to be pixel based and all sorts of percentage based flexibility will be lost.

 

 

hJBLvGQ6T7utP8xpVzs-Gw.png

 

That's my understanding of what happens, but if you need more clarification on the why, let me know. I'm sure  @GreenSock can clarify.

 

 

  • Like 2
Link to comment
Share on other sites

Ya I figured that out, I just think it is natural to expect that GSAP will take into consideration if we use percent based translate in CSS. Instead GSAP will calculate current position and add into matrix. But it's not a big issue and can be worked around easily. Plus I can't really think of scenarios where it will cause problems.

  • Like 1
Link to comment
Share on other sites

Yep, @Carl is exactly right. And the reason GSAP doesn't read the percentage-based stuff from the existing CSS is because it's practically impossible since the browser always reports the current style (via getComputedStyle()) as a matrix() or matrix3d() which has everything baked into it. There are no percentages at all. That's another reason why we strongly recommend that folks just use GSAP directly to do their transforms because it's faster, more accurate, and keeps the data segregated properly. :)

  • Like 5
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...