select?
html
<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
<select onchange="alert(this.elements[this.selectedIndex].value)">
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
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
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Conrad Lender
> Joost Diepenmaat wrote:
>> <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?
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".
Just asking.
- Conrad
PS: Agree about this.*options* and accessibility (in some cases),
of course.
PPS: I could go looking for that thread but right now I CBA :-)
Conrad Lender
> it didn't mean we couldn't just write
That should have been "could", obviously.
Too many negatives.
Conrad chart (empirical):
| ++ **
| ++ *+ *
| +++ ** + *
|+++**** + *
| ++ *
| ++*+++++++++++++++++++++
+------------------*---------------------
* number of beers ->
*
+ coding prowess
* language management
Sorry =)
- Conrad
Joost Diepenmaat
> Joost Diepenmaat wrote:
>> <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
selectedIndex was missing from the intelisense of vs7.1,
also "this" doesn't work with intelisense.
thanks.
Thomas 'PointedEars' Lahn
> On 2008-09-26 23:54, Thomas 'PointedEars' Lahn wrote:
>> Joost Diepenmaat wrote:
>>> <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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
dhtml
> Conrad Lender wrote:
>> On 2008-09-26 23:54, Thomas 'PointedEars' Lahn wrote:
>>> Joost Diepenmaat wrote:
>
> 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?
>
> PointedEars
Conrad Lender
>> 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.
>> 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.
Now I had to look it up, it was only a month ago after all. It was an
interesting thread, which is probably why I immediately thought of it
when you wrote "window.alert"., although towards the end it was mostly
people trying to convince each other of what "theory" means in a
scientific context (I'm afraid I disagree with you on that count again,
btw, but that's getting really off-topic, and I've had my share of
potential flame wars today). The "theory" being that there was no
browser in existance where 'window.alert' was not the same as 'alert'.
Here's the thread I'm referring to:
http://preview.tinyurl.com/4qrnqv
I'm not going to read that monster again tonight (CBA, see below ;-),
but what it came down to were mostly exchanges like this one:
[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, and can quote them
better than anyone else here. 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?
>> 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". Don't get me wrong, I fucking love swearing,
but I usually try to be civilized in forums and groups.
- Conrad
Thomas 'PointedEars' Lahn
> 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
Jeff Schwab
> 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.
dhtml
> 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
Conrad Lender
> 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
Conrad Lender
> Conrad Lender wrote:
>> 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
dhtml
> 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-forms/current-work/#htmlformelement
Garrett
>
>
> - Conrad
Thomas 'PointedEars' Lahn
> 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?
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.
>> 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'?
Argument from fallacy.
>> 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?
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.
Maciej Łebkowski
> > <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|.
You can always refer to the global object by:
(function () { return this; })()
--
Maciej Łebkowski
dhtml
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"