LayerSlider in Safari #main padding-top anomaly

update…

i’ve been doing more research & feel like i’m close but still not complete.

now my code is…

	<script>
		jQuery(window).on("load resize",function() {
			jQuery("#main").css("padding-top", jQuery("#header").height());
		});
	</script>

i discovered that the “load” function seems to take care of that initial Safari loading the wrong height. but still need the “resize” function for when the browser window is resized. i figured out i can use both :-)

but now there seems to be some sort of delay happening (in Safari & Chrome & Firefox).

if you start with your browser window width anywhere smaller than max, empty cache, & reload, you’ll see the LayerSlider begins pushed down farther from the menu than it should be. but within a second or two, it pops back up into place.

i can’t figure out how to even troubleshoot this since it pops back in to place before i can get the dev tools to load & examine its rendered css.

it does look like that either the first slide or the area bg begins too large then when it shrinks down to the appropriate size is when it pops in to place. it’s happening so fast i can’t tell what’s causing it.
note: i do have the first slide image as a background image to the layerslider div. that was done to try & minimize the empty area that shows before the first slide loads.

so, can you:
1) confirm my js/jquery is correct, &
2) let me know what’s going on with that loading delay thing?

thanks.

hi Ismael, thanks for the reply!

unfortunately, that did not work. it had no change on the delay pop in to place thing, and it reverted back the Safari problem.

oh, & i tried it both the way you sent and also with replacing all the “$” with the word “jQuery” (as is apparently the way to get it to work in wordpress).

hi Ismael,

well, it didn’t, so i had to.

i made a post just about that when that happened @ https://kriesi.at/support/topic/how-to-dynamic-padding-top-on-content-under-shrinking-responsive-fixed-header/

i did end up having to add custom css because our client wanted the main header to stretch across the whole content width & shrink from there. if i left it as default, then when the browser window got to a certain size & under, it would wrap the header image in margin/padding so much so that as the window shrunk, the header image would get way too small. so i adjusted the css to keep the header image at full width with no margin/padding as it shrunk.

i’m not sure if what i did there is what disabled the auto-calculating padding-top to the main content area or not. but regardless, the jquery i came up with at the above link seemed to work great… until someone pointed out about the Safari glitch (and now layerslider glitches).

so, i’m content with the new jquery fixing the Safari glitch (by adding the “on load and resize function”).

but do you have any idea why the Layerslider would load at fullsize then jump down to the appropriate size?
can you see it happening? re: http://dev.sistasthemusical.com
(remember to make the browser window smaller, empty cache, then load/reload to see effect).

thanks.
-jason.

PS: to clarify, i just commented out the background image i gave to the layerslider, of the first slide, so you can see that tht’s not the reason for the jump. the whole div is for some reason loading larger than it should & then resizing a moment later.

no, it’s happening on Safari, Chrome, & Firefox (Mac),

but only if the window is smaller than its max (1200 i think) & bigger than the mobile version (768 i think).

update: after i removed the css to have a background image behind the layerslider div, that visual effect of it loading big then shrinking down has gone. so i guess it was the bg that was loading big & resizing, not the layerslider. still not sure ‘why’ that would happen, but not necessary to figure out.

BUT, i guess i’ve been dealing with multiple issues here that looked as if it was one issue; as we’ve been whittling it down…
– the revised javascript took care of the padding-top for the content issue in safari,
– removing the bg img on the slideshow took care of the blowout resize issue,
– but now this still leaves a weird effect that’s probably related to either the nav menu or the content padding-top calc.

on all 3 browsers for me, again if the window is in between the max & min sizes (the smaller you get before it changes to mobile view, the more dramatic you’ll see this), and on every page, when you load/reload, the nav menu height is too big or the content padding-top is too much, so when the page loads, the content is pushed down, then it jumps up in to position.

i wish there was a way to watch the css for each tag as the page loads to see if it’s one thing when it loads then changes right after loading.

update:
i just found this code embedded in the head that i’m wondering if is causing the problem…

<style type='text/css' media='screen'>
 #top #header_main > .container, #top #header_main > .container .main_menu  .av-main-nav > li > a, #top #header_main #menu-item-shop .cart_dropdown_link{ height:150px; line-height: 150px; }
 .html_top_nav_header .av-logo-container{ height:150px;  }
 .html_header_top.html_header_sticky #top #wrap_all #main{ padding-top:202px; } 
</style>

…it appears around line 100 when i look at the source code via Chrome dev tools.

i can’t figure out why this little block is embedded in the page when all the others are linked files. IMO only my custom css should appear there.
but what i “THINK” might be happening is, this #main padding-top loads, which pushes the content down too far when the window is smaller than max, and then my javascript/jquery snip loads which brings the content back up to where it needs to be based on the header height (since the header shrinks as the window gets smaller).

so i can’t figure out a way to negate/reset that padding-top of 202px that loads first, & just let the js handle what the value should be.

does this make any sense?
do you agree/disagree with my analysis?
if that’s the case, how can i get rid of that style block?

thanks again for your help.
-jason.