When a selection is made, I’m trying to make 2 things happen…
Save the text which is selected (such as Welcome)
<script type="text/javascript">
function findTopic() {
var dropdown = document.getElementById("Topic_ID");
var field = document.getElementById("Topic");
field.value = dropdown.options[dropdown.selectedIndex].text;
}
</script>
Usually the best way to access form fields is via a unique identifier on the form itself, accessing fields via the elements collection, and it’s better to not have your scripting scattered around in your HTML elements.
A first-run at improving things is to give the form a unique identifier and use that to access the form fields, then use scripting to define the onchange event for the form field.
function findTopic() {
var form = document.getElementById('selectTopic'),
dropdown = form.elements['Topic_ID'],
field = form.elements['Topic'];
field.value = dropdown.options[dropdown.selectedIndex].text;
}
var form = document.getElementById('selectTopic');
form.elements['Topic_ID'].onchange = function () {
findTopic();
this.form.submit();
}
The above works fine, but it does have some issues that we may want to tweak. The findTopic function is duplicating our access to the form, so we can instead pass a form reference directly to the function.
The this keyword isn’t needed either, for the form variable is fully accessible from within the anonymous function, and speaking of the anonymous function, it’s better to give it a name so that if we interrupt the code within that function, we’ll have some idea of where we are and what’s supposed to occur.
function findTopic(form) {
var dropdown = form.elements['Topic_ID'],
field = form.elements['Topic'];
field.value = dropdown.options[dropdown.selectedIndex].text;
}
var form = document.getElementById('selectTopic');
form.elements['Topic_ID'].onchange = function updateAndSubmit() {
findTopic(form);
form.submit();
}
The advice not to scatter your callbacks in the HTML is sound, but I wouldn’t do it with straight JavaScript unless you have no intention of supporting older IE browsers. I know the newest one or two can handle the standard event model, and I know 8 can’t. Not sure about 9. So jQuery is safer.
When the user uses a mouse the click on the new option fires the event; when he uses a keyboard the event is fired when the select box is blurred.
When you focus on a select box and go through its options with the keyboard, IE and Opera fire the change event every time you select a new option. The other browsers fire the event only when you confirm the new option by leaving the select box.
If you’ve not ran across some of the bugs listed on that page for change and other events than that’s good for you. I have once or twice and have used prototype and later jQuery to deal with them cause I don’t need the additional headache.
If JQuery can deal with a cross browser problem then so can plain JavaScript since that is the language that JQuery is written in. Just that JQuery contains a huge amount of code including cross browser solutions to almost everything whereas a cross browser solution to a specific problem will probably only involve a half dozen statements or so.
Ahh yes, that’s the one where older IE browsers trigger the change event when keyboard navigation is used, on each of the select options that you visit.
If you have time to research and implement a solution to cross browser problems on a case by case basis then good for you. I don’t. Besides, if you point at the google cdn of jQuery odds are the library is already cached on their system anyway.