This stacking div strategy is simple to implement, but it is not useful for any serious application. Apple has never advertised two-finger scroll and the user is so pampered by the flick effect that this scheme might make your app look like from another planet. You may call it viewport or anything else, but these limitations call for more and more workarounds for serious app developers. Apple should seriously consider fixing/mitigating this issue/limitation.
...2 cents, Manish On 7/30/07, Randy Walker <[EMAIL PROTECTED]> wrote: > > > Ryan, > > What didn't work about the scroll divs? The scrolling or the ability to > keep a button bar at the bottom? Or both? > > I just reworked my layout and ran down to the Apple store and verified > that > stacking three fixed height divs on top of one another with the middle div > also set to overflow:auto will two-finger scroll the middle div just fine, > leaving me a static header & footer that don't scroll off the > screen. This > was without setting CSS position values. > > To get the Javascript scrollTo(0,1) to cause the address bar to go away, > the > page needs to be at least 1 pixel taller than the available screen height. > So in portrait mode, my stacked divs total 417px in height. (screen > height > = 416px when address bar is hidden). When my total height was exactly > 416px, then the scrollTo(0,1) didn't make the address bar go away and my > bottom div was too far down off the screen to be seen. > > Here's my three divs: > height:43px > height:334px;overflow:auto > height:40px. > > I was even able to use some scriptaculous/prototype effects to extend my > header downwards, covering the content scrollable div and not moving the > footer div, to reveal my search field. > > Now I know without a doubt I can make a side div for an alphabet. I will > have to replace my middle div with an iFrame so I will have a target for > my > alphabet links. > > -=Randy > > > On 7/28/07 6:30 PM, "RyanA" <[EMAIL PROTECTED]> wrote: > > > > > Nevermind... scroll divs do not work either. > > > > On Jul 28, 9:10 pm, RyanA <[EMAIL PROTECTED]> wrote: > >> If want a button bar at the bottom of your web page, create 2 divs > >> with absolute positioning, then set one for your top div to allow > >> overflow (scolling div) and set the bottom div to a fix hieght with > >> your buttons. > >> > >> -=Ryan > >> > >> On Jul 28, 6:26 pm, Randy Walker <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >>> What bug? Safari in iPhone is a viewport, not a window with > scrollbars, > >>> that slides up and down a static web page. Fixed positioning won't > work > >>> because as far as the page is concerned, the window has not been > scrolled. > >>> In fact, fixed positioning does work. Your element will render > exactly at > >>> the pixel it was intended to be fixed at at, however, it will not > 'stay' in > >>> place when flicking the screen because the browser has no idea the > viewport > >>> is moving over the content. The browser believes it is keeping the > fixed > >>> element exactly where it's supposed to be because to it, the page > hasn't > >>> moved. > >> > >>> I was unaware this was considered a bug. I think it sucks, but would > seem > >>> to be by design. It may change in the future, but for now it's > behaving the > >>> way a viewport behaves, which is different than a window. > >> > >>> If your web page is 3000 pixels high, Safari in iPhone will see the > whole > >>> height as a singular, non-scrollable thing. When zoomed in, it only > shows a > >>> portion of that page. When flicking the viewport up/down, it is not > >>> 'scrolling' as we are used to thinking of scrolling. > >> > >>> Having said that, the only ways (that I've heard of so far) of fixing > an > >>> element into place is by using frames, iframes, or a combination of > fixed > >>> height divs, with the div you want to be scrollable being set to a > specific > >>> height and its CSS set to include 'overflow:auto.' That way, you can > >>> specify a fixed height header div, fixed height middle div set to > >>> overflow:auto, and a fixed height footer div where you would put your > bottom > >>> nav buttons. The combined height of all three divs must equal the > total > >>> height available in the viewport. Ie.is the top Safari bar present or > not? > >>> Are you in portrait or landscape? etc. The scrollable middle div > will only > >>> be scrollable via a two-finger up/down movement and won't be > 'flickable.' > >> > >>> -=Randy > >> > >>> On 7/28/07 9:28 AM, "Dan Wood" <[EMAIL PROTECTED]> wrote: > >> > >>>> The only suggestion I can make is to file a bug with Apple (join the > >>>> apple developer connection and use bugreport.apple.com, or just use > >>>> the form here: <http://developer.apple.com/bugreporter/ > >>>> bugrptform.html>) and wait for them to fix the problem. They are > >>>> definitely aware of the issue but the more people who complain, the > >>>> higher they will prioritize a fix. > >> > >>>> On Jul 28, 2007, at 8:53 AM, Chris Minks wrote: > >> > >>>>> The site I am working on has a page like the contacts screen on the > >>>>> iPhone. It has a long list of items and at the base of the page it > has > >>>>> a navigation bar (like the 5 buttons below your contacts). The > problem > >>>>> is, you have to scroll the entire page to get to the nav. Any tips > on > >>>>> how to keep the nav in place, while allowing the rest of the page to > >>>>> scroll? > >> > >>>>> Thanks in advance- Hide quoted text - > >> > >>> - Show quoted text -- Hide quoted text - > >> > >> - Show quoted text - > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en -~----------~----~----~----~------~----~------~--~---
