In mid-2010 I started my viewport research, and I found there were only three browsers that got it right: Nokia WebKit, BlackBerry WebKit, and Safari. The other browsers didn’t have a clue what they were doing; most importantly, they didn’t expose the crucial visual viewport dimensions to JavaScript.

Meanwhile the situation has improved a lot. Most WebKit-based browsers now get it right, as does Opera. IE gets most of it right, but not device-pixel-ratio. Firefox, the proxy browsers, and the remaining few “proprietary” (i.e. crap) rendering engines have no clue what they’re doing. (Admittedly, the viewport is tricky for proxy browsers, where the rendering engine does not reside on the device.)

Opera follows, W3C does nothing

Again it was WebKit who led the way. Although Opera has been on mobile for longer than WebKit, it didn’t properly implement the viewport until I started bugging them; and touch events came fairly late, too. That’s fine — you can’t lead in every area — but it does mean I take WebKit more seriously here.

As to W3C, it gave up its right to lead by doing nothing. I half-expected some sort of draft viewport spec based on my research; possibly with new, intriguing ideas. That hasn’t happened in the past two years, though. Therefore W3C’s role in the viewport and touch event areas has dwindled to rubber-stamping the WebKit de-facto standard.

Web developers won’t bother

That’s the theory. There’s an important practical component, too: once Safari and Android WebKit (and possibly, in the future, Chrome on Android) support something, no web developer will bother writing code branches for other mobile browsers.

Opera’s and Firefox’s recent decision to implement some -webkit- prefixes was caused by the same problem. Web developers, especially those starting to pay attention to mobile but not yet advanced enough to carefully distinguish between the 25 known browsers, will not write non-WebKit code branches, which in this case means no vendor prefixes other than -webkit-.

Something similar is already happening with viewports and touch events, and it’s better to openly acknowledge that process rather than make unrealistic demands about following irrelevant (and currently non-existing) specs and fixing all your code. Besides, in the end browser incompatibilities are the browser vendors’ fault, and not web developers’.

Problem: IE

The main problem with standardising the WebKit way of handling viewport and touch events is Microsoft. IE is going its own way with regard to device-pixel-ratio-like properties, as well as the touch events. I don’t like that, and you will hear more of it later. Delicate natures who dislike profanity will want to avoid that particular discussion.

Outside IE, though, there are few incompatibilities, although some browsers haven’t implemented all viewport properties correctly yet. That’ll change: they can’t afford to stay behind.

WebKit leads

Acknowledging that WebKit is the de-facto standard for viewports and touch events will do no significant harm, and will help move a unified web forward by creating a standard that’s already supported by most browsers.