First of all, of course browser sniffing should be avoided wherever possible. Everytime a new IE version comes out, some sites break, because suddenly a feature isn't broken anymore. The IE team has recently decided that going with standards may actually be a better idea than always inventing their own stuff. That's great. But it's also not suprising that lots of sites employ some ugly hacks to make things work in IE, because for a decade, they had to.
But just because a page checks for the existence of ActiveXObject or attachEvent does not mean that page is going to break in IE10. I wouldn't even consider this browser sniffing in all cases – quite the contrary; checking for the existence of such properties checks for the existence of a feature.
But even if they are used for browser sniffing, like in jQuery's support.xxxBubbles check (have a look at that code), this may be just used for taking a shortcut: If you use a non-IE browser, where you know that feature X works fine, there's no point in running the feature detection in the first place; if it turns out to work after all, great! But if you're running IE, you have to do the test. So guess what: You do feature detection, but hide it behind a browser sniffing check. Best of both worlds!
Second, let me give you two examples where we actually do browser sniffing, straight from our source code. The first one is from chat:
if ($.browser.msie) {
// IE fires the onstorage event without giving the event handler
// access to the data, neither through the event object nor by
// updating the localStorage *before* calling the handler. Quoting
// MSDN:
// "Internet Explorer fires events when data in a storage area is
// updated, so that information can synchronized between multiple
// instances of the browser or tabs."
// Yeah, right.
// However, testing (see http://chat.meta.stackoverflow.com/rooms/242)
// shows that the data almost always is available if checked in a
// 1-millisecond timeout created from the event handler (so probably
// a threading issue). In any case it never seems to take more than
// 50 milliseconds after the event fires for the data to be available.
// Hence we try the 1-ms timeout, and if no new data was found,
// we try again (once) after 100 ms.
// This bug seems to have been fixed in IE9.
How are you going to feature-detect an erratically appearing concurrency bug in the communication between two windows? But the workaround employed in that if block is not an actual problem for browsers that aren't broken – it just makes the handling a bit slower. So the point of browser sniffing is skipping unnecessary workarounds in known-to-be working-browsers.
The second example is from the main site JavaScript, and note that it's not even related to IE:
// Several of the comment controls are very close to each other and to
// other links. When the Android browser thinks element A is clickable
// (because it's a link or has an onclick handler), and it thinks
// element B is not, and A is close to B, and you tap on B, the browser
// thinks you have fat fingers and pretends you tapped on A. Since event
// delegation doesn't create click handlers on the particular element,
// the Android browser doesn't know it should consider it a hit area.
//
// To work around this, we do the following: If the element is *touched*
// (the touchstart event sends the *correct* target element), we add a
// dummy click handler to it and add a dummy attribute. The latter
// DOM change is necessary for Android to reconsider its hit areas.
// This adds a few unnecessary click handlers on touch-enabled devices,
// but is otherwise free of side-effects. And at most one handler will be
// added per element.
function heyAndroidThisIsClickable(context, ancestor, targetSelector) {
if (!/Android/.test(navigator.userAgent))
return;
// ...
Do you have a smart idea on how to do this via feature detection? Ask the user to do a touchscreen calibration on each page? And again, the user agent check is just made for a shortcut here; if it's not an Android browser, the workaround doesn't have to happen. But if it's the Android browser and it doesn't have this issue (it e.g. seems to be fixed or at least improved in the shipped browser in ICS), the workaroung doesn't cause issues either; as the comment says, it just "adds a few unnecessary click handlers".
That said, there may be cases where we make decisions based on feature detection where we shouldn't, and which should be changed at some point. But unless this actually breaks stuff, there's no reason to immediately drop everything and go fix it in a haste; certainly not just because the "Please please believe us, IE doesn't suck anymore" compat inspector for an unsupported browser version identifies something as "possible".
A small note regarding the jQuery version: As Jeremy said, we're indeed one minor version behind, but that's not even what your screenshot is talking about. It just notes that we use jQuery 1.7.1, and doesn't even complain about that.
What you're referring to is a message about jQuery UI. And we don't even use that in the first place!
Please incorporate the indicated changes all over the stackexchange ecosystem.
Thank you very much for your kind, considerate, and not at all condescending explanation of what we're doing wrong, and welcome to the real world.
