window object

[yb]

Hi,

Is there a standard for the global 'window' object in browsers? For
example, it supports methods such as setInterval and clearInterval, and
several others.

I know that w3c standardized several parts of the DOM, but this does
not include the window object.

Thank you

 

[RobG]

Hi,

Is there a standard for the global 'window' object in browsers? For
example, it supports methods such as setInterval and clearInterval, and
several others.

The window object is not part of either the ECMAScript Language or W3C
Document Object Model (DOM) specification - it belongs to DOM Level 0,
which is described in the introduction to the W3C DOM 1 specification as:

'The term "DOM Level 0" refers to a mix (not formally specified)
of HTML document functionalities offered by Netscape Navigator
version 3.0 and Microsoft Internet Explorer version 3.0. In some
cases, attributes or methods have been included for reasons of
backward compatibility with "DOM Level 0".'

<URL:http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-1176245063>


You will find references to the window object in the Gecko DOM reference:
<URL:http://developer.mozilla.org/en/docs/DOM:window>

and MSDN's 'HTML and DHTML' documentation:
<URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/obj_window.asp>


The global object is a concept of the ECMAScript Language (colloquially
known as 'JavaScript', which is a registered trademark of Sun
Microsystems, Inc.), see section 10.1.5 of the specification.

In user agents that have a concept of a window object, it is synonymous
with the global object. When explaining the global object, the above
reference says:

"...in the HTML document object model the window property of
the global object is the global object itself."


You can test whether that is true - 'this' outside any other context
refers to the global object:

var Global = this;

Now 'Global' refers to the global object. To check that it refers to
the same object as window:

alert( Global === window ); // shows 'true'


I guess it's possible that somewhere there is an ECMAScript environment
that implements a window object that isn't the global object. It's more
likely you'll find one that doesn't have a window object at all (but it
must have a global object if compliance matters).

I know that w3c standardized several parts of the DOM, but this does
not include the window object.

Generally there is no need to reference the window object. If there is
a circumstance that you feel 'window' should be included in a reference,
but are uncertain whether the environment supports a window object, then
use the abovementioned 'Global' variable, e.g.

var Global = this;

function someFn(){
...
Global.setTimeout(...);
...
}


Some believe that a fully qualified reference (e.g. window.setTimeout())
makes scripts run faster as it reduces the time spent on scope chain
resolution - I have never tried to confirm whether that is true or not.

 

[Lasse Reichstein Nielsen]

I guess it's possible that somewhere there is an ECMAScript
environment that implements a window object that isn't the global
object.

The Adobe SVG plugin, IIRC.
It has a window object, but it is not the global object.

Also note that the SVG specification is trying to formalize
some parts of DOM 0.

Some believe that a fully qualified reference
(e.g. window.setTimeout()) makes scripts run faster as it reduces the
time spent on scope chain resolution - I have never tried to confirm
whether that is true or not.

It should be false. In fact is should run slower, if anything.
The global "window" variable name is no different form "setTimeout".
Both must be looked up in the same scope chain, ending at the global
object. After that, "window.setTimeout" will do one further property
lookup on the global object, so it should take longer than just using
"setTimeout" directly.

/L

 

[VK]

It should be false. In fact is should run slower, if anything.
The global "window" variable name is no different form "setTimeout".
Both must be looked up in the same scope chain, ending at the global
object. After that, "window.setTimeout" will do one further property
lookup on the global object, so it should take longer than just using
"setTimeout" directly.

It is not true at least for IE 5.0 or higher and Opera 8.0 or higher -
thus for 80%-90% of the browsers on the market (grace to IE). Therefore
ECMA-compliant scope schema will be rather a rare exeption than a rule
with your visitors. One can hate it, scream and cry about it - but
at least she should be aware of it.

For IE and Opera "Global" object and "window" object constitute two
distinct programming scopes. Again I'm not talking about some
occasional models like Adobe SVG plugin or such.
I'm talking about the standard environment of a HTML page (XHTML is not
supported by IE and interpreted as regular HTML) with a script running
on it.

In such case we have Global scope (level of global variables ang Global
methods like escape, encodeURI etc.) and Window scope *above* it (level
of ID'entified HTML elements and window methods like setTimeout, open
etc.)

On lookup the engine search first in the Global scope, if not found
then in the window scope.

Therefore if we say declare
var setTimeout = 'foobar';
we shadow window.setTimeout reference (engine will find "setTimeout" in
the Global scope first thus will never look in the window scope above).

Respectively if we declare:
window['foo'] = 'bar';
and later call alert(foo) then
engine will look first in the Global scope, fail on it, then look in
the window scope and find it.

For a non-aware user the fact that:
window['foo'] = 'bar';
alert(foo); // 'bar'
may lead to the conclusion that Global scope and window scope are the
same - but nothing more far from the true than that, again - at least
for IE and Opera.

It also explain the real mechanics of possible circular reference leaks
in IE as well as explains the overall higher memory consumption by
JScript - which is *not* a memory leak but makes nervious many
developers, specially ones coming from a C++ or so background.

As I'm kind of tired of regular hysterics about "VK unbellyfeels ECMA":
here a sample and I don't care if it trigs the thinking process or the
doublethink will help as usual.
....
<script type="text/javascript">
var v1 = true;

function demo() {
var v2 = true;
alert(v1);
alert(v2);
alert(this[v2]);
alert(v3);
}

window.onload = demo;
</script>
....
<div id="v1">v1</div>
<div id="v2">v2</div>
<div id="v3">v3</div>
....

P.S. If it helped to start the thinking process (which I still hope
despite don't care too much anymore):- the next question would be: "Is
it possible and how in IE's scope model that a DOM object is still
referenced in the execution context - thus not GC-available - despite
no one JScript variable holds a reference to it?"

 

[Thomas 'PointedEars' Lahn]

[...]
The global object is a concept of the ECMAScript Language (colloquially
known as 'JavaScript', which is a registered trademark of Sun
Microsystems, Inc.), see section 10.1.5 of the specification.

In user agents that have a concept of a window object, it is synonymous
with the global object. When explaining the global object, the above
reference says:

"...in the HTML document object model the window property of
the global object is the global object itself."

However, this is not a normative statement.

You have already pointed out that "the window object" is not specified in
ECMAScript or the W3C DOM. But to be absolutely clear about this: The
above non-normative statement originates from ECMAScript Edition 1 (June
1997) where it referred to "(the) HTML (document object model)" of the
only user agents that implemented ECMAScript: Netscape Navigator (with
JavaScript), and Internet Explorer (with JScript). (Most notably, in
JavaScript there had been no separation between core language and
[Netscape] DOM/AOM before JavaScript 1.4 [1999].) It certainly was not
intended to refer to the W3C Document Object Model HTML specifications
(the earliest draft of W3C DOM Level 1 HTML dated 1997-10-09). The term
"HTML" has been changed to "the HTML document object model" in ECMAScript
Edition 3 (December 1999), probably to distinguish between the markup
language and the object model used to access the element tree created
when it is parsed.

You can test whether that is true - 'this' outside any other context
refers to the global object:

var Global = this;

Now 'Global' refers to the global object. To check that it refers to
the same object as window:

alert( Global === window ); // shows 'true'

Your logic is flawed, because the `window' property of the Global object
refers to a host object which does not need to strictly implement
ECMAScript algorithms, including the algorithm for the `===' operator.

Given the above strict comparison, it could as well be, and would strictly
conform to the ECMAScript specification, that the Global Object and the
object referred to by its host-defined `window' property are different
objects; that the properties of the object referred to by the `window'
property of the Global Object are also host-defined properties of the
Global object that are added to it before execution context is entered;
that every augmentation of the host object referred to with the `window'
property of the Global Object includes augmentation of the Global Object
(and vice-versa) through language-specific conforming extensions to the
ECMAScript specification. It has been showed already here that there is a
host object that implements the `==' operation different than specified.


PointedEars

 

[VK]

In user agents that have a concept of a window object, it is synonymous
with the global object.

I'm aware of only one browser where this is true: Firefox. "Bravo
Firefox!" etc. but with the current share of actions this standard
behavior is rather non-standard on the web-wide run.

When explaining the global object, the above
reference says:

"...in the HTML document object model the window property of
the global object is the global object itself."

While MSDN says: "For client versions of JScript, this refers to the
window object if used outside of the context of any other object."
However non-standard it may be, it is implemented exactly as
documented.

You can test whether that is true - 'this' outside any other context
refers to the global object:

var Global = this;

Now 'Global' refers to the global object. To check that it refers to
the same object as window:

alert( Global === window ); // shows 'true'

Again: this test does what expected only for Firefox. In IE you simply
getting a reference to the window and then compare window===window with
is naturally true. Global object is escaping this test. See my post in
this thread for the correct test demonstrating that Global and Window
are different objects with separate scopes.
Moreover IE distincts "The Window" (the global context atop of Global
object) and "the window" (surrent window where the script is
executing). Therefore "window" object is "The Window" while window.self
is "the window". IE needs it as it implements additional current window
scope for constructors. Say you cannot create a new instance using
constructor located in another frame (it will be "Cannot use freed
script" error).

Overall there is much more of mechanics here than one sencence from
Books of ECMA. And actually Books of ECMA is the least informative
source to look at *for this particular question*. ;-)

Just another chunk to think about (feel free to experiment further)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"
"http://www.w3.org/TR/html401/strict.dtd">
<html>
<head>
<title>Global vs. Window</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<style type="text/css">
body { background-color: #FFFFFF}
</style>

<script type="text/javascript">
/* Test 1 */
alert(this === window);
alert(this === window.window);
alert(this === self);
alert(window === self);

// IE 6.0
// true
// false
// false
// false

// Opera 8.51
// false
// false
// false
// true

// Firefox 1.5.0.1
// true
// true
// true
// true

function demo() {
/* Test 2 */
var alert = function(m) {window.alert(m+'bar');}
alert('foo'); // 'foobar'
window.alert('foo'); // 'foo'
}

window.onload = demo;
</script>

</head>

<body>

<div id="v1">v1</div>
<div id="v2">v2</div>
<div id="v3">v3</div>

</body>
</html>

 

[VK]

VK wrote:
I'm aware of only one browser where this is true: Firefox.

Actually it is not true for Firefox neither: they just tryed to *mimic*
that ECMA statement as hard as they could, so it's really difficult to
catch them on the act

Nevertheless the test #2 from my previous post gets them - I just
didn't check it first on Firefox:

function demo() {
/* Test 2 */
var alert = function(m) {window.alert(m+'bar');}
alert('foo'); // 'foobar'
window.alert('foo'); // 'foo'
// Gocha!
}

 

[Michael Winter]

function demo() {
/* Test 2 */
var alert = function(m) {window.alert(m+'bar');}
alert('foo'); // 'foobar'
window.alert('foo'); // 'foo'
// Gocha!
}

That doesn't prove anything, except that /you/ are unbelievably incompetent.

Mike

 

[VK]

That doesn't prove anything, except that /you/ are unbelievably incompetent.

As I said: whatever.

P.S.
<script type="text/javascript">
var alert = function(m){window.alert('bar');}
(this.alert('foo'));

// 'foo'
// 'bar'
</script>

 

[Thomas 'PointedEars' Lahn]

|
As I said: whatever. |
|
P.S. |
<script type="text/javascript"> |
var alert = function(m){window.alert('bar');} |
(this.alert('foo')); |
|
// 'foo' |
// 'bar' |
</script> |

|
---------------------------------------------------------------------'


PointedEars

 

[Michael Winter]

Michael Winter wrote:
[snip]

That doesn't prove anything, except that /you/ are unbelievably
incompetent.

As I said: whatever.

The fact that you don't understand your own code is proof.

P.S.
<script type="text/javascript">
var alert = function(m){window.alert('bar');}
(this.alert('foo'));

This is more interesting, but not for the reason you'd like to think.

It seems that Fx isn't parsing this properly. The following:

var alert = function() {
window.alert('bar');
};
(this.alert('foo'));

should be exactly identical; the only significant difference is the
addition of a semicolon at the end of the variable declaration. However,
the change in behaviour is profound: instead of the previous two
dialogue boxes, the code now throws a recursion error.

It seems that the previous code (posted by VK) is equivalent to:

var alert = (function() {
window.alert('bar');
})(this.alert('foo'));

That is, the native alert method is called with an argument, 'foo'. The
return value (undefined) is then passed as an argument to a function
expression, which calls the native alert method a second time, with an
argument, 'bar'. The return value from the function expression call
(undefined) is then assigned to declared variable, alert. This final
step can be observed in both cases with a call to the write method:

document.write(typeof alert); /* undefined */


To Randy (if you're reading): I think you asked for an example where
explicit semicolons make a difference. This is a bug, granted, but an
example nevertheless.

Mike

 

[Michael Winter]

On 04/03/2006 15:44, VK wrote:
[snip]

var alert = function(m){window.alert('bar');}
(this.alert('foo'));

[snip]

var alert = function() {
window.alert('bar');
};
(this.alert('foo'));

should be exactly identical [...]

I forgot to mention that removing the parentheses from around the call
(preceding semicolon, or not) also produces the expected recursion error.

[snip]

Mike

 

[Michael Winter]

Michael Winter wrote:

[snip]

That doesn't prove anything, except that /you/ are unbelievably
incompetent.

As I said: whatever.

The fact that you don't understand your own code is proof.

P.S.
<script type="text/javascript">
var alert = function(m){window.alert('bar');}
(this.alert('foo'));

[snip]

It seems that Fx isn't parsing this properly. [...]

Scratch that. I'm so used to writing:

(function() {
})(...);

that I forgot that:

function() {
}(...);

is perfectly fine as long as 'function' isn't the first token (as in the
Initialiser production, above).

Mike

 

[VK]

I don't understand ECMA/Firefox sometimes - it is true. Their way of
thinking and acting is sometimes too alien to what I used from Netscape
and Internet Explorer.

So I just have to repeat once again: "Bravo Firefox!". Whatever is
strictly spelled, vaguely mentioned or softly murmured in ECMA or W3C
is being implemented at the best of human abilities.

So then we have two scope schemas: one from IE other from FF. Opera is
kind of sitting between two chairs (which is the normal position for
this browser

I'm wandering what my tests would show for Safari/Konqueror.

 

[Thomas 'PointedEars' Lahn]

I don't understand ECMA/Firefox sometimes - it is true.

You have never displayed a blink of understanding of the specification.

Their way of thinking and acting is sometimes too alien to what I used
from Netscape and Internet Explorer.

It is not. You have just still not understood that Netscape 3+ and Internet
Explorer use ECMAScript implementations as primary scripting language, and
that conforming ECMAScript implementations may be extended compared to the
specification, according to its Conformance section.


PointedEars

 

[VK]

It is not. You have just still not understood that Netscape 3+ and Internet
Explorer use ECMAScript implementations as primary scripting language

One cannot implement something that has to be written yet (ECMAScript
specs).
Netscape Gold and Internet Explorer 3.02 simply have JavaScript 1.1 and
JScript 1.0 as primary scripting language respectively (Internet
Explorer 3.0 has VBScript as default language).

and
that conforming ECMAScript implementations may be extended compared to the
specification, according to its Conformance section.

What does it have to do with tea and China? IE and Opera have two
separate scopes: Global and enclosing Window. Firefox has (or
pretending to have) only one: Global wich is Window (or Window which is
Global - I'm really lost here). If both allowed by specs so the better.
If one of them is not allowed by specs - it doesn't make it disappear.

One cannot just keep saying "This is so because it is written so". You
need some correlation with the reality, especially if it involves
80%-90% of UA's (?)

 

[Thomas 'PointedEars' Lahn]

One cannot implement something that has to be written yet (ECMAScript
specs).

One can. It is the idea of the language that counts here, not the written
representation of it.

Netscape Gold and Internet Explorer 3.02 simply have JavaScript 1.1 and
JScript 1.0 as primary scripting language respectively

,-[ECMAScript Edition 3]
|
| Brief History
|
| This ECMA Standard is based on several originating technologies, the
| most well known being JavaScript (Netscape) and JScript (Microsoft). The
| language was invented by Brendan Eich at Netscape and first appeared in
| that company's Navigator 2.0 browser. It has appeared in all subsequent
| browsers from Netscape and in all browsers from Microsoft starting with
| Internet Explorer 3.0.
|
| The development of this Standard started in November 1996. The first
| edition of this ECMA Standard was adopted by the ECMA General Assembly
| of June 1997.
|
| That ECMA Standard was submitted to ISO/IEC JTC 1 for adoption under the
| fast-track procedure, and approved as international standard ISO/IEC
| 16262, in April 1998. The ECMA General Assembly of June 1998 approved the
| second edition of ECMA-262 to keep it fully aligned with ISO/IEC 16262.
| Changes between the first and the second edition are editorial in nature.

Therefore, and because of the behavior they display, one can say
rightfully that both JavaScript 1.1 (implemented in Netscape 3.0,
August 1996), and JScript 1.0 (implemented in IE 3.0, dito) are
(extended) ECMAScript implementations.

(Internet Explorer 3.0 has VBScript as default language).

I cannot test that, yet both the W3C DOM HTML Specification (in
its reference to DOM Level 0) and the MSDN Library say otherwise.


PointedEars

 

[Richard Cornford]

It is not true at least for IE 5.0 or higher and Opera 8.0
or higher - thus for 80%-90% of the browsers on the market
(grace to IE).

What is not true? That - window.setTimeout - should take longer to
resolve than unqualified - setTimeout -? It does take longer, you just
have to time it to see that.

Therefore ECMA-compliant scope schema will be rather a rare
exeption than a rule with your visitors. One can hate it,
scream and cry about it - but at least she should be
aware of it.

So is it the resolution of Identifiers against the scope chain, or the
scope chain itself that you think does not follow the specification?
That should be fairly simple to demonstrate as all you would have to do
is show some code that ECMA 262 says should result in one behaviour that
actually exhibits another. Of course you need to both know what ECMA 262
says the code should do and understand the code written. That is a bit
of a problem for you as you don't understand ECMA 262 or the javascript
you write.

For IE and Opera "Global" object and "window" object
constitute two distinct programming scopes.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And that should be a fairly simple assertion to back-up. Although
"programming scopes" is essentially meaningless; another piece of
fictitious jargon from someone more interested in giving the impression
that they know more than they do. On the other hand "two distinct" is
concrete enough for consideration. It implies that the global object and
the window object are two distinct entities.

Again I'm not talking about some
occasional models like Adobe SVG plugin or such.
I'm talking about the standard environment of a HTML page
(XHTML is not supported by IE and interpreted as regular HTML)
with a script running on it.

In such case we have Global scope (level of global variables
ang Global methods like escape, encodeURI etc.) and Window scope
*above* it (level of ID'entified HTML elements and window methods
like setTimeout, open etc.)

The implication if which is that there are two distinct objects on the
scope chain; one the ECMAScript global object with the specification
defined properties and the other a true host object with browser defined
properties.

On lookup the engine search first in the Global scope, if not
found then in the window scope.

So in scope chain resolution the ECMAScript global object is encountered
first on the scope chain and the 'window' object comes after that?

Well, we can test that proposition with a bit of scope chain
augmentation. Suppose we explicitly put the object referred to by -
window - on the scope chain of an inner function (with a - with -
statement) and give the outer function local variables with identifiers
that would mask global properties of interest. Acting upon those
unqualified Identifiers inside the inner function would not involve the
consequences of getting to the end of the scope chain because if not
resolved as propitious of the object added to the scope chain they would
be caught by being resolved as priorities of the Activation/variable
object of the outer function.

If the window and global objects are two distinct entities that have
different sets of properties, Identifiers referring to properties of
the one that had _not_ been added to the scope chain would be
resolved as the outer function's local variables. Finding any single
Identifier that could not be resolved as a property of the object
added to the scope chain would _prove_ that there were two distinct
objects, failing to demonstrate this would suggest a single global
object. E.G:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">

var globalVar = 'Global Variable';

function getWindow(){
return window;
}
function getGlobal(){
return this;
}

window.onload = (function(){
var localFnc;
/* Identifier corresponding with IDed DIV element */
var testDiv = 'Outer Function variable';

/* Identifiers corresponding with ECMA global object properties */
var Math = 'Outer Function variable';
var Array = 'Outer Function variable';
var Object = 'Outer Function variable';
var eval = 'Outer Function variable';
/* Identifiers corresponding with browser object model global
properties. */
var clipboardData = 'Outer Function variable';
var setTimeout = 'Outer Function variable';
var alert = 'Outer Function variable';
var window = 'Outer Function variable';

/* Identifier corresponding with a declared global variable */
var globalVar = 'Outer Function variable';

/* Explicitly add a property to the - window - object:- */
getWindow()['foo'] = 'Assigned to window object'
/* Identifier corresponding with an property explicitly added
to the window object */
var foo = 'Outer Function variable';

/* Explicitly add a property to the - this - object:- */
this['bar'] = 'Assigned to window object'
/* Identifier corresponding with an property explicitly added
to the window object */
var bar = 'Outer Function variable';

/* Cannot use the - window - reference directly as it is defined
as a local string variable in this scope so call a function
that will return - window - instead:- */
with( getWindow() ){ // Add the - window - object to the inner
// function's scope chain.
localFnc = (function(){
alert(
'*Identifier corresponding with IDed DIV element\n'+
'testDiv = '+testDiv+

'\n\n*Identifiers corresponding with ECMA global object'+
' properties\n'+
'\nMath = '+Math+
'\nArray = '+Array+
'\nObject = '+Object+
'\neval = '+eval+

'\n\n*Identifiers corresponding with browser object model'+
' global properties.\n'+
'\nclipboardData = '+clipboardData+
'\nsetTimout = '+setTimeout+
'\nalert = '+alert+
'\nwindow = '+window+

'\n\n*Identifier corresponding with a declared global'+
' variable\n'+
'\nglobalVar = '+globalVar+

'\n\n*Identifier corresponding with an property explicitly'+
' added to the window object'+
'\nfoo = '+foo+

'\n\n*Identifier corresponding with an property explicitly'+
' added to the global - this - object'+
'\nbar = '+bar+
''
);
});
}
/* Return the inner function so it can be assigned to
- window.onload -:- */
return localFnc;
})();


</script>
</head>
<body>
<div id="testDiv">XXX</div>
</body>
</html>

It is also possible to repeat that experiment using the - this -
reference as the object added to the scope chain (or any other
candidate for similar consideration).

And the results of running that on IE 6 are that whichever object (-
window - or - this -) is added to the inner function's scope chain that
object has; properties that correspond with IDed DOM elements,
properties that correspond with ECMA 262 defined global properties,
properties that correspond with expected browser object model global
properties, properties that correspond with declared global variables
and properties corresponding with properties added to both the -
window - and - this - object at runtime.

This result shows no evidence of two distinct objects at the end of the
scope chain as the single object that is expected to be at the end of
the scope chain behaves as if it has all the required properties itself.

Therefore if we say declare
var setTimeout = 'foobar';
we shadow window.setTimeout reference (engine will find
"setTimeout" in the Global scope first thus will never
look in the window scope above).

No demonstration of 'shadowing' has been made. The behaviour
demonstrated is instead completely in accordance with a single global
object being subject to procedure for variable instantiation as
described in ECMA 262, 3rd ed. sections 10.1.3 and 10.2.1.

Respectively if we declare:
window['foo'] = 'bar';
and later call alert(foo) then engine will look first in
the Global scope, fail on it, then look in
the window scope and find it.

With the implication that the global object does not have an - alert -
property or a - foo - property? Neither have been demonstrated, and the
above test shows that both the - window - object and the global - this -
object behave in isolation as if they have properties corresponding with
ECMA 262 defined global properties, browser global properties, declared
local variables, runtime added properties, etc.

For a non-aware user the fact that:
window['foo'] = 'bar';
alert(foo); // 'bar'
may lead to the conclusion that Global scope and window scope
are the same - but nothing more far from the true than that,
again - at least for IE and Opera.

So far no case has been made for that conclusion.

It also explain the real mechanics of possible circular
reference leaks in IE

You mean the things that you didn't believe existed last week, and still
don't understand?

as well as explains the overall higher memory consumption
by JScript - which is *not* a memory leak but makes nervious
many developers, specially ones coming from a C++ or so
background.

Explaining the circular reference memory leaks in terms of inaccessible
additional objects in the scope chain would be inadequate as then the
problem could not be addressed, due to the inaccessibility of these
additional objects.

As I'm kind of tired of regular hysterics about
"VK unbellyfeels ECMA":

Stop making out that you know something special to people who have a
better understanding of the subject than you and have considerably
greater talent for analysis than you and you may stop people calling you
a fool.

here a sample and I don't care if it trigs the thinking
process or the doublethink will help as usual.

Although writing sentences that make sense would also contribute to your
not being considered quite the fool you currently are.

...
<script type="text/javascript">

Once again you post code without stating what it is you suppose that it
is demonstrating. And in not stating what is supposed to be demonstrated
by this code it becomes difficult to say whether it is demonstrated or
not, but presumably if you are trying to make any point at all your
notion of this code is that it demonstrates something that would differ
from the behaviour predicted by an ECMA 262 conforming implementation.
Well, lets look at the ECMA 262 derived perdition and see if the results
do demonstrate IE differing from that behaviour:-

var v1 = true;

A global variable is declare and assigned a value. Variable
instantiation in the global scope uses the ECMAScript global object as
the variable object so it would be the global object to which a property
would be added with the name 'v1', unless the property already exists in
which case it is left alone. When the global code is executed a value is
assigned to that property of the global object.

function demo() {
var v2 = true;

A local variable is created with the name 'v2' on the function's
execution context's Activation/variable object and when the function
body is executed the boolean value - true - is assigned to that
property.

alert(v1);

Output, now we get to see if behaviour corresponds with expectations.
The Identifier - alert - is resolved into a reference to the global -
alert - function and that function is called with an argument list
consisting of the value read using the Identifier - v1 - . The
Identifier - v1 - is resolved at the end of the scope chain as a
property of the global object that corresponds with the declared global
variable and has the value - true -. The - alert - function
type-converts its boolean - true - argument into the string 'true' and
alerts that.

ECMA 262 predicted outcome: alters the string 'true'.

Observed outcome: alerts the string 'true'.

alert(v2);

Similarly the Identifier - v2 - is resolved as a property of the
function's execution context's Activation/Variable object. That property
has the value - true - and alert type converts that into the string
'true'.

ECMA 262 predicted outcome: alters the string 'true'.

Observed outcome: alerts the string 'true'.

alert(this[v2]);

This time the argument to - alert - is the result of the expression -
this[v2] -. As this function is executed as a method of the - window -
object the - this - keyword is resolved as a reference to the - window -
object. The bracket notation property accessor requires that the - v2 -
Identifier be resolved, evaluated and type-converted into a string that
will be used as a property name in association with the - this - object.
The - v2 - Identifier is resolved as the local variable - v2 - with the
value - true -. That value is type-converted into the string 'true' and
used as the property name to be resolved in association with - this -,
i.e.- this['true'] -.

The expression - this['true'] - returns the value - undefined - because
the window object has no property named 'true', and alert type-converts
undefined into the string 'undefined' and alerts that.

ECMA 262 predicted outcome: alters the string 'undefined'.

Observed outcome: alerts the string 'undefined'.

alert(v3);

As we know IE (and other browsers) make DOM elements with ID attributes
available as global properties under names corresponding with their IDs,
assuming that they do not clash with declared global variables. The
Identifier - v3 - corresponds with the ID of a DOM element and does not
clash with a declared global variable so we can expect - v3 - to resolve
as a reference to that DOM element. The type-conversion of an IE DOM
element to a string is the string '[object]' so that is what will be
alerted.

ECMA 262 predicted outcome: alters the string '[object]'.

Observed outcome: alerts the string '[object]'.

}

window.onload = demo;
</script>
...
<div id="v1">v1</div>
<div id="v2">v2</div>
<div id="v3">v3</div>
...

So once again you post code that is supposed to demonstrate some arcane
'truth' that actually does no more than behave 100% in accordance with
the behaviour that would be expected of a 100% ECMA 262 3rd ed.
conforming implementation. There is certainly nothing happening here
that requires more than one global object, or suggests any additional
objects on the scope chain.

Did you, by any chance, let yourself be fooled by - alert(this[v2]); -
alerting ' undefined'? I think you did, but as has been pointed out so
many times you don't understand the basics of javascript so you don't
understand what the code you write actually does. You probably indented
to write - alert(this['v2']); - or - alert(this.v2); -, but that would
have alerted '[object]' and done nothing but demonstrated more expected
behaviour.

P.S. If it helped to start the thinking process (which
I still hope despite don't care too much anymore):-

It appears that no matter how often you make yourself look a fool in
public it never starts your thinking process. You have made the mistake
of confusing yourself with someone who knows what they are doing and
apparently no amount of evidence to the contrary is capable of enabling
you to rectify that error.

the next question would be: "Is it possible and how in IE's
scope model that a DOM object is still referenced in the
execution context - thus not GC-available - despite
no one JScript variable holds a reference to it?"

Given that you made your original proposition up off the top of your
head without any evidence to back it up and posted a non-demonstration
of it 'in action', the 'next question' is entirely moot. However, that
'next question' hardly qualifies as a question, being the sort of
incoherent rambling that might be expected from the mentally ill.

Richard.

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 3/4/2006 3:20 PM:

VK wrote:


I cannot test that, yet both the W3C DOM HTML Specification (in
its reference to DOM Level 0) and the MSDN Library say otherwise.

And those two references are always 100% correct? Think about what MSDN
had to say about IE7 and the XMLHTTPRequest Object before you answer.
And if that doesn't do it, consider what MSDN has to say about toFixed()
and where it is known *not* to work.

MSDN and W3C are not always correct. Doesn't mean I agree with VK (I
don't care what the default language in IE3.0 was), I do disagree with
the notion (and VK pointed it out) that "Just because something says so
doesn't make it right)". And that alone makes me not care what the specs
say as much as I care what the browsers/UA actually *does* with code.

 

[Richard Cornford]

You lack of awareness of web browsers is becoming legendary.

Actually it is not true for Firefox neither: they just
tryed to *mimic* that ECMA statement as hard as they could,
so it's really difficult to catch them on the act

And particularly difficult when you don't know what the code you write
is supposed to do, have no analytical skills and don't really comprehend
logic.

Nevertheless the test #2 from my previous post gets them
- I just didn't check it first on Firefox:
LOL

function demo() {
/* Test 2 */
var alert = function(m) {window.alert(m+'bar');}
alert('foo'); // 'foobar'
window.alert('foo'); // 'foo'
// Gocha!
}

So after all this time (what is it, 8-9 years) of supposedly scripting
web browsers you don't actually understand how local variables work? You
create a local variable called - alert - and then assign a reference to
a function object to it and then you don't see why the unqualified
Identifier - alert - is resolved as a reference to that local variable
(and its assigned function) while the property accessor - window.alert -
resolves as a reference to the global - alert - function? How many false
conclusions have you drown over those years form misconceiving the code
that your write?

How can you possibly hope to deduce anything about how web browsers
behave if you don't even know what the code you are writing is supposed
to be doing? Don't you think it would be a good idea to stop bothering
people here with your misconceived nonsense until you have learnt the
basics of the language you are so keen to assert your expertise in?

Richard.