NAME and ID attributes are identical.???

[lkrubner]

I'm hoping I understand this bit correctly:
http://www.jibbering.com/faq/faq_notes/form_access.html
When writing HTML that conforms to a DTD that allows FORM elements to
have NAME attributes it is possible to also give the FORM element an ID
attribute that corresponds with its NAME attribute (so long as the ID
is unique on the page). The form will appear as a member of the
document.forms collection under a property name that corresponds with
the value of the NAME and ID attributes (as they are identical).
Does that mean that if I went through all my forms tonight and changed
every NAME attribute to ID, pretty much nothing would happen? My
Javascript would work the same, as if nothing had changed? And when
those forms were submitted to the server, and interacted with PHP, PHP
would find the form inputs, it doesn't matter if those inputs have ID
or NAME???

 

[David Dorward]

Does that mean that if I went through all my forms tonight and changed
every NAME attribute to ID, pretty much nothing would happen?

No, only name is important for submitting form data. The id is for client
side stuff only.

 

[Ivo]

I'm hoping I understand this bit correctly:
http://www.jibbering.com/faq/faq_notes/form_access.html
<snip>
Does that mean that if I went through all my forms tonight and changed
every NAME attribute to ID, pretty much nothing would happen? My
Javascript would work the same, as if nothing had changed? And when
those forms were submitted to the server, and interacted with PHP, PHP
would find the form inputs, it doesn't matter if those inputs have ID
or NAME???

That 's right, yes it would, and no it does matter.
The form itself will be happy to be id'ed instead of name'd, but the form
elements, ie. the input, select, textarea or other such objects inside the
form should still have a name if their name-value pairs are to submitted to
the server in the usual way.

 

[VK]

NAME is a legacy attribute. It was introduced in forms at those prehistoric
times then no one thought about DOM, DHTML, XML etc.
Later 3W decided to keep the "name" as a valid primary naming attribute for:

forms
form elements
images
links
anchors

What allowed to keep gigs of existing code of being valid without major
rewriting (and without changes in form submission mechanics).
So with these 5 elements you should follow the old "NAMEing" tradition. With
any other elements you should use the modern "IDfication".

Also important to notice, that by the current 3W standards NAMEs and IDs are
sharing the same name space.
Two consequences of it:

[1] You must use either NAME or ID, but not the both.
<form name="myFormName" id="myFormID"> is equally pointless and error prone
as
var myVar="value1"; var myVar="value2";
or
var myVar, myVar = "value";

[2] ID is ruled by the common variable naming rules. NAME is of CDATA type
(briefly meaning any imaginable combination of characters). But as they are
sharing the same name space, browser has to serve the "biggest possible
request", which is CDATA in this case. As a result, naming rules for IDs
existing only on the paper. In the reality you can use any CDATA for IDs:
'{!!!!-My Greetings to 3W---}'
will work as well as
'myCorrectID'
(I hope you'll not jump too heavily on this opportunity though.)

 

[VK]

To make it easier to accept:
think of plural exceptions in English:

parent - parents
father - fathers
mother - mothers
child - children

Is 'children' an exeption? Surely! But try to tell me that the correct
modern form should be 'childs'.

 

[Michael Winter]

[snip]

forms
form elements
images
links
anchors
[snip]

So with these 5 elements you should follow the old "NAMEing" tradition.

No. With form controls that are to be submitted, use the name attribute.
With all other elements, including form controls that are not to be
submitted, use the id attribute. The only exception to this rule is if you
want to (or need to) support NN4 (or similar) which doesn't include id
support.

[snip]

Also important to notice, that by the current 3W standards

^^
W3C

[snip]

[1] You must use either NAME or ID, but not the both.

That's also incorrect. You can use both but, with the exception of form
controls, the values must be the same.

[snip]

[2] ID is ruled by the common variable naming rules. NAME is of CDATA
type (briefly meaning any imaginable combination of characters). But as
they are sharing the same name space,

They only share the same name space when they are used for anchor names.

browser has to serve the "biggest possible request", which is CDATA in
this case. As a result, naming rules for IDs existing only on the paper.
In the reality you can use any CDATA for IDs:
'{!!!!-My Greetings to 3W---}'
will work as well as
'myCorrectID'
(I hope you'll not jump too heavily on this opportunity though.)

Don't do it at all! Just because you *can* do things doesn't mean you
should. Taking that approach will produce invalid HTML and you might be
surprised if a user agent decides to ignore that attribute, or modify the
value (not that I suspect any do...).

The legal characters that compose the ID data type are perfectly
reasonable, and there is no reason to make a document invalid just to
include some other character. Don't forget that ids have several purposes,
not just limited to scripting.

Mike

 

[VK]

Also important to notice, that by the current 3W standards

^^
W3C

W3 recently makes me lexdyslic... eh... dyslexic

[1] You must use either NAME or ID, but not the both.

That's also incorrect. You can use both but, with the exception of form
controls, the values must be the same.

var a = 1;
var b = 2; var b = 2; // you can do this too, but why?
var c = 3;

Don't do it at all!

Yes, I meant the same!

 

[Michael Winter]

[snip]

You can use both [name and id] but, with the exception of form
controls, the values must be the same.

var a = 1;
var b = 2; var b = 2; // you can do this too, but why?
var c = 3;

As I said, id is the attribute you should be using, but some ancient
browsers require the name attribute to be present. So always use id, but
if you need backward-compatibility, add name.

[Use non-ID characters in an id attribute]

Yes, I meant the same!

Sorry, but it didn't read that way.

Mike

 

[VK]

As I said, id is the attribute you should be using, but some ancient
browsers require the name attribute to be present. So always use id, but
if you need backward-compatibility, add name.

OKed, but reluctantly.
I think it's a 3W... oops... W3C fault.
They should stop to be fussy-pussy for a second, and just make form (and
form elements) an official exception from IDfication (child - children,
why - because of the history issues).
I don't like the situations then "this is right, and this is right too, and
this may be right too sometimes, etc."

[Use non-ID characters in an id attribute]

Yes, I meant the same!

Sorry, but it didn't read that way.

(I hope you'll not jump too heavily on this opportunity though.) )
[missed in OP]

All the world needs is smile(y).

 

[David Dorward]

They should stop to be fussy-pussy for a second, and just make form (and
form elements) an official exception from IDfication

I disagree. Keeping bad design around just because it is there now isn't a
good idea.

(child - children, why - because of the history issues).

The English language grows organically. (X)HTML is _designed_ and has
_versions_. You can't compare them.

I don't like the situations then "this is right, and this is right too,
and this may be right too sometimes, etc."

Its more like: "This is not right. This is right. You may want to use both
during the transitional phase while user agents catch up."