On the topic of standards... help!

[davidjam]

OK as usual I need help.

First, is it true that the "name" attribute is being phased out of HTML in favour of "id"?

Second question, for future compatability do I have to use (should I use) both "name" and "id" attributes (for instance on an <input type='image'>)?

Finally, is it ok if two elements on a given page have the same value for "name"?

I know these questions are wildly overlapping but... :)

[vaaaska]

I don't think it would hurt if you had name more than once, but you may or may not come up with unusual results. I'd try to stay away from it...

The last part is interesting - does it really mean that? I wonder how many form validation scripts this will kill?

+++++++++++++++++++++

4.10. The elements with 'id' and 'name' attributes

HTML 4 defined the name attribute for the elements a, applet, form, frame, iframe, img, and map. HTML 4 also introduced the id attribute. Both of these attributes are designed to be used as fragment identifiers.

In XML, fragment identifiers are of type ID, and there can only be a single attribute of type ID per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type ID. In order to ensure that XHTML 1.0 documents are well-structured XML documents, XHTML 1.0 documents MUST use the id attribute when defining fragment identifiers on the elements listed above. See the HTML Compatibility Guidelines for information on ensuring such anchors are backward compatible when serving XHTML documents as media type text/html.

Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML.

[goldbug]

Originally posted by vaaaska
The last part is interesting - does it really mean that? I wonder how many form validation scripts this will kill?

... Only the crusty ones :)

If you use both name and id on form elements, you can use proper DOM access to reference your elements (document.getElementById()).

Besides, there should still always be server-side validation. Turning off JS would render any client-side validation useless :)

[Weedpacket]

Here's something that's disturbing: the definition of the ID type:

ID ... tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

No [ or ]. Bye-bye id="field[2]".

[goldbug]

Originally posted by Weedpacket
Here's something that's disturbing: the definition of the ID type:

ID ... tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

No [ or ]. Bye-bye id="field[2]".

This can even be traced back to the SGML definitions/HTML4:
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".")

[vaaaska]

Originally posted by goldbug
... Only the crusty ones :)

If you use both name and id on form elements, you can use proper DOM access to reference your elements (document.getElementById()).

Besides, there should still always be server-side validation. Turning off JS would render any client-side validation useless :)

Ah, brain fart. You have the obvious (and good) answer to that... ;)

[Weedpacket]

Originally posted by goldbug
This can even be traced back to the SGML definitions/HTML4: Yes, but in HTML, name= attributes are of type CDATA not ID; ([ and ] are not valid for name attributes in XHTML either, which defines them as type NMTOKEN).

[laserlight]

No [ or ]. Bye-bye id="field[2]".
We'll have to resort to variable variables then, unless say id="field:2" or something is used as a substitute.
What's the PHP team's actual decision on this, anyway?

[davidjam]

Thanks friendly peoples. I'll just use name and id on all anchor elements and ensure they are unique on the page (although sometimes I have a submit button at the top and the bottom of the page, so that shouldn't be so bad).

Ciao, (I won't click resolved if you guys want to continue the discuss.) :)

[pohopo]

it was always bugs me that I have to use both ID and NAME when they always have the same value. Editors should have some feature where when I type in ID=btn_submit it will automatically add NAME=btn_submit

[Weedpacket]

Originally posted by laserlight
We'll have to resort to variable variables then, unless say id="field:2" or something is used as a substitute.
What's the PHP team's actual decision on this, anyway? If memory serves it exists as a coders' convenience that they use at their own risk. I guess that means $_POST['field'][$index] would have to be written as $_POST['field'.$index], and all field indices have to be specified explicitly (no name="foo[]" or name="foo:" to use laserlight's suggestion - unless PHP's URL parser is rewritten.)

I've read a bit deeper and things are a bit clearer. What was worrying me is that all of the radio buttons in a group are supposed to have the same control name; that won't work if that is specified by an id attribute.

Rereading &sect;4.10 I see that the deprecation of name in favour of id only applies to certain elements: there is no actual mention anywhere of deprecating name in favour of id anywhere else, nor that the control name of a form field is anything other than its name attribute.

But that still doesn't save name="foo[]".

[davidjam]

Posted by weedpacket: I've read a bit deeper and things are a bit clearer. What was worrying me is that all of the radio buttons in a group are supposed to have the same control name; that won't work if that is specified by an id attribute.

Rereading §4.10 I see that the deprecation of name in favour of id only applies to certain elements: there is no actual mention anywhere of deprecating name in favour of id anywhere else, nor that the control name of a form field is anything other than its name attribute.

Which is what it says here (http://www.w3.org/TR/xhtml1/#C_8) .

Finally, note that XHTML 1.0 has deprecated the name attribute of the a, applet, form, frame, iframe, img, and map elements, and it will be removed from XHTML in subsequent versions.

So I guess radios are safe, name="group_name" and id="unique_id"... :bemused: