Vendor prefixes: it’s not about IE6—it’s just Apple vs. Google

Not so long ago, IE6 was the over-dominant browser on the Web. Technically, the Web was full of works-only-in-IE6 web sites and the other browsers, the users were crying. IE6 is dead, this time is gone, and all browsers vendors including Microsoft itself rejoice. Gone? Not entirely… IE6 is gone, the problem is back.

WebKit, the rendering engine at the heart of Safari and Chrome, living in iPhones, iPads and Android devices, is now the over-dominant browser on the mobile Web and technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying. Many sites are sniffing the browser’s User-Agent string and filtering out non-WebKit browsers. As in the past with IE6, it’s not a question of innovation but a question of hardware market dominance and software bundled with hardware.

(Daniel Glazman, Co-Chairman of the W3C CSS Working Group, Call for action: the open web needs you now)

The web has been inundated, in the past forty-eight hours, by posts, mostly from designers, lamenting (mostly) the chaotic direction in which they believe web standards are going as a result of vendor prefixes. (In case you’re muddled about the various points of view, Chris Coyier summarized them rather neatly here.) Most people will dismiss the problem as being a technical one, of interest only to the tiny minority of people directly involved in writing code for the web. Yet the issue is seriously being compared, in terms of its annoyance potential, to Internet Explorer 6—which will doubtless conjure up rather bad memories even in those relatively uninterested in tech.

For reasons I’ll explain below, I don’t think that’s actually the case. But for rather different reasons—the impact of mobile on a previously desktop-focused web, on the other hand, and the differing business models of the two dominant actors in tech today, Apple and Google, I believe the issue to be a crucial one.

If you’re unfamiliar with what we’re even talking about here, Eric Meyer wrote an excellent article on the subject last year, which summarizes pretty clearly both what purpose vendor prefixes serve, and what the controversy around them involves. If you don’t want to read the full article, the following illustration should give you an idea:

Mozilla and WebKit browsers both support gradients, but they use radically different syntaxes to achieve the same basic result. Now imagine a world where the vendors had implemented gradients without the prefixes. You would have three choices:

  • Pick which browser gets a gradient and which one doesn’t.

  • Use CSS hacks or browser sniffing to serve up different styles to different browsers.

  • Walk away from using gradients entirely.

This wouldn’t be a problem if websites conscientiously implemented prefixes when using these properties (like I do on this site for gradients, border radiuses and box shadows), and used tools such as Modernizr to handle what should be rendered in older browsers where those properties just aren’t supported at all.

The above solution, admittedly, requires one to include several lines of CSS—typically, something like this, for instance:

.borderradius #post-metadata, #sidebar-links {
    color: #000;
    background: #999999;
    background: -webkit-gradient(linear, left top, left bottom, from(#cccccc), to(#999999));
    background: -webkit-linear-gradient(top, #cccccc, #999999);
    background: -moz-linear-gradient(top, #cccccc, #999999);
    background: -ms-linear-gradient(top, #cccccc, #999999);
    background: -o-linear-gradient(top, #cccccc, #999999);
    -webkit-border-radius: 7px;
    -moz-border-radius: 7px;
    border-radius: 7px;
    padding: 6px;
}

This might seem rather heavy-going to code by hand—yet there are plenty of ways to fix your code so it uses the right prefixes everywhere:

Why don’t people use them? I honestly don’t understand why, as the process is effortless. On the other hand, I also don’t agree with Daniel Glazman that we’re in a similar situation to when IE6 had started showing its age, yet despite being suboptimal retained significant market share. In those days, it just wasn’t possible—or at any rate never easy—to make an attractive website that displayed properly in IE6 (or IE7 and IE8, for that matter). The situation now emerging with vendor prefixes, if anything, is the reverse: the solution is there, in the form of vendor prefixes, to display a website in Webkit browsers—and the two possible directions in which we might go are:

  • non-Webkit browsers starting to adopt Webkit prefixes (presumably as well as their own), in order to remain compatible with the de facto standard and avoid being marginalized;

  • if Glazman gets his way and this doesn’t happen, people will have to continue to use the full range of vendor prefixes.

In either case, it’s hard to see why this is another IE6 situation: if Webkit becomes the standard, eventually vendor prefixes can be phased out and browsers will become more, not less compatible; and if it doesn’t, vendor prefixes will remain, being steadily phased out for each property as and when its code matures. People who refuse—though it’s hard to see why they would do this other than out of sheer laziness—to play the game are losing out.

Behind the apparent issue of vendor prefixes, of course, is another, rather different trend: the speed with which mobile environments have been gaining market share. Kroc Kamen pointed this out nearly two years ago, in a perceptive post published well before the controversy over vendor prefixes blew up:

Essentially, as long as the iPhone and iPad are able to retain mind-share, developer support and an unignorable market-share then Apple can shape the lowest common denominator for the web (even if that low is very high, like the best HTML5 / CSS3 support) just as Internet Explorer has been and largely remains the lowest common denominator for the web as seen through desktop computers.

It is for this reason that Apple and Google are competitors. Google requires that people use the web for everything they do in order to feed their core business of advertising. Google creating Chrome does not act against their business interest, it only bolsters it. Android exists because Google want more people to use smart phones so they can access the web and Google can advertise to them. Google’s business model means that they must work to keep web browser competition healthy and progressing in case one company gets the keys to the web and halts all progress just as Microsoft did with IE. A stationary web keeps native apps native and stifles Google. Apple want to keep native apps native and the web as a quirky document-centric browser that is never as well polished experience-wise as what’s on offer in the App Store.

Kroc Camen then concludes that Safari will become the new IE6: while I don’t think the comparison is appropriate for the reasons given above, I think he has a point when he says that the rules of the game have changed and that the emergence of mobile is making it more difficult to maintain a clear-cut set of rules—making the W3C CSS Working Group’s position a rather muddled one. Given the fierceness battle underlying the business models of the web-centric Google and the app-centric Apple, any standards that don’t accommodate both are doomed to irrelevance.