Open dcsan opened 9 years ago
I guess the question is around if there's a way to mix the modes a bit better or to limit the effect of the native scrolling to just target a single div.
using famous' own (still undocumented?) appMode
flag
appMode: false
it seems to break normal famous layout elements eg header and footer elements will get scrolled offscreen, even though they are not part of the target div with overflow setting.
other elements will naturally go off screen and force the layout to scroll.
perhaps applying position: fixed
and limitng the whole app to a div that is clamped to the screensize could fix some of this but wondering if you have a better solution.
appMode: true
and overflow-y scroll
on some divs, I get odd behavior that sometimes will scroll and sometimes not.
simple demo app posted here:
http://famous-appmode.meteor.com/story/1
click stories to get to that view.
if we could include famous in a normal web app and not break everything else it would make it much easier to use in a project.
Hi, I completely agree on this topic. I've had the idea of "native scrolling" in my mind for quite some time for now. Nothing beats native scrolling performance, even how hard we try in the Javascript world, I think.. I did some early tests with this a while back and ran into similar issues that you were having. Basically, every single issue will need to addressed properly in order for it to become a viable option. My idea is to add a "nativeScroll" option which you can set on the FlexScrollView and have it "just work". If I find some time, I really work to explore this idea further. Any ideas and solutions in this area are welcome, please post them here.
Btw, in your demo, the reason that it is sometimes not scrolling, is that there is another famous-div on top of it sometimes, capturing input events. Most of the time that famous surface is before the scrolling div in the DOM, but sometimes it is after the scrolling div. I'm not sure what that surface does, it doesn't have any styles or classes applied to it. Possibly you are laying out both those surfaces are not setting the z-translation on them, causing the DOM ordering to become relevant (and famo.us doesn't guarantee the ordering in the DOM).
Also, when I view the demo in Phone emulation mode in Chrome, the header and footer disappear. Not sure why that is.
thanks for the tip on the layers. OK i cleaned that up ( Transform.inFront stuff)
appMode: true
the app responds to the scrollwheel but not touch eventsappMode: false
touch events work, but your tabFooter gets confused and dragged up by the content at least in the sim
also browser scrollbars appear but I could probably fix that by putting all the famous content into another cropped div.
the scrolling here is pretty smooth tho, if we could get the tabbar to work
I'm worried that this is NOT what the famous engine is expecting tho, so it may break some other stuff. I'm sure they make true default for a reason.
I think the appMode setting has to be set when the engine is created, so here are two versions
http://ff-appmode-false.meteor.com/stories http://ff-appmode-true.meteor.com/stories
btw the source is also here https://github.com/dcsan/flowwy
the CSS (stylus) on that div looks like:
.vertDiv
background-color #7CFB74
overflow-y scroll
overflow scroll !important
height 50vh
border 1px dashed red
-webkit-overflow-scrolling touch
z-index 2 !important
margin 5px
because of some other notes around -webkit-overflow-scrolling
http://engineering.bergcloud.com/2013/06/android-chrome-and-webkit-overflow-scrolling-touch/
interestingly, in safari the footer doesn't seem to get messed up. in ios mobile simulator with appMode: false the text scroll works fine but tab bar is messed up by the overflowing content outside it.
but like i said i think we can workaround that but adding extra "cropping" layers may affect performance.
I tried rendering the app into a container
elem = document.getElementById("engine");
var mainContext = famous.core.Engine.createContext(elem);
and it changes much of the z-ordering. probably just hilighting problems in the app itself...
no container
with container
but it does fix the tab bar dragging problem. seems to create some performance overhead tho.
OK I got this basically working by starting the famous engine inside a container div the native scrolling now works pretty well and feels good.
however, the flex-view is triggering the "pull to reload" whenever I try and scroll down. This only happens on a device, not the emulator. (it's hard to capture in a screenshot as it happens quickly) This is on android.
http://moflow.meteor.com/story/1
new repo https://github.com/dcsan/moflow
famous-flex has some awesome sophisticated features, but I was wondering if you would add just a simple div with native scrolling, ie using
overflow: scroll
for simple html content the performance of this really can't be beaten. ff is a huge improvement over famous' internal scrollviews but it still feels a bit chuggy even with simple content on a high-end (android) phone.
Framework7 page explains this well http://www.idangero.us/framework7/#.VVkR4ZP2DdQ Native Scrolling It can sound even curious but one of the most important Framework7 feature is that it uses only native scrolling. Moreover - it multiplies its advantages! So you can still have this awesome scrolling with momentum and resistance bounce without any scrolling issues!
Ionic is also doing this afaik at least on android.
I did try just dropping in a div but famous CSS and other "features" always seem to take over such that it breaks normal browser behavior.