Кстати, только что случайно наткнулся на занятный драфт от W3C - оказывается, полгода назад там все-таки задумались о том, чтобы навести некий порядок в "оконной" проблеме. Там, в частности, требуется (must) тождественность (именно в смысле эквивалентности) значений атрибутов window и self друг другу и самому объекту window. Похоже, браузеры 2006 года решили этому последовать, и имхо это хорошо.

Интересно, как по этой части обстоят дела в IE7...

SelenIT, это же попытка реализовать все то, что ваша "интуиция упорно требует" !   ;) 
А если серьезно - почему "занятный"? Вроде как раз то, что нужно, так ведь?

Вообще, такие вот "черновики" долго превращаются в стандарты? 

По идее, действительно, то, что нужно - занятным мне показалось, что спохватилсь только в этом году)
Насчет превращения черновиков в стандарты... честно говоря, не компетентен, но по-моему обычно проходит больше года и не меньше трех-четырех редакций...

В IE7 всё те же проблемы, проверил быстренько из адресной строки.

ой ну и поздновато я присоединился))
постараюсь наверстать упущенное. если вдруг повторения, прошу простить.

говоря о логике ие.



по поводу их значений.
по моему мнению ие совершенно правильно сравнил их.

== - сравнение их значений (values)
=== - проверка значений и совпадение типа (не встроенного типа object).

self, top - свойства window, а не сам хост. поэтому они не идиентичны.
this в тэге HEAD - ссылка на window. а если она внутри тэга body, то ссылка на элемент в котором this находится. исключением является <BODY ONLOAD="this. ...">, где this - это ссылка на window? потому что document.body.onload===window.onload

Добавлено @ 00:01 
мне кажется this в <BODY ONLOAD="this. ..."> - это как переменная, она хостом не является.
поэтому при проверке this===window буде false

JSman


Алгоритмы сравнений и в том, и в другом случае схожи для object type. Мы же исходим из того, что и window, и top, и self имеют один и тот же тип - object. Значением этих идентификаторов является ссылка на объект. Если объект у них разный, то мы должны были бы получить false уже при нестрогом равенстве, чего не происходит.

Равенство (11.9.3 The Abstract Equality Comparison Algorithm) 
The comparison x == y, wherex and y are values, produces true or false. Such a comparison is performed as follows:
1. If Type(x) is different from Type( y), go to step 14.
2.If Type(x) is Undefined, return true.
3.If Type(x) is Null, return true.
4.If Type(x) is not Number, go to step 11.
...
11.If Type( x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions). Otherwise, return false.
12. If Type(x) is Boolean, return true if x and y are both true or both false. Otherwise, return false.
13.Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.

Строгое равенство (11.9.6 The Strict Equality Comparison Algorithm) 
The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows:
1.If Type(x) is different from Type(y), return false.
...
13.Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.


Это не должно иметь значение, объект может иметь свойство, значением которого будет ссылка на него самого. При сравнении имя-объекта===имя-свойства-объекта мы должны получить true, т.к. это один и тот же объект и алгоритм сравнения прописан чётко, host/не host не должно играть никакой роли вообще.

я поясню свою логику, думаю,  что сравнение объекта хоста с его переменными self, top не должно быть true, так как теряется смысл использования строгого равенства.
 тогда зачем нам ===? если есть возможность использовать ((x==y)&&(typeof(x)==typeof(y))).

более того, объект хост существует только в единственном экземпляре, все остальные, переменные, -ссылки на него. поэтому и тип разный, хотя и пишет, что object. а вообще по документации существует 4 типа объектов..

Фишка в том, что концептуально EcmaScript-y наплевать с высокой колокольни на причуды хоста и иже с ним. Алгоритмы должны быть реализованы так, как описаны, если UA считает, что реализовал EcmaScript комформно.


Потребовалось когда-то для некоторых операций проверять совпадение типов - сделали нужный алгоритм, потом под это дело и оператор нарисовали, но в подавляющем большинстве случаев обходятся и без него.


В IE global namespace - это чёрный ящик, объект Global сам по себе, WINDOW само по себе (но нам незаметна разница), а кроме того встречаются какие-то объектные привидения для работы с ID элементов, можно даже попробовать как-нибудь это доказать...

Zeroglif, 
 
Ух, обожаю "привидения"! Еще одна тайна! Только за это можно в IE влюбиться навеки...
А если серьезно, то может, хотя бы в общих чертах, но чуть подробней, чиркнете об этом пару строк?

мне кажется Microsoft просто дальше пошли. и дело не в неправильной реализации, а то, что EcmaScript больше полагается на Web, а Microsoft использует JS для многих целей (типа WSH)


typeof, если не изменяет память с javascript 1.0, а === с 1.3
более того, посмотрел в одном справочнике, что 
=== - NN n/a  IE J3  ECMA n/a IE 3  ECMA n/a.

т.е. ИЕ раньше начал использовать ===, чем это стало стандартом

Это сообщение отредактировал(а) JSman - 2.11.2006, 21:00