I found that in the source for onetrip, which is the only one of the "ready for iPhone" apps that I've found which is formatted correctly on the actual phone.
> I found that in the source for onetrip, which is the only one of the > "ready for iPhone" apps that I've found which is formatted correctly > on the actual phone.
On 6/29/07, David Cann <davidjc...@gmail.com> wrote:
> safari is assuming an 800px width. Anyone found a solution to this > yet?
Since the iPhone does not have a "window", it has to decide what width to use when it first renders the page in the zoomed-out mode. By default it renders it in 980 pixels wide, which they said they found the be the best number for most web sites. My assumption is that this number was also picked as it is just a little over 3 times the width of the iPhone. (Note there is an exception, if you connect to a .mobi domain the iPhone defaults to a viewport of 320.)
Often 980 is not the appropriate size -- for instance, some narrow pages (such as many single column word press blogs) will render with a huge amount of white space to the left and right. In theses cases, you can use a meta tag in the <head> to give the iPhone a hint as to what viewport size to use, for example <meta name="viewport" content="width=560" /> will render the initial window in a smaller width window.
If you give the hint <meta name="viewport" content="width=320" /> you will get no scaling which is appropriate for iPhone webapps. However, there is some question in my in my mind if this is the best technique, as if you are using the iPhone in horizontal orientation, the initial viewport will now be too narrow.
Instead, you may be able to use one of the other choices for viewport, which in addition to height is initial-scale (first loaded scale), user-scalable (boolean), minimum-scale (default 0.25), maximum-scale (default 1.6).
I think some experimentation is required as to what is the best approach. I suspect that something like <meta name="viewport" content="initial-scale=1.0" /> may be the best choice for iPhone webapps, as I think it will do the right thing at both orientations.
I'd test this myself tonight, but because of an AT&T activation SNAFU, I'll not have my iPhone activated until tomorrow, so if someone else can test some of these viewports, I'd appreciate it.
Thanks, Christopher, for ideas above on setting viewport to keep iPhone Safari browser from zooming out on every page, even when the HTML/CSS would permit the content to be shown without zooming out.
I have tried to test this on the "emulator" iPhoney, but it doesn't appear to work there.
What folks like me who don't yet have an iPhone in hand need to know include: (1) What apps on the Internet work on an actual iPhone without constant zooming -- please provide website so one can look at their HTML/CSS (2) Does the Viewport suggestion above work? Can you point to an Internet app that successfully uses it?
Anybody else noticing that Safari keeps reloading pages when I return to Safari after using other apps on the phone? I suspect this is a memory management issue, but it's very annoying and a bad user experience on AJAX apps. I ought to be able to keep several tabs open in the background at all times and return to them right where I left off. When you refresh the page on most AJAX apps, you're returned to the home page.
The slow JavaScript execution has really been bugging me, so I ran a speed test here:
On my dual G5, I get about 430 milliseconds, but on my iPhone, I'm consistently getting greater than 10,000 milliseconds!
It's clear now why their WWDC web app was so simple and really not web 2.0 or AJAX at all. Considering these fairly serious flaws is giving me hope that this is a temporary stop-gap measure on Apple's part while they are (hopefully) working on a Cocoa-esque API for us.
<Christoph...@iPhoneWebDev.com> wrote: > On 6/29/07, David Cann <davidjc...@gmail.com> wrote:
> > safari is assuming an 800px width. Anyone found a solution to this > > yet?
> Since the iPhone does not have a "window", it has to decide what width > to use when it first renders the page in the zoomed-out mode. By > default it renders it in 980 pixels wide, which they said they found > the be the best number for most web sites. My assumption is that this > number was also picked as it is just a little over 3 times the width > of the iPhone. (Note there is an exception, if you connect to a .mobi > domain the iPhone defaults to a viewport of 320.)
> Often 980 is not the appropriate size -- for instance, some narrow > pages (such as many single column word press blogs) will render with a > huge amount of white space to the left and right. In theses cases, you > can use a meta tag in the <head> to give the iPhone a hint as to what > viewport size to use, for example <meta name="viewport" > content="width=560" /> will render the initial window in a smaller > width window.
> If you give the hint <meta name="viewport" content="width=320" /> you > will get no scaling which is appropriate for iPhone webapps. However, > there is some question in my in my mind if this is the best technique, > as if you are using the iPhone in horizontal orientation, the initial > viewport will now be too narrow.
> Instead, you may be able to use one of the other choices for viewport, > which in addition to height is > initial-scale (first loaded scale), user-scalable (boolean), > minimum-scale (default 0.25), maximum-scale (default 1.6).
> I think some experimentation is required as to what is the best > approach. I suspect that something like <meta name="viewport" > content="initial-scale=1.0" /> may be the best choice for iPhone > webapps, as I think it will do the right thing at both orientations.
> I'd test this myself tonight, but because of an AT&T activation SNAFU, > I'll not have my iPhone activated until tomorrow, so if someone else > can test some of these viewports, I'd appreciate it.
Three issues that I'm still having: * Lack of the onmousedown event is blocking my custom div flick scroll... both horizontal and vertical. * When the user clicks on a text box, it automatically zooms in, but when exiting the text box, it doesn't automatically return to the zoomed out state. I'm testing if I can set the default size of the text box to be so large that Safari realizes it doesn't need to zoom in. * The incredibly slow JavaScript execution is making my YUI animations very choppy.
-d
On Jun 30, 9:11 am, Julian David <mobid...@gmail.com> wrote:
> Thanks, Christopher, for ideas above on setting viewport to keep > iPhone Safari browser from zooming out on every page, even when the > HTML/CSS would permit the content to be shown without zooming out.
> I have tried to test this on the "emulator" iPhoney, but it doesn't > appear to work there.
> What folks like me who don't yet have an iPhone in hand need to know > include: > (1) What apps on the Internet work on an actual iPhone without > constant zooming -- please provide website so one can look at their > HTML/CSS > (2) Does the Viewport suggestion above work? Can you point to an > Internet app that successfully uses it?
I have confirmed from an actual iPhone user that using <meta name="viewport" content="width=320" /> in the HTML <head> prevents the iPhone Safari browser from zooming out, as long as the body of the page does not have content wider than 320. The iPhone also appears to scale well when rotated.
We tried the <meta name="viewport" content="initial-scale=1.0" /> declaration in an actual iPhone and it did what it is supposed to do (scale up to the larger width), but we found it less preferable because it scaled things too much. For instance most lines of text longer than 12 characters at 10pt size wrapped.
Our conclusion is to use Christopher's first suggestion: <meta name="viewport" content="width=320" /> and then tweak/play if your application has special needs.
On 6/30/07, Julian David <mobid...@gmail.com> wrote:
> I have confirmed from an actual iPhone user that using <meta > name="viewport" content="width=320" /> in the HTML <head> prevents the > iPhone Safari browser from zooming out, as long as the body of the > page does not have content wider than 320. The iPhone also appears to > scale well when rotated.
I've found so far I'm unhappy with viewport of 320 in horizontal orientation. I want the visual size of the fonts in horizontal to be the same size as the fonts in vertical. I just want the text to be reflowed wider.
> We tried the <meta name="viewport" content="initial-scale=1.0" /> > declaration in an actual iPhone and it did what it is supposed to do > (scale up to the larger width), but we found it less preferable > because it scaled things too much. For instance most lines of text > longer than 12 characters at 10pt size wrapped.
> Our conclusion is to use Christopher's first suggestion: <meta > name="viewport" content="width=320" /> and then tweak/play if your > application has special needs.
That is too bad -- I was hoping inital-scale would do what I want and keep the font sizes the same in both orientations.
Have you tried any of the other viewport variants? user-scalable, minimum-scale, maximum-scale? How about font size tweaks using:
So, I don't have an iPhone, but I am trying to make my web app iPhone friendly, and I think this should be done, I have made a page that takes the querystring and puts it into meta viewport tags.
> Three issues that I'm still having: > * Lack of the onmousedown event is blocking my custom div flick > scroll... both horizontal and vertical. > * When the user clicks on a text box, it automatically zooms in, but > when exiting the text box, it doesn't automatically return to the > zoomed out state. I'm testing if I can set the default size of the > text box to be so large that Safari realizes it doesn't need to zoom > in. > * The incredibly slow JavaScript execution is making my YUI animations > very choppy.
> -d
> On Jun 30, 9:11 am, Julian David <mobid...@gmail.com> wrote:
> > Thanks, Christopher, for ideas above on setting viewport to keep > > iPhone Safari browser from zooming out on every page, even when the > > HTML/CSS would permit the content to be shown without zooming out.
> > I have tried to test this on the "emulator" iPhoney, but it doesn't > > appear to work there.
> > What folks like me who don't yet have an iPhone in hand need to know > > include: > > (1) What apps on the Internet work on an actual iPhone without > > constant zooming -- please provide website so one can look at their > > HTML/CSS > > (2) Does the Viewport suggestion above work? Can you point to an > > Internet app that successfully uses it?
I just tried creating an inital page with just and iframe set to 320 x 320 for the content and using the viewport(width=320) and it works like a champ.
On Jun 29, 6:09 pm, David Cann <davidjc...@gmail.com> wrote:
> I've tried both 100% and 320px wide, but neither is working. I think > safari is assuming an 800px width. Anyone found a solution to this > yet? > -d
The "viewport" is actually part of canvas, which is what WebKit leverages to do all it's funky magic. Quite simply: "The viewport is the part of the screen that you are currently seeing; everything you see from the webpage is part of the viewport."
Whereas the canvas is everything else: "The canvas is the part of the document the background-image is painted on. You can say it has an infinite height and width so you can't position something on it."
> Default view port width is 390px. It's easy to get too narrow if you're not careful. Need to specify viewport property. <meta name="viewport" content="widget=320" />
> Six view port properties that can be set.
> width, height, initialscale, user - scalable ...
> We'll need to take advantage of -"WebKit":http://webkit.org/-text-size-adjustment to make things legible after double tap. -wgetkit-text-size-adjust:none|auto|percentage
Anyway, that should give you some idea of what's going on. I find it odd that they're using a metatag rather than a CSS property applied to the body, but maybe that's something we should lobby the webkit folks on... ;)
Chris
On Jun 30, 9:59 am, dvogel <dlvo...@gmail.com> wrote:
> I just tried creating an inital page with just and iframe set to 320 x > 320 for the content and using the viewport(width=320) and it works > like a champ.
> On Jun 29, 6:09 pm, David Cann <davidjc...@gmail.com> wrote:
> > I've tried both 100% and 320px wide, but neither is working. I think > > safari is assuming an 800px width. Anyone found a solution to this > > yet? > > -d
> > Default view port width is 390px. It's easy to get too narrow if you're not careful. Need to specify viewport property. <meta name="viewport" content="widget=320" />
The actual default for non-.mobi domains is 980, which is why iPhone optimized web pages always appear so small on the screen. .mobi domains default to 320.
I've added <meta name="viewport" content="width=320"> to my site, and it seems to keep the page from initially displaying at less than 1:1. Based on reports from friends, anyway.
On Jul 1, 2007, at 3:52 PM, Christopher Allen wrote:
> On 7/1/07, Chris <chris.mess...@gmail.com> wrote: >>> Default view port width is 390px. It's easy to get too narrow if >>> you're not careful. Need to specify viewport property. <meta >>> name="viewport" content="widget=320" />
> The actual default for non-.mobi domains is 980, which is why iPhone > optimized web pages always appear so small on the screen. .mobi > domains default to 320.
On 7/1/07, Jeff Harrell <jefferyharr...@gmail.com> wrote:
> I've added <meta name="viewport" content="width=320"> to my site, and > it seems to keep the page from initially displaying at less than 1:1. > Based on reports from friends, anyway.
If you are going to do width=320, I'd highly recommend you also set user-scalable=0 (someone has reported that user-scalable=false may not work, but I've not confirmed it yet).
The reason why is that you'll find that after certain actions, in particular text input, that the scaling will go beyond 100%, making your page to require scrolling to use, or pinching to return back to the 320 wide.
I don't think this is the ultimate solution, as there are still issues with horizontal orientation that are being worked out, but using the above seems to solve 90% of them.
