Re: name="" deprecated in XHTML

Sebastian Mendel wrote:
> isn't it common to use
> <input type="radio" name="color" value="red" />
> <input type="radio" name="color" value="blue" />
> or
> <input type="checkbox" name="color[]" value="red" />
> <input type="checkbox" name="color[]" value="blue" />


> so isn't it confusing to say on other elements ID and NAME share same 
> space and name has to be unique?

No, since the spec as Johannes Koch quoted lists which elements this 
rule applies to:

"The id and name attributes share the same name space. This means that 
they cannot both define an anchor with the same name in the same 
document. It is permissible to use both attributes to specify an 
element's unique identifier for the following elements: A, APPLET, FORM, 
FRAME, IFRAME, IMG, and MAP. When both attributes are used on a single 
element, their values must be identical."

INPUT is not in that list.

What is confusing is that there's effectively more than one NAME 
attribute in HTML 4.01:

1. NAME as unique element identifier (A, APPLET, FORM, FRAME, IFRAME, 
IMG, MAP); deprecated in favour of ID. If ID is present on the same 
element, the values must be the same. This attribute has the NAME data 
type ( ).

2. NAME as non-unique (!) parameter key for PARAM. This attribute has 
the CDATA data type ( ).

3. NAME as non-unique (!) key for form control submission for INPUT, 
BUTTON, SELECT, and OBJECT. This attribute has the CDATA data type.

4. NAME for a piece of metadata about the document on the META element. 
I'm not sure what it means if the NAME is repeated (e.g. if you repeat 
NAME="author" have you specified two authors?). This attribute has the 
NAME data type.

getElementsByName appears to apply to all of these:

Note there is, more helpfully perhaps, a getElementsById method. Also 
note that Internet Explorer has a notorious bug where getElementsByName 
may also select elements by ID.

In the case of form controls, values of ID and NAME may differ, for example:

     <legend>Favorite fruit</legend>
     <label for="apple">Apple:</label><input type="radio" id="apple" 
     <label for="banana">Banana</label><input type="radio" id="banana" 
     <label for="orange">Orange</label><input type="radio" id="orange" 

The selected value is submitted to the server with fruit as the key, 
e.g. fruit=orange. But the ID attribute uniquely identifies a particular 
option and associates it with (technically one or more, but usually one) 
LABEL element via the FOR attribute.

> so just thought deprecating name on some elements is the wrong way

Only the use of NAME instead of ID has been deprecated (1 out of 4 above).

(X)HTML doesn't need another generic means of arbitrarily grouping 
elements in a document (that's what CLASS is for) or uniquely 
identifying elements in a document (that's what ID is for). It /may/ 
need further ways to create special sets of elements, much as you have 
sets of params with the same NAME attribute and sets of form controls 
with the same NAME attribute.

Note that using classnames to group elements is in fact extremely common 
practice in everyday web publishing, e.g. for styling or for marking up 
data with microformats:

JavaScript libraries have plugged the gap in the W3C DOM by defining 
getElementsByClassName functions, for example:

Browser implementors are beginning to add such functions to their DOM 
implementations, for example:

The HTML5 draft proposes to standardize it:

Benjamin Hawkes-Lewis

Received on Tuesday, 1 July 2008 06:57:07 UTC