4

I am working on a large web application project and the previous designer favored the use of ids as handles to form fields over name attributes.

I suppose one advantage of this is that the lookup of that field via Javascript is faster through ids.

A big problem I'm now running into, however, is that ids have global scope. I want to refactor a large set of database column names to a more standard naming scheme, which doesn't include any column name prefix to identify which table the column belongs to. This is going to cause problems in those forms that use ids, since the field ids correspond directly to the column names. Column names which were things like "zon_name" and "pro_name" are now going to both be just "name". This will cause non-unique ids in the html.

So, after that long preamble, here's my question...

Before I try to address this scoping issue by changing all the forms to use name attributes instead of ids, are there any other reasons I'm not considering that the original developer may have had for using ids besides the speediness of their lookup?

I know this is a long one so I appreciate anyone who is brave enough to read through and give a good answer. Thanks!

Qantas 94 Heavy
  • 15,750
  • 31
  • 68
  • 83
David Sanders
  • 4,069
  • 1
  • 24
  • 38

3 Answers3

4

Name and id do different things and, while there is some overlap, they are not interchangeable for the most important things they do.

Use name

  • To determine what key will be given to the data when the form is submitted to the server
  • To create radio groups
  • From JS/CSS when you need to reference multiple form controls at once (and when adding a class or using the element type is not more appropriate)

Use id

  • In the for attribute of the control's <label>
  • From JS/CSS when you need to reference a specific input

I suppose one advantage of this is that the lookup of that field via Javascript is faster through ids.

Not significantly (especially when the name is a unique one).

It sounds like the original designer hasn't been following standard conventions and has come up with something highly JavaScript dependant.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • It seems that way to me as well. The only other use, which you and the person below mentioned, is that the for attribute of a label must correspond to an id. But the only real functionality that this seems to set up is that, when you click on a label, it takes you to the corresponding field referenced in "for" by id. This doesn't seem like a particularly useful thing if it means you have to litter your DOM with unique ids for every form field on your page (which could be thousands). – David Sanders Oct 03 '11 at 22:35
  • 3
    That is a **major** benefit if you are trying to click a radio button or checkbox. [Big click targets are better](http://en.wikipedia.org/wiki/Fitts's_law). But it **also** associates the label with the control for the benefit of (for example) screen readers. If you have thousands of inputs then (aside from the page probably being unwieldy anyway) you are probably generating them programatically and adding a counter for an autogenerated prefix isn't hard. – Quentin Oct 03 '11 at 22:37
  • Okay, good to know there are other uses. I think the main problem is that this practice was adopted without a lot of foresight. There are already many duplicates of the same form which uses the same ids to begin with. So the original designer either didn't realize this or didn't realize what the intended use of the id attribute is. Furthermore, the form serializer looks for ids when building post requests to the server. So that practice has become an integral part of how the app works. It's gonna be hard, but I think I have to start cleaning this up. – David Sanders Oct 03 '11 at 22:43
  • @Quentin both reasons to use `id` can be avoided. Wrapping the form element inside `label` and avoid `for`. And use only `id` for the `form` for fast lookup, then use `name` to access the form fields. – Mic Oct 03 '11 at 22:48
  • 1
    @Mic — `for` has better browser support and allows for more flexible layout then putting the control inside the form. – Quentin Oct 04 '11 at 08:18
3

If you're using forms, you should be using <label for="aFormElement"> along with your form elements.

The for attribute on label matches up with an id attribute, not a name attribute.

So, you really need both id (for the label, amongst other things) and name for server-side code.

thirtydot
  • 224,678
  • 48
  • 389
  • 349
  • I think he means the benefits of `name` versus `id` to access the form elements from JavaScript..? – David Thomas Oct 03 '11 at 22:30
  • Actually, I do remember this was another reason he appeared to have done it. The app also uses a lot of label elements and those link to ids. Thanks for reminding me! – David Sanders Oct 03 '11 at 22:32
  • You can avoid ID's, if you wrap the form element inside the label: `` – Mic Oct 03 '11 at 22:35
1

For the speed to find your elements, you can set just id on the form.
Then for the fields use name to read them like:

var form = document.getElementById('theForm'),
    productName = form.productName.value;
Mic
  • 24,812
  • 9
  • 57
  • 70