Jump to content
Search Community

How to deal with 100vh on Mobile Snap

Roger Junior test
Moderator Tag

Recommended Posts

Hey guys, this is my first post here, I'm well aware of posting a minimal demo but it seems that the issue is also kinda related to performance (and also, Codepen overwrites the 100vh behavior so the address bar doesn't get hidden), let me explain:

 

I've found a post here on the forum, that says that when the address bar gets hidden on the phone all GSAP calculations need to be redone, but my website also uses a lot of ThreeJS animations that are kinda heavy and this whole GSAP calculation takes too much time to complete.

 

Every time you are scrolling down, the elements that were supposed to snap and fill the whole screen with 100vh get shifted down, and then it takes like 2 seconds to recalculate and the website gets scrolled to a completely different section (but with proper alignment).

 

It's clear that the issue is with the visibility of the address bar, but I have no idea how to solve it. 

 

I've attached a video of the behavior and I also will leave the website link https://atlantica.global/

 

Again, sorry for not having a minimal demo, but I'm pretty sure the problem is related to the screen resize calculations. This is not even the first time this happens, but in this case, it is very noticeable.

 

Is this a common behavior? How could I fix that?

Link to comment
Share on other sites

If you want it to just skip doing those recalculations, do this: 

ScrollTrigger.config({ ignoreMobileResize: true });

https://greensock.com/docs/v3/Plugins/ScrollTrigger/static.config()

 

The down side is that of course the start/end measurements won't get recalculated according to the new screen size, but it sounds like you don't mind that. 

Link to comment
Share on other sites

14 hours ago, GreenSock said:

If you want it to just skip doing those recalculations, do this: 

ScrollTrigger.config({ ignoreMobileResize: true });

https://greensock.com/docs/v3/Plugins/ScrollTrigger/static.config()

 

The down side is that of course the start/end measurements won't get recalculated according to the new screen size, but it sounds like you don't mind that. 

 

Hey Jack, thanks for the response :)
 

This does help with the flashing, but I'm still getting this weird pining (as in the attached file).

 

This is the code that I'm using for the pinning:

var tl_start = gsap.timeline({
  ease: "linear",
  scrollTrigger: {
    trigger: "#we-are",
    pin: true,
    start: "top",
    end: "bottom",
    scrub: 2,
    anticipatePin: 1,
    fastScrollEnd: true,
    normalize: true,
    end: "+=" + window.innerHeight * 3,
  },
});

 

If the element is actually smaller than the screen, shouldn't it be pinned to the top? How could I fix that?

 

(This doesn't happen all the time, actually is very unpredictable when this will happen, this bug occurs when I'm scrolling up and down and also only happens on mobile)

IMG_2933.PNG

Link to comment
Share on other sites

Hey @Rodrigo, I've been playing with svh units and It seems to be the solution (though is not widely supported yet). Since the containers will be bind to the smallest screen height, there won't be any shifting in size as the address bar disappears.

 

I thought it might be a conflict with other JS codes from the website, and I removed every single line of code that wasn't related to GSAP leaving only the styles (so I could see the basic animation) and it seems that the error still persists - when the address bar gets hidden it leaves this gap on the top of the page; even after adding the  start: "top top"part.

 

Apparently, this might not be common to happen, maybe it can be something with position attributes of the elements, I'll be happy to try to provide a minimal demo later so maybe you guys can take a look at this top padding issue, but otherwise, the svh solution will be good enough for now (as I'm desperate to finish this job hahaha)

Link to comment
Share on other sites

Also, here's a video of how it turned out with svh. It's not perfect because it leaves this white space at the bottom, but I think it would be easy to fiz with a pseudo element or something like that.

 

Maybe, another solution would be declaring a VH unit with JS at the DOM load so it will be fixed, like that: (and then use the CSS variable instead of the VH unit itself)


let vh = window.innerHeight * 0.01;
document.documentElement.style.setProperty("--vh", `${vh}px`);

.mov

 

I don't know hahaha these are all some ideas

 

 

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