Conrad Lender wrote:
> On 2008-09-27 00:54, Thomas 'PointedEars' Lahn wrote:
>>> So, have you found a browser yet where the global object isn't
>>> window?
>> Have you found a language reference that states alert() is a method of
>> the ECMAScript Global Object instead of Window host objects?
>
> Well that's the crux. Language references are fine (holy even, for some
> people), but the real world is a mess.

Please, the "real world" argument has already been milked for what it's
worth! All who think they live in that "real world" should finally come to
recognize that standards do not build up from thin air, but they are mostly
created by dedicated people, they keep on existing and are implemented for a
reason, that is *interoperability*. Nothing in your "real world" would work
(together), had not two or more people agreed on a standard about how to do
things. See below.

But I am not even talking about the ECMAScript Language Specification here,
I am talking about the language references, written and published by their
implementors. They should know what they implemented, should they not?

> It doesn't matter if I do or do not find a reference, when for all
> practical purposes, in all browsers that anyone has cared to test, alert
> is window.alert. But see below.

It is reasonable to assume that because the first scripting language for the
Web defined a method to be a method of Window objects (even though those
objects were redefined later to belong not to that language but to the DOM
API instead) this is rather likely to be so in other implementations, for
the sake of compatibility and interoperability, which follows from the need
for compatibility when you want to be a serious competitor.

If the outcome of the Browser Wars shows anything, it is that despite M$ is
considered to be the winner, the "real world" is, slowly, moving to Web
standards, whereas proprietary solutions are limited to certain fields of
application. That would seem to be a natural process, given that all forms
of information interchange need a common ground to work.

In contrast, it is *not* reasonable to assume that because a subset of
superficially tested Web browsers has an alert() method of the Global Object
that must apply for all Web browsers or even all user agents. Especially
not when there is no reference material at all to back up that assumption.

> I still refuse to use 'window.alert' until I'm shown one single instance
> where a simple 'alert' doesn't work as expected. [...]

Fallacy: Shifting the burden of proof.

> [Jeremy J Starcher]
> | >> In most major browsers, "window" refers to the global object,
> | >> unless overridden.
> | [Thomas 'PointedEars' Lahn]
> | > No, in *some* browsers it *appears* as if that were the case.
> | > However, it was overlooked that a host object includes the
> | > possibility to let it appear so.
>
> And so on. I'm sure that you know the specs by heart,

Hardly. JFYI: Whenever I am referring to ES3F, I have searched through the
PDF document that I have open in the background most of the time. You could
be right if you said I might have a better idea than many subscribers of
this newsgroup on where to find what in the Spec.

> and can quote them better than anyone else here.

Maybe so, but that would not seem to count. As the saying goes (CMIIW),
even the Devil can quote the Bible.

What really matters is if you can understand what you are quoting and apply
what you read in a Specification to a certain problem. I think I am not
that bad at it, but as for ECMAScript, Lasse or Richard can probably do it
better than me.

> But theoretical possibilities aside, this problem does not appear to
> exist in the real world. Yes I know, I state this without having tested
> each and every instance out there. Still the theory stands; and what else
> can we do than work with what we're given?

Maybe logic and reason instead of a number of conclusions being jumped to?

>>> PPS: I could go looking for that thread but right now I CBA :-)
>> ^^^ Unfortunately, I am not familiar with that abbreviation and STFW
>> was inconclusive so far. What does it mean?
>
> Uh, I've sort of tried to avoid explicit profanity here... CBA is just
> short for "can't be arsed". [...]

I found that meaning already but, since English is not my native language,
I was not sure how it applied here. Thanks.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Conrad Lender wrote:

> Conrad chart (empirical):
>
> | ++ **
> | ++ *+ *
> | +++ ** + *
> |+++**** + *
> | ++ *
> | ++*+++++++++++++++++++++
> +------------------*---------------------
> * number of beers ->
> *
> + coding prowess
> * language management

It's nice to know I'm not the only one with that bump around the second
or third drink. Too bad things go down-hill so fast.

Conrad Lender wrote:
> On 2008-09-27 00:54, Thomas 'PointedEars' Lahn wrote:
>>> So, have you found a browser yet where the global object isn't window?
>> Have you found a language reference that states alert() is a method of the
>> ECMAScript Global Object instead of Window host objects?
>
> Well that's the crux. Language references are fine (holy even, for some
> people), but the real world is a mess. It doesn't matter if I do or do
> not find a reference, when for all practical purposes, in all browsers
> that anyone has cared to test, alert is window.alert. But see below.
>
> I still refuse to use 'window.alert' until I'm shown one single instance
> where a simple 'alert' doesn't work as expected. I'm barring
> redefinitions of alert here, of course, just as you're barring
> redefinitions of window.

The attempt to resolve an identifier on the window can fail if the
identifier is found on the scope chain. Event handler content attributes
have an augmented scope chain that includes the element itself, the form
(if the element has a form), and the document.

For example:

<!DOCTYPE html>
<html lang="en">
<head>
<title>Augmented Scope in Event Handler Attributes</title>
</head>
<body>
<img name='alert' alt="Alert!" src="alert.jpg">
<form action="no">
<select onchange="window.alert(alert);">
<option>a</option>
<option>b</option>
</select>
</form>
</body>
</html>


when the select is changed, Result is elert "[object HTMLImageElement]"
(or other implementation-dependent string representing the image).

The event handler code would have an augmented scope chain like:-

with(document) {
with(body) {
with(this.form) {
with(this) {
window.alert(alert);
}
}
}
}

and the identifier |alert| would be resolved on |document|.

"onclick='alert([data, files, title])'"

The identifiers |data| and |files| would, in some cases, be resolved on
the augmented scope chain, either as a property of the file input or of
the form.

The identifier |title| would be resolved on the element before being
resolved on the document.

Garrett


>
>
> - Conrad

On 2008-09-27 04:18, dhtml wrote:
> The attempt to resolve an identifier on the window can fail if the
> identifier is found on the scope chain. Event handler content attributes
> have an augmented scope chain that includes the element itself, the form
> (if the element has a form), and the document.
...
> The event handler code would have an augmented scope chain like:-
>
> with(document) {
> with(body) {
> with(this.form) {
> with(this) {
> window.alert(alert);
> }
> }
> }
> }

Thanks, I hadn't thought of that. I have only rarely used event handler
attributes in the past 2 years or so, but still, this is definitely
something to watch out for. I'm not sure if I should let that count as a
counter example to "the theory", though. When any named element can
become a property of document, and the document scope has priority over
the global scope... anything can happen. If you had a second img element
in your example, like this,

<img name='window' src="window.jpg">

then the global 'window' reference would be obscured, and window.alert
would be undefined. This is similar to redefining 'window' or 'alert' in
function scope, and doesn't affect the question if 'window' is always
the global object (unless it's been redefined or obscured).

As an aside, does the DOM really require that any named element will
automatically become a property of document? That appears, idk, unsafe
at least.


- Conrad

On 2008-09-27 03:12, Thomas 'PointedEars' Lahn wrote:
> Conrad Lender wrote:
>> Well that's the crux. Language references are fine (holy even, for some
>> people), but the real world is a mess.
>
> Please, the "real world" argument has already been milked for what it's
> worth!

Has it, then?

Obligatory car analogy: I drive a car, and I respect the laws, and I
wish everybody else would too. But they don't. So what am I to do, drive
at full speed when I have the right of way, or let the jerk with the
Hummer go first to avoid a crash?

It's the same thing. We all agree that standards are necessary, and if I
had my way, I'd send every developer who violates them (either by choice
or by gross negligence) to a reeducation camp in Siberia. But I don't
get my way, and there are jerk browsers out there. They bend and ignore
the rules (tell me it ain't so), and we as developers still have to
deliver a product that will interoperate with them.

So there you have it. Specs and standards and laws on the one hand, and
harsh reality on the other. We have to deal with it.

> But I am not even talking about the ECMAScript Language Specification here,
> I am talking about the language references, written and published by their
> implementors. They should know what they implemented, should they not?

Indeed they should. Has any of them ever released anything suggesting
that the global object isn't always 'window'?

> If the outcome of the Browser Wars shows anything, it is that despite M$ is
> considered to be the winner, the "real world" is, slowly, moving to Web
> standards, whereas proprietary solutions are limited to certain fields of
> application. That would seem to be a natural process, given that all forms
> of information interchange need a common ground to work.

No argument there. If the implementations hadn't grown up to a point
where they agreed about the most important things, we would never have
had a revival like the one they call "Web 2.0". Standards conformance
was the single most important prerequisite for that.
That and the hype :-/

> In contrast, it is *not* reasonable to assume that because a subset of
> superficially tested Web browsers has an alert() method of the Global Object
> that must apply for all Web browsers or even all user agents. Especially
> not when there is no reference material at all to back up that assumption.

Look, you can call it a "subset of superficially tested Web browsers"
all you want, but I hope you can agree to this:

- there is no way to test all possible user agent variants
- the browsers that account for >98% (higher probably, but I'm
feeling conservative) of worldwide users today *have* been tested
- not a single browser has *ever* been found that would refute the
theory that window == global object in browsers

Thus it is a reasonable working theory that there are no browsers (with
any remotely significant market share) that behave differently. Why then
do you still insist on prepending 'window.' to those method calls?

>> I still refuse to use 'window.alert' until I'm shown one single instance
>> where a simple 'alert' doesn't work as expected. [...]
>
> Fallacy: Shifting the burden of proof.

Yes, sir, I *am* shifting the burden of proof to you. Because all that
I'm saying is that all browsers except maybe a possible as-yet-unknown
esoteric browser behave like that. Now prove me wrong.

> JFYI: Whenever I am referring to ES3F, I have searched through the
> PDF document that I have open in the background most of the time.

I figured as much. And I'm grateful that you do it, because I've
actually learned quite a bit from your references. I have looked at the
specs from time to time (been a while though, I admit), but it's very
dry reading, and if you're not actually trying to implement your own
interpreter, it has too much detail for normal developers.


- Conrad

Conrad Lender wrote:
> On 2008-09-27 04:18, dhtml wrote:
>> The attempt to resolve an identifier on the window can fail if the
>> identifier is found on the scope chain. Event handler content attributes
>> have an augmented scope chain that includes the element itself, the form
>> (if the element has a form), and the document.
> ..
>> The event handler code would have an augmented scope chain like:-
>>

Sorry, the example should not include body.

with(document) {
with(this.form) {
with(this) {
window.alert(alert);
}
}
}

That previous example I had was wrong. I apologize.

>
> Thanks, I hadn't thought of that. I have only rarely used event handler
> attributes in the past 2 years or so, but still, this is definitely
> something to watch out for. I'm not sure if I should let that count as a
> counter example to "the theory", though. When any named element can
> become a property of document, and the document scope has priority over
> the global scope... anything can happen. If you had a second img element
> in your example, like this,
>
> <img name='window' src="window.jpg">
>
> then the global 'window' reference would be obscured, and window.alert

That is true. And this example:

<img name='window' src="window.jpg">
<img name='document' src="document.jpg" title="cup">

would create an issue where it would not be possible to refer to
unqualified |body|.

onchange="alert(body.aLink)"

> would be undefined. This is similar to redefining 'window' or 'alert' in
> function scope, and doesn't affect the question if 'window' is always
> the global object (unless it's been redefined or obscured).
>

Declaring |window| as an element ID or name is not a good idea.

It is not as obvious as declaring a variable identifier |window|.

Declaring |window| as an element ID or name, the attribute value then
becomes a property of a Host object (|document|, and in IE, |window|).
This object gets added to a scope chain in an event handler. It is a
little less obvious than:

function createCallback(fun) {
var window = document.body; // No!
return function() {
alert(window.alert);
}
}

Because it would seem perfectly benign to a novice to create an image or
link with an notification messages and then give that div the id="alert".

<img id="alert">

That seems much more subtle, to me.

> As an aside, does the DOM really require that any named element will
> automatically become a property of document? That appears, idk, unsafe
> at least.

No. That's only true of forms. There's a specification that say a form
has behavior of a 'Collection'. The 'Collection' behavior isn't really
standardized in any way.

It appears unsafe to me, too. I would recommend not using that at all.
Use getElementById instead.

The browser may still add the element id as a property of the document,
so names like "alert" should be avoided and relying on an augmented
scope chain may result in some properties being resolved somewhere along
the way and this will depend on the browser (host objects have different
properties depending on the browser).

Web Forms 2.0 gives new properties, including:

labels
valid
data

More WF 2.0:
http://www.whatwg.org/specs/web-form...tmlformelement

Garrett

>
>
> - Conrad