What is this "Jerking" - On this page scroll right to the top, then if you're using a mac use two fingers and scroll up more... the page will scroll further up (page moves downwards) revealing a gray area and bounce back up after you lift your fingers off the touchpad.
Question is how do i prevent this "jerking" effect with CSS or JavaScript?
I know it's possible because if you go to facebook or pinterest and click on an image you get a lightbox. In that lightbox "mode" you won't get this "jerking" effect.
I initially thought it's something to do with lightboxes or css fixed positioning but even in http://lokeshdhakar.com/projects/lightbox2/ "mode" it still "jerks". How did fb and pinterest do it?
ps. use chrome or safari. firefox doesn't have this effect.
Facebook seems to accomplish this by setting the CSS attribute "overflow: hidden" on the document body when a picture is displayed. I just tested it myself by adding the following CSS to an HTML file and the bounceback scrolling was disabled.
<style type="text/css">
body {
overflow: hidden;
}
</style>
Of course, this will prevent your page from scrolling at all. I agree with Quentin, this is standard UI behavior and you shouldn't change it unless you have a good reason.
Related
I would like to find a solution for the following behaviour.
If you go to the next link example page and change to the mobile view in the developer tools, you could see that for some of the devices that you can choose the toolbar hide partially on scrolling down. Even the view creates a margin in the right side of the page that can be shown scrolling laterally.
I can not find who is causing the issue. I have checked the sizes of every single div in the page even for hidden div. I don't know if the issue is related with the property fixed in the css.
Here you can see what I mean, the toolbar is hidden when scroll down and if you scroll laterally some small margin appears.
Perhaps not a direct fix, but the Firefox inspector has a 3D mode that is actually very helpful in finding the offending elements in these cases.
You can solve it with the following edits:
.slick-prev: {left: 0;}
.slick-next: {right: 0;}
.container{padding: 0;} (inside of ".main-banner" one)
I am going to get roasted for this but I've searched on StackOverflow and tried to implement the suggestions provided to no avail. Whenever I am using the menu on my website (on mobile devices) the main page still scrolls when I move my thumb and it causes glitches with the display. I cannot get it to lock in place when the menu is open.
Here's what I've tried
Position: relative (on body)
Height: 100% (on body)
Overflow: Hidden (applied to Body when you click to open menu)
None of those have worked. As you can see, the page still scrolls on mobile. Currently my live example shows this:
https://www.brotherhoodgaming.net
Any suggestions are welcome. I'd prefer a CSS solution to this rather than Javascript or Jquery (although Jquery toggleClass is fine as long as CSS is the baseline solution).
I'm looking for the correct way to assure that dynamically revealed content is visible after scrolling in an iframe on ipad / iOS5.
Oh Iframes and iPad - what a wonderful old chesnut you are. I know that:
iPad expands iframes to the full height of the content within it (almost like it was using HTML5's "seamless" property, but not quite since it doesn't inherit styles or events from the parent). Bizarre, annoying to many, but true.
<iframe height="100%"> is therefore useless since it sizes to its content not to the container
I need to wrap my iframe in a div - a la
<div id="wrapper" style="-webkit-overflow-scrolling:touch;overflow:auto;">
<iframe width="100%" height="100%" src="about"blank"></iframe>
</div>
or else introduce some trickery to set the scroll position of the frame (which I think is based on tricks mentioned in this article)
My issue is that content that is dynamically shown inside the iframe body (e.g. jquery tabs, accordion, etc) may cause the browser to crop the content at the display extent of the page.
E.g. if my "tabs" are most of the way down the visible viewport inside the iframe and I perform a two-finger scroll (or implement the one finger scrollTop hack) then after that content is scrolled into view, some of its content that was previously not drawn remains undrawn. Clicking to a second tab / back again causes the content to appear as if the page doesn't draw off-screen content. After this, if I then scroll back up to the top of the page the content isn't drawn for the start of the page (which was previously visible). Scrolling the page up and down a few times with a two-finger scroll resolves the issue.
I had read this article that stated that the problem was fixed. But it doesn't seem to be fully fixed; and still doesn't get around the issue that because you have to wrap your iframe in a div and put scrollbars on that div, desktop browsers may show a double scrollbar depending on how they interpret overflow:auto.
p.s. I'm using HTML5 boilerplate page both inside and outside the iframe, with the correct meta viewport settings.
I found I was also able to solve the problem by making the document as tall as the iframe content. (As suggested Iframe Content Not Rendering Under Scroll In iOs5 iPad/iPhone) But in my case I didn't want the user to be able to scroll down in the now tall app, because its supposed to be a fullscreen application. I used this code to prevent vertical scrolling:
/*
Prevent Scrolling down.
*/
$(document).on("scroll",function(){
checkForScroll();
});
var checkForScroll = function(e)
{
var iScroll = $(document).scrollTop();
if (iScroll > 1){
// Disable event binding during animation
$(document).off("scroll");
// Animate page back to top
$("body,html").animate({"scrollTop":"0"},500,function(){
$(document).on("scroll",checkForScroll);
});
}
}
I evaluated a lot of options and wrote this blog post, including test code.
http://dev.magnolia-cms.com/blog/2012/05/strategies-for-the-iframe-on-the-ipad-problem/
Hope this helps,
Topher
I'm assuming there is a bug in iOS safari in how it treats iframes with defined width / height. Without width / height being defined it tries to scale them automatically to fit their content without any scrolling needed.
The best workaround I've found is to not scroll the iframe at all, but rather to scroll a wrapper div inside the framed-in page.
Here's an example:
<iframe id="stupid-iframe" width="600" height="200" src="a-file.html"></iframe>
a-file.html:
<html>
<body>
<div id="wrapper" style="width: 100%; height: 100%; overflow: auto; -webkit-overflow-scrolling: touch;">
...all my normal content...
</div>
</body>
</html>
This is a very tedious problem, especially if you are in a scenario where you must use a dynamically scaling iframe, in my case with the YouTube iframe API. You are not able to control the scroll properties of the iframe. It doesn't even work if you modify the iframe elements in the ios simulator/safari debug window.
The best solution that I found was to use negative positioning to remove the excess whitespace. Android may have mixed results so you have to use browser detection and apply that way.
I'm working on a jQuery lightbox type plugin that needs to function for mobile devices and desktops. I'm having a problem with the full screen overlay effect. From my research, it seems that the standard solution for this is to use position: fixed or background-attachment: fixed to accomplish the overlay effect. Of course, mobile devices don't support fixed positioning, and so I'm trying to find another way.
Right now, I'm attaching a function to $( window ).on( 'resize' ) to get the new dimensions of the window and set the overlay to them. The problem I'm seeing is that this is triggering flickering scroll bars that make the whole thing really jumpy when I size the window down. You can see the effect here: (http://jsfiddle.net/dominic_p/ZqLCx/3/ or http://3strandsmarketing.com/lightbox.php).
Any idea how I can solve this? The code is still in heavy development so it's kind of a mess, but I tried to highlight what I think the 2 problem areas are in the jsFiddle with a comment that says "THE PROBLEM: START".
UPDATE:
I had a brilliant idea to just change the positioning to fixed for desktop browsers and still rely on my resizing scripts for mobile browsers. It seems to have helped a lot, but there is still some significant flicker when the browser window starts to get small (especially when shrinking it vertically). Also, when using position: fixed on Android 4 there is suddenly a large white gap on the side of the screen that I can horizontally scroll to in portrait mode only. Anyone have an idea of how to resolve either problem?
The solution for the flicker problem seems to be to set the overflow-x (or just overflow if you prefer) property for the <body> element to hidden. For curiosity's sake, it actually wasn't the overlay layer, but the lightbox contents that were causing the flicker.
I'm still struggling with the white gap that shows up on Android, but that's a separate problem, so I'm posting this as the solution.
Using the supersized script http://buildinternet.com/project/supersized/ on a new site. Same thing happens with the demo site. http://buildinternet.com/project/supersized/3/core.html
When I view it through my iPhone / Android, not seeing the bottom of the site, basically unable to scroll down.
Does this have to do with the CSS or that this script does not work with ?
EDIT:
Did not know that jQuery not capable of working on mobile devices. Guess that why they came up with jQuery mobile...
The issue, as far as I can tell, has to do with the inner block having an absolute position and a height:100%. That prevents the page from scrolling.
Change the position to relative and the inner block shows up below the background.
Change the height to auto and the background does not resize.
The best compromise I've come up with is to add the following to my CSS:
#media screen and (max-device-width: 480px) {
.focus_wrapper { poxsition:relative; height:auto;}
}
The image is displayed in the background but if the foreground item is longer than the screen, the background image terminates and doesn't repeat. Sorry I don't have a better answer.