Given that scrollTo actually works, it makes perfect sense for scrollX and scrollY to work. That's why I think it's an "excuse." Apple clearly knows about "scrolling" adequately to support the scrollTo API, but not adequately to tell you where you actually scrolled to once the scrolling is complete.
-- Yehuda On 7/30/07, Randy Walker <[EMAIL PROTECTED]> wrote: > > Useful or not, it's the only way to get a static header and/or footer. > I've heard from some that think that two-finger scrolling it's painfully > obvious and people will catch on fast. Others, like yourself, think it's > silly and pointless and Apple needs to do something. > I tend to fluctuate back and forth, depending on how well my development > is going. :) > > I have seen Apple videos that talk about and demonstrate two finger > scrolling in a web page. Can't remember which, since I have seen so many > different videos. > > Currently, I have both header/footer. I get two things with this; ability > to scroll without losing buttons at top/bottom, ability to add in an > alphabet for jumping to a letter in the list. Only implemented the latter > as div placement, no linking yet, but it stays put while the div underneath > is two-finger scrollable. > > Calling it a viewport isn't an excuse, it's the proper name for what it is > at the moment. I agree Apple needs to come up with a better solution. > Believe me, I agree! > > -=Randy > > > On 7/30/07 2:16 AM, "Manish Sharma" <[EMAIL PROTECTED]> wrote: > > 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] > <mailto:[EMAIL PROTECTED]> <[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 <http://Ie.is> <http://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 > <http://bugreport.apple.com> <http://bugreport.apple.com> , or just use > >>>> the form here: <http://developer.apple.com/bugreporter/ > > <http://developer.apple.com/bugreporter/><http://developer.apple.com/bugreporter/++%3Chttp://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 - > > > > > > > > > > > > > > > > > > > -- Yehuda Katz Web Developer | Procore Technologies (ph) 718.877.1325 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
