Prev: get or post?
Next: appendChild that fails in Safari, but succeeds in FF, Camino
From: Jorge on 26 Jan 2010 13:29
On Jan 26, 4:04 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Matthias Reuter wrote:
> > Jorge wrote:
> >> window *is* already -in any decent browser- an alias of the global
> >> object(1):
>
> > I was wondering about that passage in ECMA-262, Section 10.1.5:
>
> > "[...] for example, in the HTML document object model the window property
> > of the global object is the global object itself."
>
> > That matches what you're saying and contradicts what several others are
> > saying. The question is, is this normative to the DOM or descriptive
> > (e.g. for the time it was written)?
>
> As Richard said.  I would like to add an explanation as to why it is
> "descriptive (and only an example)", hopefully for future reference:
>
> As a rule of thumb, examples in specifications are *never* normative.
>
> If you look closely, you can recognize the level of requirement in the part
> that you have omitted (`[...]'):
>
> | 15.1 The Global Object
> |
> | [...] Initially the global object has the following properties:
> |
> | [...]
> | * Additional host defined properties. This may include a property whose
>                                              ^^^
> |   value is the global object itself; [see quotation above]
>
> That little word "may" is very important; so important, that in many other
> specifications it is written in ALL-CAPS -- "MAY" -- so that it is not
> overlooked in the prose.  It means that there is the possibility of what is
> described, but no requirement is made by the specification that it needs to
> be made happen, and no recommendation is made to make it happen or to make
> it not happen.  IOW, it is completely neutral wording, by contrast to
> "must/shall" (absolute requirement to be), "should" (recommendation in
> favor), "should not" (recommendation against), "shall not/must not"
> (absolute requirement not to be).  See also RFC 2119, which defines these
> terms common to many (if not all) technical specifications, and which is
> therefore referred to by many specifications (for example, W3C
> specifications).  (Unfortunately, it is not referred to explicitly by the
> Editions of the ECMAScript Language Specification; however, given general
> use, and the way these words are used in the Specification, there can be no
> doubt as to their meaning.)

To begin with, the ECMA specs are the wrong place to look for
"window", so it hardly matters whether there's a may or a may not or
whatever in a comment in an unrelated spec. The browsers' API when/if
spec'ed (not in this case) is spec'ed somewhere else.

> Then you need to consider the scope of the Specification; no *programming
> language* standard can provide a normative basis for the implementation of
> a *host-defined (proprietary) feature* based on some *markup language*.

Blah blah.

> There is _not_ /the/ "HTML document model", but several ones.  Even at the
> time this wording was first used (1999/2000) there were at least three DOM
> APIs: the NN4 DOM, the MSHTML DOM, and W3C DOM HTML Level 1; the first two
> were not called "DOM" at the time (the prevalent term was "DHTML", cf. the
> MSDN Library which still employs that term), and the latter one (obsolete
> since 2003) did not specify the `window' property (nor do its successors to
> date).  As a rule of thumb, double-check all statements made by ECMA people
> about HTML or the DOM, and by W3C Specifications about ECMAScript
> implementations (for example, there are similar errors in examples in HTML
> 4.01).

Yes, blah blah.

> Finally, a property can _not_ *be* an object; it can only _refer_ to one.  
> (Unfortunately, the Specification employs sloppy wording in several
> normative places, while being rather unnecessarily pedantic in others
> [especially in Edition 5]; a property can _not_ have an object for its
> value, but only a reference to the object.)

Yes, and what does this have to do with anything?

And, what's wrong with global.window= global; ?

> On a personal note, Jorge has been told these and other basic things a
> hundred times before already, but he would not listen (or try to
> understand).  The record shows he is likely only trolling; ignore him.

You're saying nonsenses -again- Pointy.
--
Jorge.
From: Dmitry A. Soshnikov on 26 Jan 2010 14:46
On Jan 26, 6:04 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:

> `window' refers to a host object, _not_
> the built-in Global Object.

Everybody knows (really).

Regarding to browser scripting and its host environment there're some
specific cases in specific implementations when `this' and `window'
will return different results for manipulating with some data (for
example, `hasOwnProperty' and variable declarations in current version
of Opera).

But regarding to property accessor - do you know some browser host
environment (regardless its implementation of mapping properties for
`this' and `window') where reading from `this' (global) and `window'
for the same property, will provide different results?

So regardless the specific cases (and especially for those when
property has been set to `window' object), accessing properties of
`window' is acceptable. Moreover, some implementations have some
optimization for reading `window' name in identifier resolution.

>
> On a personal note, Jorge has been told these and other basic things a
> hundred times before already, but he would not listen (or try to
> understand).  The record shows he is likely only trolling; ignore him.
>

Try to speak to the point only. This sentence will be completely
correct in its meaning if you do .replace(/Jorge/g, "Thomas
'PointedEars' Lahn") ;)

/ds
From: Jorge on 26 Jan 2010 19:53
On Jan 26, 4:04 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Matthias Reuter wrote:
> > Jorge wrote:
> >> window *is* already -in any decent browser- an alias of the global
> >> object(1):
>
> > I was wondering about that passage in ECMA-262, Section 10.1.5:
>
> > "[...] for example, in the HTML document object model the window property
> > of the global object is the global object itself."
>
> > That matches what you're saying and contradicts what several others are
> > saying. The question is, is this normative to the DOM or descriptive
> > (e.g. for the time it was written)?
>
> As Richard said.  I would like to add an explanation as to why it is
> "descriptive (and only an example)", hopefully for future reference:

FOR FUTURE REFERENCE:

The browser provides not one but *two* aliases of the global object:

window === globalObject; and self === globalObject;

Both are themselves properties of the globalObject:

window === globalObject.window; and self === globalObject.self;
"window" in this === "self" in this === true;

And both are as you can easily see, circular references:

globalObject.window= globalObject; and globalObject.self=
globalObject;
^ | ^ |
|_______________________| |_________________|

as in a= {}; a.self= a;

Any property of the window object is a property of the globalObject
(because they are exactly the same object), e.g. window.top ===
this.top === globalObject.top, and "top" in this === true, or "top" in
(function(){return this;})() === true, etc.

It's neither so difficult to comprehend, nor so difficult to remember.
--
Jorge.
From: Eric Bednarz on 26 Jan 2010 20:14
Jorge <jorge(a)jorgechamorro.com> writes:

> And, what's wrong with global.window= global; ?

I would put my bet on a runtime error in IE < 8 and breaking
(window.)onload in IE 8, so nothing you would care about.
From: Jorge on 26 Jan 2010 20:18
On Jan 27, 2:14 am, Eric Bednarz <bedn...(a)fahr-zur-hoelle.org> wrote:
> Jorge <jo...(a)jorgechamorro.com> writes:
> > And, what's wrong with global.window= global; ?
>
> I would put my bet on a runtime error in IE < 8 and breaking
> (window.)onload in IE 8, so nothing you would care about.

That wasn't code intended to be run. It was meant to explain what
window is: a property of the globalObject that points to itself.
--
Jorge.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: get or post?
Next: appendChild that fails in Safari, but succeeds in FF, Camino