Archive: April, 2011

Andy recently published 320 and up, a fork of Mobile Boilerplate that inverts his previous boilerplate media queries i.e. now it starts with the small-screen styles and layers on the styles for larger widths, rather than beginning with larger-width styles and nullifying them for smaller screens.

This is definitely the best way to apply width-specific styles, be it with media queries or with JavaScript. But I get a little nervous when I see pixel values that correspond to specific device widths: 320 pixels, 480 pixels, etc.—it’s certainly an improvement on relying on one mythical width like 960 pixels, but I worry that it still means crafting the display of content to match the dimensions of currently fashionable viewports. This is what Mark describes as the “canvas in” approach:

It’s my belief that in order to embrace designing native layouts for the web – whatever the device – we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out.

Now it may well be that your content is pixel-based—images or video perhaps—and the dimensions happen to correspond to the viewport widths of specific devices, but in my experience most of the content I deal with is still very much of the written word variety …and pixels aren’t necessarily the best unit for dealing with text. That’s one of the reasons why I tend to use em-based media queries.

My basic point is that it should be the content that dictates the media queries. For some sites, it might be appropriate to only serve up a linearised layout to very small screens while applying a columnar layout for slightly larger devices like tablets. For other sites, tablet-sized screens should get a linearised layout—it all depends on the content.

One of my favourite examples of content-out thinking is Dan’s article on type-inspired interfaces. I think there’s a general agreement amongst web designers that we should be designing from the content out but there’s still an over-reliance on canvas-in tools like predefined grids. Likewise in the world of wireframing and information architecture, when we should be concentrating on the content we often gravitate towards designing the menus and navigation first.

This is something that Luke talked about with Jared recently, mentioning his design principle of “content first, navigation second.”

Luke has famously advocated a mobile first approach to web development, which is a great way of focusing on what’s most important to deliver to the user. But don’t take it too literally. In some ways it would be equally viable to try out “print-stylesheet first” or any other “non-desktop environment first” strategy. The key point is that you’re thinking about the content first and foremost:

Losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business. There simply isn’t room for any interface debris or content of questionable value. You need to know what matters most.

That isn’t to say that you can’t serve up some extra nice-to-have content to wider screens, but that should be added on—possibly with conditional lazy loading—rather than having everything including the kitchen sink thrown in from the start.

Mobile web design has already established a number of excellent best practices whereas traditional “desktop” web design has become the domain of laziness and complacency. The result is a web of bloated documents with buried content, as documented in Merlin’s Flickr set, Noise to Noise Ratio:

Sure. There’s definitely some excellent original work in there — in the middle of all those ads and self-links and chrome and value-added “journalism.”

Yeah. Keep looking. No, seriously. There’s gotta be something in there.

Right?

There’s a general agreement that the “mobile” user is not to be trifled with; give them the content they want as quickly as possible ‘cause they’re in a hurry. But the corollary does not hold true. Why do we think that the “desktop” user is more willing to put up with having unnecessary crap thrown at them?

Unnecessary page cruft is being interpreted as damage and routed around with tools like the Readability bookmarklet, Safari’s Reader functionality, and Instapaper. These services exist partly to free up content from having a single endpoint but they also serve to break content free from the shackles of stifling overwrought containers. This isn’t anything new, of course; we’ve been here before with RSS. But the existence of these new reader-empowering tools should be taken as a warning …and a challenge—how can we design for our content in such a way that the reader won’t need or want to reach for Readability or Instapaper?

Some of the worst offenders in creating bloated content-crushing designs—often news sites—have separate mobile versions, usually at an m. subdomain. There the content is served up without the frills, cruft and pagination of the “desktop” version. I’ve started noticing that when people are sharing links—via Twitter, email, or whatever—it’s often these leaner m. versions that are getting passed around …precisely because they are often easier to read, no matter what device you’re using.

We’ve been here before, as I pointed out in a comment to Paul’s misguided post on mobile design:

In the bad ol’ days, it was common practice to create a “separate but equal” text-only site for screenreader users. It ghetto-ised those users and it was, frankly, a cop out. These days, it’s understood that screenreader users should get the same content as everyone else, but that the site should be built the right way to begin with. (interestingly, some sites noticed that “regular” non-screenreader users were choosing to go to the “accessible” version because it was faster and simpler—there’s a lesson to be learned there for those who still think of desktop and mobile sites as different things)

Needless to say, I disagree completely with this proclamation from Jakob Nielsen:

Desktop computers and mobile devices are so different that the only way to offer a great user experience is to create two separate designs — typically with fewer features for mobile.

I’m perplexed by the reasoning that concludes that if a website is suffering from clear usability issues, the solution is to create a splinter site for some users while leaving everyone else to suffer on. Note that I’m not suggesting that everyone get the same experience—far from it. Thanks to progressive enhancement (and let’s face it, responsive design done right is a perfect example of progressive enhancement) we can serve up the content that people want and display it to the best ability of any particular device.

That’s the key difference: start with the content, not the device.

This is a really exciting time for web design. The increasing diversity of devices is throwing into sharp relief just how complacent and wrong-headed our traditional fixed-width bloated desktop-centric approach has been. As with any period of change, there’s plenty of nervousness too. People are scrambling to figure out how best to deal with mobile devices:

• “Should I be learning Objective-C?”
• “Should I be mastering HTML5?”
• “Should I be learning a mobile app framework?”

You could be doing any or all of those things. But don’t skimp on the content strategy.

Reminder: the usual caveat applies.

Creating telephone answering systems can be fun as I discovered at History Hack Day when I put together the Huffduffer hotline using the Tropo API. There’s something thrilling about using the human voice as an interface on your loosely joined small pieces. Navigating by literally talking to a machine feels simultaneously retro and sci-fi.

I think there’s a lot of potential for some fun services in this area. What a shame then that the technology has mostly been used for dreary customer service narratives:

Horrific glimpse of a broken future. I sniffed while a voice activated phone menu was being read out and it started from the beginning again.

There’s been a lot of talk lately about injecting personality into web design, often through the tone of voice in the microcopy. When personality is conveyed in the spoken as well as the written word, the effect is even more striking.

Have a listen for yourself by calling:

• 206-504-2025 from within the States or
• +990009369996101162 on Skype.

That’s the number for Customer Service Romance:

What happens when Customer Service bots start getting too smart? What if they start needing help too? How would they use the tools at their disposal to reach out to those they care about? What if they start caring about us a little too much?

It’s using the Voxeo service, which looks similar to Tropo.

The end result is amusing …but also slightly disconcerting. You may find yourself chuckling, but your laughter will be tinged with nervousness.

On the face of it, it’s an amusing little art project. But it’s might also be a glimpse of an impending bot-driven algorithmpocalypse.

My trip to Shanghai went swimmingly. It kicked off with W3C Tech, which was a thoroughly lovely event.

I gave my talk—The Design Of HTML5—with the help of an excellent interpreter performing consecutive interpretation. It was my first time experiencing that—I had previously experienced simultaneous interpretation in Spain and Japan—and it was quite a good exercise in helping me speak in complete, well-formed sentences (the translation usually occurred at the end of a sentence).

Once my talk was done, I took some questions from the audience and was then showered with good wishes and tea-related gifts. They really made me feel like a rockstar there; I’ve never had so many people want to have their picture taken with me or have me sign their copies of my books—the publishers of the Chinese translations of DOM Scripting and Bulletproof Ajax were also at the conference.

W3C Tech was held on the east side of the river so I spent the first few days in the futuristic surroundings of Pudong. Once the event wrapped up, myself and Jessica moved across to a more central location just off Nanjing road. I quite liked the hustle and bustle, especially once I remembered the cheat code of “bu yao!” to ward off the overly-enthusiastic street merchants. I wish there were something similar for the chuggers here in the UK, but I have the feeling that the literal translation—“do not want!”—will just make me sound like a lolcat.

Anyway, I had a great time in Shanghai, doing touristy things and taking lots of pictures. I particularly enjoyed getting stuck in at street-level exploring the markets, whether it was electronics or food. The fried dumplings—sheng xian bao—were particularly wonderful. I plan to deliver a full report over at Principia Gastronomica.

So long, Shanghai. ‘Till the next time.

There is little to do on the bus ride from Brighton to Heathrow other than to listen to an iPod. So that’s exactly what I did on Thursday morning, using the time to catch up on some podcasts.

I listened to a Radiolab short called Pass the Science featuring the author Richard Holmes. Robert Krulwich positively raves about his book The Age of Wonder.

Immediately after that, I listened to an interview with Freeman Dyson. I had to grit my teeth through the climate denialism to get to the good bits about his spaceship designs.

During the interview, the subject of books came up. I knew that Dyson occasionally reviewed a book or two, having read his article about James Gleick’s The Information. He mentioned that one of the finest books he had recently read was …The Age of Wonder by Richard Holmes.

The coincidence was too much. I decided I had to have this book. I jotted down the name of it in my notebook. Then I remembered …I had my Kindle with me.

Risking motion sickness, I turned it on just long enough to navigate to Amazon and download the book, overcoming my loathing of its hateful DRM.

Just to recap: based on recommendations received through audio signals sent from a handheld device that stored time-shifted conversations, I connected to a global network of machines to exchange currency and download a file onto another handheld device—all whilst travelling in a moving vehicle.

Living in the future feels pretty cool.

It was even cooler when I entered a heavier-than-air metal craft that was capable of counteracting the force of gravity long enough to take me halfway around the world in just half a day.

Wandering around Shanghai in a semi-jetlagged state also feels like living in the future—given timezone considerations, I kind of am in the future—and it also feels pretty cool.

The problem with seeing so many new sights and experiencing so many new experiences is that I have grown used to sharing them with the world via Twitter. Alas, the Great Firewall of China was forcing me to go cold turkey.

But then Jessica discovered something: it turns out that the 3G Kindle can circumvent China’s censorship (for now). My feeling of disconnectedness vanished the moment I pulled up mobile.twitter.com and saw the beautifully mundane updates from my friends across the world.

I still hate the DRM and I still have issues with the ludicrous pricing models of digital books but that’s twice now in as many days that the Kindle has given me something more than just a good reading experience.

It’s been good to be back in Brighton—especially over the past few days while Tantek has been around—but now it’s time for some more travel …and nipping up to the first day of UX London doesn’t count.

I’m going to Shanghai. Shanghai! I know, right‽

Ostensibly, the reason I’m going to Shanghai—I just like repeating that—is to speak at an event called W3C Tech this weekend. But I’m not about to turn around and hop on the first flight back, so I’m going to be spend the week afterwards being a tourist.

I fully expect to culture shocked but I’m really looking forward to this. So many things to see! So much food to try!

If you’re familiar with the megacity, I’d love to hear your suggestions. Feel free to leave a comment (that’s right: comments!) and assuming adactio.com isn’t blocked by the great firewall of China, I’ll check out your recommendations.

Oh, and on the subject of the dodgy web situation, I’m guessing you won’t be seeing any Twitter updates from me for a while. Also, if you send me an email, you probably won’t get a response any time soon …that’s got nothing to do with censorship; I’m just crap at responding to email.

旅途愉快!

If you look at my profile page on Huffduffer, this is what you’ll see:

• my details,
• what I’ve huffduffed,
• links to subscribe to my podcast and
• my tag cloud.

That’s the core information for that page, preceded by a header with site navigation and followed by a footer with some additional links.

Because I’ve provided a URL with my details, there’s some extra information displayed in the sidebar:

• my other profiles on the web, as determined by Google’s Social Graph API,
• MP3s recommended by Last.fm,
• my latest updates on Twitter.

It’s a similar situation if you look at a piece of audio I’ve huffduffed. The core information is:

• all the details about the audio (title, description, tags),
• who else has huffduffed this,
• possibly-related items and
• links to share and embed the audio.

In addition, because I’ve used a machine tag—book:author=cory doctorow—the sidebar contains:

• related articles from The Guardian,
• sales information from The New York Times,
• books on Amazon.

In both cases, this supporting information isn’t essential; it’s just nice to have.

There’s a potential performance problem though. Because this extra information is coming from third-party services—and despite the fact that I’m doing some caching—it could delay the display of the whole page. So I took some time on the weekend to adjust the architecture a little bit. Now the extra information is requested with Ajax once the core information has already loaded. This is lazy loading.

Now I’ve introduced a dependency on JavaScript, which is far from ideal, but because this is just “nice to have” information, I think it’s okay if it isn’t seen by a subset of visitors.

In fact, because this extra lazy-loaded stuff takes up valuable screen real estate, I think it might be acceptable to only serve it up to visitors who have the screen real estate to accommodate it:

if ($(document).width() > 640) {
// do lazy loading here
}

So if you load my profile on a small screen, you won’t see my latest tweets or my Last.fm recommendations. Likewise if you look at something I’ve huffduffed that’s tagged with music:artist=radiohead you won’t see information from Last.fm, pictures from Flickr or albums on Amazon unless you load the page with a wide enough viewport.

Now it could be that the real issue here isn’t viewport size, but connection speed …in which case I’m making the classic error of conflating small screen size with limited bandwidth. A script like Boomerang, which attempts to measure a user’s connection speed, could be very handy in this situation.

Lazy loading is the new fold

I was chatting with James about the implications that lazy loading could have for earlier phases of the design process: wireframing, page description diagrams, and so on.

Traditionally, you’ve got only two choices when judging what content to include: either something is on the page or it isn’t. You can use hierarchy, position and contrast to emphasise or de-emphasise the content but fundamentally, it’s a binary choice. But with conditional lazy-loading there’s a third option: include some content if the user’s circumstances warrant it.

Once again, Luke’s Mobile First approach is a useful thought experiment. It can help prioritise which elements are core content and which could be lazy-loaded:

Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn’t room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.

So when a team designs mobile first, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today’s desktop-accessed Web sites. That’s good user experience and good for business.

Sometimes there are political reasons for wanting the “extraneous detours and general interface debris.” Lazy loading for large-screen users could be the least worst option in that situation. Semantically speaking, the kind of content that might be marked up in an aside element might be a good candidate for lazy loading …if the viewport is large enough.

I have a feeling that we’re going to be seeing a lot more of lazy loading as the responsive web design revolution rolls on. Used judiciously, it could provide plenty of performance benefits. But if it’s taken too far, lazy-loading could be disastrous, resulting in sites that rely on JavaScript to load their core content—I’m looking at you, Twitter.

Yesterday I documented the way I invoke media queries on Huffduffer while making sure that desktop versions of Internet Explorer get the layout styles. There’s an alternative way of serving up layout styles to IE that doesn’t involve splitting up your stylesheets.

Supersmart Scott Jehl has written a handy script called Respond that’s a textbook example of a browser polyfill:

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will

In the case of Respond, you just need to make sure that you close every min/max-width media query declaration block with a comment:

/*/mediaquery*/

The script then executes those blocks if the specified conditions are met. You can see it action on the demo page.

The advantage of using this solution is that you don’t have to split up your styles into two documents (one for content styles, one for layout). The disadvantage is that it introduces a JavaScript dependency.

Use whichever solution works best for you, but note that two things remain constant:

You should still begin with linearised styles and only apply float and width declarations within media query blocks—think Mobile First (though I think of this as device-independence first).

You might still want to use a conditional comment to pull in Respond to avoid the extra HTTP hit for non-IE browsers. In that case, you may as well use the same clause to stop IE Mobile from parsing the script:

 <!--[if (lt IE 9) & (!IEMobile)]>
 <script src="/js/respond.min.js"></script>
 <![endif]-->

When I met up with Malarkey right before An Event Apart in Seattle he told me about a quick bit of guerrilla testing he had been doing. He popped into a store selling Windows Phone 7 devices and started surfing the web. Specifically, he started looking at sites using responsive design like Jon’s and Colly’s.

Most of the sites he looked at displayed the desktop layout instead of adapting to the smaller dimensions of the screen. That’s because the rendering engine for Windows Phone 7—some bastard hybrid of IE7 and IE6—doesn’t support media queries. So if you’re using media queries to undo width and float declarations, the media queries won’t be executed.

A better option is to begin with the layout-less version and use media queries to add in width and float declarations for the browsers that are wide enough to get that layout—this is kinda like Luke’s Mobile First approach. But if you do that, versions of Internet Explorer less than 9 won’t get those layout declarations even though the browser window is wide enough (IE9 is the first version to support media queries).

On Huffduffer I get around this problem by using conditional comments. First of all, I split off the layout styles into a separate stylesheet that is called with a media query in the link element:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">

(This isn’t ideal because now there is an extra HTTP request, but hear me out.)

Older browsers—including plenty of mobile browsers—won’t download the layout stylesheet so they’ll just get the linearised content. That’s all well and good but it leaves Internet Explorer out in the cold. Using a conditional comment, I can point older versions of IE to the same layout stylesheet:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if lt IE 9]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

Now older versions of Internet Explorer also get the layout styles. This would all be fine and dandy except for the fact that Windows Phone 7 will also get the layout styles because it will understand the conditional comment. Curses!

But with one little tweak to the conditional comment, we can tell Windows Phone 7 not to follow the link:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if (lt IE 9)&(!IEMobile)]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

That’s why Huffduffer serves up the layout styles to desktop versions of Internet Explorer but just gives the linearised layout to Windows Phone 7 …as observed by Andy in an AT&T shop on a rainy afternoon in Seattle.

All of this should become moot by September when word has it that Microsoft will upgrade the engine of Internet Explorer Mobile to be closer to IE9. Until then, this combination of stylesheet separation and conditional comments is the most robust way I’ve found to target as many layout-capable browsers as possible.

In his talk at the Lift conference last year Kevin Slavin talks about the emergent patterns in trading algorithms, the bots that buy and sell with one another occasionally resulting in events beyond our comprehension. It’s a great, slightly dark talk and I highly recommend you watch the video.

This is the same territory that Daniel Suarez explored in his book Daemon. The book is (science) fiction but as Suarez explains in his Long Now seminar, the reality is that much of our day to day lives is already governed by algorithms. In fact, the more important the question—e.g. “Will my mortgage be approved?”—the more likely that the decision will not be made by a human being.

Kevin Slavin mentions that financial algorithms are operating at such a high rate that the speed of light can make a difference to a company’s fortunes, hence the increase in real-estate prices close to network hubs. Now a new paper entitled Relativistic Statistical Arbitrage by Alexander Wissner-Gross and Cameron Freer has gone one further in mapping out “optimal intermediate locations between trading centers,” based on the Earth’s geometry and the speed of light.

In his novel Accelerando, Charles Stross charts the evolution of both humans and algorithms before, during and after a technological singularity.

The 2020s:

A marginally intelligent voicemail virus masquerading as an IRS auditor has caused havoc throughout America, garnishing an estimated eighty billion dollars in confiscatory tax withholdings into a numbered Swiss bank account. A different virus is busy hijacking people’s bank accounts, sending ten percent of their assets to the previous victim, then mailing itself to everyone in the current mark’s address book: a self-propelled pyramid scheme in action. Oddly, nobody is complaining much.

The 2040s:

High in orbit around Amalthea, complex financial instruments breed and conjugate. Developed for the express purpose of facilitating trade with the alien intelligences believed to have been detected eight years earlier by SETI, they function equally well as fiscal gatekeepers for space colonies.

The 2060s:

The damnfool human species has finally succeeded in making itself obsolete. The proximate cause of its displacement from the pinnacle of creation (or the pinnacle of teleological self-congratulation, depending on your stance on evolutionary biology) is an attack of self-aware corporations. The phrase “smart money” has taken on a whole new meaning, for the collision between international business law and neurocomputing technology has given rise to a whole new family of species—fast-moving corporate carnivores in the Net.

After spending almost a month on the other side of the Atlantic, it was nice to return to Brighton to find it in the first bloom of Spring. Just a day or two after I returned, I was able to enjoy a nice wander around the Spring Harvest food festival sampling the culinary delights and randomly bumping into fellow geeks like Aral, Steve and Mark.

Such is the scenius of Brighton. There’s always plenty of smart folk around to gather together with, as evidenced by the multitude of geek gatherings like Build Brighton, dotBrighton and UX Brighton. Last night it was the turn of Skillswap, expertly organised by James.

Skillswap hasn’t been about swapping skills for quite a while. Instead it has morphed into a curated evening of related short snappy presentations sometimes followed by an ensemble Q and A. Last night’s theme was Skillswap Seeking Stories and it was a humdinger.

Phil Gyford expounded on his wonderful Pepys’ Diary project and how it has been nurtured over time. Gavin O’Carroll spoke about Spacelog—one of my favourite sites—and the structure of narratives, games and websites. The marvellous Matthew Sheret, who really impressed me at History Hackday, wrapped it up with a demonstration of the power that each of us has to use the internet to tell stories with our data. “You are Time Lords!” he exclaimed, and illustrated his points with some lovely artwork he commissioned from Tom Humberstone.

It was very generous of Phil, Gavin and Matt to give up their time and travel down from London to deliver such a fantastic evening of thought-provoking entertainment. Seriously, it was better than some paid conferences I’ve been to. And—thanks to the sponsorship from Madgex—there was free beer (“free” as in “free beer” …as in “beer!” …as in “free beer!!”).

Anna was working her podcasting magic, recording the talks. You can subscribe to the Skillswap Huffduffer account if you want to hear them once they’re ready.

Paul Irish, Divya Manian and Shi Chuan launched Mobile Boilerplate recently—a mobile companion site to HTML5 Boilerplate.

There’s some good stuff in there but I was a little surprised to see that the meta viewport element included values for minimum-scale=1.0, maximum-scale=1.0, user-scalable=no:

Setting user-scalable=no is pretty much the same as setting minimum-scale=1.0, maximum-scale=1.0. In any case, I’m not keen on it. Like Roger, I don’t think we should take away the user’s right to pinch and zoom to make content larger. That’s why my usual viewport declaration is:

Yes, I know that most native apps don’t allow you to zoom but I see no reason to replicate that failing on the web.

But there’s a problem. Allowing users to scale content for comfort would be fine if it weren’t for a bug in Mobile Safari:

When the meta viewport tag is set to content="width=device-width,initial-scale=1", or any value that allows user-scaling, changing the device to landscape orientation causes the page to scale larger than 1.0. As a result, a portion of the page is cropped off the right, and the user must double-tap (sometimes more than once) to get the page to zoom properly into view.

This is really annoying so Shi Chuan set about fixing the problem.

His initial solution was to keep minimum-scale=1.0, maximum-scale=1.0 in the meta viewport element but then to change it using JavaScript once the user initiates a gesture (the gesturestart event is triggered as soon as two fingers are on the screen). At the point, the content attribute of the meta viewport element gets updated to read minimum-scale=0.25, maximum-scale=1.6, the default values:

var metas = document.getElementsByTagName('meta');
var i;
if (navigator.userAgent.match(/iPhone/i)) {
  document.addEventListener("gesturestart", gestureStart, false);
  function gestureStart() {
    for (i=0; i<metas.length; i++) {
      if (metas[i].name == "viewport") {
        metas[i].content = "width=device-width, minimum-scale=0.25, maximum-scale=1.6";
      }
    }
  }
}

That works nicely but I wasn’t too keen on the dependency between the markup and the script. If, for whatever reason, the script doesn’t get executed, users are stuck with an unzoomable page.

I suggested that the script should also set the initial value to minimum-scale=1.0, maximum-scale=1.0:

var metas = document.getElementsByTagName('meta');
var i;
if (navigator.userAgent.match(/iPhone/i)) {
  for (i=0; i<metas.length; i++) {
    if (metas[i].name == "viewport") {
      metas[i].content = "width=device-width, minimum-scale=1.0, maximum-scale=1.0";
    }
  }
  document.addEventListener("gesturestart", gestureStart, false);
}
function gestureStart() {
  for (i=0; i<metas.length; i++) {
    if (metas[i].name == "viewport") {
      metas[i].content = "width=device-width, minimum-scale=0.25, maximum-scale=1.6";
    }
  }
}

Now the markup still contains the robust accessible default:

…while the script takes care of initially setting the scale values and also updating them when a gesture is detected. Here’s what’s happening:

1. By default, the page is scaleable because the initial meta viewport declaration doesn’t set a minimum-scale or maximum-scale.
2. Once the script loads, the page is no longer scalable because both minimum-scale and maximum-scale have been set to 1.0. If the device is switched from portrait to landscape, the resizing bug won’t be triggered because scaling is disabled.
3. When the gesturestart event is detected—indicating that the user might be trying to scale the page—the minimum-scale and maximum-scale values are updated to allow scaling. At this point, if the device is switched from portrait to landscape, the resizing bug will occur because the page is now scaleable.

Jason Weaver points out that you should probably detect for iPad too. That’s a pretty straightforward update:

if (navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPad/i))

Mathias Bynens updated the code to use querySelectorAll which is supported in Mobile Safari. Here’s the code I’m currently using:

if (navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPad/i)) {
  var viewportmeta = document.querySelector('meta[name="viewport"]');
  if (viewportmeta) {
    viewportmeta.content = 'width=device-width, minimum-scale=1.0, maximum-scale=1.0';
    document.body.addEventListener('gesturestart', function() {
      viewportmeta.content = 'width=device-width, minimum-scale=0.25, maximum-scale=1.6';
    }, false);
  }
}

You can try it out on Huffduffer, Salter Cane, Principia Gastronomica and right here on Adactio.

Right now there’s still a little sluggishness between the initial pinch-zoom gesture and the scaling; the scale values (0.25 - 1.6) don’t seem to take effect immediately. A second pinch-zoom gesture is often required. If you have any ideas for improving the event capturing and propagation, dive in there.

Update: the bug has been fixed in iOS 6.