join all form field in text-area - problem with internet explorer

[jamhead]

Hi there,

i´m quite new to javascript and have a question to my first "project":

I want a documentation utility for work in which i can document hotline-calls.
So i made a form and an output textarea where all form field should display after pressing the button.

http://jsfiddle.net/yQy7a/

while this works on firefox and chrome it wont work on internet explorer. But I need an internet explorer compatible solution...can you point out whats wrong with it ?

I posted it on jsfiddle.....ffel free to "mess arround" with it :

greetings from germany,
Philipp

[xelawho]

you are asking for the value of your selects:

var text4 = document.getElementById("fehlerquelle").value

but the options only have text:

<select size="1" id="fehlerquelle" name="fehlerquelle">
<option>HVT</option>
<option>KVZ</option>
</select>

if you want to use their values values you should give them values (which can be independent from the option text):

<select size="1" id="fehlerquelle" name="fehlerquelle">
<option value="234">HVT</option>
<option value="KVZ">KVZ</option>
</select>

FF and Chrome are a lot more lenient - if they are asked for an option value and there isn't one they will use the option text as a fallback, but this is one of the few instances where I think that IE is doing the right thing

[WolfShade]

Originally Posted by xelawho

...but this is one of the few instances where I think that IE is doing the right thing

For me, those instances are rare, indeed. But I agree with you.. options should be forced to have both value and text.

[Old Pedant]

I'm on the fence on this one.

When an <option> without a value= is selected and the <form> is sent to server-side processing, indeed *ALL* browsers (by specification) then instead send the text of that <option>.

So, from the server-side view of things, in the absence of a value, the text is the value.

So those browsers that do the same thing with the DOM (and it *is* the DOM, not JavaScript, never forget) can be said to simply be emulating normal browser behavior.

Still, it does seem a violation of the tradition of the DOM.

Here's an interesting tidbit: Originally, the *ONLY* browser that allowed you to use formreference.selectName.value was MSIE! Netscape *INSISTED* that you must use form.select[form.select.selectedIndex].value Again, in the original spirit of the DOM, I think Netscape was right. But MSIE prevailed and now all browsers support form.select.value and now we have the ironic situation that all except MSIE have taken the DOM-enhancement one step further.

[xelawho]

I quite like formreference.selectName.value - I don't really mind about violating the spirit of the DOM or whatever. It seems to me that a select having a raw value is in keeping with other form elements (even though I know that it's not actually the select tag that holds the value but the option tag, but then the select tag is *never* going to have a value, so there is no ambiguity for me).

But then I like to live on the edge. I personally look forward to the day when we can do formreference.selectName.text

[Old Pedant]

Oh, don't bet me wrong. I'm not going to go back to writing form.select[form.select.selectedIndex].value !!

I did enough of that back in NS 4.7 days.

And I actually like the idea the form.select.value gives me the same thing that the server-side code will see.

But neither can I fault MSIE for *NOT* doing this.

That's what I meant by "on the fence."

[jamhead]

Great....it works perfectly with the <option value="">
Thank you all for helping