As I mentioned in a previous post, I wish there was some standard or convention or consensus on what values to attach to the name attribute of common input elements.
I thought it would be a good idea to open up a thread to devote to this very thing, so feel free to add your comments below.
First, just so everyone is clear, here is an example of the code to which I refer:
<input type="text" name="foo" />
The attribute I am referencing is name="foo". We will be discussing the value for that attribute (in this case, what replaces “foo”).
Here are some suggestions.
| Field purpose | Name value |
|---|---|
| A person’s full name | Name |
| First name | FirstName |
| Last name | LastName |
| Street address | Address |
| City | City |
| Province | Province |
| State | State |
| Postal code | PostalCode |
| Zip code | ZipCode |
| Country | Country |
| Phone number | Phone |
| Fax number | Fax |
| Search term | q |
What do you think? Do you have any other suggestions? What are some other common fields?
If you know persons who might be interested in this idea, please let them know about his thread so they can contribute to the discussion.
Kim, I have found the following sites in my travels:
http://www.google.com/support/toolbar/bin/answer.py?answer=18183&topic=117
http://www.ietf.org/rfc/rfc3106.txt
Both of these links indicate some uniformity amongst developers but there is a missing open format that can guide people through development.
There is a need for a standard, framework or guidline for the name attribute that doesn’t necessariy relate to ecommerce.
Best wishes on your hunt.
Jay
Kim:
In my development work I use similar form field names as you suggest. Perhaps the one exception is ZipCode. I usually just use Zip.
However, I always name the field Postal Code since the site I work on has heavy international traffic. While some daring “international” (cough, Canadian) visitors might put their postal code in the zip field, many do not.
So usually the text next to the field is Postal Code, but the name of the field is zip.
All the others you suggest are the ones I normally use. We had a terribly managed web development company set up our main site years ago, and though I’ve tried to clean up much of their disasterous coding, some of it remains.
I must admit that I don’t really understand the concern because, other than looking at the source code, the visitors won’t see the naming and probably wouldn’t care: theoretically, you could use anything as long as your application is properly configured to accomodate the field names (debugging issues aside). However, the label text is important and has an impact on usability.
Can you explain why this is important?
The biggest benefit for users is auto-complete features in browsers, as I mentioned in my previous post.
If I am filling out a form and it asks me for my email, I should be able to use the email address stored in my autocomplete. Unfortunately this works by the name of the field.
So while it may appear to be the same field to the user (each asking for an email address), it may not work seamlessly because the names are different (mail, email, e-mail, session_key, etc) in each form.
Ahh! Thanks!
This scheme is consistent with what I use. I agree there is going to be a trade off between what’s semantics and what’s commonly used (i.e. “Search” vs. “q”).
The whole point of a standard would be to make it easier for browsers to recognize the form elements, so what’s common would be the preference. In cases where there’s no consensus semantic should rule.
Part of me says that subjective field marking makes the web unique and beautiful and all sorts of other sunshiney nice fun stuff. Uniqueness in naming conventions makes for fun discoveries sometimes.
But then, I think about who the people who are straying too far from standardized naming conventions are: myspacers and geocities-types and the sorts of people who design with Netscape Communicator and still tell their friends they are designers.
So, yes. I empathize with your plight, and your naming convention scheme seems quite alright :D