Anyway you're right.  Top and bottom Safari menus take up about 40
pixels each.  The top address bar goes away if you scroll, and we're
hoping that doing a software scroll of one pixel down will make it
automatically go away.  Or perhaps some activity.  Don't know.

As for the bottom menu, that's a real pain, and hopefully Apple has a
plan for that.  Not only does it use up valuable screen real estate,
but it gets in the way of the prime handheld directive of keeping our
buttons near the bottom.   But okay, if that's the way it is, then
we'll just need a buffer space and place buttons in the middle.   What
we don't want to happen, of course, is have users accidentally hit
Back and lose their work.

Kev

1.  Isn't there a javascript event for ondoubleclick?  Peraps Safari
will do strange things to it.
2.  There should also be some padding around form elements in general
to make it easier to click on the one you want.  Also a screen resize
event might get fired due to the keyboard popping up.  This means we
might want to have a event attached to each form element to handle it
special.
3.  The more I think about it I hope there is a nice way to make an
iPhone .css sheet and load it specifically.

more thoughts about safari on the iphone...

1.how will the iphone handle hover or mousover events? will they be
ignored??

2. will it support local pages , that access local files, such as the itunes
library?

3. will I be able to send a page as an e-mail or a link as an sms?

I guess I can wait until I have one in my hands...

--
Ⓙⓐⓚⓔ - יעקב   ʝǡǩȩ   ᎫᎪᏦᎬ

On Jun 19, 12:35 pm, HairyPotter <magnol...@gmail.com> wrote:

Based on product shots of iPhone blown up to have a screen width of
320 ...

The full screen height is 480.
The system status bar (time, wireless, battery, etc) is about 20.
The Safari title/address bar (top) is about 60.
The Safari toolbar (bottom) is about 45.

It would seem that the viewing area would be, at a maximum, equal to
what's left over after "permanent" elements are removed: "full -
status bar - toolbar = 415". But that's almost 20 pixels larger than
the GasApp report, a difference that cannot easily be attributed to
errors in image scaling.

Subtract the title bar and we're down to 355, or 40 pixels smaller
than the GasApp report; another huge discrepancy. So, 396 does not
appear to reflect the space between the Safari bars.

Interestingly, "full - system - title = 400", which matches the 396
well enough, but this would mean that the "viewable area" includes
space used by the bottom toolbar. That doesn't seem very viewable to
me.

What am I missing?

(Hmmm ... Maybe the toolbar can be hidden. I have no idea how you'd
toggle the hiding and showing, but this would neatly explain the
dimensions.)

--"Day Late" Don

So it would seem that when an app first appears, it would have:

   480 - 20 - 60 - 45 = ~355.

Then if you scroll and make the address bar disappear, you get back
60:

    480 - 20 - 45 = 415

And if the bottom menubar can be taken away,  we end up with the most:

    480 - 20 = 460

As you say, clearly something doesn't match that article.

Kev

On Jun 27, 1:28 pm, nroose <nro...@earthlink.net> wrote:

On Jun 27, 5:21 pm, Neven <neven.mr...@gmail.com> wrote:

On Jun 27, 2:36 pm, nroose <nro...@earthlink.net> wrote:

Also, how good is iPhoney (1.1) for testing?