HTML / XHTML Forms

1. The NAME Attribute
2. The ID Attribute
3. How NAME Deprecation Affects Forms
4. How to use ID in Forms
5. Tests
6. Examples
7. Notes

The NAME Attribute

The name attribute in HTML was used on many elements to provide a identification token for reference by the browser and by scripts. As documented in the W3 XHTML Specifications the HTML name attribute is deprecated for the elements a, applet, form, frame, iframe, img, and map for XHTML 1. The id attribute is now used in place of the name attribute as a unique identifying token in XHTML documents.

The W3 HTML Compatibility Guidelines noted that the change from name to id could affect the intended functionality of a web page. For example, the name attribute was often used in conjunction with a to create anchors on a web page. These anchors could then be used as links to jump from section to section in a page as shown in example 1. For valid and up-to-date XHTML (or forward-thinking HTML) the code should use id in place of name as shown in example 2. The expected behavior relies on the web browser, however, and some browsers at the time of the specification were not yet programmed to jump to anchors defined by id attributes alone. Thus, the the W3 HTML Compatibility Guidelines append the note that "identical values may be supplied for both of these attributes to ensure maximum forward and backward compatibility" as shown in example 3.

The ID Attribute

The id attribute can be used on nearly every HTML element, although it is a well-known standard documented by the W3 that the id attribute must be unique (appear only once) within a given document. The id attribute is used to apply CSS styles, to find and manipulate elements with Javascript, and to provide a unique reference to an element, which is useful for a variety of purposes. In an XHTML form, the id attribute can give the form element a unique name. Both HTML and XHTML forms can associate a field label with the appropriate input by matching the for attribute of the label to the id attribute of the input.

How NAME Deprecation Affects Forms

You may have noticed that the ubiquitous input element, the tag used to create form fields, is not mentioned in the list of elements for which name is deprecated. The input element's cousin, the select element, is not on the list either (although their parent element, the form tag, is among those affected). Simply speaking, the deprecation of name in favor of id does not affect the use of name for the fields of XHTML forms; name is essential to forms.

• The name element is the one used to pass the values of form fields. If a field is not named using name, the field and its value will not be passed for server-side processing. (See example 4.)
• Some form fields need to contain a matching name in order to function as expected^[1]. An input with the type "radio" is expected to present an array of options from which only one option can be chosen (otherwise you would use "checkbox"). This relationship between one radio and another is indicated by matching name attributes. (See example 5.)

How to use ID in Forms

The fact that name is not deprecated for the input element or select element is important to an observed "undesirable behavior" in Firefox 3.0.5 (take a look at the tests). Although coders know that the id attribute must be unique within a given HTML document, it is easy^[2] to overlook this fact and inadvertantly combine incomplete knowledge regarding the deprecation of name and a habit based on the HTML compatibility guidelines to write forms with incorrect code (see example 6). Blindly adhering to the idea that name and id should match can and will result in duplicated id attributes within a form. Since the name attribute is not deprecated for form fields, id should be used normally. Obviously if it will not result in id being duplicated, name and id can match, but id, as the standards state, should never be duplicated within a single page (see example 7).

Tests

Examples

Example 1

1:<a name="anchor1"></a>
2:<a href="#anchor1">Link to anchor 1</a>
				

1. Creates an anchor named "anchor1" in the position of the document flow at which the code appears.
   • The anchor itself is not visible unless it is added to a visible element, such as a heading.
   • Some older browsers were not programmed to jump to an anchor unless the anchor was added to an a element.
2. Creates a link to the anchor named "anchor1" in the position of the document flow at which the code appears.
   • Once the link is clicked, the browser focuses on the position of the document at which the anchor (from line 1) was inserted.

Example 2

1:<a id="anchor2" />
2:<a href="#anchor2">Link to anchor 2</a>
				

1. Creates an anchor named "anchor2" in the position of the document flow at which the code appears.
   • The anchor itself is not visible unless it is added to a visible element, such as a heading.
2. Creates a link to the anchor named "anchor1" in the position of the document flow at which the code appears.
   • Once the link is clicked, the browser focuses on the position of the document at which the anchor (from line 1) was inserted.

Example 3

1:<a name="anchor3" id="anchor3" />
2:<a href="#anchor3">Link to anchor 3</a>
				

1. Creates an anchor named "anchor1" in the position of the document flow at which the code appears.
   • The anchor itself is not visible unless it is added to a visible element, such as a heading.
2. Creates a link to the anchor named "anchor1" in the position of the document flow at which the code appears.
   • Once the link is clicked, the browser focuses on the position of the document at which the anchor (from line 1) was inserted.

Example 4

1:<input type="text" id="fullname" value="Full Name" />
2:<input type="text" name="fullname" id="fullname"  value="Full Name" />
				

1. Creates a text input field without the name attribute.
   • Under all known circumstances this field (as part of a hypothetical form) and its value would not be submitted with the form.
2. Creates a text input field with the name attribute.
   • This field (as part of a hypothetical form) would be submitted (as part of a hypothetical form) with its name and value.

Example 5

1:<input type="radio" name="question1"  value="Yes" />
2:<input type="radio" name="question1" value="No" />
				

1. Creates an radio input (grouped with other radio inputs named "question1") with the value "Yes".
2. Creates an radio input (grouped with other radio inputs named "question1") with the value "No".

Example 6

1:<input type="radio" name="question2" id="question2" value="Yes" />
2:<input type="radio" name="question2" id="question2" value="No" />
				

1. Creates an radio input (grouped with other radio inputs named "question2") with the value "Yes".
   • Note that the id is identical to the name. If you expect your radios to function normally and also adhere to the "matching" rule, id is duplicated.
2. Creates an radio input (grouped with other radio inputs named "question2") with the value "No".
   • Note that the id is identical to the name. If you expect your radios to function normally and also adhere to the "matching" rule, id is duplicated.

Example 7

1:<input type="radio" name="question3" id="question3_yes" value="Yes" />
2:<input type="radio" name="question3" id="question3_no" value="No" />
				

1. Creates an radio input (grouped with other radio inputs named "question3") with the value "Yes".
   • Note that the id does not match name. This is the appropriate practice which keeps id from being duplicated and allows a label to be associated with the input.
2. Creates an radio input (grouped with other radio inputs named "question3") with the value "No".
   • Note that the id does not match name. This is the appropriate practice which keeps id from being duplicated and allows a label to be associated with the input.

Notes

Note 1

Forms are one of the areas in which the best practice of "separation of content, behavior, and style" is especially difficult. Form elements and their attributes explicitly state many things about the fields' appearance and expected behavior.

Note 2

In retrospect, it seems obvious that violating the standard regarding repetition of an id within a document (just because it is a form and the compatibility guidelines state that name and id should match) is wrong-headed. Personally, I assumed (mistake) that if name was deprecated for one element, it was (or would eventually be) deprecated for all elements. All the information was in front of me, I simply failed to add 2 and 2 correctly. However, I've noticed this in others' source code as well, so it seems useful to document this information.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License .