The other day, the Dojo blog announced the public beta of Renkoo, an “evite killer” which relies heavily on the asynchronous features of Dojo and “Comet”, the name that’s been given to the use of long-lived HTTP connections to provide instant updates of state in event-driven web applications.
Except I can’t check out Renkoo in my browser of choice — Safari — because I get automatically redirected to their “unsupported browser” page. They have a brief write-up on their blog of why Safari support is problematic, though I can’t help thinking that a social application which can’t work in Safari is starting out with the odds stacked against it. Safari has a pretty small slice of the overall browser market, but in the context of a social application which will depend on building networks of people, market share in the general population is almost meaningless: what’s important is browser market share among the critical adopters who will make or break the network. If you develop social software and you haven’t already read danah boyd’s “Cluster Effects and Browser Support”, stop right now and go read it. I’ll wait.
Anyway. I understand why Renkoo has problems with Safari. From what I read on their blog, it appears they have one of the few legitimate cases I’ve ever seen for sniffing out browsers and excluding them: the Comet model doesn’t appear to really be workable in Safari right now. In the long run I think they’re screwed if they can’t find a way to work in Safari, but they’re really in a rock-and-a-hard-place situation and I don’t envy them one bit.
But lately I’ve been seeing a major renaissance of browser sniffing in cases where it is, frankly, unjustifiable. Browser sniffing is dead, and has been for years.
The first death of browser sniffing
When the Web first really took off, the only significant player in the browser market was Netscape Navigator, whose rise and fall form a sort of Ozymandias for the Internet age. There were other browsers, though, and generally you could tell them apart reliably: they mostly had unique user-agent strings which were sent with every request, and by looking for the HTTP
User-Agent you could figure out which browser you were talking to and make some assumptions about what it supported.
Netscape’s user-agent string was easy to spot, because it included the string “Mozilla”; early Netscape user-agent strings looked like this:
Mozilla/3.0 (OS/2; U)
And when Internet Explorer came on the scene, it was easily recognized by having “MSIE” in the user-agent string, and all was well with the world. Netscape and Microsoft worked hard to cram new unique features into their browsers, but the user-agent strings made them easy to tell apart, right? Well, not really. Very early in its history, IE started including the word “Mozilla” in its user-agent string; for example, here’s the string from IE 1.5:
Mozilla/1.22 (compatible; MSIE 1.5; Windows NT)
So every IE release since 1.5 has done this, complicating attempts to reliably tell IE and Netscape apart and making web design even more difficult, since IE and Netscape were, at the time, anything but “compatible” with each other.
If we’d been smart, web geeks would have stopped sniffing user-agent strings then and there. But of course people kept right on sniffing, developing ever more complex sets of rules to tell apart browsers whose user-agent strings began borrowing more and more liberally from each other. For the longest time, Opera sent a string almost identical to IE’s, originally to get around sniffers which locked out non-IE clients. Safari’s default user-agent string includes “Gecko” — the rendering engine of Mozilla and its descendants — though it most certainly isn’t a Gecko browser. Today, through some native support and some creative extensions, Opera, Safari and Firefox all have facilities available for changing the user-agent string to anything you like and can effectively masquerade as any major browser on the market.
In other words, it’s been about a decade (IE 1.5 was released in 1995) since the last time user-agent sniffing offered a straightforward way to figure out which browser a user has. But that hasn’t stopped people from trying.
The second death of browser sniffing
In the modern era of the Web — assumed for purposes of this article to have begun in 2003, the year the first versions of Safari and the-browser-now-known-as-Firefox appeared — sniffing is even more problematic because writing a new web browser has become ridiculously easy, thanks to embeddable open source rendering engines. Embedding a rendering engine is, of course, nothing new; AOL for Windows embedded the Internet Explorer rendering engine for years, and Windows, through the various incarnations of its application object model, has long exposed IE for use by other applications. But that was one engine on one platform.
In recent years, we’ve seen two solid cross-platform, open-source rendering engines come to maturity: Gecko and KHTML (which has since given birth to the Mac-specific WebKit application framework at the heart of Safari and several other Mac browsers). And embedding seems to get easier with each passing year, thanks to increasingly prolific bindings for a number of languages and desktop environments (for example, consider this demo from last year, which builds a Gecko-based web browser in only a few minutes, using Ruby Gecko bindings and the GNOME desktop’s interface builder).
When what you’re doing is actively countering the goals of your site, it’s time to stop.
He’s dead, Jim
So sniffing the user-agent string to find out whether a browser can handle what you want to throw at it has died not once, but twice: the first time because major browser developers intentionally obfuscated their user-agent strings, and the second time because new, perfectly capable browsers have their own strings which won’t be in your list. Maintaining an up-to-date list of every user-agent string of every capable browser, including new browsers which embed Gecko, KHTML or WebKit, is basically a hopeless task.
- Renkoo is trying to do it.
- Nintendo is trying to do it, as Mark Wubben recently discovered — Camino is perfectly able to handle their site, but it’s not in their list of “approved” user-agent strings.
- Google is trying to do it; I recently tried out a WebKit-based browser that’s just as capable as Safari on the rendering front, but because it wasn’t in a hard-coded list of user-agent strings, GMail kicked me out to its plain-HTML interface with a “get a better browser” banner across the top of the screen.
And that’s just the tip of the iceberg; if I wanted to, I could dig up dozens, probably hundreds of high-profile sites which are all too happy to drive away potential traffic by engaging in browser sniffing; just today, I saw a story on Slashdot about the Boston Globe literally telling someone to stop using Opera, another perfectly capable web browser with an advanced rendering engine at its heart (if I recall correctly, Opera’s engine is called “Presto”).
For as far back as I can remember, the Mozilla project has maintained a “technology evangelism” sub-project aimed at moving sites away from the horrors of IE-only sniffing, but it appears that the only real response has been to move to “IE or Firefox only, and maybe Safari”; that’s not an improvement. That’s treating a superficial symptom instead of curing the disease. And this weekend I came across “Gecko is Gecko”, which tries to educate developers on the existence of embedded Gecko in browsers that aren’t Firefox. One of their suggested solutions — sniffing for “Gecko” in the user-agent string instead of “Firefox” — is a minor improvement (and has the added benefit of giving Safari a free pass), but again this just treats a symptom.
Let me say this as clearly as I can: sniffing user-agent strings and comparing them against a list of “approved” or “known good” browsers is dead. Dead as a doornail. Yank the sniffing scripts out of your toolbox and throw them away. These days, you’re far more likely to be excluding capable but (to you) unknown browsers than you are to be excluding 1.x editions of Netscape Navigator.
Sniff the right way
getElementById. There are a couple of small wrinkles in this rosy picture (notably Safari which, last I checked, exposes a method called
preventDefault on DOM events, even though it doesn’t actually do what
preventDefault is supposed to do), but I’d be willing to bet it’s as least as effective, percentage-wise, as sniffing for the “big four” (IE, Firefox, Safari and Opera) and it has the advantage of being future-proof: when the browser market changes, user-agent sniffing scripts have to be laboriously updated. But so long as you’re testing for actual features, you never have to update;
getElementById isn’t going to get renamed any time soon.
And to really hammer it home, keep in mind that this is by far the most effective way to implement AJAX effects. Versions of IE prior to 7 expose
XMLHttpRequest object lives are all that’s needed to effectively work out how to do AJAX.
Even better: just stop sniffing
That’s still only a partial solution, though. The Platonic ideal is what’s come to be known as “progressive enhancement” (or, for the buzzword-inclined, “Hijax”): instead of building an advanced interface and then worrying about how to exclude browsers that can’t handle it, first build a simple interface that works everywhere, and then layer the fancy effects on top of it (using techniques like feature sniffing if necessary). Jeremy Keith has done some great evangelism for this technique, including coining the “Hijax” name and providing one of the best write-ups of how it should work.
For the unfortunates
Of course, not everyone is so lucky, and I recognize that. Some designers and developers are stuck working at places where old-school user-agent sniffing is still mandated from On High, because something that kind of worked in 1996 must be really great to have in 2006, right? Anyone who’s caught in that situation has my deepest sympathy. And a suggestion.
If you have absolutely no other choice besides user-agent sniffing, do it the way Yahoo does it, and feel free to drop that name in discussions with corporate bigwigs; an article on some guy’s blog won’t carry much weight, but the field-tested techniques of one of the Internet’s biggest companies will hopefully get their attention. Yahoo uses a system called “graded browser support”, in which every browser falls into one of three categories:
- Grade A contains browsers which have been thoroughly tested and which are known to be capable of handling everything Yahoo wants to throw at them.
- Grade C contains browsers which have been thoroughly tested and found lacking.
- Grade X contains everything else, including both known browsers which haven’t been tested, and unknown or new browsers.
The key here is how Yahoo treats the “grade X” browsers: most places lump them in with “grade C” and either serve a watered-down interface or refuse to serve anything at all. Yahoo, however, assumes that unknown browsers are capable, an assumption more likely to be correct in these modern times, and goes so far as to say that
Unlike the C-grade, which receives only HTML, X-grade receives everything that A-grade does. Though a brand-new browser might be characterized initially as a X-grade browser, we give its users every chance to have the same experience as A-grade browsers.
If you absolutely must sniff based on user-agent strings, this is the philosophy to adopt; the pool of ancient browsers which can’t handle modern features is known and documented, so unknown browsers are much more likely to be new and — thanks to the availability of advanced, embeddable rendering engines — more than capable of dealing with any fancy effects you want to use.
And once you’ve introduced your management to this style of thinking, I heartily encourage sending them the entire article on Yahoo’s grading system; the analogies they use for explaining accessibility and progressive enhancement (particularly the color versus black-and-white TV one) are top-notch, and may help you make further inroads toward adoption of modern development techniques.
But in the long run, user-agent sniffing is dead, and with each passing day the old-school forms of sniffing offer less and less utility and more and more opportunities to accidentally drive away people who would otherwise have been revenue-generating users. Switching to the inclusive Yahoo-style model is a good first step, but it’s just a stopgap in the march toward more modern and more powerful techniques like feature sniffing and progressive enhancement; if you’re doing user-agent sniffing here and now, at the end of 2006, your new year’s resolution should be to stop before the end of 2007.