What happens if several text fields have the same name?

[wolfing1]

Like, I know if several checkboxes have the same name, I can get the
ones that were checked after submit with a request.form("name") and
maybe do a split(request.form("name"),",") to cycle through them.
I tried the same thing with textfields (input type=text), but doesn't
seem to work the same.
Do they behave differently?

[Martin Honnen]

wo******@yahoo.com wrote:

Like, I know if several checkboxes have the same name, I can get the
ones that were checked after submit with a request.form("name") and
maybe do a split(request.form("name"),",") to cycle through them.
I tried the same thing with textfields (input type=text), but doesn't
seem to work the same.
Do they behave differently?

When form data is submitted name=value pairs are submitted so on the
server you can't tell from the submitted data whether it comes from
input type="text" or input type="checkbox" controls.
As for processing the submitted form data on the server that depends on
the framework/language used on the server, if you use ASP/VBScript then
you can use a for each loop e.g.

For Each Value In Request.Form("inputName")
Response.Write Value & "<br>"
Next

If it is not ASP you are using then ask in an appropriate group on the
server side framework/language you are using. For further ASP questions
you could use the ASP groups on nsnews.microsoft.com.
--

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

[Tim]

On 24 May 2005 09:00:50 -0700,
wo******@yahoo.com posted:

Like, I know if several checkboxes have the same name, I can get the
ones that were checked after submit with a request.form("name") and
maybe do a split(request.form("name"),",") to cycle through them.
I tried the same thing with textfields (input type=text), but doesn't
seem to work the same.
Do they behave differently?

This sounds like a JavaScript issue, not HTML (how you're going about using
forms), but you don't really say what you're doing and how, and it sounds
like you might be using forms incorrectly.

For things like radio or select form elements, where you're using
multiple-choices for any one particular answer (whether allowing multiple
answers out of the choices - checkboxes, or only one answer out of all of
the choices - radio buttons), all the *associated* input elements have to
use the same name. And conversely, any disassociated input elements must
use different names.

e.g.

<fieldset>
<legend>Gender</legend>
<label><input type="radio" name="sex" value="female"> female</label><br>
<label><input type="radio" name="sex" value="male"> male</label><br>
<label><input type="radio" name="sex" value="other"> other</label>
</fieldset>

<fieldset>
<legend>Likes these pets</legend>
<label><input type="checkbox" name="pets" value="cats"> cats</label><br>
<label><input type="checkbox" name="pets" value="dogs"> dogs</label><br>
<label><input type="checkbox" name="pets" value="fish"> fish</label>
</fieldset>

But, for things like text input elements, they're all individual,
stand-alone, data entry gadgets, and each must use their own names.

e.g.

<fieldset>
<legend>Your names</legend>
<label>First name: <input type="text" name="firstname"></label><br>
<label>Surname: <input type="text" name="lastname"></label>
</fieldset>

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Harlan Messinger]

Tim wrote:

On 24 May 2005 09:00:50 -0700,
wo******@yahoo.com posted:

Like, I know if several checkboxes have the same name, I can get the
ones that were checked after submit with a request.form("name") and
maybe do a split(request.form("name"),",") to cycle through them.
I tried the same thing with textfields (input type=text), but doesn't
seem to work the same.
Do they behave differently?

This sounds like a JavaScript issue, not HTML (how you're going about using
forms), but you don't really say what you're doing and how, and it sounds
like you might be using forms incorrectly.

For things like radio or select form elements, where you're using
multiple-choices for any one particular answer (whether allowing multiple
answers out of the choices - checkboxes, or only one answer out of all of
the choices - radio buttons), all the *associated* input elements have to
use the same name. And conversely, any disassociated input elements must
use different names.

e.g.

<fieldset>
<legend>Gender</legend>
<label><input type="radio" name="sex" value="female"> female</label><br>
<label><input type="radio" name="sex" value="male"> male</label><br>
<label><input type="radio" name="sex" value="other"> other</label>
</fieldset>

<fieldset>
<legend>Likes these pets</legend>
<label><input type="checkbox" name="pets" value="cats"> cats</label><br>
<label><input type="checkbox" name="pets" value="dogs"> dogs</label><br>
<label><input type="checkbox" name="pets" value="fish"> fish</label>
</fieldset>

But, for things like text input elements, they're all individual,
stand-alone, data entry gadgets, and each must use their own names.

Reference? I don't think they have to, and it works just fine. In ASP,
you get an array of values, whether it's with SELECT options,
checkboxes, or text fields.

[Adrienne]

Gazing into my crystal ball I observed wo******@yahoo.com writing in
news:11**********************@g44g2000cwa.googlegr oups.com:

Like, I know if several checkboxes have the same name, I can get the
ones that were checked after submit with a request.form("name") and
maybe do a split(request.form("name"),",") to cycle through them.
I tried the same thing with textfields (input type=text), but doesn't
seem to work the same.
Do they behave differently?

That should still work. I am assuming you are using ASP. What is the
value of request.form("name") if you do response.write "Name: " &
request.form("name")?

This is really a server side issue, and should be directed to a server
side group. If you are using ASP, I would suggest you take this to
microsoft.public.inetserver.asp.general .

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

[Jim Moe]

wo******@yahoo.com wrote:

Like, I know if several checkboxes have the same name, I can get the
ones that were checked after submit with a request.form("name") and
maybe do a split(request.form("name"),",") to cycle through them.
I tried the same thing with textfields (input type=text), but doesn't
seem to work the same.

My experience is that you get the contents of the text box that is last
defined with a given name. None of the others show up.

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Alan J. Flavell]

On Tue, 24 May 2005, Jim Moe wrote:

My experience is that you get the contents of the text box that is last
defined with a given name. None of the others show up.

Then you have an incomplete server-side implementation, but this
is off-topic for the HTML authoring group.

The HTML spec specifies the format of the submitted dataset (as sent
from the client to the server). That part is on-topic here.

The interface between the server and your server-side process depends
a bit on what it is (CGI, ASP, PHP, whatever), but the most portable
interface is defined by the CGI, which is now an informational RFC
http://www.ietf.org/rfc/rfc3875 , and would be on-topic in
comp.infosystems.www.authoring.cgi (beware the automoderation bot).

Any complete implementation should give you access to multiple values
from "form control(s)"[1] with the same name.

At this point in the procedure the server neither knows nor cares what
kind of form control that was. They could easily be of different
kinds (e.g a pull-down list and a type-in text box of the same name)
if you wanted. Or not, as you choose.

have fun

[1] using that term as it's used in the html4 spec.

[Zif]

Harlan Messinger wrote:

Tim wrote:

[...]

But, for things like text input elements, they're all individual,
stand-alone, data entry gadgets, and each must use their own names.

Reference? I don't think they have to, and it works just fine. In ASP,
you get an array of values, whether it's with SELECT options,
checkboxes, or text fields.

Regardless of what happens on the server, what is served to the client
should be consistent with the DOCTYPE supplied with the document.

Presuming that HTML is being served, an input name must be unique
within a form unless it is a checkbox or a radio button. From memory,
IE allows the creation of a collection using identical names on any
element, however that is not consistent with the W3C HTML 4
Specification.

<URL:http://www.w3.org/TR/html4/interact/forms.html#adef-name-INPUT>

<URL:http://www.w3.org/TR/html4/interact/forms.html#input-control-types>

Most browsers will cope with invalid HTML, however that does not make
its use valid or reasonable.

If the intention is to group a bunch of elements visually, then
FIELDSET is the logical choice:

<URL:http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET>

If the intention is to create a group of elements that can be accessed
purely by script, 'DIV' or 'SPAN' may do the job. As a last resort,
the 'class' attribute may fit the bill.
--
Zif

[RobG]

Alan J. Flavell wrote:

On Tue, 24 May 2005, Jim Moe wrote:

My experience is that you get the contents of the text box that is last
defined with a given name. None of the others show up.

Then you have an incomplete server-side implementation, but this
is off-topic for the HTML authoring group.

I disagree with that. If the OP is serving invalid HTML that has INPUT
text elements with duplicate names, browser behaviour is not defined
and you can't be certain of what will be returned to the server.

In that context, it is very much a HTML issue.

The HTML spec specifies the format of the submitted dataset (as sent
from the client to the server). That part is on-topic here.
And what the server sends to the client is irrelevant? The server needs
to start out by sending valid HTML (or whatever is specified in the
DOCTYPE), otherwise you are just guessing at what the UA may do.

[...] At this point in the procedure the server neither knows nor cares what
kind of form control that was. They could easily be of different
kinds (e.g a pull-down list and a type-in text box of the same name)
if you wanted. Or not, as you choose.
If that was to occur in the same form, then that is invalid HTML and UA
behaviour may not be what you expect.
have fun

[1] using that term as it's used in the html4 spec.

--
Rob

[Alan J. Flavell]

On Wed, 25 May 2005, Zif wrote:

Presuming that HTML is being served, an input name must be unique
within a form unless it is a checkbox or a radio button.
Citation, please? I don't find any such text in the HTML4 spec.
From memory,
There's no extra charge for checking before posting.
IE allows the creation of a collection using identical names on any
element,
As do the WWW-compatible browsers that I tried, indeed.
however that is not consistent with the W3C HTML 4 Specification.
I'll reserve judgment on that till we've found the relevant text in
the HTML4 spec. The use of the same name on radio buttons and
checkboxes has a defined effect as laid down in the HTML4 spec, yes,
but I find nothing which prohibits the use of the same name on mixed
control types. I certainly don't find the text which you're claiming
to have remembered.
<URL:http://www.w3.org/TR/html4/interact/forms.html#adef-name-INPUT>

<URL:http://www.w3.org/TR/html4/interact/forms.html#input-control-types>
Not there either...
Most browsers will cope with invalid HTML, however that does not
make its use valid

Which validator and which DTD did you use, and where's your
demonstration document? Mine (using name=, not id=) passed without
errors. Trying to use the same id=, even on two radio buttons, or two
checkboxes, *will* fail HTML validation, in spite of your claim, but
that's a general HTML rule, it isn't specific to forms.

And don't forget select multiple: that too can submit several values
with the same name, although in this case you'd normally have just one
"control" with the name in question.

thanks

[Alan J. Flavell]

On Wed, 25 May 2005, RobG wrote:

Alan J. Flavell wrote:

On Tue, 24 May 2005, Jim Moe wrote:

My experience is that you get the contents of the text box that is last
defined with a given name. None of the others show up.
Then you have an incomplete server-side implementation, but this is
off-topic for the HTML authoring group.

I disagree with that. If the OP is serving invalid HTML

I still see no evidence that the OP needs to serve "invalid" HTML to
achieve this.
text elements with duplicate names, browser behaviour is not defined
and you can't be certain of what will be returned to the server.

The behaviour is defined in
http://www.w3.org/TR/html4/interact/...#form-data-set

If two "successful controls" have the same name, then the "form data
set" submitted to the server will contain two name=value pairs with
the same name.

That is a specification of the form data set as submitted from the
browser/client to the server. It's not a specification of a software
interface between a server and a server-side process - you'd need to
look elsewhere for that, as I already said.

The HTML spec specifies the format of the submitted dataset (as
sent from the client to the server). That part is on-topic here.

And what the server sends to the client is irrelevant?

Congratulations, you're arguing against something that I never said.

At this point in the procedure the server neither knows nor cares
what kind of form control that was. They could easily be of
different kinds (e.g a pull-down list and a type-in text box of
the same name) if you wanted. Or not, as you choose.

If that was to occur in the same form, then that is invalid HTML

Where's your test document to demonstrate this claimed invalidity?

[Adrienne]

Gazing into my crystal ball I observed RobG <rg***@iinet.net.auau> writing
in news:%c*****************@news.optus.net.au:

I disagree with that. If the OP is serving invalid HTML that has INPUT
text elements with duplicate names, browser behaviour is not defined
and you can't be certain of what will be returned to the server.

In that context, it is very much a HTML issue.

Here is an example of a form which uses the same name:
<http://www.intraproducts.com/beta/usenet/samecontrols.asp>

It is perfectly valid client side as well as server side.

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

[RobG]

Alan J. Flavell wrote:

On Wed, 25 May 2005, RobG wrote:

Alan J. Flavell wrote: [...]

The HTML spec specifies the format of the submitted dataset (as
sent from the client to the server). That part is on-topic here.
And what the server sends to the client is irrelevant?

Congratulations, you're arguing against something that I never said.

You appeared to be dismissing the fact that what the server sends to
the client is also important.

The OP's view was that duplicate names on checkboxes or text inputs
should give similar results (name/value pairs with the same name).

Apparently that's not what occurred. Martin Honnen's reply is likely
sufficient explanation.

At this point in the procedure the server neither knows nor cares
what kind of form control that was. They could easily be of
different kinds (e.g a pull-down list and a type-in text box of
the same name) if you wanted. Or not, as you choose.

If that was to occur in the same form, then that is invalid HTML

Where's your test document to demonstrate this claimed invalidity?

The HTML 4 spec does not explicitly say you can't have form elements
with identical names. It does explicitly say how to deal with
checkboxes and radio buttons that share the same name, I understood
that to mean other form controls should not have identical names.

It appears that form elements with duplicate names validate quite
happily with the W3C validator. While that may not always be
sufficient proof of validity, I'm happy to accept it in this case when
there is no evidence to the contrary.

Score: me 0, AJF 1
--
Rob

[Alan J. Flavell]

On Thu, 26 May 2005, RobG wrote:

Alan J. Flavell wrote:

> The HTML spec specifies the format of the submitted dataset (as sent
> from the client to the server). That part is on-topic here.

And what the server sends to the client is irrelevant?

Congratulations, you're arguing against something that I never said.

You appeared to be dismissing the fact that what the server sends to
the client is also important.

Sure it's important, but it doesn't seem to be the problem here: what
the server is sending to the client is dependent on what the
server-side process has decoded from its interface to the server, and
that's evidently incomplete here. I'd still be recommending looking
at *that* part of the procedure (in its proper place,
comp.infosystems.www.authoring.cgi if the interface in question is the
CGI). By the time the server-side process is composing HTML to send
to the client, it's too late.

cheers

[Jukka K. Korpela]

RobG <rg***@iinet.net.auau> wrote:

It appears that form elements with duplicate names validate quite
happily with the W3C validator.
It's no surprise, given the fact that the 'name' attribute is declared
with CDATA content. We need not know more, as regards to validity.
While that may not always be
sufficient proof of validity,

You seem to be toying with some private definition for "validity";
maybe you meant "conformance to the HTML specification".

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

[RobG]

Jukka K. Korpela wrote:
[...]

While that may not always be
sufficient proof of validity,

You seem to be toying with some private definition for "validity";

Not at all.
maybe you meant "conformance to the HTML specification".

I don't understand your confusion, you seem to have understood the
meaning well enough - what other interpretation was inferred?

In this forum I would expect that the adjective "valid" and its
derivatives would be interpreted as conformance with the relevant W3C
HTML specification. I don't think that's a private notion.

The W3C 'validator' page proclaims:

"The W3C Markup Validation Service is a free service that checks Web
documents in formats like HTML and XHTML for conformance to W3C
Recommendations and other standards."

which I think tends to support that view - i.e. that 'valid' equates to
conformance to a specification.

The fact that a file is sent to the W3C markup validation service and a
response is returned that proclaims:

"This Page Is Valid HTML 4.01 Strict!"

does not, of itself, provide a 100% guarantee that it is, though I
would expect that in the vast majority of cases it does. Hence my
caution in declaring the response from the validator service as
absolute proof of validity - others are free to make up their own mind
on that point.

For me, when combined with advice from Alan Flavell and further reading
of the W3C HTML specification, it is quite sufficient and I said so.
--
Rob

[Alan J. Flavell]

On Tue, 31 May 2005, RobG wrote:

Jukka K. Korpela wrote:
[...]

While that may not always be
sufficient proof of validity,
You seem to be toying with some private definition for "validity";

Not at all.

"Valid" in an SGML or XML context is a technical term with a precise
meaning, as Jukka already knows very well, but you apparently do not.

maybe you meant "conformance to the HTML specification".

I don't understand your confusion,

(that's because you are confused... nothing to get excited about,
but not a good basis for an argument)
In this forum I would expect that the adjective "valid" and its
derivatives would be interpreted as conformance with the relevant
W3C HTML specification.
But that's not correct. Conformance with the text of the HTML
specification has quite a number of additional constraints which are
not part of being "valid" in the technical sense meant here.
Validity is determined by the applicable DTD, and only by the DTD,
nothing more.
The fact that a file is sent to the W3C markup validation service and a
response is returned that proclaims:

"This Page Is Valid HTML 4.01 Strict!"

Indeed, it says it's "valid" (and names the DTD which applied); it
doesn't say anything about whether it's conformant to additional
constraints in the text of the specification. For most everyday
purposes, it may be enough to know that it's valid; but if you're
going to set out to argue with specialists, then you need to know
exactly what it means to be "valid". And that's where you've caught
yourself out here, I'm afraid. Jukka can be a bit terse, but he's
correct on this point.

[RobG]

Alan J. Flavell wrote:

On Tue, 31 May 2005, RobG wrote:

Jukka K. Korpela wrote:
[...]

While that may not always be
sufficient proof of validity,

You seem to be toying with some private definition for "validity";
Not at all.

"Valid" in an SGML or XML context is a technical term with a precise
meaning, as Jukka already knows very well, but you apparently do not.

maybe you meant "conformance to the HTML specification".

I don't understand your confusion,

(that's because you are confused... nothing to get excited about,
but not a good basis for an argument)

No, I'm not confused. Wrong or misguided perhaps, but the fact that I
have a different understanding of something does not make me confused.

In this forum I would expect that the adjective "valid" and its
derivatives would be interpreted as conformance with the relevant
W3C HTML specification.

But that's not correct. Conformance with the text of the HTML
specification has quite a number of additional constraints which are
not part of being "valid" in the technical sense meant here.
Validity is determined by the applicable DTD, and only by the DTD,
nothing more.

[...]

Thank you for the explanation.

I had an inkling along those lines but clearly missed the subtlety of
Jukka's reference.

I now understand the difference, as understood here, between
conformance to the specification and "valid HTML". I think that
understanding is quite different to what may be assumed by a ordinary
person, but when in Rome...

Jukka could have explained his viewpoint in perhaps a few words, but
chose to be obscure. Perhaps that has resulted in a far better
explanation for all, so the general good has been served.
--
Rob