i'm using skrollr.js and skrollr-menu for creating a parallax website. I have 3 divs with nested elements that i would like to parallax at different speed. Everything works as expected on desktop but on iPad running iOS 7 i am experiencing a problem with the way the elements are positioned and the speed at which they scroll. The 3 different divs have a class of position: fixed, and nested elements a class of position: absolute; and are positioned on Y axis using top:px, (tried using % instead with mixed results). other (non-nested, ie. #content) divs seem to be working consistently across all browsers and device though. I would really appreciate any help with this problem it has been driving me crazy for days, this is my first project using skrollr so i dont have much expericence but so far i'm loving it except for this glitch on iOS, i have checked the documentation and related question in stackOverflow but still no luck! Hopefully someone will be able to point me in the right direction, here's a fiddle of how im trying to achieve this, although to see it in iOS i will have to provide a direct link to the project shortly, please bear with me since i had to port an existing project for using it with skrollr on mobile devices so i would like to clean up code as much as possible before submitting to avoid confusion, in the meantime here is the fiddle:
//Init Skrollr
$(document).ready(function(){
var s = skrollr.init({
forceHeight: false,
smoothScrolling: true,
smoothScrollingDuration: 150
});
skrollr.menu.init(s, {
easing: 'outCubic',
animate: true,
duration: 1000
});
});
http://jsfiddle.net/shinobisan/EvPdL/6/
Thanks!!
On mobile the skrollr-body element is moved using CSS transforms, which will break fixed positioned elements. Please read this part of the documentation, which I just extended with a second paragraph.
Starting with skrollr 0.6.0 there's just one thing you need to do: Include an element on your page with the id skrollr-body. That's the element we move in order to fake scrolling. The only case were you don't need a #skrollr-body is when using position:fixed exlusively. In fact the skrollr website doesn't include a #skrollr-body element. If you need both fixed and non-fixed (i.e. static) elements, put the static ones inside the #skrollr-body element.
Or to put it differently: On mobile the skrollr-body element is moved using CSS transforms. You can't have position:fixed or background-attachment:fixed inside elements which use CSS transforms as per CSS spec (http://meyerweb.com/eric/thoughts/2011/09/12/un-fixing-fixed-elements-with-css-transforms/). That's why those elements need to be outside of the skrollr-body element.
https://github.com/Prinzhorn/skrollr#what-you-need-in-order-to-support-mobile-browsers
Related
I recently took an interest in building websites and am still very inexperienced, so my apologies if this is easily answered.
I was asked by a friend to build her a simple portfolio website for fashion designs. As such, the website mainly has image galleries. The images come in various sizes and rather than ordering them manually to make it look better, I found the Masonry plugin. I implemented masonry.pkgd.min.js into my code (initialized through the HTML) and ran into two issues:
The main issue that might make question 2 moot entirely… It looks fine in IE and Firefox, but the images come up overlapping in Chrome and it looks horrible. I cleared my cache several times and tried implementing the imagesLoaded plug-in, which did absolutely nothing. I am very new to Javascript and as such have to rely on copy/pasting this sort of plug-in whereas someone else might be able to delve in and tweak it, but at the same time I had no issues getting tabbed content and this does work in two browsers. Any idea why it doesn’t work in Chrome and what I can do to fix it?
After the plug-in, I don’t seem to have any control over automatically centering the image columns in the gallery/container and they are aligned left by nature. I more or less fixed this by manually setting a margin-left that puts everything in the right place, but would like to know if there is a better solution.
Please let me know if I need to include screenshots or specific code.
Issue One:
Try adding imagesLoaded. Chrome in particular has an issue if you don't use it with masonry. I suggest trying the solution in the third box first, it's the easiest and fastest loading. This code will go in your .js file if you have one, or in your script tags if you don't.
If the "why" interests you, it's because your containers load before your pictures and don't know how tall they should be.
Issue Two:
You're right on with this one. You can't center the whole masonry container itself (you can get close, but at certain browser widths there will be a small gutter on the right), but you can center the images within their containers by adding a margin like you did or using:
position: relative;
margin-right: auto;
margin-left: auto;
This question already has answers here:
iPhone Web App - Stop body scrolling
(6 answers)
Closed 9 years ago.
I've been working on a mobile webapp as of late. I'm optimizing mobile-first, focusing specifically on iOS for the iPhone right now. I don't want the precise look of a native app, but I think that the feeling of being native is of absolute importance. I've made the markup and CSS to reflect this idea, leaving me with this (annotated to better understand the problem I'm having later on):
This all works problem-free, and it also has the advantage of having a native feel, with static header and footer, and a scrollable inner view (thanks to -webkit-overflow-scrolling: touch).
As anyone who has used iOS for more than 5 minutes will know, when you scroll up or down, you get some nice momentum scrolling. Also, when you hit the top of a list, you get a nice 'bounce' effect:
I feel that this helps to define the feeling of iOS, and such a small detail can go a long way. Luckily, when you are below the top of a list in a scrollable element in a webapp, and scroll past the top, you get the same effect. This is the desired behavior in action:
However, when you are at the top of the list, and try to recreate the same bouncing behavior a the top of the list (à la Setting.app, seen above), we get the following behavior, which is not desired:
I've seen some similar questions on Stack Overflow, but these all opt for disabling bouncing. I'm wondering if it's at all possible to keep bouncing, but always make it occur on body section section#main, not on webapp's chrome. I'm not using jQuery, so I'd prefer answers to be in straight-up JavaScript (bonus points for a CSS solution, though).
Here's a GitHub repo with all of the code (Sinatra, HAML, and Sass; current branch is so), or a JSFiddle with broken images and links, but shows the issue in question on an iPhone (best to add to homescreen to test).
OLD INFO: I've solved this: http://www.hakoniemi.net/labs/scrollingOffset/nonbounce.html
NEW INFO: This is now a jQuery plugin that can be found from here: http://www.hakoniemi.net/labs/nonbounce/.
There are several issues, like losing the zooming capability when this is applied or it's dynamic updating isn't working fluently.
But now the simplest way is to define: <div class="nonbounce">...</div> and then $.nonbounce();
I ran into the same problem and came up with this solution:
http://demo.josefkjaergaard.com/stackoverflow/element_scroll/index.html
Basically I prevent the scroll-content from being in its maximum positions.This prevents the body-scroll from being activated.
It works but it does create a little snap at the end of the easing. With a little more work this behavior could probably be hidden by offsetting the content in opposite direction.
Here are some useful resources I found on the subject:
https://github.com/joelambert/ScrollFix
http://apdevblog.com/optimizing-webkit-overflow-scrolling/
http://www.hakoniemi.net/labs/nonbounce/
http://www.kylejlarson.com/blog/2011/fixed-elements-and-scrolling-divs-in-ios-5/
http://cubiq.org/iscroll-4
How about this pseudo-code:
document.body.addEventListener("ontouchstart", function(event) {
if(document.getElementById("main").scrollTop > 0) return;
event.preventDefault();
event.stopPropagation();
}, false);
In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.
Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.
Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.
i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.
Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>
#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.
It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.
Before you say this isn't possible, I know it is. Here's an example: http://victoriabeckham.landrover.com/INT
The main problem is that iOS freezes DOM manipulation on scroll, so you have to use some sort of technique to overcome the problem. The parallax plugin I was hoping to use is stellar.js, but the issue I am running into is that the "iOS demo" for that plugin isn't really usable on a desktop. I fiddled with it for 3 hours this morning, and couldn't get a setup that works correctly on both iOS and desktop.
I need some ideas, either a technique to configure stellar.js to work the same way on both (I'm not sure if that's possible), or another library that works on both, or maybe some insight on how I could program a workaround myself.
Any help is appreciated.
Step 1: Create and object like this
{
startFrameNumber: {
//first obj
id: idOfElement
duration: howeverManyFrames
startLeft: whatever
endLeft: whatever
startTop: stillWhatever
endTop: whateverAgain
},
nextStartFrameNumber: {
}
}
Step 2: Make the page unscrollable via CSS, ie 100% height and width with and overflow: hidden
Step 3: When the user scrolls (via custom scrollbar, keyboard action, or touch events) advance the animation x frames based on how far they scrolled or whatever. If your animation object you created has a key [frame] then add that to the queue of things that are visible and moving, and move all those things in the queue to their appropriate places and/or remove them from the queue of active objects
That's it. The function for moving things around should be pretty straight forward, except getting the animations smooth will take a little playing around with.
Simply scroll each layer of parallax effect manually and control them yourself without relying on browser's page scrolling.
I've successfully implemented cross device/browser parallax scrolling with the help of the Zynga Scroller js library.
It takes care of one of your main concerns which is the interoperability of click and touch events and scrolling on mobile webkit devices – this allows you to manipulate the DOM as you scroll.
Then, to create the parallax effect you have three options:
Simulating a real-world 3d parallax by using 3d transforms (with a parent/wrapper element that controls perspective and transform origin).
Using a 2d parallax library such as stellar.js or skrollr
Building your own parallax scrolling algorithm.
Here's a quick demo (using existing sample code) of option 1 showing how smooth parallax scrolling would work across desktop and mobile devices. Of course, you're limited to devices that have support for 3d transforms. Note that the Zynga Scroller works via click/touch and drag – it should probably not be used as a dekstop solution as the only thing that would be required is overflow: scroll in CSS.
Have a look at the jQuery-Plugin "Scroll Path" http://joelb.me/scrollpath and combine this with different layers and speeds. You will have recognized that the scrolling of the example page is not just a vertical parallax stage but also moves layers horizontally while you scroll up and down. This is possible with Scroll Path.
Try using http://cubiq.org/iscroll-4 and stellar.js together.
Do your parallax stuff for desktop normally and then add a 'touchmove' Event Listener to fire the scroll event:
document.body.addEventListener('touchmove', function(){$window.scroll()}, true);
Tested and working on iPad 2 with iOs 5.1.1
I'm looking for a non-jquery solution to add a persistent footer overlay to my mobile site. It is similar to a popup ad that is on top of content but anchored to the bottom of the page.
I've been using a javascript approach to this:
window.addEventListener(
'scroll',
function() {
//if scrolled and offsets are the same (iphone)
if(_self.initOffsetY == window.pageYOffset)
{
document.getElementById(_self.id).style.bottom = _self.initWindowHeight - window.innerHeight+"px";
}
else
{
document.getElementById(_self.id).style.bottom = _self.initWindowHeight - window.innerHeight - window.pageYOffset+"px";
}
},
false
);
where initPage Height is the initial page height and initOffsetY is the initial offset of the page. This takes care of the case with the browser menu bar.
But it doesn't really work too well on android. The positioning is off. Can someone explain why? Thanks
You should probably use either of these standalone scrolling helpers:
http://joehewitt.github.com/scrollability/
or http://cubiq.org/iscroll
Wouldn't it be better to have two separate elements, a main wrapper and a footer div perhaps, and enable scrolling in just the wrapper (overflow:auto;)? This would avoid most browser inconsistencies, or even cases where JS is turned off.
There's a drawback though. You will need to program a method for scrolling inner elements for some mobile devices. There are libraries for this (gasp!), but frankly it isn't too hard to program yourself (as I've done with my site).
If you're attached to this approach of floating an element to where you want it / approximating position:fixed, you're going to have a number of things to check, one being html code that you've got to make sure there aren't any margins or padding interfering with the above script. The quick hack solution would be to just measure the heigh difference and calibrate your script according to that. The number you get from the calibration might be helpful in determining the source of the problem. There are probably some additional tricks to make this work smoothly, but I would go with a library thats being used already, and it looks like there are a number of them: http://bradfrostweb.com/blog/mobile/fixed-position/
btw - the iscroll4 library will fix the scrolling issue with overflow:auto on ios < 5, android < 4