Last week I got annoyed at the large differences in syntax for vendor-prefixed device-pixel-ratio media queries. I said, half in desperation and half as a threat, that it might be better to have only the WebKit rendering engine and ditch the rest.
Meanwhile I’ve had some time to think about it, and I find that I still support the idea of multiple rendering engines. Competition is still good, just as it was ten years ago.
HOWEVER. There’s an important exception.
Why do I give WebKit such a pre-eminent place in exactly these two areas? Because it’s the most advanced mobile rendering engine, and viewports and touch events only really matter on mobile.
Back in late 2009 when I started my touch events research only one browser did it right: Safari. Android was kind-of trying, but not very effectively, and the rest didn’t have touch events at all.
Meanwhile that has changed drastically: except for IE and the proxy browsers, all mobile browsers implement the touch events to some degree. Still, it was WebKit (especially Safari) that took the lead.
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.)
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.
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
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’.
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.
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.
If you like this blog, why not donate a little bit of money to help me pay my bills?