Is it possible to add momentum/intertia scrolling to a trigger.io-wrapped HTML5 iOS app?
I'm currently building a basic app, and noticed that the Webview does not respond to the momentum of a swipe action when scrolling through content (iOS 6; iPhone 5). In other words, a slow swipe and a fast swipe end up scrolling to the same section of the Webview (unlike a native app, where said fast swipe should scroll to a farther section).
Is it possible to change this behaviour and make it more native-like? I have tried following these iOS momentum scrolling instructions and modifying the CSS as shown below, however this doesn't work:
html {
overflow: scroll;
-webkit-overflow-scrolling: touch;
}
As a workaround I feel that I could potentially use an intertia-emulating JS library within my webview, however I want to avoid this option if possible.
Thanks in advance!
I don't know much about your app's css, but -webkit-overflow-scrolling: touch; would only give the touch scroll inertia to fixed or absolute elements with fixed height/width in the viewport. Applying -webkit-overflow-scrolling: touch to the body or html element would only work if you did something like
body {
position:fixed;
top:0;
right:0;
bottom: 0;
left: 0;
overflow: auto;
-webkit-overflow-scrolling: touch;
}
We use it in our trigger app to emulate UITableView
Yes. Try out Hojoki where you can see momentum scrolling in action:
https://itunes.apple.com/us/app/hojoki/id525010205?mt=8
You don't have to do anything special to enable momentum scrolling in iOS. If you're not seeing it then it is likely that some styling or 3rd party library you're using as intefered with it.
Yes. I've managed to implement it with iScroll but had to modify the library. I really don't recommend -webkit-overflow-scrolling: touch as it does not render any DOM changes while momentum scrolling is occuring. So if you reize an element as a result of an element scrolling, it looks awful.
Here is my repository where I've added a new callback onScrolling() to alert when the scrolling animation is occurring in iScroll: https://github.com/simpleshadow/iscroll/blob/master/src/iscroll.js
And here's an example I'm using in my Trigger.io app where I change the height of the div during momentum and touch scrolling: http://jsfiddle.net/simpleshadow/wQQEM/22/
Related
I'm encountering a strange issue only on Safari iOs 13. I have an element which has horizontal scroll (native scroll, overflow-x: auto).
On iOs 13, when I scroll this area, when an element outside the viewport comes in the viewport, first it's hidden, then flickers and becomes visible.
Here's a screencast of this issue: https://imgur.com/a/Y2Lz2GH
You can see it live: https://www.thebackpackerz.com/agenda/concerts-rap-paris/
My guess is that's related to iOs 13 new features :
Added support for one-finger accelerated scrolling to all frames and
overflow:scroll elements eliminating the need to
set-webkit-overflow-scrolling: touch.
Changed the default behavior on iPad for wide web pages with
responsive meta-tags that require horizontal scrolling. Pages are
scaled to prevent horizontal scrolling and any text is resized to
preserve legibility.
But well, right now, it's like a bug to me. Any idea to patch this?
I also had the same issue and after trying different solutions i came up with this.
.bottom-nav-wrapper {
position: fixed;
width: 100%;
overflow-x: scroll;
overflow-y: hidden;
}
And in this wrapper you can place your cards/elements for horizontal scrolling.
I am developing an application in Cordova, where the user can switch between a few 'screens', which are just hidden divs brought into view by a transition.
The scrolling on iOS has been terrible, so I added -webkit-overflow-scrolling: touch to the container element and it sorted out the scrolling issue I had.
However, since then the page transitions cause the pages to flash each time the application moves to a new page.
Here is my CSS
.scrollable {
overflow: scroll;
-webkit-overflow-scrolling: touch;
}
Once a button is pressed to proceed to the next page it uses this javascript code for the transition
this.lastScreen.getLayout().getElement().css({
'left': -$(window).width(),
'transition': 'left 0.25s ease-out'
});
this.currentScreen.getLayout().getElement().css({
'left': 0,
'transition': 'left 0.25s ease-out'
});
<div class="container scrollable">
//screen content here
</div>
If I remove the -webkit-overflow-scrolling: touch; from the scrollable class it works fine, no flash happens. However, the scrolling of the page is terrible.
I am running iOS 9.3.1. I read around and found out this may have been an issue from iOS 8+ but can't really find a difinitve answer to help me
I suggest you to use native transitions with cordova´s app.
http://plugins.telerik.com/cordova/plugin/native-page-transitions
Add this CSS to the classes that have transitions:
-webkit-transform: translate3d(0px,0px,0px);
It just force hardware acceleration, so it become smoother than the normal one, and probably fix your issues
This question requires some explaining, so please bear with me.
Contrary to popular belief, inertia scrolling (the very smooth 60fps scrolling) is not enabled on web pages in Mobile Safari by default. As it makes a world of difference in user experience, I have enabled it by dynamically applying this CSS to the HTML and BODY element of the page, after a Modernizr test for iOS specifically:
<style>
.touchscroll {
overflow: auto;
-webkit-overflow-scrolling: touch;
position:relative;
height:100%;
}
.touchscroll body {
height:100%;
overflow: auto;
-webkit-overflow-scrolling: touch;
position:relative;
}
</style>
The above basically makes the body element a scrollable element and by means of -webkit-overflow-scrolling: touch, one gets the smooth intertia scrolling effect on the entire page. Some more background on this solution can be found here (disclaimer: article by myself).
It works, so far, so good. The problem is that this solution effectively disables another highly desired behavior of Mobile Safari: normally, when scrolling down, it will make the address bar smaller, and hide the bottom bar of the browser entirely. They re-appear when scrolling back up.
Unfortunately, the above technique disables this for some reason. Yes, we've got super smooth scrolling, yet the browser bar is always large and the bottom bar permanently stays visible, both taking up valuable space.
My question therefore is, can I have both? I want the super smooth scrolling on the entire page, yet I also want the default hiding behavior of browser elements when scrolling.
An example of a site where I am using this is here:
http://www.jungledragon.com/
If you open that in Mobile Safari, you will see the smooth scrolling, yet not the hiding of browser elements when scrolling down.
I think you're setting both the <html> and the <body> element to scroll. You should apply these CSS rules to 1 element you want to be able to scroll.
So either the html or body, not both.
To setup an off-canvas menu I have to set the body to "overflow:hidden" to remove scrolling from the body and add it back in to a container around the content with "overflow-y:scroll". When I do this it seems to slow the scrolling on mobile specifically iOS devices.
Is there some sort of performance issue with moving the scrollbar from the body?
Rather than a performance issue this is likely that your not seeing 'Momentum' scrolling on your iOS device
This can be solved by adding '-webkit-overflow-scrolling:touch' to your scrolling element i.e:
.scrolling-content {
overflow-y: scroll;
-webkit-overflow-scrolling: touch;
height:100%; /*A value other than height:auto needs to be set*/
}
By default iOS devices use 'momentum' scrolling on the body but adding 'overflow-y:scroll' to an element does Not set a element to 'momentum' scrolling by default
See https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling for more info
Note: there's a number of Gotcha/Bugs with using -webkit-overflow-scrolling: touch on certain browsers
I'm building a mobile app for IOS, with html5. I'm using "-webkit-overflow-scrolling: touch" to get the native inertia scrolling, but it's very buggy. I've solved the issues with content not rendering until the scrolling stops, but one persistent bug is this:
When I try to scroll up and down, nothing happens, but when I try to scroll horizontally, the content scrolls vertically (90 degrees off axis). If I navigate around my app and come back to the page, it will sometimes be fixed. Also, sometimes it won't scroll at all, despite being full of content.
From what I've googled, the consensus seems to be that Apple is aware of this bug, and has no intention of fixing it any time soon. Has anyone found a solution to get -webkit-overflow-scrolling to work correctly?
I also have struggled with this bug for months. The best characterization that I've found is:
https://bugs.webkit.org/show_bug.cgi?id=87391
which says that it happens when the page has an iFrame and the contents are set from Javascript. My current workaround in The Graphics Codex version 1.6 is to use iScroll4 to explicitly scroll the page rather than using touch scrolling. Because Javascript is single-threaded, this can be slow if you're also performing animations or background loading content.
I encountered the same problem: a node using -webkit-overflow-scrolling: scroll that would intermittently scroll up/down only with a left/right scroll gesture.
Here's what I found to be possible causes:
iframe present on the page anywhere, visible or otherwise (source)
visibility: hidden applied to any parent of the scrollable node (source)
However, none of these situations were present in my web app. I had a scrollable <ul> inside of a pure CSS modal dialog that I wrote which used a clever trick to add a transparent underlay -- an ::after pseudo-element with position: fixed.
When I removed the position: fixed from the pseudo-element, the problem went away! Of course, this made my clever trick useless, but it was interesting to learn that this bug could be triggered by this situation.
Device: iOS 5.1.1 on 2012 iPad 3 (retina)
Offending code:
/* Underlay */
.dialog::after {
z-index: -1;
position: fixed; /* <--- This was the problem! */
top: 0;
left: 0;
right: 0;
bottom: 0;
background-color: rgba(0,0,0,0.4);
content: "";
}
tl;dr: if containing elements have a fixed position pseudo-element, removing it could fix your scrolling problem.
I know that the issue is kind of old, but I had to make my website work on iOS 5. Unfortunately i couldn't remove nor replace the iframe. I've noticed that the presence of iframe caused the problem only if it was rendered before the element which was ment to scroll smoothly. Appending iframe to the document later (after the element with -webkit-overflow-scrolling: touch) fixed the problem :)