When making a scrollable div, for iOS devices, momentum scroll doesn't work - so you must use the 'beta' -webkit-overflow-scrolling: touch; property.
However, this seems to crash the browser for me - not immediately, but seemingly randomly. Removing all of the -webkit-overflow-scrolling: touch; properties stop the browser from crashing.
I've tried using iScroll, touchSwipe, and a few other plugins that I can't remember the name of, but have either been too cumbersome to implement (I have a very short timeframe for development) or haven't worked as desired.
Does anyone experience the same problem, and if they have, have you found a solution?
I happened to me on bigger list with about over 100 elements.
When I removed it it works, but without the momentum scrolling ofcourse.
I tested on iOS5 and latest iOS6, on both an iPod Touch 4.1 and iPad 2, it seems that on the Touch I get the Safari crash more often, but on the iPad it also happens.
It seems like an Apple bug they didn't properly solve.
I noticed this happening when I had it applied to multiple elements on the page... I dropped it down to being applied only on the "active" div, and it doesn't crash anymore. Lame.
let content = document.querySelector(".content");
if (content.scrollTop <= 0) {
content.scrollTop = 1;
} else if (content.scrollTop >= content.scrollHeight - content.clientHeight) {
content.scrollTop = content.scrollHeight - content.clientHeight - 1;
}
Related
Since iOS10, there seems to be a problem with the CSS border-image attributes.
I used to work with something like this:
border-image: url('data:image/png;base64,somedata') 30 30 30 stretch;
However, since updating to iOS10 on iPad (and I would guess on iPhone as well), the border-image is no longer visible, leaving it transparent.
This happens with Safari and Chrome browsers on iPad.
Here's a fiddle so you can see how it behaves on iPad vs computer:
https://jsfiddle.net/g99y6pg3/1/
I also tried with a border-image: url(filename.png) instead of data:image/png, but got the same result.
Thanks for your help!
You need set property 'border-color' = 'white'
I've been working on a new responsive website, and when I start testing in on IPad, I found that it was crashing consistently (tested on IOS 6, IOS 7 and IOS 7.1.1).
After a few hours, I found that what was causing the crash was this CSS instruction:
-webkit-backface-visibility: hidden;
I was able to create a sample on jsfiddle that replicates this issue:
http://jsfiddle.net/CBqCH/6/
In our case, we were using that style on a listing page, that has for ex: 500 items..
Is this a known issue? Or am I 'styling' it wrong?
Looking at your css/fiddle its like your adding this like this:
*{ -webkit-backface-visibility: hidden; }
Or in other words you are adding it on all the divs...
NEVER target all elements (of course it will crash if you're calling multiple), only the ones you need to.
But if not this it seems, that it is common using these css on iOS:
Mobile Safari on iOS crashes on big pages
http://www.dimshik.com/ios-7-runs-out-of-memory-when-using-webkit-transform/
I'm working on some CSS being used in a UIWebView in iOS. I'm able to round the corners of a div in iOS 6 using the border-radius property, but I can't replicate the effect in iOS 5.1 using either border-radius or -webkit-border-radius properties. Is there a workaround, or am I doing something wrong? Here's the CSS.
#ad-wrapper {
postion:absolute;
top:50%;
left:50%;
margin-left:-140px;
margin-top:-109px;
width:280px;
height:218px;
position:absolute;
overflow:hidden;
-webkit-border-radius:12px;
border-radius:12px;
}
which works for iOS 6:
but not for iOS 5.1:
I'm brand new to web development (having done mostly native iOS before this), so any help is appreciated.
For iOS 5, I was able to fix it by applying -webkit-border-bottom-left-radius, bottom-right-radius, etc. to the correct sub elements.
I'd still like a better fix, as just using the single corner radius in one place is a much cleaner solution, but I may have to settle for this.
I am using a parallax effect with javascript but I'm having issues with iPad.
I know the "$(window).scroll" is not triggered on webkit touch devides - only when we release the screen - so i'm using:
window.addEventListener("touchmove", triggerScroll, false);
function triggerScroll(event)
{
var scrollTop = $(window).scrollTop();//event.touches[0].pageY; //window.pageYOffset();
$("#allCanvas .divCanvas").each(function(index, element) {
var speed = $(element).data('speed');
var initialTop = $(element).data('initialtop');
$(element).css('top', initialTop-(scrollTop*speed));
});
}
The problem is that it flickers the .divCancas a few pixels to the top or bottom depending if I'm scrolling to top or down.
I tracked the TOP value passed on $(element).css('top', initialTop-(scrollTop*speed)); and it's every time correct. The correct "TOP" value, eventhough webkit move it for a few milleseconds to the wrong position.
I tried also:
-"margin-top" rather than "top" with no difference.
-Removing all other objects and making the ".each" loop through only one div, so I guess is not a jQuery performance issue.
Has anyone came across this problem?
Many thanks
Diego
Maybe try using some of the -webkit css animation features... these run very smoothly on iOS devices. Here's a great demo of that (webkit only): http://jibjub.com/demo/HTML5/cube.html
This is a curious one.
I have an IBOutlet UIScrollView playScrollView whose height is exactly 1/3 of it's contentSize's height. The app is in landscape. I call this code...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, page * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
... (the int page ranges from 0 to 2) to start on page 1 (displaying the middle third) then go up or down as needed when the user presses buttons.
This works fine for iOS4 both device and simulator, and has been live on the app store for months with no problems. Even iOS5 devices are fine with existing builds, it was only when the app was recompiled for iOS5 that it stopped working correctly on iOS5 devices.
Since updating to XCode 4.2, This doesn't work for iOS5. It goes one page too low, showing the bottom page when it should show the middle. I can get the code to work for iOS5 (device and simulator) by changing page to (page-1)...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, (page-1) * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
...but of course this breaks iOS4, which works fine with the old code, but gets stuck one page too high with this new code. iOS4 and iOS5 are exactly PLAY_VIEW_PAGE_HEIGHT out-of-step (288 pixels, a third of the height of playScrollView). The same thing happens if I use setContentOffset: instead.
One other curious thing, probably the key to this. If I don't do the scrollRectToVisible at all, then iOS4 sits at the top of playScrollView, wheras iOS5 shows the middle third, (ie PLAY_VIEW_PAGE_HEIGHT pixels down).
I could detect the iOS and use different code for each, but that's a horrible kludge. If it's an iOS5 bug and they fix it in a future release, that would break the live app.
Has anyone any ideas, or noticed anything similar? Thanks.