select?

[html]

I have a select tag as follows

<SELECT ID="Select1" NAME="Select1" ONCHANGE="do_alert()">
<OPTION>1</OPTION>
<OPTION>2</OPTION>
</SELECT>

I need, when the user choose an option, to print an alert
which displays the text in the option chosen, i.e. 1 or 2
in this example, but how do I access the value of the html
select tag, I tried

alert(document.getElementById('Select1').value);

But this seems to be an empty alert box. Any ideas what might I be
doing wrong?

Tia

 

[Joost Diepenmaat]

I have a select tag as follows

<SELECT ID="Select1" NAME="Select1" ONCHANGE="do_alert()">
<OPTION>1</OPTION>
<OPTION>2</OPTION>
</SELECT>

I need, when the user choose an option, to print an alert
which displays the text in the option chosen, i.e. 1 or 2
in this example, but how do I access the value of the html
select tag, I tried

alert(document.getElementById('Select1').value);

But this seems to be an empty alert box. Any ideas what might I be
doing wrong?

<select onchange="alert(this.elements[this.selectedIndex].value)">

 

[Thomas 'PointedEars' Lahn]

<select onchange="alert(this.elements[this.selectedIndex].value)">

<select onchange="window.alert(this.options[this.selectedIndex].value)">

And it is a bad idea regarding accessibility.


PointedEars

 

[Joost Diepenmaat]

<select onchange="alert(this.elements[this.selectedIndex].value)">

<select onchange="window.alert(this.options[this.selectedIndex].value)">

And it is a bad idea regarding accessibility.

Of course it is.

 

[html]

hi, thanks it works, my confusion arose due to the fact that
selectedIndex was missing from the intelisense of vs7.1,
also "this" doesn't work with intelisense.
thanks.

 

[Thomas 'PointedEars' Lahn]

<select onchange="alert(this.elements[this.selectedIndex].value)">

<select onchange="window.alert(this.options[this.selectedIndex].value)">

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?

I remember a thread where you said that just because nobody has ever
seen such a browser, it didn't mean we couldn't just write "alert"
instead of "window.alert".

You remember incorrectly. I am pretty sure I did point out on more than one
occasion that assuming that the ECMAScript Global Object had an alert()
method was error-prone, since Netscape JavaScript 1.0 already defined it to
be a method of Window objects, and the `window' property of the Global
Object to refer to such an object.

Just asking.

Just replying.

[...]
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?


PointedEars

 

[dhtml]

You remember incorrectly. I am pretty sure I did point out on more than one
occasion that assuming that the ECMAScript Global Object had an alert()
method was error-prone, since Netscape JavaScript 1.0 already defined it to
be a method of Window objects, and the `window' property of the Global
Object to refer to such an object.

Can you provide an example of the error?

 

[Thomas 'PointedEars' Lahn]

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?

^^^ 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

 

[dhtml]

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

 

[dhtml]

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-forms/current-work/#htmlformelement

Garrett

 

[Thomas 'PointedEars' Lahn]

Has it, then?

Yes, it has been used here ad nauseam; without much success, but that was to
be expected, though.

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.

Fallacy of the single cause.

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.

False dilemma.

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

Argument from fallacy.

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?

Because your logic is still flawed.

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.

I will definitely not waste any nanosecond of my time to support any fallacy.


PointedEars

 

[dhtml]

You can always refer to the global object by:
(function () { return this; })()

By 'unqualified' I'm using java-speak to refer to the Base object of the
property that exists in the aug'd scope. |body| is a property of
|document} and the scope chain is aug'd with |document| for most event
handlers. So, instead of "unqualified" body that relies on augmented scope:-

onclick="alert(body)"

- a "qualified" version would be:

onclick="alert(window.document.body);

- but, as you point out, it would be possible to access the |global|
object by using an anonymous function that returns |this|.

onclick="alert((function () { return this; })().document.body)";

Not the prettiest looking code.

Alternatively, you could use for most modern browsers:-

onclick="alert(this.ownerDocument.body)"

Which brings looks up to about a "5"