G
Garrett Smith
Guest
Stefan Weiss wrote:
> On 09/02/10 01:49, Garrett Smith wrote:
>> I'm confused about IE's evaluation of window == document.
>>
>> IE:
>> window == document; // true
>> document == window; // false
>
> I may be missing something, but don't you want both of these to evalute
> to false? If so, Thomas's suggestion (using ===) should solve the
> problem. If you're dealing with some weird edge case, a comment should
> do it, IMHO. As if our code wasn't already riddled with "this is only
> for IE compatibility" comments ;-)
>
The problem with === is that window === window is not always true.
javascript: alert([window === window.window, window === self])
> I've never encountered this case, but I agree: it's definitely weird,
> non-standard behavior. I wish there was a way to talk to the IE
> developers, to ask them questions like this. With almost every other
> browser, you could just look at the source code and see what's going on,
> but IE is completely opaque. They don't even have a public bug tracker.
They do have a bug tracker (slow, when it works):
http://connect.microsoft.com/IE
I've filed bugs there myself.
Good bugs sometimes get marked as WONTFIX, INVALID, or Can't Reproduce.
The W3C Mailing Lists might seem like a way to talk to IE devs, but they
are a waste of time. The W3C is a pay-to-play organization arrogantly
out of control (put your money where your mouth is or STFU (or we'll ban
you permanently, lie about the reasons and lie and say it's only for two
weeks)).
My current test is based off using window on RHS. Given `a` and `b`, if
they are both the window, then
a == b.window; // true
If either `a` or `b` is `document`, then:
a == b.window; // false
In my code, there isn't any way `a` could be undefined because a
TypeError would prevent the object from being added to the registry:
a.addEventListener //
> On 09/02/10 01:49, Garrett Smith wrote:
>> I'm confused about IE's evaluation of window == document.
>>
>> IE:
>> window == document; // true
>> document == window; // false
>
> I may be missing something, but don't you want both of these to evalute
> to false? If so, Thomas's suggestion (using ===) should solve the
> problem. If you're dealing with some weird edge case, a comment should
> do it, IMHO. As if our code wasn't already riddled with "this is only
> for IE compatibility" comments ;-)
>
The problem with === is that window === window is not always true.
javascript: alert([window === window.window, window === self])
> I've never encountered this case, but I agree: it's definitely weird,
> non-standard behavior. I wish there was a way to talk to the IE
> developers, to ask them questions like this. With almost every other
> browser, you could just look at the source code and see what's going on,
> but IE is completely opaque. They don't even have a public bug tracker.
They do have a bug tracker (slow, when it works):
http://connect.microsoft.com/IE
I've filed bugs there myself.
Good bugs sometimes get marked as WONTFIX, INVALID, or Can't Reproduce.
The W3C Mailing Lists might seem like a way to talk to IE devs, but they
are a waste of time. The W3C is a pay-to-play organization arrogantly
out of control (put your money where your mouth is or STFU (or we'll ban
you permanently, lie about the reasons and lie and say it's only for two
weeks)).
My current test is based off using window on RHS. Given `a` and `b`, if
they are both the window, then
a == b.window; // true
If either `a` or `b` is `document`, then:
a == b.window; // false
In my code, there isn't any way `a` could be undefined because a
TypeError would prevent the object from being added to the registry:
a.addEventListener //