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("n ame") and
maybe do a split(request.f orm("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?

[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.ne t.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.intraproduc ts.com/beta/usenet/samecontrols.as p>

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.infosystem s.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.ne t.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 "conformanc e 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 "conformanc e 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 "conformanc e 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 "conformanc e 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