View Full Version : XHTML 1.1 Is the name attribute obsolete?

11-21-2003, 03:49 PM
I'm new to PHP, but I want to learn with the right habits. The W3 says the name attribute is depricated a depricated part of HTML 4.0 and only the ID tag fits the new XHTML 1.1 standards. But in all the forms with PHP actions and POST methods I've seen (tutorials and page sources alike), the name tag is still used. The variable array $_POST["name"] is used to read from the names of the form fields. I want to learn the right way if there is a alternative solution. How would I read a form by its ID instead of name?

11-21-2003, 03:51 PM
the best way i found is:

<input type="text" name="textfield" id="textfield" />

that way its keeping to the standards by using id, and will work in browsers that dont support the ID parameter.

11-21-2003, 04:38 PM
Originally posted by missing-score
the best way i found is:

<input type="text" name="textfield" id="textfield" />

that way its keeping to the standards by using id, and will work in browsers that dont support the ID parameter.

So does this mean that in PHP name and ID mean the same thing? Will $_POST["ID"] work all the same? I would imagine that would cause problems distinguishing between name and ID unless only one exists. Or maybe it varies on PHP version.

11-21-2003, 04:42 PM
I've not had any problems using the name attribute in xhtml 1.1. PHP only gets the fields info from $_POST['name'] not id as far as I know

11-21-2003, 04:48 PM
Maybe the name attribute will be used only for forms in the future. It seems to be the only option right now and it does work. But for javascript, there's many more options when using ID instead. Names are just more fitting for forms though.

11-21-2003, 04:57 PM
Oh yeah, the name tag is only for form fields and frames as far as I know. For divs, etc you need the id tag

11-21-2003, 09:36 PM
Name and ID are not the same.

In XHTML 1.0 Strict and XHTML 1.1 name is deprecated in favour of ID for most elements, but nonetheless name and ID are not the same - ID must always be unique, where name can form a collection.

And that's one reason why name is still available for forms - because form elements sometimes need to make a collection by name (radio controls, for eg). The other reasons is that unnamed elements do not submit their data - an element with no name will not be in the $_GET or $_POST array, and you can't go $_POST["element_id"]

You don't usually have to include an ID as well, but it matters for things like <label> - the FOR attribute of <label> identifies an element by ID, not by NAME. It's also forward-compatible, because then you can identify those elements in the DOM as well as through the forms collection. It generally make sense, just to ease confusion, to give an element the same ID as its NAME, but obviously it's not always possible, because ID must be unique.

Personally, I still use the forms collection for form processing. And I'll continue to do so for the foreseeable, because that's what it's for.


IMO forms are too important to leave to browser support - legacy browsers need forms to work, even if they don't need style or scripts.

11-22-2003, 12:35 AM
i've started using IDs instead of names in my form tags, and running it through a validatation JS using onsubmit="return validate(this)" as the reference for my form. Works nicely.

I also use document.getElementById('form_id') instead of document.form_name as this sticks to the XHTML doctype.

11-22-2003, 10:01 AM
I've treated forms as just buttons to hold onClick events in javascript in the past. And then using for loops and other such equations to gather the values by index document.forms[0][i] and such. I never learned the real use of forms in an HTML tutorial because you'd raelly have to learn something server side to understand it. So now it's making full sense. I had no idea what hidden forms were for until now.:p