I have a problem concerning changing the background position with jQuery. The website I am working on (http://www.jeroenrood.nl/GortzFruit), has a scrolling animation (either scrollwheel or on anchor click), and the top position of the img-tag in the background changes slowlier than the scrolling speed.
This creates a fluent parallax scrolling effect in Chrome and Firefox, but not in Internet Explorer. In IE (regardless which version) this effect stutters a lot (as can be seen at the aforementioned link).
This is the code that I use, concerning the parallax scrolling effect (HTML):
<div style='height:1000px;background-color:#333;position:relative;' id='page1'>
<img src='images/bg1.png' alt='' style='display:inline;position:absolute;top:-60px;left:0px;width:100%;z-index:0;' class='background' />
</div>
And this is the javascript/jQuery code:
var page1 = $('#page1').offset().top;
var windowHeight = $(window).height();
$(window).scroll(function(){
var scrollTop = $(window).scrollTop();
//if the first page is in the viewport
if((page1 <= (scrollTop+windowHeight))&&((page1+1000) >= scrollTop)){
newOffset = -60 + ((scrollTop - page1)*0.8);
$('#page1 .background').css('top',newOffset);
}
});
Somehow IE seems to lag in processing this position of the image and applying it. Does anyone have an idea of how to make IE have a similar smooth scrolling effect as Chrome or Firefox?
Thanks in advance,
Jeroen
Edit:
Okay, I am on my way to finding the solution!
I tried background-attachment:fixed, which did not result in stuttering in IE. Then I thought, well, this css could be combined with the parallax effect. There are gaps in the transition in IE that cause the stuttering, so maybe I can bridge them with background-attachment:fixed.
This seems to work! Now it even is a fluent animation in IE. Even with a massive background image.
This is the code (HTML):
<div style='height:1000px;background-color:#333;position:relative;text-align:center;' id='page1'>
<div class='background' style='display:inline;position:absolute;top:-60px;left:0px;height:1000px;width:2000px;z-index:0;background-image:url(images/bg1.png);background-repeat:no-repeat;background-position:left -60px;background-attachment:fixed;'></div>
</div>
And this is the relevant javascript/jQuery code:
var page1 = $('#page1').offset().top;
var windowHeight = $(window).height();
$(window).scroll(function(){
var scrollTop = $(window).scrollTop();
//if the first page is in the viewport
if((page1 <= (scrollTop+windowHeight))&&((page1+1000) >= scrollTop)){
newOffset = "left "+ (-60 - ((scrollTop - page1)*0.2))+"px";
$('#page1 .background').css('background-position',newOffset);
}
});
Make this image a lot smaller. It is 2000×2386 pixels and 8.3MB large. You could make it 1000×1193 pixels and convert it to JPEG. JPEG compresses photos better than PNG. Browsers can process small images a lot faster than large images.
Related
I have a weird issue where my div is not scrolling vertically in Chrome on my MacBook display. If I move the window (without resizing it or anything) to a different display vertical scrolling works. If I scroll horizontally first that "unlocks" the vertical scrolling. Only in Chrome, only on the MacBook display.
I can't share the page here, but I can try to re-produce it with some different content if that is helpful. Thought I would check if it is a known issue first. I have some jquery resizing things going on that might be a lead.
setTimeout(function() {
var table_p = $("#table");
var position = table_p.position();
var viewheight = $(window).height() - position.top - 10;
table_p.height(viewheight);
$(window).resize(function() {
var table_p = $("#table");
var position = table_p.position();
var viewheight = $(window).height() - position.top - 10;
table_p.height(viewheight);
});
}, 250);
Turns out setting a height in the css for #table fixed the problem, even though the height is replaced by js soon after.
I'm having trouble with an animated scrollbar. The intended behaviour should be on clicking the nav-button, scroll with ease to the end of the page(and a little break near the end).
Now the problem on PC works perfect. On android device (I tried my phone), the scrollTop value and the ($(document.body).height() - $(window).height()) do not match. There is exactly 55px less with the scrollTop thus acting all sorts of strange... Also sometimes it works sometimes it doesn't. I've figured it has something to do with the browser bar collapsing and upsetting the value...but i can't figure it out.
I've tried the following: initializing the variables on scroll event, i've tried vanilla js that didn't work. Need help :) for reference http://www.developer.morningmood.org , also i've printed out the values on bottom of the page if it helps. Here's the code.
contactF = Math.floor($(document.body).height() - $(window).height());
$("#cont").click(function(){
if ($(document).scrollTop() < contactF && flagScroll==true){ //flag stops other buttons from beying pushed
flagScroll = false;
var inter = setInterval(function(){
var doc = $(document).scrollTop();
if (doc == contactF){ // this is the final desired position
clearInterval(inter);
flagScroll = true;
pix = 10; //pixels to jump
return;
}
if (doc >= contactF-50){ // this is a break on aproach
pix = 1;
}
$(document).scrollTop(doc + pix);
}, 10);
}
})
EDIT: also to find the bug, you nedd to scroll from the top of the page all the way to the bottom, if from the top of the page you just push the contact button it works. but if you scroll it doesn't, it upsets the value...
Had the same exact problem and spent a whole day to figure it out.
You are right about the address bar collapse on Android chrome messing it up. Turns out the jQuery function $(window).height() always reports the viewport height that is before the address bar collapses. To get the correct value, use window.innerHeight instead. You can find more information about URL bar resizing here https://developers.google.com/web/updates/2016/12/url-bar-resizing
You can also find people asking similar questions regarding the safari address bar auto-hide, the solutions are similar. Mobile Safari $(window).height() URL bar discrepancy
I have some strange behavior from firefox, I'm building a single page portfolio and as a graphic designer the coding has been hard. I wanted to smoothly control the navigation and then later added scaling to all the elements (designed for 1920x1080 full screen initially). The lecturer dropped a bomb that it needed to scroll vertically as well, I am in the process of trying to get the vertical navigation to work.
The issue is when I switch to full screen most of the navigation code seems to take a long pause before it executes. This only happens when I switch to full screen. If I switch and refresh then it's ok. I really want to know whats slowing the whole thing down.
I have tried safe mode with no plugins. I'm using Firefox 24.0 with Firebug to get at the bits an pieces.
I have created a code fiddle (my first and it's already broken):
http://jsfiddle.net/jeffreyknipe/xfjmC/1/
The code for the scrolling is as follows:
function navTo(horizontal, vertical) {
browserWidth = $(window).innerWidth();
browserHeight = $(window).innerHeight();
newRatio = browserWidth / 1920;
$('html body div#full_site section#pages_section').animate({
marginLeft: '-' + browserWidth * horizontal,
marginTop: (browserWidth / 16 * 9) * vertical
}, 1000);
if (horizontal == 0) {
$('#menuspace #floating_topbar #menuzone').animate({
marginRight: 0
});
} else {
$('#menuspace #floating_topbar #menuzone').animate({
marginRight: (newRatio * (-340))
});
};
};
I know the coders out there will frown on how inefficient the code is but any advice will be appreciated. The biggest thing is the full screen code slow down.
Thanks.
The issue came in when animating the changes in items or location when going to and from full screen. I switched to setting the new values with .css rather than .animate (I did want it to animate to the new location) but since animation here wasn't a deal breaker and it solved the issue I'm a happy camper.
I have to assume that it wants to animate but the java script engine or some thing in Firefox get too busy during the change, it's almost a bug but I can't isolate whats happening while the script is jammed so I can't report it.
I have a content slideshow:
slide container
|--> wrapper
|------> slide1, slide2, etc.
that works as simple as calculating wrapper's position X and slide's position X to determine where to slide the wrapper for the next/previous slide to show up within container's viewport. It's pretty straight forward.
For Firefox and Chrome I am using CSS3 transform and transition-duration to animate the slides. Everything works perfect. Almost.
The problem is only when I click next button very fast. I am using jQuery's
$(selector).position().left
to read the slide's position X (left) and position becomes 0 (instead of expected, say, 300px). I do have a flag isAnimating to prevent users from going too fast but that does not help either. It does prevent from scrolling content too fast but position left may still be 0 as if something else is causing it to fail to determine.
I did a brief search and discovered that if it was image being loaded, some browsers would fail to determine its position until loading is over. However, each slide has an image but inside of it. The slide's CSS seems to have all widths and margins set fine.
The question is why may this be happening based on the scenario I described and possibly what can be improved to determine position X at all times for Firefox, Chrome browsers?
I've decided that if offsetLeft is not reliable for me at all times, I could use width of an element and its index position within container to figure out position X
var newWrapperPos = undefined;
$(lotWrapper).children('div').each(function(index){
if($(this).attr("id") === "slot"+id){
var width = $(this).width();
newWrapperPos = index * width;
return false;
}
});
//now I can shift wrapper to position = newWrapperPos
Sorry I couldn't share the code - it is a bit time consuming to rip off all pieces of functionality involved. But if somebody has a better answer, let me know. For now this works fine for me.
I have a small problem.
I'm trying to do something like nikebetterworld.com's parallax background.
In my first attemp, I got something that works, but it can work better.
When I scroll, the background position changes. The problem is that it changes a few milliseconds after the scroll, so I can see how the background "jumps" after scrolling.
code:
var $w = $(window);
function move($c) {
var scroll = $w.scrollTop();
var diff = $c.offset().top - scroll;
var pos = '50% ' + (-diff)*0.5 + 'px';
$c.css({'backgroundPosition':pos});
}
$w.bind('scroll', function(e){
move(some_container);
});
Any suggestions?
Thanks.
Edit
Look at this example: http://jsfiddle.net/MZGHq/
(Scroll down until you see the background image)
The key is to use a fixed background if you must have it smooth. See http://jsfiddle.net/MZGHq/7/
References:
This page seems to have a good explanation of how the vertical parallax effect works: http://www.webdesignshock.com/one-page-website/
Also take a look at this one (they don't use fixed background...note how it looks a little jumpy like yours):
http://www.franckmaurin.com/the-parallax-effects-with-jquery/
var pos = '50% ' + (-diff)*0.5 + 'px';
I believe the problem is the 0.5. When you calculate the new position there is enough of a difference between the previous and new location for it to be a perceptible shift.
Changing 0.5 to 0.2 or lower minimizes this a bit, however the parallax effect is less pronounced - which is not what you want.
I would try a different approach - take a peek at GitHubs 404 page as an example:
https://github.com/ddflsdigjh;ad
use 'fixed' background
the displacement of background position should be much bigger than scroll (not 0.5 but 0.01)
it seemed that the problem take place only in FF. This is the slowest browser in rerendering pages and javascript.