Tag Archives: iPhone

Cheatsheet from today’s Open Web Camp “Refactoring for Mobile” talk

For the Open Web Camp attendees, here’s my cheatsheet from the Refactoring for Mobile talk I gave today at Stanford:

Get it as a CSS file and view it in your favorite code editor:


Or preview here:

The first thing we need is a media query and to add
<meta name="viewport" content="width=device-width,
minimum-scale=1.0, maximum-scale=1.0">
to the head:
@media only screen and (max-device-width:480px) {
For starters, note the two divs #wrapper and #contents.
Let's use those to create our structural layout and
fold back in some of those design elements.
#wrapper {
background:url(img/back2.png) no-repeat center top;
#contents {
margin:0 auto;
Now, let's style the main navigation buttons. First, we
will use inline-block to give block-like behavior to the
buttons but retain width based on the content. Then we set
the color, font size, and floating, and add a bit of box
.menu a {
padding:1em 0.95em;
border-left:1px solid #888;
-webkit-box-shadow:0px 1px 5px #222;
We can now use border-radius to style the left and right
buttons instead of image files:
.first_menu a {
.menu li:last-child a {
What if we flip to Landscape? There's a media query for
@media screen and (orientation:landscape) {
.first_menu a {
Now we can style the body content. #middle-contents is
the main containing block. We can use the background image
from the main stylesheet, but alternately we can use rgba
backgrounds to get finer control. Add border radius and box
shadow for depth.
#middle-contents {
/* background:url(img/side.png) repeat-y;*/
-webkit-box-shadow:0px 1px 6px #000;
box-shadow:0px 1px 6px #000;
Let's style the banner text and have some fun with it using
web fonts. Here's a font we'll pull in, using TTF and SVG formats.
Sadly, the vendors have many opinions on the solution, but
FontSquirrel can help sort it out.
@font-face {
src: url('Lobster_1.3-webfont.ttf') format('truetype'),
url('Lobster_1.3-webfont.svg#webfontcOtP3oQb') format('svg');
#logo a {
font-family:Lobster, sans-serif;
text-shadow:0px 2px 4px #000;
#logo h1 {
font-family:Lobster, sans-serif;
The float is creating a spacing issue. We can fix that
with a clear:
#header { clear:both; }
We are getting close. Now on to the bottom of the page.
The #comments section is too wide. We need to reset it:
#comments {
#comments textarea, #comments input {
border:1px solid #000;
That input button could be nicer:
#comments input.button {
margin:0 auto;
Now we have something that looks like it was meant for a
mobile device. Let's wrap this up by making the final
links look like tap-friendly buttons:
#right-col a {
background-image: -webkit-gradient(linear, left top, left bottom,
from(#666666), to(#666666), color-stop(.5,#333));
border:1px solid #000;
Maybe those final link items were over the top.
Let's restore them to inline links:
#copyrights a {
Now add some HTML5: Add placeholder="I think..." to the textarea in
comments.php, line 191.
Add input types to email and url fields.
Finish with atouch icon: <link rel="apple-touch-icon" href="piano.png"/>
(Note to attendees: I forgot to add the piano.png file to my project files.
But this works otherwise!)

iPhone icons

Here are some lovely PSDs available for download; excellent for picking apart how to create great iPhone icons:


(Found via http://twitter.com/flyosity/status/15798736074.)

This will be important for iPhone apps but even more important down the road (in my opinion) for web apps that have custom icons associated with them. If you’d like to learn more about this technique, full instructions for creating a custom desktop iPhone icon for a web page or web app are right here in Jonathan Stark’s excellent go-read-this-now book on building web apps with HTML, CSS, and JavaScript:


The gist of which is essentially you are creating a 57 x 57 icon and then adding one of the two following HTML lines to identify it:

The first option inherits the glossy light effect and corner radius from the iPhone OS. The 2nd one does not, so you have to handle corner radius and any desired light effects manually. iPad icons use 72 x 72 pixel resolution. I’m not sure yet, but I’m betting the new OS will have something closer to the 72 px size. Anyone know the answer?

Should academic paper publishing embrace EPUB?

Sometime last year I was considering home improvement options to our house, I was thinking about building a large, built-in bookshelf in our upstairs study area. I always loved to see lots of books on the wall, and really enjoyed pulling down a book to have a browse on whatever subject interested me from my own personal library. But there was all this discussion regarding ebooks, and I was thinking if this ever caught on big time, then printed books would eventually go the way of the dodo – the end of their 400-year cycle of greatness was at hand, and the new way to read anything was going to be on a digital screen.

I’ve since come to my senses. I love books – the binding, the texture of fine paper, the fact that it doesn’t require a battery or power cord, and even the smell are all plusses in my book. Books have been around a long time, and they’re here to stay. Ebooks are just another channel of distribution for such content, and I believe that both have their place in the modern era.

However, for academic research papers, I think we can safely kill the paper. Particularly, I think it should all begin moving towards the EPUB format. I read a lot of academic papers in my work, and I find myself wishing that more of this stuff were published as EPUBs. In contrast to my love of books above, I think academic research would largely be much better served in a purely electronic format. It’s already going that way from the reader’s point of view, right?

Typically, when academic papers get published electronically, the format of choice is PDF. Or in earlier days, PostScript. If you’re lucky, someone had the foresight to publish their paper as HTML. The advantage of a flexible format such as HTML is that you can resize the fonts. Text can flow. It’s easier to get a clean copy of a text or data segment out of HTML than it is from PDF for quoting in one’s own paper, because copying from PDF tends to yield horrific line break issues and other artifacts on the clipboard.

PDF is, I’m sorry to say, hard to read on smaller screens. PDF expects paper, and refuses to reflow itself into smaller screen sizes such as an iPhone or Android device form factor. It barely passes on the 1024 x 768 iPad screen. Anything smaller, such as most ebook readers, is going to be unacceptable. Having to zoom in and scroll left to right to read one line of text at a time on a mobile device is not what anyone would call a user-friendly reading experience.

EPUB by contrast works great on mobile devices. Using the Stanza reader on iPhone is quite comfortable. iBooks on the iPad platform is a joy to use.

After reading this tweet by Dave Gutelius today, I was reminded of how much I hate printing out all my academic papers in preparation for travel. Flying is reading time, and printing this stuff out and stuffing it in my backpack is time consuming, a waste of paper, and added weight that I don’t want to carry.

Stuffing those papers onto my iPad and using GoodReader is a step in the right direction. But still, all too often the PDFs are formatted for paper, not for screen, and I am still cursing the format. PDF usually assumes letter-sized or A4-sized paper, and most ebook readers have physically far smaller screen sizes. Far better I think to start providing EPUB options for academic research, so that folks like me who need ginormous fonts and such can read with greater ease.

Or, should it just go to straight HTML? At that point, papers might even be able to add a little functionality to the electronic reading experience – change variables in information graphics, show rendered 3D representations of models, and so on. EPUB doesn’t support anything fun like HTML5 DOM handling or Flash, although CSS3 might work depending on the EPUB reader’s implementation. Either way, PDF ain’t fitting the bill ebook readers, and I think this sort of format will be far more important in the coming months and years as ebook-capable mobile devices become more and more commonplace.

The madness of screens vs. browsers on the mobile web

This evening as I was doing some research on mobile web development, I got myself on a tear about the wild differences we face as web developers regarding screen sizes and default browser installations, and came up with this:

Make Model Resolution Default Browser Engine*
Amazon Kindle 600 x 800 NetFront
Apple iPhone 480 x 320 WebKit
Apple iPod Touch 480 x 320 WebKit
BenQ M315 128 x 128 Opera
HTC G1 320 x 480 WebKit
Kyocera Mako S4000 128 x 160 Openwave
Motorola Hint QA30 320 x 240 Openwave
Motorola Krave ZN4 240 x 400 Openwave
Motorola KRZR K1 176 x 220 Opera
Motorola RAZR V3 176 x 220 Opera
Motorola ROKR E2 240 x 320 Opera
Motorola SLVR L7 176 x 220 Opera
Motorola V980 176 x 220 Opera
Motorola VE240 128 x 128 Openwave
Motorola ZINE ZN5 240 x 320 WebKit
Nokia 6300 240 x 320 Opera
Nokia 2605 Mirage 128 x 160 Openwave
Nokia N81 240 x 320 WebKit
Nokia N810 800 x 480 Gecko
Nokia N82 240 x 320 WebKit
Nokia N95 240 x 320 WebKit
Nokia N96 240 x 320 WebKit
Palm Centro 320 x 320 NetFront
Palm Treo 680 320 x 320 NetFront
Palm Treo 750 240 x 240 Internet Explorer
Palm Treo 755p 320 x 320 NetFront
Palm Treo 800w 320 x 320 Internet Explorer
Palm Treo Pro 320 x 320 Internet Explorer
RIM Blackberry Bold 480 x 360 Blackberry Browser
RIM Blackberry Pearl 240 x 320 Blackberry Browser
RIM Blackberry Storm 480 x 360 Blackberry Browser
Samsung Behold T919 240 x 400 NetFront
Samsung BlackJack SGH-i607 240 x 320 Internet Explorer
Samsung Epix i907 320 x 320 Internet Explorer
Samsung Eternity SGH-A867 240 x 400 Openwave
Samsung Highnote M630 176 x 220 Polaris
Samsung Omina i910 240 x 400 Internet Explorer & Opera
Samsung Rant M540 176 x 220 Polaris
Samsung Rugby A837 176 x 220 NetFront
Samsung Saga i770 320 x 320 Internet Explorer & Opera
Samsung SPH-Z400 176 x 220 Obigo
Siemens SX66 240 x 320 Internet Explorer
Sonim XP3 128 x 160 Opera
Sony Ericsson C702a 240 x 320 NetFront
Sony Ericsson C905a 240 x 320 NetFront
Sony Ericsson TM506 240 x 320 NetFront
Sony Ericsson W595a 240 x 320 NetFront
Sony Ericsson W760 240 x 320 NetFront
Sony Ericsson X1 800 X 480 Internet Explorer & Opera

*Some service providers will opt to use a different browser than the ones listed here.

It is interesting to note the diversity on these fronts. Screen sizes are all over the map, and the browsers here are not the usual suspects we see on the desktop. As for browsers, while it is certainly possible on many of these platforms to install a different browser (Opera being the usual choice), most users don’t bother. Regardless, Opera is the dominant player in this space, with significant marketshare owned by all the other actors on the mobile stage. As I research this topic, the WebKit engine proves to be the vast trendsetter and it is interesting to see how many platforms besides the iPhone are picking this one up. And trends show that this landscape is evolving rapidly as mobile capabilities increase and users begin surfing the web on their mobile devices with greater and greater frequency. ABI Research sees web browser installations on smartphones expanding from 130 million in 2008 to 530 million by 2013. The mobile web is a vastly unexplored frontier in web design and we should start seeing more and more attention getting paid to this aspect of the online world.

Update: Amazon Kindle’s Basic Web is based on NetFront – table updated to reflect this.

iPhone and mouse events

PPK has written his impressions regarding his shiny brand-new Jesusphone. (I wonder did he get black or white?)

In his post, he tells us the initial reports for the behavior of mobile Safari with regards to things like documentation (missing), mouse event implications (game changing), and how the disjunct state of finger tapping and dragging compares with the continuous state of the traditional OS desktop mouse pointer. In particular, he points out the fact that the assumed ever-present mouse pointer (the little cock-eyed arrow which points black and to the upper left on Mac, and is white and points to the upper right on Windows) can no longer be counted on. And in fact, there is no icon any more. Your fingertip is it, my friend!

With the coming of the iPhone the mouse model has lost its inescapable logic. Mousemove, mouseover and mouseout (and even poor old :hover) have been downgraded to device-specific events that may not survive in the long run.

May not survive… hmmm, interesting impact. I think he could be right here.

But — and here lies the problem — these events are used in countless web sites and applications for a variety of purposes, and Apple simply cannot afford these sites not working on the iPhone.

Interestingly, so far Apple has found that it indeed can afford to dispense with Flash and Java on the iPhone platform, and while most complain that the checkbox isn’t complete, some argue that Apple is doing just fine and won’t be in any hurry anytime soon. Certainly demand for these babies has been extremely high so far. I would be interested to see how many of such sites absolutely depend on such functionality to work, and how many of those either change their site behaviors or create iPhone-friendly web presences as the demand for the mobile web increases. Wondering… but at the very least, things like these aforementioned mouse events – Flash, Java, and the like – are not yet queued up on Apple’s priority list, or else they chose to take the less-is-better approach. It is an interesting question: How much of the specifications do browser vendors adhere to on such a limited platform such as mobile devices? What is practical? What is feasible?