Home WebKit as de-facto standard for viewports and touch events

WebKit as de-facto standard for viewports and touch events

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.

I will treat the WebKit implementation of all viewport-related and touch-event-related CSS and JavaScript as the de-facto standard. If there is only one WebKit implementation, I will measure how well Opera, IE, and Firefox emulate it. I will also ignore any W3C standard that does not comply with established WebKit practice.

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.
WebKit takes the lead.
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.
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.
Source QuirksBlog

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.