Shrink Amount in Pro Header builder is wonky

[simeoned]

I am opening this thread in hopes of finding a solution to an issue mentioned in this topic:

The behavior of Shrink Amount in the header builder is strange

…which was never fully resolved, it seems.

The problem is that when using a smartphone (pixel 2, both firefox and chrome behave the same way), the setting to make a sticky bar shrink causes an unexpected “doubling” of the shrink amount when scrolling back up to the top and then back down again. Here’s the scenario…

1. Initial page load, header is 17rem (roughly 235px of actual screen real estate)
2. On scroll down, header shrinks as expected and all contents follow suit (roughly 117px of actual screen real estate). Shrink amount os set to 0.5 (see attached)
3. Scroll back up to top, header expands to original state as expected.
4. Scroll back down, header shrinks to roughly half of the intended size (about 60px)

Repeating this action causes a doubling of the effect again so that there is now 30px used… and so on until it totally disappears. However, the contents of the bar remain visible but are positioned in unexpected ways, For example, the logo’s top half is positioned off screen and cut off.

Reloading the page resets everything and you can consistently repeat the issue again. Here are the settings I’m using in the header builder:

Link to the issue (only a problem on mobile phones, the issue will not happen if you just reduce your browser width):

Home - Rx Message on Hold

Please have a look and let me know what can be done. Thanks!

[rad]

Hi @simeoned,

Thanks for reaching out.

I couldn’t reproduce it on my installation, and in your setup, I could only trigger the issue if I swipe fast. But it works okay on normal scrolling speed. Would you mind providing your admin login credentials in a secure note?

And may I know which device you’re testing it with? Maybe the processing speed could affect it as well.

Thanks!

[simeoned]

1. Swiping / scrolling fast is a reasonable user behavior that is likely to happen in the real world all the time. We can’t expect users to not do reasonable things with their devices to excuse away poor UX.

2. And anyway, I can make it happen even at slow scrolling speeds. The issue seems to trigger more regularly if you scroll far enough to make the browser’s address bar scroll out of view and then back in repeatedly. Again, something user’s are likely to do.

3. Which device I’m working with:

I quote my original post, “The problem is that when using a smartphone (pixel 2, both firefox and chrome behave the same way)…”

Google’ flagship Pixel 2, essentially brand new.

[Prasant]

Hello @simeoned,

Thanks for updating the thread.

I wanted to take a closer look at your setup but the login details you have shared is not working. Can you please confirm the login credentials? I am getting ERROR: The username or password you entered is incorrect. Lost your password? error message.

Thanks.

[simeoned]

Secure note updated… User was spelled wrong. Sorry

[ruenel]

Hello There,

To minimize the wonkiness, you can add a trigger selector or trigger selector. Having it that way, it will take a few scrolls before the header will be shrank.

Combining both trigger will not give a good result.

Please let us know how it goes.

[simeoned]

@RueNel
Thank you for your reply but this is not an acceptable answer for several reasons:

1. I don’t wan’t to minimize it. I want to eliminate it. Do you not agree that this should not be happening at all?
2. Your suggestions have zero effect on the problem.

So yeah, I’d say it hasn’t gone well.

Perhaps @Rad and / or @Prasant could weigh in on this now that credentials have been provided. Please advise.

[simeoned]

Well, In an attempt to get something done on this, I have done the following in functions.php to add/remove classes based on scroll length:

add_action( 'wp_head', 'shrunken_head' );
function shrunken_head () {

echo "
<script>
jQuery(window).scroll(function() {    
    var scroll = jQuery(window).scrollTop();
    if (scroll >= 1) {
        jQuery('.x-bar-fixed').addClass('darker stable-shrink');
    } else {
    	jQuery('.x-bar-fixed').removeClass('darker stable-shrink');
    }
});
</script>
";
};

And then added my classes to the child stylesheet:

.darker {
background-color:rgba(0,0,0,0.9) !important;
	-webkit-transition: background-color 300ms ease;
	-ms-transition: background-color 300ms ease;
	transition: background-color 300ms ease;
}

.stable-shrink{height:8rem !important;min-height:8rem;height:auto !important;height:8rem;} 

Where the min-height 8rem is roughly half the height of the initial 16rem I have set as the height of the bar (changed it from 17rem to make it an even number). I have then left the shrink amount at 0.5, which should mean the same half I have coded into the style sheet now.

The effect of this is that the bar itself is now not shrinking erratically but the logo still shifts progressively upward.

My theory is that this has to do with the behavior of mobile browsers hiding and showing the address bar based on the same scrolling action that also triggers the shrinking. The math is wrong because it’s taking these extra pixels (and the fact that that are showing/hiding based on the same scroll action) into account and not just the viewport as is the case on a desktop.

[rad]

Hi @simeoned,

The problem is, space due to the address bar is calculated, or can’t be calculated. The CSS or Javascript has no capability to access that feature of mobile browsers. It’s the same on IOS devices and tried many times, the appearing and disappearing address bars causes issues. And for the same reason, FIXED navigation of X theme is disabled on mobile devices.

And since it’s a Pro header, there is no automatic way to disable the fixed navigation since it’s custom (user made). And the Hide during breakpoints is added to the user could hide a header bar with fixed navigation from mobile. Like different header bar for mobile.

I’ll continue checking, but I can’t promise any workaround.

Thanks!

[simeoned]

@Rad, yes this is what I think is happening too. And it makes sense. But to be clear, it’s not really the FIXED part that is causing the issues I think… its the shrink calculation (sizing and resizing after the address bar appears/disappears/reappears multiple times).

I do hope that a satisfactory solution can be achieved though. A sticky nav with shrinkable elements inside is something that I see being utilized on a lot of sites these days. Hopefully, there is some technique that can be conceived of that would circumvent the mobile issues discussed here. Now that the problem is understood, maybe a solution will present itself. I know I’ll be thinking about it and will update the thread if I come up with anything.

For now, here’s what I’ve done on the site I am working on…
I’ve refactored the bar(s) now so that there is a desktop version and a mobile version for the bars themselves (which is where the shrink config takes place). In other words, upstream from the whole problem really:

So I hope this is helpful to anyone experiencing this problem. Thanks for digging into it with me and please do let us know if there is something that can be done using a single bar config as originally conceived.

• Dan

[rad]

Hi @simeoned,

It’s the FIXED position since shrinking is only possible with FIXED header (eg. Sticky). The shrinking only adds up to the issue which makes it more noticeable.

I’ll continue checking but I recommend not using sticky headers on mobile to prevent, scrolling with animation could also contribute to this, and this is noticeable on parallax background too.

Thanks!