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

how to refer "this Value of the SELECT component in javascript?

P: n/a


--
Hop@Ni
Jul 23 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a
niyong wrote:
--
Hop@Ni


It's usually best to put your query in the body of the post, not
in the subject, it gives the replier something to quote and
maintains the chain of posts.

If by "this Value of the SELECT component" you mean the value of
the currently selected <option> in a <select size="1">, the way
to obtain the value from outside the form is:

var selectObject =
document.forms['formName'].elements['selectName'];
var theValue =
selectObject.options[selectObject.selectedIndex].value;

from the <select> itself:

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

From the FAQ for this newsgroup: <url:
http://jibbering.com/faq/#FAQ4_13 />

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available
at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html
Jul 23 '05 #2

P: n/a
In a land long ago, in a time far away
Grant Wagner <gw*****@agricoreunited.com> wrote:
from the <select> itself:

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


I've been under the impression that this can be (savely)
shortened to:
<select onChange="alert(this[this.selectedIndex].value)">

Any browsers that wouldn't get this?
Yours
P

Jul 23 '05 #3

P: n/a
PatD wrote:


I've been under the impression that this can be (savely)
shortened to:
<select onChange="alert(this[this.selectedIndex].value)">

Any browsers that wouldn't get this?

That will work in every browser I have.
Mick
Jul 23 '05 #4

P: n/a
Lee <RE**************@cox.net> writes:
<select onChange="alert(this[this.selectedIndex].value)">
That will work in every browser I have.


Now test "alert(options[selectedIndex].value)"

which is slightly shorter and probably slightly more standard.


I'd say it was less standard, if anything. The tradition of making
intrinsic event handlers methods of the object they are on will make
"this" always refer to that object. Omitting "this." depends on the
browser making the properties of the object available directly (as by
"with (this) { ... }"). Browsers differ in how many properties they
make available - some also make the properties of the document and the
enclosing form available, others don't. I would feel much less certain
that all future browsers will implement this the same way.

I can't find a current browser where it makes a difference, though.

What *is* more standard is:
"alert(this.value);"
I.e., taking the value directly from the select element. However, that
is a more recent standard, and not all old browsers support it.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #5

P: n/a
Lee wrote:
Mick White said:
PatD wrote:


I've been under the impression that this can be (savely)
shortened to:
<select onChange="alert(this[this.selectedIndex].value)">

Any browsers that wouldn't get this?


That will work in every browser I have.

Now test "alert(options[selectedIndex].value)"

which is slightly shorter and probably slightly more standard.

Fails in NN4, though.
Mick
Jul 23 '05 #6

P: n/a
Lee
Mick White said:

PatD wrote:


I've been under the impression that this can be (savely)
shortened to:
<select onChange="alert(this[this.selectedIndex].value)">

Any browsers that wouldn't get this?

That will work in every browser I have.


Now test "alert(options[selectedIndex].value)"

which is slightly shorter and probably slightly more standard.

Jul 23 '05 #7

P: n/a
Lasse Reichstein Nielsen wrote:
Lee wrote:
Now test "alert(options[selectedIndex].value)"
<snip> I can't find a current browser where it makes a difference,
though.

<snip>

It fails on Opera 6 (current on some phones apparently) and at least one
other embedded browser (NetFront?) that I have seen. I think I would
stick with:-

this.options[this.selectedIndex].value

- as it is HTML DOM standard and nobody has named a context in which it
will not work.

Richard.
Jul 23 '05 #8

P: n/a
Lee
Mick White said:

Lee wrote:
Mick White said:
PatD wrote:

I've been under the impression that this can be (savely)
shortened to:
<select onChange="alert(this[this.selectedIndex].value)">

Any browsers that wouldn't get this?
That will work in every browser I have.

Now test "alert(options[selectedIndex].value)"

which is slightly shorter and probably slightly more standard.

Fails in NN4, though.


Nope. That's where I first started using it.
it's "this.value" that fails in NN4.

Jul 23 '05 #9

P: n/a
PatD wrote:
In a land long ago, in a time far away
Grant Wagner <gw*****@agricoreunited.com> wrote:
from the <select> itself:

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


I've been under the impression that this can be (savely)
shortened to:
<select onChange="alert(this[this.selectedIndex].value)">

Any browsers that wouldn't get this?

Yours
P


I wouldn't take the risk to save 8 characters. If I used the above code
in enough places to warrant saving 8 characters, I'd write a function
and save much much, much more space (I might even attach the events
dynamically at load time rather then code them as HTML attributes).

Back to the original question however. A <select> has a collection of
<option> objects, each of which has a "value" attribute (as well as
other attributes), it also has a property called "selectedIndex". It
seems reasonable to me to access the "value" attribute of the <option>
object at the selectedIndex position within the collection. I use:

this.options[this.selectedIndex].value

because it is exactly what I intended, for the same reason I choose to
use:

document.forms['formName'].elements['elementName'] over
document.forms['formName']['elementName'] (or worse still:
document['formName']['elementName']).

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html
Jul 23 '05 #10

P: n/a
Grant Wagner wrote:
this.options[this.selectedIndex].value


It should be noted that this will fail under at least two situations:
1) If there are no options at all in the select element
2) If there are no options selected

Neither of these will usually occur in an onChange event, except for a
multiple select list. Unless there are browsers which allow for unselecting
every option in a select-one list, but Ive never seen one.

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Jul 23 '05 #11

P: n/a
In a land long ago, in a time far away
Grant Wagner <gw*****@agricoreunited.com> wrote:

[cut: almost everything]
[left: bare minimum to understand what's going on]
PatD wrote:
><select onchange="alert(this.options[this.selectedIndex].value);">

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

I wouldn't take the risk to save 8 characters. If I used the above code
this.options[this.selectedIndex].value
document.forms['formName'].elements['elementName'] over
document.forms['formName']['elementName'] (or worse still:

Interesting threat. Who would have thought so at its beginning? :)

Well, my personal favorite is:
this.options[this.selectedIndex].value

and, I'm slowly changing from
document.forms['formName']['elementName']
to
document.forms['formName'].elements['elementName']
Hm, I guess that some day, someone will start a threat on whether
"document.stuff..."
should not be replaced with
"window.document.stuff..."
Until then, see you, and thanks for all the feedback
Yours
P

Jul 23 '05 #12

P: n/a
PatD wrote:
In a land long ago, in a time far away
Grant Wagner <gw*****@agricoreunited.com> wrote:

[cut: almost everything]
[left: bare minimum to understand what's going on]
PatD wrote:
><select onchange="alert(this.options[this.selectedIndex].value);">
<select onChange="alert(this[this.selectedIndex].value)">

I wouldn't take the risk to save 8 characters. If I used the above code
this.options[this.selectedIndex].value
document.forms['formName'].elements['elementName'] over
document.forms['formName']['elementName'] (or worse still:


Interesting threat. Who would have thought so at its beginning? :)

Well, my personal favorite is:
this.options[this.selectedIndex].value

and, I'm slowly changing from
document.forms['formName']['elementName']
to
document.forms['formName'].elements['elementName']

Hm, I guess that some day, someone will start a threat on whether
"document.stuff..."
should not be replaced with
"window.document.stuff..."

Until then, see you, and thanks for all the feedback

Yours
P


Well, I tend to use "window.location.href", but I do not use
"window.document.forms...", nor do I use "window.alert();" although
technically, "location", "document" and "alert()" are all members of the
(usually) omni-present "window" global object in a Web browser.

I'm not sure why I do this, although some of it has to do with the fact that
"location" is a magical object, in that assigning a value to it directly
changes it's "href" property (or, if you prefer, "location" is a magical
property of "window", such that changing it changes window.location.href).
As a result, "location = 'someurl';" is perfectly valid Javascript that
appears to be a simple variable assignment, but in reality can navigate a
Web browser to a new page. Worse yet "var location = 'someurl';" outside of
any function does _not_ navigate the browser to a new page, and stomps all
over the ability to do so via window.location.href (in fairness, the same
could be said of "var document = 'whatever';" or "var alert = 'stuff';").

In the end, I would have been much happier if Javascript authors were
_required_ to use "location.href = 'someurl';" because that is what you are
doing, changing the "href" property of the global Location object. The fact
that the original design of the browser DOM allows these magical objects
with their mysterious behavior breaks the very concept of OO within the
language.

Assigning a string directly to window.location (window.location =
'http://www.yahoo.com';) should remove the reference to the global Location
object and make it eligible for garbage collection, replacing it with a
reference to a String object containing "http://www.yahoo.com", but that's
not what happens in most (all?) browers.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html
Jul 23 '05 #13

P: n/a
Lasse Reichstein Nielsen wrote:
Lee <RE**************@cox.net> writes:
<select onChange="alert(this[this.selectedIndex].value)">
That will work in every browser I have.


Now test "alert(options[selectedIndex].value)"

which is slightly shorter and probably slightly more standard.


I'd say it was less standard, if anything. [...]


It should work in a standards compliant browser and it works in
Mozilla/5.0. "this" is part of the scope chain, so it does not
need to be mentioned explicitely.
PointedEars
Jul 23 '05 #14

P: n/a
Richard Cornford wrote:
Lasse Reichstein Nielsen wrote:
Lee wrote:
Now test "alert(options[selectedIndex].value)"

<snip>
I can't find a current browser where it makes a difference,
though.


<snip>

It fails on Opera 6 (current on some phones apparently) and at least one
other embedded browser (NetFront?) that I have seen.


Those browsers should be considered borken or
at least not standards compliant in this regard.
I think I would stick with:-

this.options[this.selectedIndex].value

- as it is HTML DOM standard [...]


Non sequitur. Following the scope chain specification is
not less standard. See ECMAScript 3 (2000), section 10.1.4.
PointedEars
Jul 23 '05 #15

P: n/a
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
Lasse Reichstein Nielsen wrote:
I can't find a current browser where it makes a difference,
though.

<snip>

It fails on Opera 6 (current on some phones apparently) and at least
one other embedded browser (NetFront?) that I have seen.


Those browsers should be considered borken or
at least not standards compliant in this regard.


Nonsense.
I think I would stick with:-

this.options[this.selectedIndex].value

- as it is HTML DOM standard [...]


Non sequitur. Following the scope chain specification is
not less standard. See ECMAScript 3 (2000), section 10.1.4.


The ECMA 262 3rd edition scope chain specification has nothing to do
with the behaviour under discussion. It describes how scope chins are
defined/constructed. It says nothing about what objects will appear on
the scope chins of intrinsic event handlers beyond the implication that
the global object will be at the end of them.

Richard.
Jul 23 '05 #16

P: n/a
Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote:
Lee writes:
><select onChange="alert(this[this.selectedIndex].value)">
That will work in every browser I have.

Now test "alert(options[selectedIndex].value)"

which is slightly shorter and probably slightly more standard.


I'd say it was less standard, if anything. [...]


It should work in a standards compliant browser and it works in
Mozilla/5.0. "this" is part of the scope chain, so it does not
need to be mentioned explicitely.


You are falling into the trap of assuming that because Mozilla is the
most standard compliant browser then what Mozilla actually does is
standard. The custom scope chain that is built by Gecko browsers is
unique in terms of the object on the scope chain and the rules used to
construct it. Indeed, experimentation in this area suggests that none of
the browsers that provide custom scope chains for browser built
intrinsic event handling functions provides the same scope chain, or
uses the same rules for its construction, as any other. This is
behaviour that is not standardised.

Richard.
Jul 23 '05 #17

P: n/a
Lee
Richard Cornford said:

Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote:
> Lee writes:
>>>><select onChange="alert(this[this.selectedIndex].value)">
>>>That will work in every browser I have.
>>
>> Now test "alert(options[selectedIndex].value)"
>>
>> which is slightly shorter and probably slightly more standard.
>
> I'd say it was less standard, if anything. [...]


It should work in a standards compliant browser and it works in
Mozilla/5.0. "this" is part of the scope chain, so it does not
need to be mentioned explicitely.


You are falling into the trap of assuming that because Mozilla is the
most standard compliant browser then what Mozilla actually does is
standard. The custom scope chain that is built by Gecko browsers is
unique in terms of the object on the scope chain and the rules used to
construct it. Indeed, experimentation in this area suggests that none of
the browsers that provide custom scope chains for browser built
intrinsic event handling functions provides the same scope chain, or
uses the same rules for its construction, as any other. This is
behaviour that is not standardised.


Some browsers may include additional objects in the scope chain,
but any that doesn't include "this" is pretty clearly broken.

Jul 23 '05 #18

P: n/a
Lee <RE**************@cox.net> writes:
Some browsers may include additional objects in the scope chain,
but any that doesn't include "this" is pretty clearly broken.


If by "broken" you mean: will make a significant number of existing
pages break, then I'll have to agree. I wouldn't mind if the scope
chain hack was removed, though.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #19

P: n/a
Thomas 'PointedEars' Lahn <Po*********@nurfuerspam.de> writes:
Those browsers should be considered borken or
at least not standards compliant in this regard.


There is no standard for this.
I think I would stick with:-

this.options[this.selectedIndex].value

- as it is HTML DOM standard [...]


Non sequitur. Following the scope chain specification is
not less standard. See ECMAScript 3 (2000), section 10.1.4.


Following *a* scope chain is part of ECMAScript. The specific scope
chain used for intrinsic event handlers is not part of any standard
(if any existed, it *would* be the W3C HTML DOM), and goes against
normal behavior of closures by having unrelated DOM objects in the
scope chain and not just variable objects created by function
calls.

/KL
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #20

P: n/a
Lee
Lasse Reichstein Nielsen said:

Lee <RE**************@cox.net> writes:
Some browsers may include additional objects in the scope chain,
but any that doesn't include "this" is pretty clearly broken.


If by "broken" you mean: will make a significant number of existing
pages break, then I'll have to agree. I wouldn't mind if the scope
chain hack was removed, though.


What I mean is that the methods and variables of the object
that is the execution context should always be included in
the current scope chain.

Jul 23 '05 #21

P: n/a
Lee wrote:
Lasse Reichstein Nielsen said:
Lee wrote:
Some browsers may include additional objects in the scope chain,
but any that doesn't include "this" is pretty clearly broken.


If by "broken" you mean: will make a significant number of existing
pages break, then I'll have to agree. I wouldn't mind if the scope
chain hack was removed, though.


What I mean is that the methods and variables of the object
that is the execution context should always be included in
the current scope chain.


I don't see the problem. If you want to access the properties of the -
this - object you have the - this - reference to use for the task. That
is specified and I am yet to hear of a browser where it doesn't work
(and if I do I will regard that browser as broken).

Otherwise the desire to use a non-standard, inconstant and not
universally implemented feature of web browsers is usually rendered non
error producing with feature detection, though the overhead in doing
that makes the use of the - this - keyword look like the simpler option.

Richard.
Jul 23 '05 #22

P: n/a
Lee
Richard Cornford said:

Lee wrote:
Lasse Reichstein Nielsen said:
Lee wrote:
Some browsers may include additional objects in the scope chain,
but any that doesn't include "this" is pretty clearly broken.

If by "broken" you mean: will make a significant number of existing
pages break, then I'll have to agree. I wouldn't mind if the scope
chain hack was removed, though.
What I mean is that the methods and variables of the object
that is the execution context should always be included in
the current scope chain.


I don't see the problem. If you want to access the properties of the -
this - object you have the - this - reference to use for the task. That
is specified and I am yet to hear of a browser where it doesn't work
(and if I do I will regard that browser as broken).


My point is that you shouldn't have to specify "this" in this case.
I specify it most often just to make the intent more clear to
the person reading the code. The other valid uses are to pass
a reference to the current object or to distinguish between arguments
and object fields in a constructor.
Otherwise the desire to use a non-standard, inconstant and not
universally implemented feature of web browsers is usually rendered non
error producing with feature detection, though the overhead in doing
that makes the use of the - this - keyword look like the simpler option.

It works in all versions of IE, Netscape, Mozilla and Opera that
I've ever had installed. In which broken browser(s) do you need
to specify "this" to access the attributes of the object that is
the current execution context, or in which broken browser(s) is
the form element object not the execution context of its event
handler?

Jul 23 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.