Currently, the most accurate method of detecting Internet Explorer 7 with JavaScript is the following:

var ie7 = (document.all && !window.opera && window.XMLHttpRequest) ? true : false;

There’s an alternate, but in my opinion less future proof, method:

var ie7 = (typeof document.addEventListener != 'function' && window.XMLHttpRequest) ? true : false;

I don’t believe they will ever drop document.all, but I’m certain they are going to fix addEventListener method.

Test conditions

Here’s a quick breakdown of objects/methods tested:

document.all

returns true in all Internet Explorer versions and also in Opera

window.opera

also known as opera object, returns true in Opera

window.XMLHttpRequest

returns true in Firefox, Opera, Safari and IE 7

returns false in IE 6 and lower

So far, I haven’t found flaws in this detection method. However, if someone knows better, please do tell. Ken Snyder pointed out that the native XMLHttpRequest can be disabled in IE 7 by unchecking Tools -> Options -> Advanced -> “Enable native XMLHTTP support” option… Bummer!

Conditional Comments

Last, but not least, you can always set ie7 variable to true inside conditional comments:

<!––[if IE 7]>
<script type="text/javascript">ie7 = true;</script>
<![endif]––>

First of all, from this few first days testing it, Internet Explorer in it’s last reincarnation is much better browser than I thought it’d ever be. It’s still not the first class piece of software, but at least most of the real-life CSS issues have been fixed. However, there are still a few nasties. Continue reading ›

Let’s make one thing straight right now – this article has nothing to do with the fact that more and more girls and guys are contacting us and ask for a job. Really! However, if you’re the one looking for a position, maybe these few tips would help. Continue reading ›

This bug is already documented at QuirksMode. Basically, instead of normal list-item increment: 1, 2, 3 and so on, IE 6 renders 1, 1, 1,…

It’s sometimes triggered by setting any value for an ol’s width property. Read more about it and see test pages at QuirksMode.

Setting and overriding list-style property rules for a list-item does the same mess. For example:

li    { list-style: none; }
ol li { list-style: outside decimal; }

would trigger this bug.

The workaruond is more than obvious – list-style property should be set only for list items in unordered lists.

In Firefox there’re those annoying black 1px thin horizontal lines inside iframe. I haven’t found anything useful so far, even though the bug has been mentioned here and there.

So, the question is – what’s your experience with this nasty thingy? To make this even more interesting, the one who comes with the bulletproof solution will receive a copy of CSS Mastery, Dom Scripting or ppk on JavaScript.

Update

This error occures in Firefox 1.5.0.7, both Win and Mac.

Update 2

The workaround for the above is to set rule position: absolute to an iframe. No coordinates should be specified (left or top), and the parent element should not be set to position: relative, as this throws the iframe back to square one.

Ed’s note: The bug has nothing to do with the ‘rounding error’.

Update 3

You’ll have to register at Coolinarika.com to see the working example.