|
Posted by Michael Winter on 06/29/05 02:44
On 29/06/2005 00:14, Gérard Talbot wrote:
[snip]
> It's better to initialize the variable to null rather to undefined as
> later parts of the code test for/compare the reference to null and not
> to undefinded.
That comparison is equivalent. I should have pre-empted that in my
previous post - my apologies. See section 11.9.3 - The Abstract Equality
Comparison Algorithm[1] in ECMA-262 3rd Ed., specifically steps 1, 14,
and 15.
[snip]
> There is no browser that supports window.open() that does not support
> window.focus().
The issue isn't browser support as such, but that of pop-up blockers
(which is why I mentioned them). However, your statement is quite a
wide-ranging one that is difficult to substantiate either way.
[snip]
> If open() is faked, then WindowObjectReference will be null and the
> WindowObjectReference.focus() will create a js error.
Not necessarily. It is known that there are pop-up blockers which
produce code that returns non-null values from overridden open methods.
These resulting objects are usually made to appear like a global
(window) object, and may in fact be synonymous with the global object
for the current browser/tab instance, but not always. As I said, if
we're talking best practice then code should prepare itself for these
possibilities.
If you're really interested, read through the archive of
comp.lang.javascript on the subject of pop-up blockers.
Mike
[1] The Abstract 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), go to step 14.
...
14. If x is null and y is undefined, return true.
15. If x is undefined and y is null, return true.
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Navigation:
[Reply to this message]
|