Repeated field names in a form... Standard behavior?

[Andres Eduardo Hernando]

Hi,
I'm not entirely sure this is the right group to ask this question, but I saw a similar one above, and the group's
charter is not clear enough about it, so, here I go: ;)

What is the standard behavior (if any) when the same name is attached to more than one field in a <form>?

An example (that closely resembles the problem I'm working on) will be (this is a standard radio group without a
default selected option):
<form ...>
<input type="radio" name="Q1" value="1"> opt 1
<input type="radio" name="Q1" value="2"> opt 2
...
<input type="radio" name="Q1" value="n"> Don't know
</form>
The idea is that, in our context "Don't know" and "Don't answer" are very different things, so we want to keep track
of both possibilities. Off course, adding a "Don't Answer" option, selected by default, looks odd as we are forcing the user
to actually give an answer. So "Don't Answer" should be actually that: leaving the question unanswered.

If the user only clicks "submit" we won't get any value for the field "Q1", what is the right behavior as there wasn't
a selected option.

Now, I have discovered that, if I add:

<input type="hidden" name="Q1" value="NoAns">

Right after the <form ...> tag, I get "NoAns" if the user didn't make a choice, and the value associated with the
selected option if she did. This holds for all the browsers I have tried so far (IE6, NN7, NN4, Opera 7). Nevertheless, I'm
not sure if this is the standard behavior (to send back the last value associated with the field name), and I've been unable
to find anything on the web about this type of situations (maybe I didn't look in the right place so a pointer to some source
of information will be a nice answer).
I reckon that it's probably a bad idea to replicate field names in a form (even more if they are of different
'types') but the alternative way through this problem (to add a hidden field with a list of the questions included in the page
and then modifying the associated CGIs to explicitly scan for those questions) will require major surgery in the whole project
something we cannot afford right now... :)

Thanks a lot, and please, *do* let me know if this question is off-topic, I don't want to make your lives miserable.
Andres.

--

[Martin Honnen]

Andres Eduardo Hernando wrote:

What is the standard behavior (if any) when the same name is attached
to more than one field in a <form>?

Check
http://www.w3.org/TR/html4/interact/...html#h-17.13.2
and maybe
http://www.w3.org/TR/html4/interact/forms.html#radio
if you have several <input type="radio" name="radioName" ...> in one
form then these form a group of mutually exclusive buttons of which only
one can be checked at a time and consequentially only one can be
successful and submitted. For other controls if you have several with
the same name then for each sucessful control the name=value pair is
submitted.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Safalra]

Andres Eduardo Hernando <he******@ls02.fas.harvard.edu> wrote in message news:<bu**********@news.fas.harvard.edu>...

What is the standard behavior (if any) when the same name is attached
to more than one field in a <form>?
It appears that all successful controls are meant to be submitted in
the form data set, even if they share the same name.
An example (that closely resembles the problem I'm working on) will be
(this is a standard radio group without a default selected option)
[snip]
RFC 1866 says:

"At all times, exactly one of the radio buttons in a set is checked.
If none of the <INPUT> elements of a set of radio buttons specifies
`CHECKED', then the user agent must check the first radio button of
the set initially."

So one radio button should be selected, although most user agents
don't honour this requirement.
If the user only clicks "submit" we won't get any value for the field "Q1",
what is the right behavior as there wasn't a selected option.

Although there should be according to RFC 1866...

You technique will probably work, although it is relying on
non-standard behaviour.

--- Safalra (Stephen Morley) ---
http://www.safalra.com/hypertext

[Harlan Messinger]

us****@safalra.com (Safalra) wrote:

Andres Eduardo Hernando <he******@ls02.fas.harvard.edu> wrote in message news:<bu**********@news.fas.harvard.edu>...

What is the standard behavior (if any) when the same name is attached
to more than one field in a <form>?
It appears that all successful controls are meant to be submitted in
the form data set, even if they share the same name.

An example (that closely resembles the problem I'm working on) will be
(this is a standard radio group without a default selected option)
[snip]

RFC 1866 says:

"At all times, exactly one of the radio buttons in a set is checked.
If none of the <INPUT> elements of a set of radio buttons specifies
`CHECKED', then the user agent must check the first radio button of
the set initially."

So one radio button should be selected, although most user agents
don't honour this requirement.

If the user only clicks "submit" we won't get any value for the field "Q1",
what is the right behavior as there wasn't a selected option.

Although there should be according to RFC 1866...

Which is the specification for HTML 2, which was superseded four years
ago by HTML 4, which states, "If no radio button in a set sharing the
same control name is initially "on", user agent behavior for choosing
which control is initially "on" is undefined." For example, IE 6
doesn't select any of the choices if none of them has a CHECKED
attribute.

You technique will probably work, although it is relying on
non-standard behaviour.

--- Safalra (Stephen Morley) ---
http://www.safalra.com/hypertext

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Alan J. Flavell]

On Sat, 17 Jan 2004, Safalra wrote:

It appears that all successful controls are meant to be submitted in
the form data set, even if they share the same name.

They're intended to be actually submitted as separate name=value
pairs, indeed, even when some names are the same.

But if your forms evaluation script uses (as certainly /should/ use)
some respected and peer-reviewed module or library - such as CGI.pm in
Perl - to decode the submission parameters, be sure the check its
documentation to see how it will hand these parameters to the program.

As for the detailed issues, what you said wasn't wrong, although the
emphasis on rfc1866 was a bit dated if I might say so ;-)

Might I suggest my page on this topic for another look at the issues,
which aren't all just pedantic detail, some of them do IMHO have real
usability relevance -

http://ppewww.ph.gla.ac.uk/~flavell/www/testradio.html

cheers

[Andres Eduardo Hernando]

Alan J. Flavell <fl*****@ph.gla.ac.uk> wrote:

On Sat, 17 Jan 2004, Safalra wrote:

It appears that all successful controls are meant to be submitted in
the form data set, even if they share the same name.

They're intended to be actually submitted as separate name=value
pairs, indeed, even when some names are the same. But if your forms evaluation script uses (as certainly /should/ use)
some respected and peer-reviewed module or library - such as CGI.pm in
Perl - to decode the submission parameters, be sure the check its
documentation to see how it will hand these parameters to the program.

Just a few words, to summarize what I've learned with this thread and a little of experimentation:

1. All the successful controls *are* actually submitted (at least, in IE6, NN7, and OPERA7 that I have tested).

2. The trick is in the script size. In CGI.pm (what I am using), multivalued parameters contain all the associated values in
an array (that's in the documentation) but in reverse order (that's not in the documentation!, in fact, it should be the
opposite, I quote: "As of version 1.5, the array of parameter names returned will be in the same order as they were submitted
by the browser. Usually this order is the same as the order in which the parameters are defined in the form (however, this
isn't part of the spec, and so isn't guaranteed)."). But, putting a hidden input *before* the radio group works in the
other way:

If I write:
<input type="hidden" name="group1" value="NoAns">
<!- Radio group also named "group1" ->

and then force the parameter to return the whole list of values:

join(';',$query->param("group1"))

Returns:
"NoAns" if the user didn't selected an option in the radio group.
"X; NoAns" if the user selected the option with value X.

Hence, treating the parameter as single-valued returns "NoAns" in the first case and "X" in the second case.

3. Nevertheless, the above behavior relies in the browsers submitting the "name=value" pairs in the same order they are in
the form. Since that's not in the spec, I cannot count with it. So, I'll need to change my scripts.

4. It is advisable to always put a "CHECKED" option in the radio groups as different specs have changed what the browsers
should do when it's absent... If I only could convince my coauthors of this need!... :(
Thanks a lot for all the answers,
Andres.

--

[Andres Eduardo Hernando]

Andres Eduardo Hernando <he******@ls02.fas.harvard.edu> wrote:

opposite, I quote: "As of version 1.5, the array of parameter names returned will be in the same order as they were submitted
by the browser. Usually this order is the same as the order in which the parameters are defined in the form (however, this
isn't part of the spec, and so isn't guaranteed)."). But, putting a hidden input *before* the radio group works in the

Ooops! That's the wrong quote... But I guess you got the idea.

Andres.
--

[Chris Morris]

Andres Eduardo Hernando <he******@ls02.fas.harvard.edu> writes:

The idea is that, in our context "Don't know" and "Don't
answer" are very different things, so we want to keep track of both
possibilities. Off course, adding a "Don't Answer" option, selected
by default, looks odd as we are forcing the user to actually give an
answer. So "Don't Answer" should be actually that: leaving the
question unanswered.

I would say that you definitely *should* include an explicit 'No
answer' as the default state.

On common graphical browsers, if no radio button in a group has
'checked="checked"' then none start selected, and so none get submitted.

If a user then selects one, there is no way for them to go back to
selecting none again _without reloading the page_. Therefore if they
accidentally click 'yes' when they meant 'no answer' they can't easily
change their minds if there's no explicit 'no answer' button.

--
Chris

[Neal]

On 19 Jan 2004 12:54:22 +0000, Chris Morris <c.********@durham.ac.uk>
wrote:

Andres Eduardo Hernando <he******@ls02.fas.harvard.edu> writes:

The idea is that, in our context "Don't know" and "Don't
answer" are very different things, so we want to keep track of both
possibilities. Off course, adding a "Don't Answer" option, selected
by default, looks odd as we are forcing the user to actually give an
answer. So "Don't Answer" should be actually that: leaving the
question unanswered.

I would say that you definitely *should* include an explicit 'No
answer' as the default state.

On common graphical browsers, if no radio button in a group has
'checked="checked"' then none start selected, and so none get submitted.

If a user then selects one, there is no way for them to go back to
selecting none again _without reloading the page_. Therefore if they
accidentally click 'yes' when they meant 'no answer' they can't easily
change their minds if there's no explicit 'no answer' button.

Perhaps - and this is off the cuff - setting a "display: none;" class to
the radio button with the No Answer value set checked...

[Chris Morris]

Neal <ne*****@spamrcn.com> writes:

On 19 Jan 2004 12:54:22 +0000, Chris Morris <c.********@durham.ac.uk>

I would say that you definitely *should* include an explicit 'No
answer' as the default state.

On common graphical browsers, if no radio button in a group has
'checked="checked"' then none start selected, and so none get submitted.

If a user then selects one, there is no way for them to go back to
selecting none again _without reloading the page_. Therefore if they
accidentally click 'yes' when they meant 'no answer' they can't easily
change their minds if there's no explicit 'no answer' button.

Perhaps - and this is off the cuff - setting a "display: none;" class
to the radio button with the No Answer value set checked...

What benefit would that give? I've not tested it, but the most likely
result is that it wouldn't display that radio button, which means that
if you *do* click on another one, you can't click back to 'no answer'
because you can't see it to click on. Might as well not include it at
all and save some bytes in that case (unless your aim is to convince
people to turn off CSS support in their browsers and/or switch
browsers to one without CSS support).

--
Chris

[Jukka K. Korpela]

Harlan Messinger <hm*******************@comcast.net> wrote:

Which is the specification for HTML 2, which was superseded four
years ago by HTML 4, which states, "If no radio button in a set
sharing the same control name is initially "on", user agent
behavior for choosing which control is initially "on" is
undefined."

That's rather obscure, since it means that the HTML 2 type behavior is
allowed, and the behavior of not having any button "on" is allowed
(though a pedant might claim otherwise - "which control" might be seen
as implying that one of them is initially "on"), _and_ a browser might
make the last button "on" by default, or something else. I don't think
they really meant that. They just couldn't decide between two behaviors
and allowed both, without realizing what else became permitted.

But it's a strong reason to always include an initially selected radio
button into each group of radio buttons. It's strange that authors miss
this simple principle.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html