More specifically, today I will shout at web developers who think that delicately inserting an iPhone up their ass is the same as mobile web development.

Before we start, a little thought experiment. Suppose I proposed the following:

1. IE6 is today’s most advanced browser. (Note: this was actually true back in 2000. Please bear with me.)
2. IE6’s market share is about 80%.
3. The other browsers are way worse than IE6, and developing for them is a pain; something we’re not interested in and are a bit afraid of.
4. Therefore we will develop websites exclusively for IE6.

Would you agree with those sentiments, even if we’re back in 2000 and IE6 is really the best browser we have?

Or would you reply that our sites should work as well as they can in all browsers through the use of web standards, progressive enhancement, and all the rest of the best practices we’ve been preaching for the past ten years?

I distinctly remember a time when we web developers cared about such concepts. But those times are long gone.

That’s a fair question. It deserves a fair answer.

Apparently, the touchstart event object persists in browser memory even when the event has long ended. More importantly, it continues to be updated with information about the current touch action.

This is interesting. It’s also profoundly different from the desktop, where a similar trick with the mousedown, mousemove, and mouseup events definitely does not work.

Both iPhone and Android display this behaviour. Therefore future implementations of the touch events should, too.

Disclosure: This research was ordered and paid for by Vodafone. Nokia, Microsoft, Palm, and RIM have helped it along by donating devices to me.

When a user touches the screen of a touchscreen phone, sufficient events should fire so that web developers know what’s going on and can decide what actions to take. Unfortunately most mobile browsers, especially Opera and Firefox, are severely deficient here.

The touch action is way overloaded, and most browsers have trouble distinguishing between a click action and a scroll action. Properly making this distinction is the only way of creating a truly captivating mobile touchscreen browsing experience.

The iPhone’s touch event model is excellent and should be copied by all other browsers. In fact, these events are so important that I feel that any browser that does not support them by the end of 2010 is out of the mobile browser arms race. There’s only one problem with the iPhone model, and it’s relatively easy to fix.

I have created a drag-and-drop script that works on iPhone and Android as well as the desktop browsers, a multitouch drag-and-drop script that works only on the iPhone, and a scrolling layer script that forms the basis of faking position: fixed on iPhone and Android, who do not support that declaration natively.

I will hold a presentation on my research at the DIBI conference, Newcastle upon Tyne, 28th April. It will likely include future discoveries and thoughts.

As longtime readers may remember, I was totally burned out at the end of both 2007 and 2008. I’m happy to report that that trend has been broken; although I was glad to have a little holiday at the end of 2009, I returned to work without noticeable problems. So that’s good.

However, I have decided that certain aspects of my professional life are in need of a change; notably my public speaking and my compatibility tables.

Basically I’m going off the conference track for a while in order to spend more time with my mobile phones.

I will honour agreements made beforehand, which means I’ll speak at the following occasions:

1. Transmissions 3, Manchester, 28th of January, together with Chris Mills. The focus of this meeting will be the mobile Web.
2. Technique Retreat, 29th to 31st of January in Morecambe, near Manchester. Here I’ll be a trainer and workshop leader. If you want to do a bit of JavaScript or mobile web development with me around to help you, sign up. There’s still a few tickets left.
3. Dutch: Sessie op de Howest te Kortrijk over het mobiele web, in de week van 29 maart.
4. The DIBI conference in Newcastle upon Tyne, 28th of April. I’ll speak about the mobile Web.
5. It’s possible one item will be added to this list.

After that, though, I will be very reticent in accepting new speaking gigs.

I will also make some changes to my compatibility tables because the kind of tests I've been doing in the pas ten years are not really suited for mobile browsers.

In a discussion on the WHAT-WG IRC channel Jeremy got fed up with the fact that he can’t just point people at the spec during his HTML5 evangelism:

I'm doing my damndest to evangelise HTML5 to front end developers and designers but you guys don't make it easy.
[...]
As if this stuff wasn't confusing enough for authors already. Now they have to put up with stupid spec obfuscation for the sake of some minor semantic victory for someone somewhere.
[...]
The WHATWG couldn't make the spec more author-unfriendly if they tried.

Inevitably, it was pointed out that specs aren’t meant for developers but for browser vendors. That’s true but unhelpful, just as it has been for the past ten years. The ritual dance begins anew.

Personally, I’m not going to take part in the dance this time. I already know what the outcome is going to be, and I’m going to skip the rituals.

Because “HTML5” is so vaguely defined we web developers can decide for ourselves what is part of HTML5 and what isn’t, and that’s something I’m looking forward to. (If spec defenders don’t like that they should have been clearer.)

My favourite examples are geolocation and Web Storage, which will feature prominently in my upcoming HTML5 mobile compatibility tables despite the fact that they’re not in the spec. They’re new, exciting, and absolutely vital on mobile. They’re in my HTML5 spec.

HTML5 is the continuation of Web 2.0 by other means, just as Web 2.0 was the continuation of DHTML. Apparently we need a vague, all-encompassing term for cool new stuff that we want browsers to support and clients to buy so we can play with it.

That’s what HTML5 should be. Because there are new and exciting things going on, people will start to make wish lists. Exactly which items on those lists are described in a document called “HTML5” will slowly cease to matter, as long as they have some browser support.

As soon as a certain feature appears on enough HTML5 lists it will become canonical. Conversely, the stuff that nobody’s really interested in will no longer be HTML5, even if it’s in a spec with that name.

I consider this a Good Thing. Wisdom of the crowds and all that. (Again, if spec defenders don’t like it, they should have been more accomodating to authors.)

So what’s in your HTML5 spec? Top three, anyone?

Yet.

Pretty soon, however, B. is going to spend a few months in the outlying parts of Indonesia, and during that time he has to be able to access his business bank account. He was wondering if a modern mobile phone would fit this use case, and, if so, which one.

When he told me all that I whipped out my iPhone. “Something like this, you mean?” He was suitably impressed, and when I told him I regularly have six to twelve phones lying around on my desk he practically begged for an opportunity to come by and try them all in order decide what kind of phone he wants.

That was of course fine by me. User testing is never to be despised, and since B. is not technical and has no experience with touchscreens to speak of, he is the perfect test subject.

Last week we held our session, and this entry is the report.

Tested phones: Nokia N97, Samsung M1, HTC Touch Pro (Windows Mobile), SonyEricsson W960i, Nokia E71, BlackBerry 9500, HTC Pioneer (Android), LG M900, Nokia N900, iPhone.

John Gruber wants me to mention the Cocoa Touch framework. He feels that its excellence is an important factor in the success of native iPhone apps.

Point is, although Gruber’s probably right, he ought to be wrong.

My post could be construed as a rant. Hell, parts of it were a rant. (Nobody said this blogging stuff is easy, especially when you’re passionate about something. But if I can’t speak my mind here, what’s the point of having a blog?)

Several people I respect a lot said that I’d made a stupid mistake and was just plain wrong. After some thought I decided they are right.

I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid.

Special thanks go to Dion Almaer and Faruk Ates, who took the time and trouble to write a factual rebuttal of some points, as well as Andrew Hedges, who provided me with a few examples when I needed them most.

While writing the current article I figured out there’s a whole lot of undigested information in my head that I instinctively used in my previous article but didn’t bother to explain properly. This is especially true for payments and the general state of Web technologies on mobile.

Despite my mistakes the whole thing seems to have kick-started a solid, sensible discussion about the differences between native apps and Web apps, and which one is better under which circumstances. I’d like to continue that discussion.

The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies.

It was only last Friday I told a roomful of Web developers that Apple is evil, and a spontaneous applause erupted. Since then, however, I have changed my mind completely. The Web developers and I were wrong.

Apple is not evil. iPhone developers are stupid. Their problems with the App Store approval process are entirely their own fault and they deserve no commiseration.

I hope the App Store approval process sticks around for a loooooooong time.

Update: I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid. Read my follow-up post.