As of now I'm running into an issue when it comes to testing a website on iOS devices. It seems a DIV element does not carry its overflow:hidden property well. Or at all, really.
This is what the site's layout should be (with the overflow-setting working):
This is what the layout is like on an iOS device:
I've tried many things, such as editing the body and html css overflow and/or position properties, adding a wrapper around the body tag and many more 'mainstream' solutions I came across while googling. None worked, sadly.
The CSS for the item not properly working on iOS is this:
width: 94.4%;
height: 400px;
overflow: hidden;
position: relative;
margin: 0px;
display: inline-block;
box-sizing: border-box;
How'd I know (or at least think) it's the overflow? As soon as I turn it off in the browser through inspecting the element, the issue happens.
Is there anybody who can give me some insight into the issue?
If you need any more information, I'd be happy to provide.
As Demnogonis suggested in a comment to my original post, I added
vertical-align: top
And now the layout is fixed on iOS devices.
Related
I have a native iOS app with a webview to display web content.
I have a fixed header in my app with the following properties:
#header {
height: 60px;
background-color: #mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: fixed;
width: 100%;
z-index: 1;
}
Before I upgraded to iOS 11 everything worked fine. Now when I scroll down/up the header disappears during the scroll, and when the scroll is done, the header appears again.
This can also be reproduced in Xcode 8.
I'm just writing some code, try with one by one
Try with below
self.automaticallyAdjustsScrollViewInsets = false
Try with below
[self.webView.scrollView setContentInsetAdjustmentBehavior:UIScrollViewContentInsetAdjustmentNever];
Try with below (change your code)
header {
height: 60px;
background-color: #mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: fixed;
width: 100%;
z-index: 1;
transform: translateZ(0);
-moz-transform: translatez(0);
-ms-transform: translatez(0);
-o-transform: translatez(0);
-webkit-transform: translateZ(0);
-webkit-font-smoothing: antialiased;
}
And some helpful links might be useful for you!
http://ayogo.com/blog/ios11-viewport/
https://forums.developer.apple.com/thread/90472
How to fix the iOS 11 input element in fixed modals bug
https://github.com/PierBover/ios-iframe-fix
https://stanko.github.io/ios-safari-scoll-position-fixed/
From Apple official note:
Important:
Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app. Do not use UIWebView or WebView.
So you should try once with WKWebView.
position: fixed has always been a problem with iOS. It seems that in every version of iOS the problem persists. Now, I couldn't find anything regarding the change of behaviour of your application from iOS 10 to 11, you could consider reporting this as a bug; on the other hand having seen the multitudes of people who encountered this problem and the fact that affects more or less all the recents versions of iOS I would suggest not to use position: fixed.
The most common workaround is transform: translateZ(0), this not only works on iOS and prevent any possible flickering, it also forces the browser to use hardware acceleration to access the GPU to make pixels fly. It should work also without the prefix -webkit- from iOS 9.
I had this very similar issue with a Cordova project built for iOS, which uses a webview. Cordova uses the UIWebView by default as its webview engine and I tried all the possible fixes mentioned in this thread and many others. Finally our only solution was to change the webview engine from UIWebView to WKWebView (https://developer.apple.com/documentation/webkit/wkwebview). With Cordova, introducing the WKWebView is pretty straightforward with a plugin https://github.com/apache/cordova-plugin-wkwebview-engine
After introducing WKWebView and dealing with some of the issues it causes we are no longer experiencing the flickering or disappearing fixed positioned elements while scrolling in iOS 11.
We had the similar issue and it got fixed with below 2 plugins
https://github.com/apache/cordova-plugin-wkwebview-engine
https://github.com/TheMattRay/cordova-plugin-wkwebviewxhrfix
First plugin will change default WebView to WKWebView and second plugin provide fix for CORS issue that we see for using WKWebView.
The trick is to force GPU acceleration. Do this by adding translate3d to the #header element.
transform: translate3d(0,0,0);
If elements nested inside the #header element continue to disappear add translate3d to them as well.
Position fixed doesn't work well with iOS, but I used position absolute in my cordova apps which never causes any issue for me.
You may have already seen this post on some changes in iOS 11, but if not maybe it would apply to your situation?
One of the viewport-fit: contain/cover/auto options?
Or changing your code to use a constant value for the padding-top?
Did you try to use position:sticky instead of position:fixed?
In past it works really well on iOS.
Please make note that is position:sticky requered rule top to be defined.
So final solution in your case should be:
#header {
height: 60px;
background-color: #mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: -webkit-sticky;
position: sticky;
top: 0;
width: 100%;
z-index: 1;
}
Also if you need extra offset from top you could adjust top:0; rule from zero to any number in px.
And one more final note: that is sticky element will not extract element from document flow and will act as ordinary document element (like div with position:static or relative), but not like absolute positioned element (in case of fixed or absolute).
http://caniuse.com/#feat=css-sticky
I have been battling against this very same problem myself.
The issue (at least as manifested in the app I am working on) only seems to happen on screens which are a combination of tall (in that they require a good deal of scrolling) and fairly complex.
Generally, at least for me, the problem only seems to really manifest when momentum scrolling kicks in.
Although there's one screen in particular, which contains 15 left-right-scrollable rows of images, that will break the head/footer no matter how slowly you scroll it.
In my own defense... I had absolutely nothing to do with the design. :-)
At any rate...
After much searching an experimentation, I have managed to come up with a "solution" of sorts.
Mind you, I'm not claiming this is the way to go here. But perhaps someone with more experience than I have in the mobile app space, can take this information and extrapolate something less sucky from it.
The first piece looks like this:
html,
body {
position: fixed;
width: 100%;
height: 100%;
overflow: hidden;
-webkit-overflow-scrolling: auto;
}
And then for the container that acts as the main body of your screen:
.main-content-area {
overflow-y: auto;
height: 100%;
}
This is going to kill momentum scrolling for your app. Which is not great, I know. But as a result of curtailing the user's ability to scroll very quickly, screen rendering seems to be able to keep up and the problem goes away.
Again, I'm not recommending this as a viable solution for production. Because it's obviously not great.
I'm offering this up more as a possible stepping-stone to a real solution, in the hopes that it helps.
===>>> UPDATE:
I have a working solution. But, as others before me have pointed out, I had to avoid the use of Fixed Positioning.
Instead, I used Absolute Positioning to define Header, Footer and Main Content sections of the page. Then allowed scrolling only in the Main Content section.
If it helps, I have the POC I put together available on BitBucket
this works for me
position: sticky
I had this same issue with both position:fixed and position:sticky. Chaging from UIWebView to WKWebView fixed it for me:
#import <WebKit/WebKit.h>
....
#property (weak, nonatomic) IBOutlet WKWebView *myWebView;
"Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app. Do not use UIWebView or WebView."
https://developer.apple.com/documentation/webkit/wkwebview
I'm trying to get momentum scrolling to work, by setting a class called momentum-scrolling on a top level div that wraps the part of the content that scrolls. The class is defined as:
.momentum-scrolling
{
overflow: auto;
-webkit-overflow-scrolling: touch;
}
Yet it is not working (testing in simulator on both iOS 7.1 and 8.1).
Here is a link to view the example on jsbin directly (suitable for viewing in a mobile device for testing):
http://jsbin.com/cewobokisi/1/
Here's the link to the editable stuff on jsbin:
http://jsbin.com/cewobokisi/1/edit?html,css,output
(Note that the CSS shown includes minified bootstrap, and a few other things. I left this like this because while it's a bit harder to edit, I was trying to reproduce the issue exactly as we have it in our site now, in case anything we're doing is causing the issue.)
Update
I've got a modified version here (http://jsbin.com/sibofucexe/1) where I've modified the .momentum-scrolling style to include position: fixed, height/width 100% (based on some other posts I found with momentum scrolling examples):
.momentum-scrolling
{
position: fixed;
height: 100%;
width: 100%;
overflow: auto;
-webkit-overflow-scrolling: touch;
}
And that does now allow for inertial/momentum scrolling to work!
However, now I lose the ability to tap on the top bar to scroll the window to the top, and occasionally I cannot scroll up or down (typically when the DOM is being manipulated by JavaScript, due to an ajax hit to add more data).
Any ideas on these issues? Am I doing this wrong?
I know this is a late reply, but for the sake of future Googlers:
According to CSS Tricks, you must use overflow: scroll rather than overflow: auto. That may cause your first example to work.
I am trying to finish my first website and thought it was pretty much finished but am having an issue with viewing some page layouts on an iPhone 5 (S and C). On my 4 it's fine and on an iPad I tested it on. Also fine on Android.
The issue is the fixed navbar (bootstrap) is bouncing around on the galley pages (it's a photography site) which have a horizontal scrolling div but it's ok on standard page layouts. I have disabled a mouse wheel plugin it's running to check if it's that and it has no effect on the iPhone 5 issue. Normal layout pages are fine.
the url is: http://www.pjrundle.co.uk
The problem occurs on any of the photography pages.
Sorry if this is a really obvious newbie question. Here is the css for the div containing the side scrolling gallery. I tried removing absolute positioning and no effect.
.scroll {
white-space: nowrap;
background-color: white;
padding-top: 73px;
position: absolute;
left: 0px;
}
Any advice greatly appreciated.
Thanks.
Thanks mijopabe, I fixed it in the end by adding:
.scroll {
white-space: nowrap;
background-color: white;
padding-top: 73px;
position: absolute;
left: 0px;
width: 100%;
overflow: auto;
}
Not really sure why it worked without this on other browsers to be honest but fixed anyway.
Cheers.
There's an iframe, which basically has more content than fits into the frame. The sizing of the frame is based on the browser screen size and lets the overflow scroll, which works perfectly on all browsers, except for iOS. On iOS, safari decides to resize the frame to fit the content. Not what you'd expect.
Example code on jsFiddle:
http://jsfiddle.net/R3PKB/2/
Try it out on your iOS devices:
http://jsfiddle.net/R3PKB/2/embedded/result
The HTML:
<div class="frame_holder">
<iframe class="my_frame">
// The content
</iframe>
</div>
The CSS:
body {
position: relative;
background: #f0f0f0;
}
.frame_holder {
position: absolute;
top: 50px;
bottom: 50px;
left: 50px;
right: 50px;
background: #ffffff;
}
.my_frame {
width: 100%;
height: 100%;
border: 1px solid #e0e0e0;
}
You can make it work by adding a wrapping div with overflow: auto; and -webkit-overflow-scrolling:touch;.
Here's your example with it: http://jsfiddle.net/R3PKB/7/
According to previous questions on SO it's a bug since iOS 4. I found more info here:
https://stackoverflow.com/a/6721310/1047398
iframe on iOS (iPad) content cropping issue
This is an old question, but since it comes first on google and the issue exists on nowadays ios devices, I repost a better fix that I found on this page:
How to get an IFrame to be responsive in iOS Safari?
Basically, if you have an iframe with scroll (let's say a twitter widget), the solution above won't work very well because it makes the parent scrollable. The fix that worked for me is replacing height: 100% with height: 1px; min-height: 100%;.
If iOS Safari is displaying your iframe content from a different origin than expected (i.e. it is shifted over by some pixels), try adding scrolling="no" as an attribute to the iframe. This should prevent it from automatically fitting its content.
More here.
using height: 1px; min-height: 100%; did not work for me, though I did not need a scrolling element. I had to use the overflow:auto; on a surrounding div instead. Note that this method is discouraged as it may have unintended consequences, but I tested on Android/iOS and desktop browsers and could not find any issues yet. fingers crossed.
This is a nice post from Andy Shora on some iOS iframe nuances: http://andyshora.com/iframes-responsive-web-apps-tips.html
I have attached two pictures, the first shows the "desktop" of the webapp I work on, some of the icons you see open dialogs made of a <div/> containing an <iframe/>, but while on a normal pc it all works properly, on the iPad it seems there is a problem with the z-index of some elements, as shown in second picture.
The small red rounds with number inside are defined as follows:
.countComunicazioni {
position: relative;
background: url(/images/admin/menu_sgs/counter.gif) no-repeat center center;
height: 35px;
width: 35px;
color: #FFF;
top: -105px;
left: 120px;
z-index: 0;
font-weight: bold;
display: none;
}
.countComunicazioni p {
margin-top: -5px;
padding-top: 10px;
}
The markup is a <div class="countComunicazioni"/> tag and a <p/> tag inside.
I also noticed that now the problem also appears in Google Chrome V22, the numbers in red circles are always on top even if they have z-index == 0 and the dialogs have z-index > 1000.
As per this bug report ( http://code.google.com/p/chromium/issues/detail?id=144518 ), the change seems to be intended, even if I would bet it'll broke many layouts, not only ours.
This problem was not present in previous versions of Google Chrome, nor is present on Firefox V15 or Internet Explorer V9, where everything is rendered problem.
How can this problem be solved? I'm no CSS expert, so I must admit I have tried little, if anything, so far... And also, who is "right" here? Is our markup incorrect, or does the problem lie in google chrome new rendering strategy?
EDIT
It seems I've been able to solve the issue shown in the two pics: all the dialogs generated from my web app are placed inside a <div/> with position:fixed placed on the very top of the body, now I tried to move the div to the very bottom of the page, and the layout seems now correct.
There is one more problem though: when opening a modal dialog, the opaque layer that is supposed to be created between the dialog and the below content, is actually created above it, see new screenshot.
How could this problem be solved? Does it require modifying our javascript or is it an issue with jquery ui itself?
Just found out myself that the way that chrome 22+ handles z-index has been altered.
Check out this awesome explanation here that I didn't write here...
http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements
Basically the way I understand it is that elements which have
position: fixed
now get counted with their own z-index layer so you'll have to adjust your pages accordingly to suit.
Hope that helps!