By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,636 Members | 1,181 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,636 IT Pros & Developers. It's quick & easy.

Client-side DOM: are 'window' and 'document' real objects?

P: n/a
I'm seeing some unexpected (at least to me) behavior in the 'window' and
'document' objects under Netscape 7.1 and Internet Explorer 6.0.

When a property is added to the prototype for 'Object', it was my
understanding that it should be visible to all objects.

But it appears that it is NOT visible in the 'window' object of either IE or
Netscape.
It is visible in the 'document' property of Netscape, but not IE.
It is visible in user-created objects and object literals in both Netscape
and IE (as expected).

Thus it appears that 'window' and 'document' do not act like normal objects.

Also, under IE 'window' and 'document' do not have constructor properties,
whereas in Netscape they are defined as 'Window' and 'HTMLDocument'
respectively. This seems particularly strange since even object literals
have a constructor property (in both browsers).

1) Is this the correct behavior for the 'window' object?
2) Is the Netscape or IE behavior correct for the 'document' object?
3) Can anyone point me to appropriate documentation for the behavior or
these objects?

Below is an HTML page which demonstrates this behavior.

If anyone could shed any light on what is going on here (or point me to a
good resource), I would be very grateful.

Thank you.
<html>
<head>
<title>window object test</title>
<script type="text/javascript">
function showInfo() {
var dateObject = new Date();
var literalObject = {x:1, y:2};
alert("window.constructor = " + window.constructor);
// 'undefined' in IE, 'Window' in Netscape
alert("document.constructor = " + document.constructor);
// 'undefined' in IE, 'HTMLDocument' in Netscape
alert("dateObject.constructor = " + dateObject.constructor);
// 'Date' in both browsers
alert("literalObject.constructor = " + literalObject.constructor);
// 'Object' in both browsers
Object.prototype.testProperty = "Hello";
alert("window.testProperty = " + window.testProperty);
// 'undefined' in IE and Netscape
alert("document.testProperty = " + document.testProperty);
// 'undefined' in IE, "Hello" in Netscape
alert("dateObject.testProperty = " + dateObject.testProperty);
// 'Hello' in both browsers
alert("literalObject.testProperty = " + literalObject.testProperty);
// 'Hello' in both browsers
}
</script>
</head>
<body onload="showInfo();">
<h3 align="center">window object test</h3>
</body>
</html>
Jul 20 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"Hermit Crab" <he********@att.net> wrote in message
news:vX***********************@bgtnsc04-news.ops.worldnet.att.net...
<snip>
Thus it appears that 'window' and 'document'
do not act like normal objects.
The ECMA 262 3rd Edition specification would categorise document (and
all of the DOM elements/nodes under it) as a "Host Objects" (section
4.3.8) and makes no requirements of host objects. On web browsers the
window object is also the object that ECMA 262 refers to as the global
object (Section 15.1) and the global object is specified as having no
[[Constructor]] property and implementation dependent [[Prototype]] and
[[Class]] properties.

<snip>1) Is this the correct behavior for the 'window' object?
Yes, in so far as it is not incorect.
2) Is the Netscape or IE behavior correct for the
'document' object?
The only criteria of correctness available for the document object are
the W3C Core and HTML DOM specifications and Netscape 6+ and IE 5.5+
more or less conform to that specification in their implementations.
But the W3C DOM specifications define interfaces and say nothing about
prototypes, constructors or inheritance (because they are intended to be
language neutral).
3) Can anyone point me to appropriate documentation for
the behavior or these objects?

<snip>

ECMA 262 and the W3C DOM specifications are referenced in the
comp.lang.javascript FAQ:-

<URL: http://jibbering.com/faq/ >

Richard.
Jul 20 '05 #2

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:br*******************@news.demon.co.uk...
The ECMA 262 3rd Edition specification would categorise document (and
all of the DOM elements/nodes under it) as a "Host Objects" (section
4.3.8) and makes no requirements of host objects.


<snip of extremely helpful reply>

Thanks very much for you reply. I took a look at the sections of ECMA-262
that and would like to verify that I'm understanding it correctly. It seems
that:

1) Host objects may, but are not required to inherit functionality from
Object.

2) Attempting at add functionality to any 'host' object via the prototype
property of the constructor should be avoided. Depending upon the
implementation, the updates to the prototype property may not be allowed.
Adding properties to a prototype should only be done for user-defined
objects and those specified in ECMA-262.

Have I interpreted you response correctly?

In any event, you've pointed me in the right direction. I hadn't really
been aware of the differences between 'host' and 'native' objects. I'll go
back and do some more reading.

Thanks for taking the time to help me.
..

Jul 20 '05 #3

P: n/a
"Hermit Crab" <he********@att.net> wrote in message
news:4C***********************@bgtnsc04-news.ops.worldnet.att.net...
<snip>
... . It seems that:

1) Host objects may, but are not required to inherit
functionality from Object.
Yes.
2) Attempting at add functionality to any 'host' object
via the prototype property of the constructor should be
avoided.
That might be a bit strong. Generally I would tend to avoid modifying
the prototype of host objects (if available) but if handled with the
caution that is required in any reliable client-side script it could be
a more efficient alternative to a less direct method.

Though I don't see much point in modifying the document or the window
via their prototypes as there is only one of each and they can be
modified directly with the same effort.
Depending upon the implementation, the updates to the
prototype property may not be allowed.
Yes, and there may be no publicly accessible prototype property or
constructor.
Adding properties to a prototype should only be done for
user-defined objects and those specified in ECMA-262.
User-defined objects are certainly where this type of functionality can
be expected to work reliably.
Have I interpreted you response correctly?

<snip>

Yes.

Richard.
Jul 20 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.