The problem with using ‘stock’ scrolling is that applications that use sticky headers can’t effectively use the stock scrollbar, especially if the app also has to run on the desktop where the scrollbar is a big content hogging control and it just looks plain wrong to have a scrollbar next a non-scrolling region. Whatever the reasoning – the behavior sucks when you run into it and while I can appreciate the ideology behind it, it’s just not realistic to expect that you won’t need quality custom scrolling in a mobile Web app. The reasoning is that the stock scrolling is very efficient while custom scrolling is supposed to be confusing and also is a resource hog for battery life. Android 4.x and newer and even Windows Phone) do just fine with smooth scrolling by default, but iOS and old Android browsers need this special CSS hint to avoid the extremely choppy default scrolling.Īccording to rumors Apple does this on purpose to discourage custom scroll schemes in browsers to more or less force usage of the stock browser scrollbar. Most reasonably modern mobile browsers (ie. In order to get a div to scroll you have to use the –webkit-overflow-scrolling: touch style to force scrolling to work smoothly. position:fixed and –webkit-overflow-scrollingĪs I’ve written about before, iOS doesn’t do smooth tag scrolling by default. The content styling on the container is applied to most pages in the application, yet frequently the failure occurs only on a few or even just one of the content pages – even though the content is hosted in the same freaking scrolling container. Oddly though it’s not every page using the same scrollable content container layout. No amount of rotating and refreshing makes it work. When it happens the content appears to ‘stick’ where the page behaves as if there where no scrollbars at all – not on the page or the content area. It works fine even on an iPhone, but when running on an iPad more often than not (but not always – apparently it depends on the type of content) the content area will simply not scroll. To make this work I use absolutely positioned headers and footers (if used – typically for phone sizes only) using ‘fixed’ styling.Īll of this works great in desktop browsers and just about any mobile browser. The content area is wedged between the header and the footer (or the bottom of the document if there is no footer) and the content needs its own scroll functionality rather than what the built-in browser scrollbar provides. In typical mobile apps I create, I tend to have a header area, a content area and in some cases a footer area. I’ve run into problems with scrolling tags with iOS Safari on a number of occasions and each time, I end up wasting untold amounts of time.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |