How the iPhone Will Save Web Standards

Today, Apple has announced the beta release of Safari for Windows – the browser that will be shipped with every iPhone.

safari

This is great on multiple levels:

  1. Developers can finally run tests against the Safari browser without having a Mac (usually these tests simply didn’t happen). This was the reason many sites broke on Macs.
  2. Safari has a strong track record from Mac enthusiasts, which is a mostly separate crowd from Firefox enthusiasts. Thus, this may help further increase adoption of non-IE browsers.
  3. Applications can be tested against the iPhone without an actual iPhone in hand.

That last point is crucial. Right now, everything targets IE, and this is a pain for web development because IE bastardized web standards such as HTML and JavaScript. This meant anything you programmed had a chance to break in IE even if it worked in every other browser on the planet. 

The iPhone may be the best thing to have happened to the Internet since Firefox was born.

If the iPhone becomes the new target platform, standards become truly relevant. Why? Because for the first time in history, hordes of regular Joe consumers will have web access in the palm of their hand, and no company wants their website to completely break when viewed through the iPhone. This is especially true as more and more people begin to consume information strictly through their handheld devices and stop visiting web sites that don’t work on their phones. As a personal example, even though I read lots of news sources when on a desktop, on my Blackberry, I only read a select few sources that are built to handle mobile browsers.

The point is: web publishers can no longer choose to target IE. And as many analysts predict, with or without Apple, the mobile web will match or over take desktop web usage in the near future. Just take a look over at Japan to see what I mean.

So as a developer, I would like to thank the iPhone for making my life better. 🙂

5 thoughts on “How the iPhone Will Save Web Standards”

  1. “web publishers can no longer choose to target IE”…

    I spent the entire day today debugging, for IE6, a website which I’d developed and tested in IE7, Firefox and Opera. (Yeah, it worked in Win Safari Beta… but that doesn’t prove anything for Mac.) Anyway before looking up some stats, I had this attitude of: Why should I care about IE6? Shouldn’t people be upgrading to IE7 already? Isn’t IE6 marketshare waning? Sadly, not very fast… IE6 is still, by a significant margin, the most used browser out there. So rather than inconvenience a third of my viewers (who for whatever reason can’t/won’t upgrade) and would just go away instead, I bit the bullet, split off an IE-specific stylesheet with conditional comments, and in the end… *shrug*, I learned a bunch of CSS hacks and it all works well now in all 4 tested browsers.

    So I don’t think it’s a question of, as you said, web developers “choosing to target IE”, but rather of developers who in the past ignored Firefox/etc. but can’t any more. Reality is that with IE’s 60% market share (of which 2/3 goes to that bastard child, IE6), pragmatic developers still have to target IE and will need to for a whole lot longer.

    Win Safari IS fast, though! Why can’t the FF folks get their rendering engine to work like that?

  2. From what I’ve heard, Safari for Windows doesn’t have the same bugs/quirks as Safari for Mac. (I believe this, given how perfectly things I’ve debugged on Firefox (without testing on other platforms) render in Win Safari. So unfortunately, you still have to test on Mac Safari. But fortunately there’s Browsrcamp for us Mac-less folks.

  3. Correction: Web publishers can no longer choose to target only IE.

    Which is a good thing (although I’d say that’s been true for a while now, but perhaps I’m over-optimistic on that point). However, I think that designing around IE bugs will still be a feature of web development for some time.

Comments are closed.