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

Unexpected clearing of radio button

P: n/a
I have a page containing:

<FORM NAME=radios>
<INPUT TYPE=RADIO NAME=RAD VALUE=1 ID=RAD1>
<LABEL FOR=RAD1>Check One</LABEL>
<A onClick="document.radios.RAD[0].checked=false; return false">Uncheck
One</A><BR>
<INPUT TYPE=RADIO NAME=RAD VALUE=2 ID=RAD2>
<LABEL FOR=RAD2>Check Two</LABEL><BR>
<DIV STYLE="display:none"><INPUT TYPE=RADIO NAME=RAD ID=RAD3></DIV>
<A onClick="document.radios.RAD[2].checked=true; return false">Select
Hidden</A><BR>
<BUTTON onclick="if (document.radios.RAD1.checked) {alert('Check one is
checked')} else {alert('Check one is not checked')}">Try Me!</BUTTON>
</FORM>

You can see this at the bottom of http://swiftys.org.uk/test.html

If you check one of the two visible buttons then click the "Try Me!"
button, then you get the expected alert, but the radio button is also
unchecked. Can anyone tell me why the radio button gets unchecked when
all I have done is refer to its checked attribute?

I know that adding "return false" to the end of the JavaScript on the
button stops the button getting unchecked, but I don't understand why it
should be necessary.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Sep 23 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Sep 23, 10:00*am, Steve Swift <Steve.J.Sw...@gmail.comwrote:
I have a page containing:

<FORM NAME=radios>
<INPUT TYPE=RADIO NAME=RAD VALUE=1 ID=RAD1>
<LABEL FOR=RAD1>Check One</LABEL>
<A onClick="document.radios.RAD[0].checked=false; return false">Uncheck
One</A><BR>
<INPUT TYPE=RADIO NAME=RAD VALUE=2 ID=RAD2>
<LABEL FOR=RAD2>Check Two</LABEL><BR>
<DIV STYLE="display:none"><INPUT TYPE=RADIO NAME=RAD ID=RAD3></DIV>
<A onClick="document.radios.RAD[2].checked=true; return false">Select
Hidden</A><BR>
<BUTTON onclick="if (document.radios.RAD1.checked) {alert('Check one is
checked')} else {alert('Check one is not checked')}">Try Me!</BUTTON>
</FORM>

You can see this at the bottom ofhttp://swiftys.org.uk/test.html

If you check one of the two visible buttons then click the "Try Me!"
button, then you get the expected alert, but the radio button is also
unchecked. Can anyone tell me why the radio button gets unchecked when
all I have done is refer to its checked attribute?

I know that adding "return false" to the end of the JavaScript on the
button stops the button getting unchecked, but I don't understand why it
should be necessary.
Your form gets reloaded... Because without "return false;" you submit
the form...
>
--
Steve Swifthttp://www.swiftys.org.uk/swifty.htmlhttp://www.ringers.org.uk
Sep 23 '08 #2

P: n/a
On Sep 23, 10:00 am, Steve Swift wrote:
I have a page containing:
<snip>
<BUTTON onclick="if (document.radios.RAD1.checked) {
alert('Check one is checked')} else {alert('Check one
is not checked')}">Try Me!</BUTTON>
</FORM>
<snip>
If you check one of the two visible buttons then click the
"Try Me!" button, then you get the expected alert, but the
radio button is also unchecked. Can anyone tell me why the
radio button gets unchecked when all I have done is refer
to its checked attribute?

I know that adding "return false" to the end of the JavaScript
on the button stops the button getting unchecked, but I don't
understand why it should be necessary.
The official default type for the BUTTON element is "submit", and when
you click a submit button any containing from is submitted. In this
case the effect is to re-load the page (as the FORM element does not
have the (officially required) ACTION attribute and in its absence the
URL of the current page (usually) becomes the ACTION.

However, IE gets this wrong and defaults the type of its BUTTON
elements to "button", so if you use a BUTTON element always provide it
with an explicit TYPE attribute if you want consistent (ish) behaviour
across browsers, and always use the TYPE you want ('button' if you
have no intention of having it submit the form, and 'submit' if you
want the form submitted).

Also, returning false from onclick handlers for submit buttons (of the
various sorts) is usually not a good idea; instead have the onsubmit
handler for the FORM element do any cancelling of submissions that may
be required.

Sep 23 '08 #3

P: n/a
Steve Swift wrote:
<FORM NAME=radios>
<INPUT TYPE=RADIO NAME=RAD VALUE=1 ID=RAD1>
<LABEL FOR=RAD1>Check One</LABEL>
<A onClick="document.radios.RAD[0].checked=false; return false">Uncheck
One</A><BR>
<INPUT TYPE=RADIO NAME=RAD VALUE=2 ID=RAD2>
<LABEL FOR=RAD2>Check Two</LABEL><BR>
<DIV STYLE="display:none"><INPUT TYPE=RADIO NAME=RAD ID=RAD3></DIV>
<A onClick="document.radios.RAD[2].checked=true; return false">Select
Hidden</A><BR>
<BUTTON onclick="if (document.radios.RAD1.checked) {alert('Check one is
checked')} else {alert('Check one is not checked')}">Try Me!</BUTTON>
</FORM>

You can see this at the bottom of http://swiftys.org.uk/test.html

If you check one of the two visible buttons then click the "Try Me!"
button, then you get the expected alert, but the radio button is also
unchecked. Can anyone tell me why the radio button gets unchecked when
all I have done is refer to its checked attribute?

I know that adding "return false" to the end of the JavaScript on the
button stops the button getting unchecked, but I don't understand why it
should be necessary.
When I found the cause it was sort of obvious. The button was submitting
the form, which was defaulting to a GET at the current URL, thus
emulating a reload, thus resetting the radio buttons to unchecked.

What was less obvious was that the same behaviour occurred even when the
<BUTTONwas moved below the </FORMputting it outside of the form, but
with the same result.

This is almost certainly invalid HTML, so what happens is undefined. It
was still pretty surprising.
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Sep 23 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.