position:fixed solution?
Matthew
for iPhone. Obviously, the desire to have a fixed toolbar at the top
or bottom is going to almost a requirement for many web app
developers.
So, the first thing that came to my mind was to manually keep
positioned elements fixed via JavaScript. No luck here either!
If you pull up http://www.quirksmode.org/viewport/experiments/scrolling2.html
in your iPhone you'll note that none of the following work:
pageXOffset and pageYOffset
document.body.scrollTop and document.body.scrollLeft
Has anyone found a work around?
Come on Apple, if you're going to state that Safari for the iPhone is
as powerful as the desktop version, please enable it to do basic CSS2
and JavaScript functions!
codeninja
position your header and footer absolutely at the top and bottom of
the page, then place your content in an auto scrolling div which fits
between them. Steps would have to be taken to resize the content div
on orientation change, but there has been good progress on that front
in this forum.
Dallas
On Jul 3, 12:36 am, Matthew <mkriva...@gmail.com> wrote:
> As it's already been mentioned position:fixed is not working in Safari
> for iPhone. Obviously, the desire to have a fixed toolbar at the top
> or bottom is going to almost a requirement for many web app
> developers.
>
> So, the first thing that came to my mind was to manually keep
> positioned elements fixed via JavaScript. No luck here either!
>
> If you pull uphttp://www.quirksmode.org/viewport/experiments/scrolling2.html
dean.j.robinson
with auto-scrolling divs? I'm guessing probably not.
This one thing is a real pain for me, I've got fixed 'toolbars' both
top and bottom on http://hahlo.com , but due to the problems with
"position:oh-hai-im-fixed-but-not-on-teh-ifone" I've changed them back
to just being at the very top and the very bottom of the (sometimes
quite long) page. In my opinion this ruins the 'app' feel of the site.
Influence
> as powerful as the desktop version, please enable it to do basic CSS2
> and JavaScript functions!
I think this was conscientious design decision by apple to avoid
cluttering the limited 480px height. Just imagine some 200 pixels high
position:fixed navigation control on top of a page ... doesn't leave
much room for the content.
As a workaround (in case even auto-scrolling divs won't work), have
you thought about using a clipped div and do the scrolling yourself?
This on the other hand could mean losing the two finger scrolling
capability...
Anyway, some overview of the changes made to WebKit/Safari for better
user experience with small screens and touchscreen input would help
very much. This should have been released by Apple long ago (or at
least on launch date, if they have to keep everything secret),
including some comments about the reasoning behind each change.
Johannes
Influence
> as powerful as the desktop version, please enable it to do basic CSS2
> and JavaScript functions!
I think this was conscientious design decision by apple to avoid
Matthew Krivanek
The clipped div solution is definitely works as it's what I'm doing
currently but I was hoping to have the iPhone natively handle the
scroll.
Just a thought, perhaps iFrames will work. Not the most desirable
solution, but I'll try and let everyone know.
[mk]
Matthew Krivanek
I've posted an example here: http://matthewkrivanek.com/launchpad/experiments/test1.html
Note: You must use two fingers in order to make the div scroll.
>From a usability perspective I don't see how users would intuitively
know to use two fingers for a scroll. On most web pages, using one
finger makes the page scroll. How are we to go about educating the
user on how to do this? Provide instructions in the app? Not a very
desirable solution to me.
I guess another alternative is to implement some form of Javascript
scrolling solution as David Cann did for his Digg app. Thoughts?
[mk]
Christopher Allen
> Ok. I-frame solution didn't work, but the auto-scrolling div works.
> I've posted an example here: http://matthewkrivanek.com/launchpad/experiments/test1.html
>
> Note: You must use two fingers in order to make the div scroll.
Very nice -- I'll have to look closer at your technique here. I've
never used clipped divs before.
> >From a usability perspective I don't see how users would intuitively
> know to use two fingers for a scroll. On most web pages, using one
> finger makes the page scroll. How are we to go about educating the
> user on how to do this? Provide instructions in the app? Not a very
> desirable solution to me.
>
> I guess another alternative is to implement some form of Javascript
> scrolling solution as David Cann did for his Digg app. Thoughts?
I think that supporting two-finger scrolling, but also having some
simple buttons that click to scroll one item up and down may end up
being the best idea.
-- Christopher Allen
Justin Williams
On Jul 3, 9:55 am, "Christopher Allen" <Christoph...@iPhoneWebDev.com>
wrote:
>
> I think that supporting two-finger scrolling, but also having some
> simple buttons that click to scroll one item up and down may end up
> being the best idea.
>
Are you concerned with user backlash over forcing two finger
scrolling?
-
Justin Williams
http://www.carpeaqua.com/
http://www.secondgearllc.com/
Matthew Krivanek
knowing that two finger scrolling exists, and when to use it versus a
single finger scroll. For the majority of web pages on the iPhone a
single finger scroll works just fine...
[mk]
-
Matthew Krivanek
http://www.launchpadhq.com
http://www.matthewkrivanek.com
bdj21ya
deal with Apple not even telling us about this stuff. Two-fingered
scrolling is never mentioned ANYWHERE in Apple's docs that I know of,
and certainly not on their development page.
I really can't see any good reason not to enable position:fixed. It's
just annoying, some items should be allowed to float over the page if
we're to have any hope of making apps with a good user experience.
Randy Walker
repositioning an element back to the top of the visible area when it's
scrolled out of site? However, since it's a viewport and not a window, is
the 'top' always the very top most part of the page and not the viewable
area? In other words, do we know what that top viewable pixel line number
changes to (if anything) when the page is scrolling?
-=Randy