Quarter Life Crisis

The world according to Sven-S. Porst

« UncontrolledMainGreat Writing »

iPhone Web Design

847 words on

The big disappointment at Apple’s recent developer conference was that they announced web applications as the way to develop applications for their new iPhone. I don’t think people seriously expected a full-blown SDK at this early point of the iPhone’s existence, but people were a bit annoyed by Apple pretending that web applications could compete with actual – presumably Cocoa based – applications.

While it is true, and proven over and over again by companies like Google or parts of the ‘web 2’ crowd, that you can do amazing things inside a web browser using JavaScript today, this still falls short of what native applications can do. The finer points of a good user interface are frequently lost when HTML and JavaScript are all people can use for their interfaces. Mac users need to look no further than their Dashboard to understand that. Dashboard widgets frequently don’t fit in with the system’s user interface standards. And don’t even get me started on how they quite reliably disappoint when it comes to aspects like localisation or number formats which are just taken as a given in ‘real’ Cocoa programming. I am sure that many of those aspects can be handled in web applications as well but doing so will require considerably effort.

And yet, I recently got the opportunity to help out with some CSS aspects of Karelia’s TeleMoose (née amaphone) iPhone web application. It delivers an iPhone optimised experience of amazon shopping: straightforward searches, usage optimised for the iPhone screen and – crucially – much shorter load times with the site coming in at 10-20% of the download size of the usual amazon site.

My first remark on this is that it is a joy. A joy to do CSS work without the what will IE6 do to this? question haunting you all the time and being able to use all the great stuff that WebKit supports – right down to rounded corners. That was quite cool.

Until Dan got to try things out on his iPhone fo real. Which revealed that iPhone’s Safari really doesn’t like two things: position:fixed and overflow:auto for items with a fixed height. With ‘doesn’t like’ essentially meaning ‘ignores’. And as the site was developed in the ‘Safari is your SDK’ spirit and was supposed to have elements fixed at the top or bottom of the screen with the page content scrolling above or below them, these CSS features were essential for making things work. Without them it’s not clear to either of us how we can display something like a search field or a button at a fixed position on the screen.

I ended up wondering what exactly Apple were thinking. As our knowledge is today – and it seems to be even richer than what Apple themselves now reveal about the iPhone’s browser – Apple didn’t just decide/manage to not have a SDK for the iPhone ready and allow third party applications. They furthermore seem to have disabled the very features in their web browser which could have enabled a web application (that is non-trivial / wants to display more than a single screenful of text) to create a decent UI.

With Apple presenting the web browser as the development environment for the iPhone I had fully expected a bit more commitment to that. All I can see is a tag to tell the iPhone to not render pages at the insanely wide width of 980px (a width which may be great for Apple’s recent redesign but which I usually find by far too wide for comfortable reading – particularly on sites with a fluid layout) and a few other simple display tweaks.

What I don’t see is a way to do anything that may make a web page seem worthy of a ‘designed for iPhone’ label. Like access to the orientation sensor say: most likely you don’t want to display a list vertically when the screen is in landscape mode – just as the iPhone’s iPod switches to CoverFlow mode on rotation because the list wouldn’t work well in landscape mode and CoverFlow wouldn’t work well in portrait mode.

Of course precise positioning of buttons at the bottom of the screen would be necessary for a good application, if only because it’s the only place where you can reach for buttons without covering other parts of the screen up with your fingers. But exactly that doesn’t seem to be possible. Ideally, I think, the iPhone should also allow ‘applications’ to replace or hide some of its browser UI chrome. Its screen may be large for a mobile device but it’s still quite small.

Have you done your own iPhone work? And discovered anything interesting or even solutions to these problems? Then please leave a comment!

And believe it or not, my cuddly elk Kalle has been all enthusiastic about the site’s name change. He ordered an iPhone, just so he can use it all day. Rumours go that he’s the one who pressured Karelia into altering the name.

Elk holding a TeleMoose sign

July 5, 2007, 0:19

Tagged as web design.


Comment by Christopher Allen: User icon

The document released by Apple this week only tells the beginning of the story of how to optimize web pages for the iPhone and develop webapps. The www.iPhoneWebDev.com developer community has been working hard to fill in the gaps of missing information. Since Friday we’ve figured out some best practices for viewport settings, discovered how to hide the URL bar to make more space available to web apps, how to detect orientation changes (portrait to landscape and back), tested AJAX and javascript performance, and have made progress on quite a few issues and work arounds for a number of bugs. If you are an iPhone web coder, check out our list archives, examples, and come join our community of developers helping developers!

Also, many of us are participating in this week’s barcamp-style www.iPhoneDevCamp.com this Friday in San Francisco. We hope to see you there!

July 5, 2007, 18:09

Comment by Mike Manzano: User icon

You can detect that the iPhone has been tilted:


July 5, 2007, 20:08

Comment by Pat Flor: User icon

…iPhone’s Safari really doesn’t like two things: position:fixed and overflow:auto for items with a fixed height.

position:fixed doesn’t work because there is no scrolling, per say; think of the iPhone screen as a resizable viewport that ranges over the “browser window”, which loads the whole page in one scroll-free screen no matter what the size. This is a good thing overall, as it allows for quick, smooth access to many pages that the previous standard-window-model mobile browsers made into a nightmare. However, fixed positioning is out the window for those of us who use it (I am in the same boat with an app I am working on).

My (untested) idea is that we’re going to have to target a script at iPhone similar to the one that we use to fix absolute positioning on IE 6 and earlier. Savor the irony =)

I hope I did this markdown business OK.

July 5, 2007, 21:07

Comment by Justin Williams: User icon

The position fixed issue is my biggest pet-peeve. The lack of tracking onkey events is annoying as well.

July 5, 2007, 22:44

Comment by ssp: User icon

@Christopher: all that sounds great! As there are too many thousand kilometres between me and San Francisco I can’t make it on Friday, but Dan may be there.

@Mike: Cool! Thanks for the pointer. Doesn’t work on the MacBook though ;)

@Pat: Yeah such scripts crossed my mind as well, but they’re, well, not very elegant. And I frequently see short delays in the repositioning of elements on pages which use such scripts. Which I wouldn’t want to have.

July 6, 2007, 1:02

Comment by Craig Hockenberry: User icon

The position: fixed is a real deal killer for “web apps” because they need the toolbar at the bottom (to avoid the finger shadow.) It’s pretty clear that everything else on the iPhone is not a web app because (a) they have toolbars at the bottom and (b) the toolbars don’t scroll :-)

Here is some testing I did to try and get a toolbar. The examples work fine in Safari 3, but fail in iPhone Safari:



July 10, 2007, 3:02

Comment by Craig Hockenberry: User icon

More in-depth commentary here:



July 11, 2007, 1:27

Comment by ssp: User icon

To be honest I don’t think that Safari/iPhone’s problems are accidental. They are exactly what Apple wanted. Even my opinion of Apple’s engineers isn’t so uncharitable that I’d suspect this happened by accident.

July 11, 2007, 1:53

Comment by futalu: User icon

iPhone’s Safari really doesn’t like two things: position:fixed and overflow:auto for items with a fixed height. With ‘doesn’t like’ essentially meaning ‘ignores’.

The part about overflow:auto is wrong. At first i thought the same because of the missing but expected scrollbars. But than i found out that the iphone just uses an not so obvious way to deal with that. You can scroll in the element by using two fingers.

July 21, 2008, 3:42

Add your comment

« UncontrolledMainGreat Writing »

Comments on




This page

Out & About

pinboard Links


Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.