473,747 Members | 2,754 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Why "window.alert() " over "alert()"?

While reading c.l.j, I've noticed that some people prefer and indeed even
recommend the use of "window.alert() " over "alert()".

I can't find any technical reason to make this distinction, and seems to
have a (tiny) amount overhead since window itself points to the global
object, hence, a circular reference.

(From everything I am reading, window is just a REFERENCE back to the
global object, as opposed to a separate object.)

Which brings me to two ideas:

a) Either I am wrong, and window is really its own augmented object
through a grammar I don't follow

b) The decision is based for stylistic reasons, to remind the coder that
"alert()" is provided by the host environment and is not part of the EMCA
script specification.

Aug 23 '08 #1
24 8223
Jeremy J Starcher meinte:
While reading c.l.j, I've noticed that some people prefer and indeed even
recommend the use of "window.alert() " over "alert()".
In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
object, in browsers the window object. If somebody (deliberately or
accidentally) defines an alert function elsewhere in the scope chain, it
will be called instead. "window.alert() " leaves no room for speculation.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aug 23 '08 #2
Gregor Kofler wrote:
Jeremy J Starcher meinte:
>While reading c.l.j, I've noticed that some people prefer and indeed
even recommend the use of "window.alert() " over "alert()".

In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
object, in browsers the window object.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.

In fact, there is evidence to the contrary: MSHTML's creating "read-only"
properties of a host object in the scope chain to refer to element objects
representing elements with ID or name, also being available through the
`window' reference. But the Global Object is specified as a native object,
it has to implement the [[Put]] method exactly as it was specified; so that
cannot be the object referred to by `window', which exhibits said behavior
instead.
If somebody (deliberately or accidentally) defines an alert function
elsewhere in the scope chain, it will be called instead. "window.alert() "
leaves no room for speculation.
That is not the reason why. Because if someone declared `window' in the
scope chain before the Global Object (so as this would not refer to the
`window' property of the Global Object anymore), then the issue remained.
It is instead that it is unlikely that someone would do that.

To be absolutely sure, one would have to feature-test and use
global.window.a lert(), with `global' being a globally defined reference to
the Global Object (var global = this), instead.
PointedEars
--
var bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16
Aug 24 '08 #3
Thomas 'PointedEars' Lahn <Po*********@we b.dewrites:
Gregor Kofler wrote:
>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>object, in browsers the window object.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.
It does seem that the global object's "window" property holds a
reference to the global object itself in all current browsers, to the
point where a new browser would be causing itself problems by not
doing the same.
No standard, true, except de-facto standard.
In fact, there is evidence to the contrary: MSHTML's creating "read-only"
properties of a host object in the scope chain to refer to element objects
representing elements with ID or name, also being available through the
`window' reference.
They are equally available through the global object. They are not
ReadOnly as properties of the global/window object, though, only when
resolved through the scope chain.
But the Global Object is specified as a native object,
it has to implement the [[Put]] method exactly as it was specified; so that
cannot be the object referred to by `window', which exhibits said behavior
instead.
That, or IE doesn't follow the specification and implements [[Put]]
differently on the global object.

It does appear that MSHTML has an a step in the variable resolution
procedure that acts as if there is an object above the global object,
that holds those element-id properties. It also appears that reading
the properties directly off the global object will also give the
element with that id. This gives two ways to give the same result,
and the two are not equivalent.

Example:

<div id="foo">foo</div>
<script type="text/javascript">
alert([foo, typeof foo, window.foo, typeof window.foo]);
// alerts "[object],object,[object],object"

alert("foo" in window);
// alerts true

try { foo = 42; } catch(e) { alert(e.message ); }
// alerts "Object doesn't support this property or method"

window.foo = "window.foo ";
alert([foo, typeof foo, window.foo, typeof window.foo]);
// alerts "[object],object,window. foo,string"

</script>
<script type="text/javascript">
var foo = 37;
alert([foo, typeof foo, window.foo, typeof window.foo]);
// alerts "37,number,37,n umber"
// a function declaration also changes both.
</script>

Using the global object instead of "window" gives exactly the same
result (they are the same object, as reported by "==").

I.e., the scope-lookup appears to match page id's just before it
tests the global object. There may or may not be an object holding
the properties (I'm expecting that there isn't, and that they are
instead resolved by extending the lookup algorithm directly).

The property is not writable, but it does shadow the same property
in the global object.

It appears that the id-elements are *also* properties of the
global/window object, but these properties are not ReadOnly
and can be overwritten. After this, "foo" and "window.foo "
resolves to different values.

And further, if a variable or function with the same name is declared
in the global scope, "foo" no longer resolves to the element with that
id.
Even more interesting, the behavior depends on whether one reads the
property of the global objecct as an element before assigning it
another value:

<script type="text/javascript">
// window.bar = 42; // [1]
</script>
<div id="bar">bar</div>
<script type="text/javascript">
//alert([bar, typeof bar, window.bar, typeof window.bar]); // [2]
window.bar = "window.bar ";
alert([bar, typeof bar, window.bar, typeof window.bar]);
// alerts "window.bar,str ing,window.bar, string"
</script>

In the above, if [2] is uncommented, the final alert changes
to "[object],object,window. bar,string". I.e., the action of
*reading* "bar" as the element with that id causes later
references to give the same result.

If [1] is also uncommented, the final alert changes back again.
I.e., if a property of the name is already on the global object
when the element is parsed and added to the DOM, then its name is
not resolved specially and it is not set on the global object.
Ok, this was a diversion. The point is: There global object and
the value of the "window" property of the global object is the
same object in MSHTML, just as in the other current browsers.

My bet is that you can expect that to stay true.

....
That is not the reason why. Because if someone declared `window' in the
scope chain before the Global Object (so as this would not refer to the
`window' property of the Global Object anymore), then the issue remained.
It is instead that it is unlikely that someone would do that.

To be absolutely sure, one would have to feature-test and use
global.window.a lert(), with `global' being a globally defined reference to
the Global Object (var global = this), instead.
That's not being "absolutely sure". The "global" property could
equally well have been overwritten or shadowed, and it's probably even
more likely than someone shadowing "window" or "alert", since those
are well known global properties.

To be absolutely sure, you should create a reference to the global
object at the point where it is needed, so you don't rely on a binding
that could be overwritten or shadowed.

e.g.
var global = (function(){ret urn this;})();
global.alert(gl obal == global.window);

(which, by the way, alerts "true" in all the browsers I have available,
including in MSHTML :).

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'
Aug 24 '08 #4
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@we b.dewrites:
>Gregor Kofler wrote:
>>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>>object, in browsers the window object.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^

This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.

It does seem that the global object's "window" property holds a
reference to the global object itself in all current browsers, to the
^^^^^^^^^^^^^^^ ^^^^^
point where a new browser would be causing itself problems by not
doing the same.
No standard, true, except de-facto standard.
That is exactly what I mean. *Exhaustive* research would have included at
least a list of the tested user agents that are deemed to be "current" by
the tester. And it would have to cover *all browsers* instead for the
discussed statement to be confirmed as generally true. It is confirmations
like yours that show such general assertions to be misleading and ultimately
irresponsible.

I am going to look into your other arguments later.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Aug 24 '08 #5
Thomas 'PointedEars' Lahn <Po*********@we b.dewrites:
That is exactly what I mean. *Exhaustive* research would have included at
least a list of the tested user agents that are deemed to be "current" by
the tester.
In this case the tested browser were:
IE 8 beta, Opera 9.52, Firefox 3.01 and Safari 3.1.2
all on Windows.
And it would have to cover *all browsers*
That's impossible, so it should select a subset of known browsers
that are considered relevant.
E.g., I would omit Links, since it has no scripting support at all.
I would probably also omit Netscape version 3, since its market share
is effectively zero.

But yes, this was not an exhaustive research. It was a quick-and-dirty
check against the most common browsers and browser-engines (I can't
check iCab, don't have a Mac).

The secondary point was to say that, as far as I know, there have not
yet been a browser engine with a more than 1% user share that has not
had the global object be equal to the object referenced by the global
object's "window" property. It was so in Netscape 2 (you can add that
to the tested cases), and no browsers since have dared change that. My
experience is not "exhaustive research", but I do believe it is more
than "wishful thinking".

And the primary point was that it did hold for IE.
instead for the discussed statement to be confirmed as generally
true. It is confirmations like yours that show such general
assertions to be misleading and ultimately irresponsible.
Find one cases where it isn't true, in a browser that has any
significant number of users, and I'll agree.

*Any* standard feature of browsers might be broken or differently
implemented in some version of obscure browser. Unless that obscure
browser stays broken and gains a significant market-share, it can
safely be ignored. It is the browser producer/user's responsibility
to get it fixed.

A non-standard feature with as widespread an adherence as the "window"
property can be treated as a standard feature. If a browser fails to
be compatible with everybody else, ot an extend that it is visible in
pages, that browser will be considered broken. A de-facto standard is
at least as strong a requirement as an official standard. Since it
became a de-facto standard because of a need for that feature, it's
more likely to be implemented correctly than less important parts
of an official standard (or IE wouldn't have gotten away with
letting "[2,].length" evaluate to 2 after all this time).

The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.w indow == globalObject).

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'
Aug 24 '08 #6
Lasse Reichstein Nielsen wrote:
The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.w indow == globalObject).
However, that would be supporting a logical fallacy because I did not make
the general statement in question here. Certainly I have no intention to do
that.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Aug 24 '08 #7
Thomas 'PointedEars' Lahn <Po*********@we b.dewrites:
Lasse Reichstein Nielsen wrote:
>The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.w indow == globalObject).

However, that would be supporting a logical fallacy because I did not make
the general statement in question here. Certainly I have no intention to do
that.
Ah, am I misreading the response:

Thomas 'PointedEars' Lahn <Po*********@we b.dewrites:
Gregor Kofler wrote:
>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>object, in browsers the window object.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.
if I interpret "this assertion" as being that the global object is the
window object in browsers? Is the assertion instead that the scope
chain ends in the global object?

Neither assertion would be based on wishful thinking. The latter would
be backed up by the ECMAScript standard.

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'
Aug 24 '08 #8
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@we b.dewrites:
>Lasse Reichstein Nielsen wrote:
>>The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.w indow == globalObject).
However, that would be supporting a logical fallacy because I did not make
the general statement in question here. Certainly I have no intention to do
that.

Ah, am I misreading the response:

Thomas 'PointedEars' Lahn <Po*********@we b.dewrites:
>Gregor Kofler wrote:
>>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>>object, in browsers the window object.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.

if I interpret "this assertion" as being that the global object is the
window object in browsers? Is the assertion instead that the scope
chain ends in the global object?
No, but instead that "in [all] browsers [the global object was] the window
object". This is the result of the quantificationa l logical fallacy of
"proof by example" (because statement A is asserted to be true for example
subset B within set C, it is falsely asserted that it is/must be true for
all elements of C).

For example, a valid argument would have been "It will finally end up at the
global object, in *some* browsers the window object." This argument can be
discussed because the subset of browsers to which said property is asserted
to apply ("some") can be named, and the assertion can either be confirmed or
refuted for each element of that subset, and thereby for the entire subset.
Neither assertion would be based on wishful thinking.
Yes, the former would. The original author of that statement wishes the
statement to be (generally) true because, if so, that would make Web
development easier.
The latter would be backed up by the ECMAScript standard.
Correct, and this was not debated, of course.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Aug 24 '08 #9
So... if I were to paraphrase and understand:

alert may refer to any property along the scope chain and thus, should
not be used alone.

In most major browsers, "window" refers to the global object, unless
overridden.

Any browser where window != the global object will have enough other
problems that it can be ignored.

You may create your own reference to the global variable and use that
instead via
var globalObject = this;

in the right context, but this has all the limitations of using 'window'
Aug 25 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.